Advancing minimum Java version from 11 to 17

Development
1

We’ve hit a problem which I believe will necessitate advancing the minimum Java version from 11 to 17:

In 3.7.24, we updated the version of the swingx library on which we depend. The version of swingx we had used up to 3.7.24, which was 1.6.5, tries to load the java.applet.Applet class (even though we don’t use it), but java.applet.Applet was removed in Java 26. This caused an error for users using Java 26 during bug reporting which prevented bug reports from being sent. Upgrading to swingx 2.1 fixed this problem.

I hadn’t noticed when we upgraded to swingx 2.1 that Java 17 is the minimum requirement for it. Now users running Java 11 are having failures like the one here.

I had been hoping that we could leave Java 11 as the minimum requirement for Vassal 3 until we retire it, but it appears that won’t be possible. The OpenJDK build we use (Temurin) has an End of Life date for Java 11 in October of next year. I am guessing that nearly all of our users still using Java 11 are on Linux and only using Java 11 because it’s still their system default.

Does anyone have any insight into this? Am I correct that nearly all of our users still using Java 11 are on Linux and only using Java 11 because it’s still their system default? How can we smooth the path for those people if we raise the minimum Java version to 17 on the next release?

VASSAL 3.7.24 Does Not Run on Ubuntu Linux
2

Most Linux distributions, unless someone is using a really old version, are at least on Java 21.

I users of Debian-derived or RedHat-derived distributions use the provided .deb and .rpm packages, then everything will happen automatically.

For users that download the tar-ball, it should be stipulated in the installation instructions that they need at least Java17. Note, if users have followed the current guidelines on installing a JRE there should mostly be no problem as they are directed to use the distribution packages, and those are all new enough - except in very old releases of the distributions.

Perhaps the -release flag should be set to -release 17 in the builds?

Yours,
Christian

3

I’ve opened a PR for it: Compile for Java 17. by uckelman · Pull Request #14886 · vassalengine/vassal · GitHub

4

vassal.spec.in doesn’t require a minimum version of Java that I can see. How do we do that?

debian/control lists default-jre as a dependency, but presumably that won’t be correct on systems where the default is older than 17. What do we do there?

The PR Is failing on the debian build: Compile for Java 17 · vassalengine/vassal@6c483a8 · GitHub

Do you know of anything which should be in the PR which isn’t yet?

5

There is apparently no simple way to require a minimum Java version with RPMs—not due to a lack of expressivity in the RPM spec languge, but due to the inconsistent use of metapackage names in RPMs providing JREs.

The obvious thing, java >= 17, doesn’t work because so many JRE RPMs provide java unversioned. All the ones I can query do provide java-X, though, so we can do this:

Requires:	java-17 OR java-18 OR java-19 OR java-20 OR java-21 OR java-22 OR java-23 OR java-24 OR java-25 OR java-26 OR java-27

I hate that, but it’s probably good enough. By the time Java 28 is out, we’ll have done a new release, so the fact that it’s not open-ended won’t matter.

6

I think I have a working PR now. @cholmcc Please have a look.

1 Like
7

I made a few comments on the PR. Some of the changes are unfortunately incorrect.

Yours,
Christian

8

I don’t see any comments on PR 14886. Are you sure you submitted the comments?

9

I had made individual comments - which you should have been able to see, but not a collected review. Now done, so you should see a single review.

Yours,
Christian