Feature - Implemented Add a "Pending change in required Java version" nag message.

fronobulax

fronobulax

Developer
Staff member
This was buried in https://kolmafia.us/threads/proposal-require-java-21.30044/#post-175968 and is currently a PR https://github.com/kolmafia/kolmafia/pull/2686

The proposal is to display a message telling users that they are not running Java 24 which they will soon need.

I don't like nag messages as a user. As a professional developer we once tried to warn users of impending changes to our app that would require an upgrade that was under the user's control, not ours. The attempt failed miserably. The users who read the message swamped the Help Desk with questions - What does this mean? What am I supposed to do? How do I do it? I can't upgrade. I want my money back. and so on. So the warning didn't make things easier for the users and did get the Help Desk mad. So if other folks like the idea I'd at least like to understand why. (Hence this thread).

Not directly related but I seem to have missed the discussion and schedule concerning jumping directly from Java 21 to Java 24 (which isn't even expected for General Availability until March 18, 2025) and why? Can someone remind me? (And another thread would be fine, if not actually preferred).

Thanks.
 
Having gone through a few Java updates I have found the typical behavior is that we put in some warning, it gets ignored, then when the update finally happens, a bunch of users will flock to the forums or the discord and report that suddenly Mafia stopped working.

I don't know what is possible, but if we could add a popup the launches in place of the Mafia login window when the Java version is not sufficient, that might be the best way to address the issues.
Currently, when Mafia tries to run with an older Java version is fails silently, which is the worst kind of failure.
 
For previous updates, we have followed the LTS versions: 8 to 11 to 17 to 21. That's why the next is 24.

Irrat has filed this as a draft because it's not something we can do yet. The PR adds a message to the login screen because people were missing the message we added after you login.

It may be more confusing, but people seem to have a pretty good ability to install a new version of Java. I think it's worth trying.
 
ckb said:
I don't know what is possible, but if we could add a popup the launches in place of the Mafia login window when the Java version is not sufficient, that might be the best way to address the issues.
Currently, when Mafia tries to run with an older Java version is fails silently, which is the worst kind of failure.
Click to expand...
I'm pretty sure that Java itself is failing to start, rather than allowing an incompatible version of KoLmafia to start up and do anything at all - such as showing a popup.
 
Veracity said:
I'm pretty sure that Java itself is failing to start, rather than allowing an incompatible version of KoLmafia to start up and do anything at all - such as showing a popup.
Click to expand...
Correct.

What we could do is add an extra transition stage where we require a new version in code, before actually updating the build version. So something like:
  1. One month before we cut over to the new version, start displaying a warning.
  2. One week before we cut over to the new version, detect on startup that the version of Java is too old, display a popup stating as such, then exit.
  3. Cut over to the new version.
This doesn't address the situation where someone comes back after a long hiatus and finds that the latest version of Mafia doesn't run.

Another point that we've discussed in the past (at least among us devs) is that our distribution model is quite atypical in today's world. I don't know of any other software where you're expected to manually download a new version on a near-daily basis. If instead we had some sort of standardized launcher (and/or auto-updater) which could launch with, say, Java 6 or whatever, it could alert if it detected that the JVM in use was too old.
 
Philosophically, why do we specify a minimum version? Is it because we KNOW maifa won't work or because we don't want to deal with it in case it doesn't work. We can use one version for code features and compliance and another for bytecode and JVM. Does that change the nature of the solution?

There are many things we can try but they will never work if mafia won't even start.

The commercial solution used on projects I worked on was to just bundle the app with the JVM. That solved more installation problems for us than it created. That might not be comparable - we had a large user base that did not control their machines but needed permission and an Administrator to upgrade Java and we had a smaller userbase that needed to keep multiple of versions of Java installed - but we did support Windows, MaxOS and most flavors of *nix. Maybe that is worth exploring since it is in many ways a more sustainable approach?
 
fronobulax said:
Not directly related but I seem to have missed the discussion and schedule concerning jumping directly from Java 21 to Java 24 (which isn't even expected for General Availability until March 18, 2025) and why? Can someone remind me? (And another thread would be fine, if not actually preferred).
Click to expand...
I don't think there have been discussions of the specific schedule for the next upgrade, so much as discussions about pain points from the last upgrade and how we can avoid them next time.

Ryo_Sangnoir said:
For previous updates, we have followed the LTS versions: 8 to 11 to 17 to 21. That's why the next is 24.
Click to expand...
Actually, the next LTS is Java 25, which isn't coming out until late September. I'd be quite surprised if we adopt it before October (if at all this year).

fronobulax said:
Philosophically, why do we specify a minimum version? Is it because we KNOW maifa won't work or because we don't want to deal with it in case it doesn't work. We can use one version for code features and compliance and another for bytecode and JVM. Does that change the nature of the solution?
Click to expand...
We've discussed this before, and Java cross-compilation is not useful in the form that it's available. You cannot target a lower version than the source code.
 
fronobulax said:
The commercial solution used on projects I worked on was to just bundle the app with the JVM. That solved more installation problems for us than it created.
Click to expand...
One downside I see is that we have much more frequent updates than most commercial products, and we unfortunately require users to download a new revision to get the latest changes. Bundling the subset of the JVM that we use increases the download size by around 3x (compare the .dmg size to the .jar). For users with constrained download bandwidth, this represents a significant increase.

Further, we don't have anyone with the time, motivation, expertise, etc to work on the user experience for targeting Windows. We had previously tried using jpackage to do exactly this, but that ended up causing more confusion and problems than it was worth.
 
heeheehee said:
One downside I see is that we have much more frequent updates than most commercial products, and we unfortunately require users to download a new revision to get the latest changes. Bundling the subset of the JVM that we use increases the download size by around 3x (compare the .dmg size to the .jar). For users with constrained download bandwidth, this represents a significant increase.

Further, we don't have anyone with the time, motivation, expertise, etc to work on the user experience for targeting Windows. We had previously tried using jpackage to do exactly this, but that ended up causing more confusion and problems than it was worth.
Click to expand...

More frequent updates where the new version has obvious benefits for the user who updates is a fair point. I should remember the philosophical change from deliberately not supporting Crimbo during Crimbo to making multiple updates a day to support Crimbo content as it was spaded.

Keeping download size small is "nice to have" and not essential as far as I am concerned but that's an opinion and not a reason to do things one way or another.

I did some work to fix the Windows installer because it always did a new install and not just update the jar. That effort failed because the tools did not run on my system as advertised and no one else had the expertise or motivation to assist so bundling is probably not going to happen unless there is more enthusiasm.

So, because I really don't like the nag and what benefit it claims to provide :-) I wonder about implementing a KoLmafia multitool?

The multitool would be downloaded to the directory containing the mafia jar. It would determine the Java version and compare it to the version required for the latest mafia jar file. Version 0.1 could be as simple as running "java --version" from a command line and referring the user to online instructions that tell the user what actions to take (or not) based upon the result. The multi-tool should be written using native capabilities of the operating system and should not use Java. Future improvements would include versioning the multitool so it could check and possibly download a newer version of itself, and optionally downloading the latest version of mafia.

If the multitool were the only shiny object within my field of vision I could probably have Windows 10 and Debian 10 versions of 0.1 that sometimes worked implemented and tested in a couple of hours. The "sometimes" acknowledges that there are various was of setting up the environment to launch mafia and my initial implementation would probably only work when the version of Java that mafia used was provided by the PATH in the environment.

What is needed would be: someone to implement and maintain the MacOS; someone to assist in determining the requirements make sense; and someone to figure out the best way to host on GitHub and set that up for me.
 
fronobulax said:
I should remember the philosophical change from deliberately not supporting Crimbo during Crimbo to making multiple updates a day to support Crimbo content as it was spaded.
Click to expand...
IIRC, there were two contributing factors back in the day:
  • More strongly held opinions about not spoiling limited-time content
  • Concerns about contributing disproportionately to Crimbo-time server load.
In recent years, we have gotten the go-ahead from KoL that they're now appropriately provisioned such that they're not worried about server load.

fronobulax said:
So, because I really don't like the nag and what benefit it claims to provide :-) I wonder about implementing a KoLmafia multitool?
Click to expand...
No high-level objections here -- I think you've described a potential implementation of the launcher that I proposed. Something that checks the current set of requirements for running Mafia, then downloads the latest revision (or if the user wants to avoid a bug, some manually-specified revision) and launches it.

fronobulax said:
The multi-tool should be written using native capabilities of the operating system and should not use Java. Future improvements would include versioning the multitool so it could check and possibly download a newer version of itself, and optionally downloading the latest version of mafia.
Click to expand...
Why not just target an old, broadly-compatible version of Java, e.g. Java 8? We don't need it to be fancy, and it'd be a small enough piece of our codebase that we probably wouldn't be too sad about missing out on newer features.

I would rather not deal with cross-compiling for multiple OSes and architectures, and that's assuming that we even have the option to do so (presumably we'd want to use some cross-platform GUI toolkit).
 
heeheehee said:
Why not just target an old, broadly-compatible version of Java, e.g. Java 8? We don't need it to be fancy, and it'd be a small enough piece of our codebase that we probably wouldn't be too sad about missing out on newer features.

I would rather not deal with cross-compiling for multiple OSes and architectures, and that's assuming that we even have the option to do so (presumably we'd want to use some cross-platform GUI toolkit).
Click to expand...

