- Mar 22, 2004
- Reaction score
- Toledo, Ohio
It should be in the lib/ sub-directory of wherever you installed VASSAL. There should be a file called Vengine.jar in the same directory (if that's missing, VASSAL won't run at all).I cannot seem to find a xercesImpl.jar file on my HD.
Maybe this post will one day save my (VASL-) life.Here is an extensive post that was given to my question on the vassalengine site.
I don't grasp all the notions explained, but I believe that some here will.
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 https://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?
uckelman said here that he found other issues.This could mean that the problems evoked are not caused by the update of Java to a version higher than 8...
Could be, I downloaded the source and other than the numerous Deprecated warnings it seemed to run ok (ok = with the WARNING about the illegal reflection access).