VASSAL doesn't seem to work with Java 9 version

Hi,
There is a discussion in the gamesquad forum devoted to Advanced Squad Leader, where people say that VASSAL won’t work with the Java 9 version.
Is this true and, if ot is the case, will the issue be adressed ?

Thanks in advance for the answer.

Robin

Thus spake robinreeve:

Hi,
There is a discussion in the gamesquad forum devoted to Advanced Squad
Leader, where people say that VASSAL won’t work with the Java 9 version.
Is this true and, if ot is the case, will the issue be adressed ?

Thanks in advance for the answer.

Robin

Would you mind providing a link to that discussion?


J.

Sure.

Here it is : http://www.gamesquad.com/forums/index.php?threads/probably-a-stupid-prerequisite-problem-vassal-wont-start.150032/

Yeah, I did try it once with Java 9, but then eventually had to switch back to Java 8.
I’m sure there should be a pretty clear explanation.

This is part of the error log i get when trying to open VASL. I think I got the same warning about “illegal reflective access operation” when launching VASSAL the first time (when clicking the screen with take the tour or jump right in. Now I get to the menu but can’t open the VASL module.

This is Open JDK, Not sure if that’s an issue after reading the thread on Gamesquad?

2019-01-11 15:06:37,557 [1-main] INFO  VASSAL.launch.StartUp - OS Linux 4.15.0-20-generic
2019-01-11 15:06:37,557 [1-main] INFO  VASSAL.launch.StartUp - Java version 10.0.2
2019-01-11 15:06:37,557 [1-main] INFO  VASSAL.launch.StartUp - VASSAL version 3.2.17
2019-01-11 15:06:37,557 [1-main] INFO  VASSAL.launch.Launcher - Player
2019-01-11 15:06:38,461 [0-ProcessLauncher-2] WARN  VASSAL.tools.logging.LoggedOutputStream - WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by VASSAL.tools.image.ImageIOImageLoader (file:/home/hawk/VASSAL/VASSAL-3.2.17/lib/Vengine.jar) to field sun.java2d.cmm.ProfileDeferralMgr.deferring
WARNING: Please consider reporting this to the maintainers of VASSAL.tools.image.ImageIOImageLoader
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

Reverting to Java 8 can hardly be a long term solution, especially if you have other programs requiring the latest version.

You can have different Java versions installed. I have a dedicated JRE that runs Vassal properly, but the system JRE just gets updated whenever. You just need to make sure Vassal uses the right one (either by modifying the shell script that starts it, or explicitly running the jar via the right java binary from a custom shortcut).

I look forward to ditching Java completely when Vassal 4 arrives in the year 2057 ;)

I am not introduced in the manipulations you are speaking about.
It seems rather complicated from my non initiated point of view - I don’t know what a “shell” is fir an example.
And I believe that many people would be in my case.

Don’t you think that the VASSAL developers could design a new version compatible with Java 9?
Or at least give precise instructions about how you can have two Java versions installed and choosing the adapted one?

Updating Vassal for new versions isn’t easy. Especially since how they work
can vary across machines and operating systems. The developers are all
volunteers, doing this as a service to the hobby.

It would be better if the Java developers, which is a much, much bigger
team, wouldn’t make changes that break things.

As for instructions, it is again a case that the developers don’t have
computers with your configuration or operating systems. IIRC the main
developers use Linux. And for that system, the instructions make perfect
sense. Perhaps you could switch to Linux on your computer?

On Sun, Jan 13, 2019, 6:38 AM robinreeve <robinreeve@gmail.com wrote:

I am not introduced in the manipulations you are speaking about.
It seems rather complicated from my non initiated point of view - I
don’t know what a “shell” is fir an example.
And I believe that many people would be in my case.

Don’t you think that the VASSAL developers could design a new version
compatible with Java 9?
Or at least give precise instructions about how you can have two Java
versions installed and choosing the adapted one?


Read this topic online here:
VASSAL doesn't seem to work with Java 9 version - #8 by robinreeve


messages mailing list
messages@vassalengine.org
vassalengine.org/mailman/listinfo/messages

