Vassal/Java compatibility table

The argument has been made by the Vassal developers that, soon or later, one should commit full time to the newer versions of the Vassal engine (3.3+) because older versions of Vassal (like 3.2.17) might not work anymore with newer versions of Java.

I wonder if people could help me build a cross reference table to match the latest (and earliest?) version of Java still known to work with the various versions of the Vassal engine and operating systems.

My little contribution is to say that a module like Talon, which was developed under Vassal 3.2.17 and has issues with Vassal 3.3+, is working fine under 3.2.17 and my current JRE, which is 1.8.0_271. But I have been afraid of updating Java ever since. I am using Windows 10 64-bit (possibly not up to date with the very latest patches and service packs).

Can I safely update Java to the latest JRE (which should be 1.8.0_281)? Or does anyone know which is the latest Java version and build under which Vassal 3.2.17 fully works? Same questions for 3.3.3 and 3.4.13. Thanks.

                            OS               Java min            Java max
Vassal 3.2.17      Windows 10 - 64 bit           ?            8 update 171 (?)
Vassal 3.3.3       Windows 10 - 64 bit           ?                   ?
Vassal 3.4.13      Windows 10 - 64 bit           ?                   ?
Vassal 3.5.4       Windows 10 - 64 bit           ?                   -

3.2.17 will work with any released version of Java 8. (The current release is 8u281, but there have been several per year for the past few years, so that will keep changing until Java 8 is finally EOL.) For Macs, you can run with anything as old as Java 5, and for Linux and Windows you can run with Java 6, but the recommendation is to use Java 8 if you’re able.

Everything from 3.3.0 onwards requires Java 11 or later.

Also, that’s a misstatement of what I’ve said.

3.2.17 won’t work with Java 9 or later. It never has and and never will. There is no doubt there. Conversely, 3.2.17 does work with Java 8 and you should expect no changes to that with future Java 8 releases. I have never argued that 3.2.17 would stop working with newer Java 8 releases.

The claim I have made is this: Eventually you will have a computer where you can’t run Java 8.

Java 8 releases will soon end (maybe in 2022—it’s hard to tell what Oracle’s EOL schedule actually means). Once there are no more Java 8 releases, that means Java 8 won’t be kept current to work with operating system versions newer than it. There are new versions of Windows, MacOS, and Linux regularly, and this causes some software to require updates, which means that unmaintained software may stop working.

A better path is to update modules for 3.5 rather than to parse out in minute detail which versions of Java work with 3.2.17.

Not being into Java, I am confused by the Java release history/situation.

Before submitting I the original post I found out from Wikipedia that the latest JDK version is 17, scheduled for September this year. That makes 16 the current latest, out in March 2020, but also scheduled to “end free public updates” as early as September 2021. Conversely, Java 8, as well as the future Java 17, are scheduled to be in Long Term Support, with Java 8 going to 2026 (open JDK) and supported till 2030.

For the non initiate this is all very confusing. There is a 16, but what we are all sill really using - on Windows and Macs, at least - is Java 8 (from Oracle).

You say that for 3.3.0 onwards I need Java 11, though? But my Java auto-updater wants to update to Java 8 latest build only, though, I think. Is version 11 really out for Windows? Who/where to find it (not Oracle, I guess)? Is it really needed for Vassal 3.3+? I am currently running/developing under version 3.4.13 (and 3.5 for some tests) under Java 8 build 171 with no apparent issues…

Java 16 isn’t a Long Term Support release, which means that it will reach end-of-life not all that long after the next major version is released.

What I saw was Oracle’s support ending next year and OpenJDK going to 2026, not to 2030, but the exact dates don’t change the fact that you will eventually be unable to run Java 8 if you’ve kept current with your OS.

If you’re using VASSAL 3.3 or later, you absolutely are not using Java 8 to run it. Nothing after 3.2.17 will even launch properly with Java 8. See below.

If you have the Windows package installed for 3.3.0 or later, then it has Java bundled with it. The Windows package of VASSAL starting with 3.3.0 does not use your installed Java, does not look for your installed Java, does not care if you don’t have Java installed at all. If you have Java 8 installed independently, or if you don’t, it makes no difference for VASSAL 3.3 and later, because VASSAL 3.3+ will not use it.

(This goes for Windows and Macs. We don’t bundle Java for Linux, but there we can rely on the package manager to supply a reasonable version of Java.)

If you don’t believe me that you’re not using Java 8 with 3.4.13, check the top few lines of the errorLog. It will list the version of Java actually in use.

Ok, thanks, of course I believe you. Here is a new version of the compatibility table, see if I got it right:

                           compatible with                                                               
Vassal 3.2.17      Java version 8 (any build)                                                   
Vassal 3.3+        Java version 11 (NOTE: bundled with Vassal on Windows/Macs)                            -

3.3+ should be Java 11 or later.

Everyone on MacOS or Windows using the packages for those operating systems is actually using Java 15 with all of the 3.5 releases so far. 3.5.5 will have Java 16 bundled with it.

compatible with Vassal 3.2.17 Java version 8 (any build) Vassal 3.3+ Java version 11 or later (NOTE: bundled with Vassal on Windows/Macs)