I also had to re-install Java 1.6 for another program, and VASSAL fails the same exact way when using 1.6. I also had 1.6 installed when I was on 10.10.3 and 10.10.4. So it’s not unique to 1.6, 1.7 or 1.8, or to 10.10.5.
I have never seen this issue on my Macs–neither with Java 6 nor with Java 8. I’m currently on OS 10.10.5 on my Macbook Air but have been through all minor versions of 10.10 without any problems.
In techspeak, Vassal is creating a Java class called JarArchive that should live in the Vassal Jar file, then asking the ClassLoader what URL it was loaded from and adding /images to it. For some reason, your OS is returning ‘file:/Library/Java/Extensions/Help’ as the base URL.
Can you try an experiment. Go to the folder file:/Library/Java/Extensions/Help and change the name of images folder to images.keep, then try starting Vassal and see what happens.
Regards,
Brent.
Thanks Brent. I am a programmer but it’s been quite some time since I looked at any Java.
Renaming the folder did work. I was able to open two different mod files with no issues. So the question now is how to do this without having to rename?
I also confirmed that switching the folder name back causes the problem again.
What is in that folder?
This sounds like it might be a classpath issue. Is file:/Library/Java/Extensions/Help in your classpath?
It contains some gif from 2005 - not sure what put them there.
echo $CLASSPATH returns:
.:/Users/jbeckman/C259/Myclasses
which is from my Java class many years ago, where I put my homework.
Whatever did it was installed on both my main desktop and laptop though, as both have the same problem. An older MacMini I tried last night does not have an issue.
Something has installed a Java Extension that seems to be interfering with running Vassal.
Are you able to run a small Java program? (See below).
[code]public class ShowProperties {
public static void main(String[] args) {
String [] properties = {
“java.ext.dirs”,
“java.home”,
“path.separator”,
“file.separator”,
“java.library.path”,
“os.arch”,
“sun.boot.class.path”
};
for (int i = 0; i < properties.length; i++) {
String key = properties[i];
System.out.println(key + ": " + System.getProperty(key));
}
}
}[/code]
You’ll have to tell me how. Compiling it works but it won’t run, complaining of no main class.
“Error: Could not find or load main class .Users.jbeckman.src.ShowProperties.class”
Figured it out - needed to cd to the directory (d’oh!).
Output is showing weird here on the board so I am attaching as a file.
Remember, I have both 1.8 and 1.6; because of the shell script in the package it looks like 1.6 is preferred, but running from the command line is going to give me 1.8. Still, it failed the exact same way in 1.6 or 1.8 so maybe this output is still worthwhile.
Ok,
That’s sort of what I expected. It confirms that /Library/Java/Extensions is defined in your list of locations for Java Extensions. Why this should interfere with Vassal I am not exactly sure.
What is in the /Library/Java/Extensions/Help folder?
Short of identifying and uninstalling whatever extension is causing the problem, I suspect the workaround is to change the command line used to invoke Vassal to override the java.ext.dirs property to stop it looking in /Library/Java/Extensions
Regards,
Brent.
Looks like this was loaded by DataDirect SequeLink, which is a JDBC bridge tech - I need that. So if you can tell me how to alter the VASSAL.sh script for that override I’ll do that.
Thanks so much for all your work in troubleshooting this problem!
Try adding
-Djava.ext.dirs=""
to the command line, that should stop it checking the extension directories.
Like so:
java -Duser.dir="$INSTALL_DIR" -Djava.ext.dirs="" -classpath “$INSTALL_DIR”/lib/Vengine.jar VASSAL.launch.ModuleManager “$@”
I can’t make it work. Same exact error. I think the key is here:
VASSAL.tools.io.ProcessLauncher - launching /Library/Java/JavaVirtualMachines/jdk1.8.0_51.jdk/Contents/Home/jre/bin/java -Xms256M -Xmx512M -DVASSAL.id=1 -DVASSAL.port=49889 -Duser.home=/Users/jbeckman -Duser.dir=/Applications/VASSALmod.app -cp Contents/Resources/Java/Vengine.jar -Xdock:name=Combat Commander: Europe -Xdock:icon=/Applications/VASSALmod.app/Contents/Resources/VASSAL.icns -Dapple.awt.graphics.UseQuartz=false VASSAL.launch.Player --load – /Volumes/Internal500x/Downloads/Combat_Commander_Europe.vmod
I think maybe this process is getting started without the change. Does that sound right?
Ah, yes.
We fixed the starting of the Module Manager, but the problem is when the Module manager starts the module up. This command line is built dynamically and we can’t change it from outside. This is a Vassal issue that I will need to address. I think the Module Manager prefs needs an option to allow a player to add additional Java options when starting a module.
In the meantime, you might be able to get around this by running the module directly without the module manager. The command line is the same as you show above after the 'launching ', but remove
-DVASSAL.id=1 -DVASSAL.port=49889
and add
–standalone
Thanks. I keep running into problems trying to start it; I can’t seem to get the syntax right to allow it to work. For now I will just rename the images directory to images.xxx. While I need the JDBC bridge, I don’t often go into the help (I think last night to find out what it was was the first time ever). That’s a lot easier than trying to get this to work, and if I need the help I can change the name back. I’ll watch the release notes and look to see when this gets addressed, but until then you’ve given me a viable way to run the program. Thank you very much for all your hard work on this!
Thus spake Brent Easton:
Try adding
-Djava.ext.dirs=“”
to the command line, that should stop it checking the extension
directories.Like so:
java -Duser.dir=“$INSTALL_DIR” -Djava.ext.dirs=“” -classpath
“$INSTALL_DIR”/lib/Vengine.jar VASSAL.launch.ModuleManager “$@”
I think the right way to solve this would be to set -Djava.ext.dirs=“”
by default, for the Module Manager, Player, and Editor. Having
java.ext.dirs set to anything at all will never be right for running
VASSAL, so we could head that off by setting it to an empty string
unconditionally.
–
J.
A while off and a fresh look at things and I have finally sorted this bug out.
No need to change any Vassal startup scripts or classpaths.
Fix committed @9234 for Vassal 3.2.17
Thus spake Brent Easton:
A while off and a fresh look at things and I have finally sorted this
bug out.No need to change any Vassal startup scripts or classpaths.
Fix committed @9234 for Vassal 3.2.17
The fix is in the most recent devopment build, 3.2.17-svn9243, available
here:
vassalengine.sourceforge.net/builds/
–
J.