I will try to find the time to give a thorough description of the problem sometime in the next few days so that we can discuss possible solutions. Please bear with me, as I’m extremely busy at the moment.

Thanks uckelman.
I am looking forward to evoking other solutions than expecting Oracle to adapt to VASSAL or players to convert to Linux.

The issue is that the Vassal developers have a reference to an internal, unsupported class. There has never been any guarantee that any sun.* classes would not be changed out from under you. They are documented as internal, unsupported.

oracle.com/technetwork/java … 42232.html

Thus spake johannz:

The issue is that the Vassal developers have a reference to an internal,
unsupported class. There has never been any guarantee that any sun.*
classes would not be changed out from under you. They are documented as
internal, unsupported.

Why did we do that?

Have a look at the code for ImageIOImageLoader:

sourceforge.net/p/vassalengine/ … oader.java

This file is a collection of workarounds for 13 bugs in Java itself,
with explanations of the bugs and workarounds. It’s some dispiriting
reading if you know anything about image formats.

You’re absolutely correct that we’re using some internal, unsupported
classes that aren’t guaranteed to be changed out from under us. We were
driven to that because the supported, documented classes are broken. A
few of the bugs were already more than a decade old at the time when I
wrote their workarounds. Several even had patches waiting to be applied
attached to their bug reports.

We would never have done any of this had the image loading classes
distributed with Java been fit for purpose, or if there had been any
prospect of their being fixed promptly.

I’d find being pointed to an Oracle article entitled “Why Developers
Should Not Write Programs That Call ‘sun’ Packages” a fairer criticism
if Oracle also had an article entitled “Why Oracle Hasn’t Fixed Bugs
Which are Old Enough to Drive”.


J.

I’ve made a pass at answering some questions, as promised:

  • Does VASSAL work with Java 9? 10? 11?

Java 9 and Java 11 work for me on Linux after I remove lib/xercesImpl.jar. Apparently as of Java 9, the XML handling classes provided by the Xerces library became part of the JDK, so trying to load them from Xerces causes a name conflict which prevents the VASSAL player (but not the module manager) from starting. I haven’t tried Java 10, but my guess is that it will be the same in this regard as 9 and 11.

  • Why are you seeing illegal access warnings with Java 9 and later?

There is a bug in one of the classes Java uses for loading JPEG images which prevents reliable loading of of multiple JPEGs simultaneously. (The documentation provided by Oracle gives one no reason to suspect that JPEGImageReader is not only not thread-safe per instance, but also not thread-safe as a class, and having made it that way is so absurd that even were this documented it ought to be considered a design bug.) A bug report for this was filed with Oracle in 2010; as of today, it is still marked “Unresolved”. We work around this bug by getting access via reflection to the offending internal class, which is a lazy-loading cache, and turning it off.

The visibility of classes changed in Java 9. A module system was introduced, in which private classes and classes from unexported packages aren’t intended to be accessible from outside the module in which they live. With Java 9, access by reflection is still possible, but produces warnings. Sometime after Java 9, access by reflection will be denied by default, but is still permitted by default as of Java 11.

It looks like we can compile with either --add-exports or --add-opens for the particular class we need to get via reflection for the workaround.

(See blog.codefx.org/java/java-9-migration-guide/ for details.)

Note that compiling with either of these flags would commit us to compiling VASSAL and custom module code with a Java 9 compiler or later (which is not the same thing as requiring Java 9 or later for running VASSAL).

  • Why is our minimum requirement still Java 5?

The last time we considered raising the minimum supported verison of Java, there were a great many users of Macs for which nothing beyond Java 5 was available. We chose to keep Java 5 as the minimum at that point so as not to leave those users behind. As this was several years ago now, it may be the case that none of those machines are still in use and that we could increase our minimum supported version of Java without inconveniencing anyone.

Does anyone still use a machine which can’t be upgraded beyond Java 5?

Thanks for the comprehensive answer.

My main concern was that there is no guidance for users on how to resolve these issues (and they’re starting to see them, as their system Java’s are being updated) and since many/most of these people are non-technical, they don’t have a clue how to resolve them.

