harpua:~ mgouker$ ls -l /Library/Java/JavaVirtualMachines
total 0
drwxrwxr-x 3 root wheel 102 Apr 20 2012 1.7.0.jdk
harpua:~ mgouker$ ls -l /System/Library/Frameworks/JavaVM.framework/Versions
total 64
lrwxr-xr-x 1 root wheel 10 Feb 16 08:43 1.4 → CurrentJDK
lrwxr-xr-x 1 root wheel 10 Feb 16 08:43 1.4.2 → CurrentJDK
lrwxr-xr-x 1 root wheel 10 Feb 16 08:43 1.5 → CurrentJDK
lrwxr-xr-x 1 root wheel 10 Feb 16 08:43 1.5.0 → CurrentJDK
lrwxr-xr-x 1 root wheel 10 Feb 16 08:43 1.6 → CurrentJDK
lrwxr-xr-x 1 root wheel 10 Feb 16 08:43 1.6.0 → CurrentJDK
drwxr-xr-x 9 root wheel 306 Feb 16 19:34 A
lrwxr-xr-x 1 root wheel 1 Feb 16 08:43 Current → A
lrwxr-xr-x 1 root wheel 52 Feb 16 09:50 CurrentJDK → /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents
I also have:
harpua:~ mgouker$ ls /System/Library/Java/JavaVirtualMachines
1.6.0.jdk
Guillaume, if you use 1.7 JDK, please make sure you have Java (not javascript) off in your browser. There are security issues.
Guillaume, our jdks are a little different (you are 13 builds ahead of me). Where did you get yours? From Oracle or the Open JDK project?
I have no problem starting Vassal - absolutely no error executing Vassal, however I still have bad graphic output. I execute Vassal from the Applications folder (not through a browser - can you still do that?).
Also, uekelman, I believe I have the same output on the screen as Guillaume in Vassal itself (i.e. no text on the counters). Please see attached image. Note that the Ottomans are on the rampage.
Guillaume, Vassal will use the Java it finds in its class path. That’s why the links are important. A symbolic link points to the current VM. In your case, it will find jdk 7’s libraries now. Do you just execute the Vassal App in the Applications folder?
That’s correct. The Clash of Monarchs module, like 99% of them, uses JPG/PNG images for all its art assets. My modules use SVG images, and the problem being worked around relates to the rendering of SVG.
[quote=“gdaudin”]
I have a mouse pointer issue when launching vassal in this way.
BTW, Michael, what is the version of Java run by Vassal when you start it “normally” ?
/quote]
The short answer: The first one java finds in your class path.
What we are doing is overriding the existing class path to guarantee that we find only the jars that we know are correct. Your comment before about the system not starting because of the version indicated to me that there was still an invalid connection to a jar from a preexisting version (it was compiled with an earlier library). So uekelman’s technique excluded all the other virtual machines and launching from the command line specifying only the minimal number of jars ruled everything else out.
I will take a look at the mouse cursor a little later. I am so happy to have slept!
Got that. I meant in your install. I assume you have cleaner Java installation than me, and I was wondering how come Vassal does not run in the same way when you start “normally” and by the command line method on your machine.
Or maybe I am utterly confused, which is very plausible.
BTW, Michael, what is the version of Java run by Vassal when you start
it “normally” ?
/quote]
The short answer: The first one java finds in your class path.
What we are doing is overriding the existing class path to guarantee
that we find only the jars that we know are correct. Your comment before
about the system not starting because of the version indicated to me
that there was still an invalid connection to a jar from a preexisting
version (it was compiled with an earlier library). So uekelman’s
technique excluded all the other virtual machines and launching from the
command line specifying only the minimal number of jars ruled everything
else out.
This is not entirely accurate. You’re conflating two unrelated things,
the PATH, and Java’s classpath. Which JRE binary is used when ‘java’
is invoked is determined by the leftmost directory on the PATH contains
which contains a file called ‘java’. The Java classpath is something
that the JRE uses to find class files. It has a similar function as the
PATH, but is specific to Java and is something which gets specified
when you start the JRE. There is no way that you can set the classpath
which whill affect which JRE is started.
The reason that you can launch VASSAL by specifying lib/Vengine.jar as
the entire classpath is that Vengine.jar contains a manifest file which
adds the jars on which we depend to the classpath. The point of this is
that it makes it harder to get the classpath wrong.
Summary: The Java classpath is irrelevant here. The problem is with
the PATH (which, BTW, you can print with ‘echo $PATH’).
or “whereis java” with /usr/bin/java the most likely answer.
Any binary is found with $PATH - not just java. The “special” problem he has with mis-matched jars really seems to be a bad installation (perhaps jars from multiple versions?) I don’t know really, but reducing the variables is always a good strategy. Maybe there are shared object libraries too? PATH would be a factor then.
Any binary is found with $PATH - not just java. The “special” problem he
has with mis-matched jars really seems to be a bad installation (perhaps
jars from multiple versions?) I don’t know really, but reducing the
variables is always a good strategy. Maybe there are shared object
libraries too? PATH would be a factor then.
Why do you think he has mismatched jars? I don’t see any evidence for
that here.
