Java Runtime requirement change proposed from Java 6 to Java 8.

fronobulax

fronobulax

Developer
Staff member
Discussion started towards the end of this thread.

KoLmafia requires users to have Java 6 or better installed on their machines. There is interest, on the part of the devs and others, in changing that requirement to Java 8. The only reason NOT to do that is if there is a substantial and/or loud and/or vocal portion of the user base who cannot upgrade and we know about them.

This is your chance. If you can't upgrade then let us know and (optionally) why.

If you want to upgrade you may chime in but you're probably just preachin' to the choir :-)

The final decision is veracity's given her position of first among equals among the devs. Changes related to that decision will be rolled out no earlier than February 24, 2020 at 12:01 AM GMT. (That date is arbitrary and may change but if there is no deadline this could drag out for a very long time).
 
There's no Kolmafia MOTD function, where you can direct people to this thread, is there?
 
If we do this I might look at using Nashorn to allow scripts written in JavaScript as well as ASH. Maybe. Although it's deprecated in later Java versions.
 
gausie said:
If we do this I might look at using Nashorn to allow scripts written in JavaScript as well as ASH. Maybe. Although it's deprecated in later Java versions.
Click to expand...

Your call. I will ask two questions. What could be done with Nashorn that could not be done with a relay script? What are the mechanics of integration? I ask the latter since the current build process doesn't support grabbing a versioned jar file from elsewhere. So we will have to maintain source (see svn or Spellcast for code we eventually had to modify rather than import a jar) or someone will have to drop a jar file in \lib and keep it up to date. I worked on commercial software that integrated BeanShell and it had an oversized impact on building and build environments.
 
I looked at Nashorn and it has ant tasks, but it's in a Mercurial repo, so that's one more thing needed if it's going to be built.

I'm wondering if it would be useful to convert the ant build.xml to gradle and use the dependency management there to take care of getting the right version of Nashorn. It's been a long time since I was a professional ANT guy, but I worked on the build.xml for kolmafia about 10 years ago (back in the ANT 1.8 transition). If we converted to gradle, we could use a repo-based source for 3rd party stuff (or set up a repo if it's kolmafia 3rd party stuff).
 
We used Maven and I liked it enough that I played with making KoLmafia a Maven build but at the end of the day, I wasn't clever enough to obtain a result that was demonstrably easier than remaining with ant. Part of the issue was what was "published" for a user who was used to getting one file and then running. Bottom line though is if any of the devs who are doing the heavy lifting want (or don't want) a change in the build system, their preference trumps mine
 
yep.

If it helps with dependency management and it give the powers that be an easier time of it, It might be worth doing. Builds for me are currently a one-click affair so it's a question of newer tools for new capabilities, if there's interest.
 
fronobulax said:
The final decision is veracity's given her position of first among equals among the devs. Changes related to that decision will be rolled out no earlier than February 24, 2020 at 12:01 AM GMT. (That date is arbitrary and may change but if there is no deadline this could drag out for a very long time).
Click to expand...

Let's go for it. Veracity?
 
Yeah. I'll try it out by simply changing the source and target versions from 1.6 to 1.8.
I'm not inclined to switch from ant to Maven or Gradle at the moment.
 
Revision 19778 moves from 1.6 to 1.8

I also stuck in a little test for try-with-resources and my new Checkpoint object. That's a 1.7 feature.
 
That transition was seamless for me. Updated, compiled and ran just like normal. Thanks. I'm running openjdk 11.0.6 2020-01-14.
 
Crowther said:
That transition was seamless for me. Updated, compiled and ran just like normal. Thanks. I'm running openjdk 11.0.6 2020-01-14.
Click to expand...

Similarly ditto although my Java comes from Oracle.

I did upgrade to 13.0.2 and there is a compile error because of ambiguity. I think it is trivial because the routine with the error is never actually called and I think my fix won't break for earlier Javas but I am sitting on it for the moment rather than check it in and be proved wrong :-)
 
fronobulax said:
Similarly ditto although my Java comes from Oracle.

I did upgrade to 13.0.2 and there is a compile error because of ambiguity. I think it is trivial because the routine with the error is never actually called and I think my fix won't break for earlier Javas but I am sitting on it for the moment rather than check it in and be proved wrong :-)
Click to expand...

That sounds like the swingx ErrorReport.java error I mentioned here. The listed code compiles and runs with 13.0.2 (OpenJDK), but if it's not used, it's not clear if it's identical. I don't think swingx is going to get updated at this date...
 
MCroft said:
That sounds like the swingx ErrorReport.java error I mentioned here. The listed code compiles and runs with 13.0.2 (OpenJDK), but if it's not used, it's not clear if it's identical. I don't think swingx is going to get updated at this date...
Click to expand...

That explains my sense of dejaVu. getErrorListeners which is the offending routine is not used according to my IDE. It is in third party code that we just grabbed the source and imported. Key things is that KolMafia is maintaining the code ourselves, for better or worse.
 
You must log in or register to reply here.
Back
Top