Upgrading the dev environment to Java 9+ is a non-trivial change (although it has to be done eventually :neutral_face:), but in the short term, can we provide some guidance to non-technical users on how to get things going?

I have a whole bunch of Windows VM’s (going back to 3.1 :slight_smile:) that I use for testing other things, and I’m happy to e.g. check what combinations of Windows/Java/VASSAL/VASL seem to work, but IIRC, VASSAL doesn’t have a test suite, so just checking if it starts up is the most basic of basic tests :neutral_face:

But before any work like that can be done, what versions of Java do you want to actually target? Given that 9 and 10 are EOL, people should probably be discouraged from using them. So, for example:
Java 5-7: deprecated
Java 8: supported
Java 9-10: unsupported (might work, might not, you’re on your own)
Java 11: provisionally supported (but if you’re using VASSAL 3.2.17, click here for instructions on things you need to do)

with the aim of making Java 8 “deprecated” and Java 11 “supported”.

Thus spake pacman-ghost:

Thanks for the comprehensive answer.

My main concern was that there is no guidance for users on how to
resolve these issues (and they’re starting to see them, as their system
Java’s are being updated) and since many/most of these people are
non-technical, they don’t have a clue how to resolve them.

There was no guidance for users on how to resolve these issues because
we haven’t resovled them yet. Yesterday evening was my first chance to
investigate any of them.

I’ve found a few additional problems; once I’ve solved them, I’ll post
a test build here.

But before any work like that can be done, what versions of Java do you
want to actually target? Given that 9 and 10 are EOL, people should
probably be discouraged from using them. So, for example:
Java 5-7: deprecated
Java 8: supported
Java 9-10: unsupported (might work, might not, you’re on your own)
Java 11: provisionally supported (but if you’re using VASSAL 3.2.17,
click here for instructions on things you need to do)

I’d prefer to target 11, so long as we’re certain that 11 is available
for all plaftorms where VASSAL is run. I want this to be the last time
we migrate to a newer minimum version of Java.


J.

Thanks !!! Removing lib/xercesImpl.jar solved the problem.

Posting here because ‘report bug’ failed on an internal error (!)

These fixes didnt work for me.

  • fresh install of opensuse
  • using: java-11-openjdk-11.0.4.0-lp151.3.6.1.x86_64
  • removed /usr/share/java/xerces*.jar

Vassal starts with a warning of:

WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by VASSAL.tools.image.ImageIOImageLoader (file:/home/korg/bin/vassal.installed/VASSAL-3.2.17/lib/Vengine.jar) to field sun.java2d.cmm.ProfileDeferralMgr.deferring WARNING: Please consider reporting this to the maintainers of VASSAL.tools.image.ImageIOImageLoader WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release

but seems to start up ok (i get the about screen and main menu) but it then if i try to open vasl or run the ‘take the tour’ intro it bombs with…

