Java 21 migration

[taylor.smock]

Followup of #17858

Timelines:

• 2023-10-03: Build installer packages with Java 21 => r18848
• 2023-12-21: OpenWebStart supports Java 21
• 2024-03-20: Update Debian/Ubuntu launch script to prefer 21 over 17 and 11 => r19018
• ????-??-??: Debian switches to Java 21 (​experimental is on Java 21 as of 2024-03-20)
• ????-??-??: Ubuntu LTS switches to Java 21
• ????-??-??: Enough users have switched to Java 21 that we can move codebase to Java 21 after transition phase
• ????-??-??: Start warning users that their version of Java will be unsupported during startup (1 month), then stop allowing JOSM to finish startup (1-3 months), then start compiling JOSM with Java 21 features.

[taylor.smock]

@stoecker: What is the process for changing the Java versions for the mac/windows installers? I assume it is something that needs to be changed server side.

[stoecker]

No. These are all done on GitHub, so it's in the SVN GitHub stuff.

[skyper]

Replying to taylor.smock:

• ????-??-??: Update Debian/Ubuntu launch script to prefer 21 over 17 and 11.
• ????-??-??: Debian switches to Java 21 (​experimental is on Java 21 as of 2024-03-20)

I do not think it is feasible to wait for default-jre to switch to 21 but ​openjdk-21-jre should be available in the stable release (currently bookworm) at least as backport. At the moment it is available in the testing release (trixie) so I would say it is fine to already prefer 21 over 17 and 11.

[taylor.smock]

Replying to stoecker:

No. These are all done on GitHub, so it's in the SVN GitHub stuff.

Sorry, I should have been more explicit. I've already got ​GitHub building the ​Java ​21 ​installers.

I suspect that the installers (e.g. download/windows/josm-setup.msi) are copied via something like curl -L https://github.com/JOSM/josm/releases/download/${VERSION}-tested/JOSM-Windows-java17-${VERSION}.msi, but I could be wrong.

Replying to skyper:

I do not think it is feasible to wait for default-jre to switch to 21 [...]

Fair enough. But I suspect that it might be awhile before we can switch to Java 21 in the build source (at least if we want to make life easier for the Debian packagers).

[stoecker]

Ah yes. There are two variables winjava and macjava ;-)

Should I change them to 21?

[taylor.smock]

I think so; I haven't seen any Java 21 specific bugs in the past few months, so I think it is safe to change the installers to Java 21.

[stoecker]

Done.

[skyper]

Replying to taylor.smock:

Replying to skyper:

I do not think it is feasible to wait for default-jre to switch to 21 [...]

Fair enough. But I suspect that it might be awhile before we can switch to Java 21 in the build source (at least if we want to make life easier for the Debian packagers).

Well building with Java 21 is different and I, too, suspect that it will take years until we get there. Current stable release still has Java 11 as default and next release will have Java 17. Though, the Debian packages are build for all releases and as openjdk-21-jre is available in testing and unstable (trixie and sid) I would prefer 21 over 17 and 11 in the launch script, now.

[taylor.smock]

In 19018/josm:

See #17858/#23564: Update Java versions in Linux start scripts

Additions:

• Java 19-20 (EOL, added for completeness)
• Java 21 (preferred LTS)
• Java 22 (latest Java version)
• Java 23 (next Java version)

Removals:

• Java 8, 9, and 10: We no longer support Java < 11.

[sebastic]

Replying to skyper:

Replying to taylor.smock:

Replying to skyper:

I do not think it is feasible to wait for default-jre to switch to 21 [...]

Fair enough. But I suspect that it might be awhile before we can switch to Java 21 in the build source (at least if we want to make life easier for the Debian packagers).

Well building with Java 21 is different and I, too, suspect that it will take years until we get there. Current stable release still has Java 11 as default and next release will have Java 17. Though, the Debian packages are build for all releases and as openjdk-21-jre is available in testing and unstable (trixie and sid) I would prefer 21 over 17 and 11 in the launch script, now.

Just don't require Java 21 (i.e. don't fail to build with JDK 17) before it's available in (backports) for the current Debian stable release to keep backports of the josm package possible. While openjdk-21 is available in testing, it has not been backported.

You can prefer openjdk-21 over openjdk-17 by adding it to the launcher accordingly:

        # LTS versions in decreased order
        JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-21-openjdk/bin/java /usr/lib/jvm/java-21-openjdk-$ARCH/bin/java"
        JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-17-openjdk/bin/java /usr/lib/jvm/java-17-openjdk-$ARCH/bin/java"
        JAVA_CMDS="${JAVA_CMDS} /usr/lib/jvm/java-11-openjdk/bin/java /usr/lib/jvm/java-11-openjdk-$ARCH/bin/java"

https://josm.openstreetmap.de/browser/josm/trunk/native/linux/tested/usr/bin/josm#L23

Note that /etc/alternatives/java will be used as long as its included in JAVA_CMDS.

[taylor.smock]

@sebastic: I suspect you were writing your reply when I committed r19018 which added Java 21 LTS to the start script order.

Anyway, I suspect moving to Java 21 is a year or two out. I mostly opened this ticket so we can track progress of various blockers. We'll probably move to "requiring"[1] Java 17 (#17858) a few months after Ubuntu 24.04 is released and start allowing Java 11 features in the codebase, and then start using Java 17 features a few months after that.

[1] In this case, "requiring" means we stop JOSM startup if the Java version is < Java 17. This is supposed to (hopefully) give users a bit of time to click on the "Update Java" button before they start getting UnsupportedClassVersionError exceptions.

[jBeata]

Any progress on this, or expected time until all the plugins should support Java 21?

[stoecker]

Replying to jBeata:

Any progress on this, or expected time until all the plugins should support Java 21?

Hmm, that's a strange question.

All Plugins should support Java 21 as soon as possible, like any new Java version.

Requiring a new Java version is another topic. Plugins already now can require a higher java version when they want. JOSM will migrate to a newer version when there is a need to do so and the user numbers of older versions drop enough.

[taylor.smock]

Replying to jBeata:

Any progress on this, or expected time until all the plugins should support Java 21?

I'll split this into two questions:

1. Should my plugin run on Java 21+?
   1. Yes. We aim to run on every version over and including Java 11. So plugins should also aim to run on those versions (including the recently released Java 24).
2. Should my plugin only run on Java 21+?
   1. Up to you. Just keep in mind that there may be an influx of the plugin users on older Java versions running into issues -- we (JOSM core) should probably do some basic checks ("is the current Java version newer than or equal to the required plugin version?"), which (IIRC) we don't currently do.

Realistically, the primary blocker for incrementing Java versions is Linux users; most other users (at this point) use one of the installers, which currently package Java 21. I don't know what the latest numbers are, but I would expect that 90% of users on recent JOSM versions are running Java 21.