Good point. I lived in a world where it was not safe to assume any version of Java was installed so I was restricting myself to things that were almost certainly guaranteed to be present. Maybe I don't need to do that.

(Tangent. I had a colleague who took great joy in preaching the superiority of EMACS over vi. She was frustrated because she could not convince me. One day she had to go to a client site to install an operating system on bare metal and then install and configure our server. I received a panicked phone call from her because she needed a text editor to configure our server and the OS media only had vi. I calmed her down, walked her through the edits using vi and she left a working server behind on site. We had a good laugh and she eventually stopped getting annoyed when I would smile and ask if she had EMACS media as she left for an installation).

I wasn't thinking of cross compiling or anything like that but separate, OS specific implementations of a common feature set. I was aiming for simplicity - think of a shell script, nothing but text in the display, keyboard only and the occasional prompt for a Y or N. But I definitely need a different thing for each OS and different expertise. The biggest downside I can think of right now is I would have to remember my IDE so I can have separate project settings with different source code target levels.
 
The largest reason I'm aware of to upgrade java is the GOAWAY http status issue, which I believe is properly handled by the library in 24.

As for displaying a pop-up warning and refusing to start in older versions of Java, a thought occurs to me that maybe it could be possible to have a sub Gradle module that compiles against Java 8, and works as the jar main class. Does the version checks then calls the actual main class via say, reflection.
 
The original PR has been committed after some modification.

Some of the issues raised or alternatives discussed have been implemented in the soon to be renamed multitool which is discussed elsewhere.
 
You must log in or register to reply here.
Back
Top