2019-08-30 19:13:16,976 [0-main] INFO VASSAL.launch.StartUp - Starting 2019-08-30 19:13:16,979 [0-main] INFO VASSAL.launch.StartUp - OS Linux 4.12.14-lp151.28.13-default 2019-08-30 19:13:16,979 [0-main] INFO VASSAL.launch.StartUp - Java version 11.0.4 2019-08-30 19:13:16,979 [0-main] INFO VASSAL.launch.StartUp - VASSAL version 3.2.17 2019-08-30 19:13:17,292 [0-AWT-EventQueue-0] INFO VASSAL.launch.ModuleManager - Manager 2019-08-30 19:13:20,107 [0-SwingWorker-pool-385739920-thread-2] INFO VASSAL.launch.AbstractLaunchAction - Loading module file /home/korg/bin/vassal.installed/VASSAL-3.2.17/doc/tour.mod 2019-08-30 19:13:20,331 [0-SwingWorker-pool-385739920-thread-2] INFO VASSAL.tools.io.ProcessLauncher - launching /usr/lib64/jvm/java-11-openjdk-11/bin/java -classpath /home/korg/bin/vassal.installed/VASSAL-3.2.17/lib/Vengine.jar -Xmx159M -DVASSAL.id=2 -Duser.home=/home/korg -DVASSAL.port=39669 VASSAL.tools.image.tilecache.ZipFileImageTiler /home/korg/bin/vassal.installed/VASSAL-3.2.17/doc/tour.mod /home/korg/.VASSAL/tiles/fabc96ea565c612b78e1fd47dcf965414160e42a 256 256 2019-08-30 19:13:21,216 [2-main] INFO VASSAL.tools.image.tilecache.ZipFileImageTiler - Starting 2019-08-30 19:13:21,284 [0-ProcessLauncher-2] WARN VASSAL.tools.logging.LoggedOutputStream - WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by VASSAL.tools.image.ImageIOImageLoader (file:/home/korg/bin/vassal.installed/VASSAL-3.2.17/lib/Vengine.jar) to field sun.java2d.cmm.ProfileDeferralMgr.deferring WARNING: Please consider reporting this to the maintainers of VASSAL.tools.image.ImageIOImageLoader WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release 2019-08-30 19:13:21,303 [2-main] INFO VASSAL.tools.image.tilecache.FileArchiveImageTiler - Tiling images/Map_West.gif 2019-08-30 19:13:21,583 [2-main] INFO VASSAL.tools.image.tilecache.FileArchiveImageTiler - Tiling images/Tile_Gap_2.jpg.gif 2019-08-30 19:13:21,728 [2-main] INFO VASSAL.tools.image.tilecache.FileArchiveImageTiler - Tiling images/Tile_Hallway_1.jpg.gif 2019-08-30 19:13:21,755 [2-main] INFO VASSAL.tools.image.tilecache.FileArchiveImageTiler - Tiling images/Tile_Hallway_2.jpg.gif 2019-08-30 19:13:21,797 [2-main] INFO VASSAL.tools.image.tilecache.FileArchiveImageTiler - Tiling images/Tile_Hallway_3.jpg.gif 2019-08-30 19:13:21,832 [2-main] INFO VASSAL.tools.image.tilecache.FileArchiveImageTiler - Tiling images/Tile_Hallway_4.jpg.gif 2019-08-30 19:13:21,856 [2-main] INFO VASSAL.tools.image.tilecache.FileArchiveImageTiler - Tiling images/Tile_T_Wall.jpg.gif 2019-08-30 19:13:21,883 [2-main] INFO VASSAL.tools.image.tilecache.FileArchiveImageTiler - Tiling images/VIP-map2.png 2019-08-30 19:13:22,165 [2-main] INFO VASSAL.tools.image.tilecache.FileArchiveImageTiler - Tiling images/WAP3.gif 2019-08-30 19:13:22,208 [2-main] INFO VASSAL.tools.image.tilecache.FileArchiveImageTiler - Tiling images/bd03.gif 2019-08-30 19:13:22,251 [2-main] INFO VASSAL.tools.image.tilecache.FileArchiveImageTiler - Tiling images/bd41.gif 2019-08-30 19:13:22,362 [2-main] INFO VASSAL.tools.image.tilecache.FileArchiveImageTiler - Tiling images/tourForces.gif 2019-08-30 19:13:22,379 [2-main] INFO VASSAL.tools.image.tilecache.ZipFileImageTiler - Exiting 2019-08-30 19:13:22,404 [0-SwingWorker-pool-385739920-thread-2] INFO VASSAL.launch.AbstractLaunchAction - Loading game file /home/korg/bin/vassal.installed/VASSAL-3.2.17/doc/tour.log 2019-08-30 19:13:22,407 [0-SwingWorker-pool-385739920-thread-2] INFO VASSAL.launch.AbstractLaunchAction - Loading module VASSAL Tour 2019-08-30 19:13:22,408 [0-SwingWorker-pool-385739920-thread-2] INFO VASSAL.tools.io.ProcessLauncher - launching /usr/lib64/jvm/java-11-openjdk-11/bin/java -Xms256M -Xmx512M -DVASSAL.id=1 -DVASSAL.port=44591 -Duser.home=/home/korg -Duser.dir=/home/korg/bin/vassal.installed/VASSAL-3.2.17 -cp /home/korg/bin/vassal.installed/VASSAL-3.2.17/lib/Vengine.jar VASSAL.launch.Player --load -- /home/korg/bin/vassal.installed/VASSAL-3.2.17/doc/tour.mod /home/korg/bin/vassal.installed/VASSAL-3.2.17/doc/tour.log 2019-08-30 19:13:23,336 [1-main] INFO VASSAL.launch.StartUp - Starting 2019-08-30 19:13:23,340 [1-main] INFO VASSAL.launch.StartUp - OS Linux 4.12.14-lp151.28.13-default 2019-08-30 19:13:23,340 [1-main] INFO VASSAL.launch.StartUp - Java version 11.0.4 2019-08-30 19:13:23,340 [1-main] INFO VASSAL.launch.StartUp - VASSAL version 3.2.17 2019-08-30 19:13:23,340 [1-main] INFO VASSAL.launch.Launcher - Player 2019-08-30 19:13:23,801 [0-ProcessLauncher-2] WARN VASSAL.tools.logging.LoggedOutputStream - WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by VASSAL.tools.image.ImageIOImageLoader (file:/home/korg/bin/vassal.installed/VASSAL-3.2.17/lib/Vengine.jar) to field sun.java2d.cmm.ProfileDeferralMgr.deferring WARNING: Please consider reporting this to the maintainers of VASSAL.tools.image.ImageIOImageLoader WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release 2019-08-30 19:13:24,169 [1-AWT-EventQueue-0] ERROR VASSAL.tools.ErrorDialog - java.lang.NoClassDefFoundError: org/w3c/dom/ls/DocumentLS at java.base/java.lang.ClassLoader.defineClass1(Native Method) ~[na:na] at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016) ~[na:na] at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174) ~[na:na] at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:802) ~[na:na] at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:700) ~[na:na] at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:623) ~[na:na] at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) ~[na:na] at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) ~[na:na] at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) ~[na:na] at java.base/java.lang.ClassLoader.defineClass1(Native Method) ~[na:na] at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1016) ~[na:na] at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:174) ~[na:na] at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:802) ~[na:na] at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:700) ~[na:na] at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:623) ~[na:na] at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) ~[na:na] at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) ~[na:na] at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) ~[na:na] at org.apache.xerces.util.ObjectFactory.findProviderClass(Unknown Source) ~[xercesImpl.jar:na] at org.apache.xerces.parsers.AbstractDOMParser.setDocumentClassName(Unknown Source) ~[xercesImpl.jar:na] at org.apache.xerces.parsers.AbstractDOMParser.reset(Unknown Source) ~[xercesImpl.jar:na] at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) ~[xercesImpl.jar:na] at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) ~[xercesImpl.jar:na] at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source) ~[xercesImpl.jar:na] at java.xml/javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:122) ~[na:na] at VASSAL.build.Builder.createDocument(Builder.java:160) ~[Vengine.jar:na] at VASSAL.launch.BasicModule.build(BasicModule.java:110) ~[Vengine.jar:na] at VASSAL.build.GameModule.init(GameModule.java:855) ~[Vengine.jar:na] at VASSAL.launch.Player.launch(Player.java:83) ~[Vengine.jar:na] at VASSAL.launch.Launcher$1.run(Launcher.java:149) ~[Vengine.jar:na] at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313) ~[na:na] at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:770) ~[na:na] at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721) ~[na:na] at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715) ~[na:na] at java.base/java.security.AccessController.doPrivileged(Native Method) ~[na:na] at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85) ~[na:na] at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:740) ~[na:na] at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203) ~[na:na] at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124) ~[na:na] at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113) ~[na:na] at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109) ~[na:na] at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) ~[na:na] at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90) ~[na:na] Caused by: java.lang.ClassNotFoundException: org.w3c.dom.ls.DocumentLS at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) ~[na:na] at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) ~[na:na] at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) ~[na:na] ... 43 common frames omitted

Look here for test builds for use with Java 9 or later:

https://forum.vassalengine.org/t/upgrading-to-a-newer-version-of-java/10005/3