Community
Participate
Working Groups
We now properly detect JREs on 64 bit Mac, the default JRE setting appears wrong. The 1.5 VM is selected, but if I try to run an Eclipse Application on the 1.5 VM, I get this exception: ava.lang.UnsatisfiedLinkError: Cannot load 64-bit SWT libraries on 32-bit JVM at org.eclipse.swt.internal.Library.loadLibrary(Library.java:179) at org.eclipse.swt.internal.Library.loadLibrary(Library.java:159) I assume the 1.6 VM should be detected as the default JRE.
If I launch the 1.5 VM with -d64, it works. However, this arg does not appear in the Eclipse.ini for Mac, so how does it work? (or how does it know to launch the 1.6 VM?)
(In reply to comment #1) > If I launch the 1.5 VM with -d64, it works. However, this arg does not appear > in the Eclipse.ini for Mac, so how does it work? (or how does it know to launch > the 1.6 VM?) Since Eclipse.app uses JNI, JNI_CreateJavaVM detects that the app is running in 64-bit and selects the 64-bit JVM. Java Preferences.app sets up the order in which JVMs are searched. If Java 6 is at the top of the list in "Java Application Versions" it will be chosen ahead of Java 1.5. This also governs what you get when running 'java' from the command line. It picks the 32-bit JVM by default, even if you are running x86_64 Eclipse. As you discovered, the way to explicitly pick a 32-bit vs 64-bit JVM is to add -d32 or -d64 as a VM option. %java java version "1.5.0_16" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b06-277) Java HotSpot(TM) Client VM (build 1.5.0_16-130, mixed mode, sharing) % java -d64 -version java version "1.5.0_16" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b06-277) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_16-130, mixed mode) % java -d32 -version java version "1.5.0_16" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b06-277) Java HotSpot(TM) Client VM (build 1.5.0_16-130, mixed mode, sharing) The default JVM options for 64-bit VMs should have '-d64' pre-set. For good measure, 32-bit should have '-d32' in the default options.
The launcher is 64-bit only, so loading the 32-bit VM isn't an option in that case and the -d64 isn't necessary. If you are just running 'java' Apple will choose first the 32 bit code unless you explicitly say otherwise.
(In reply to comment #3) > The launcher is 64-bit only, so loading the 32-bit VM isn't an option in that > case and the -d64 isn't necessary. If you are just running 'java' Apple will > choose first the 32 bit code unless you explicitly say otherwise. Technically speaking, your last sentence isn't correct. The order of selection is determined by what you see in Java Preferences.app. If the user doesn't explicitly change it the default order is Java 1.5/32-bit, Java 1.5/64-bit and then Java 1.4.2. If I drag the 64-bit 1.5 JVM to the top of the list 'java' will run 64-bit. If possible, JRE detection should identify 32- and 64-bit JVMs separately.
(In reply to comment #4) > If possible, JRE detection should identify 32- and 64-bit JVMs separately. Do you know how one would distinguish which VMs are 32/64 bit? Would it be better to detect that a 64 bit version of SWT is being launched and add -d64 argument (like we add the -XstartOnFristThread)?
Ideally, we'd add the -d64 automatically when launching 64 bit SWT libraries. Not sure how we know what version of SWT libraries are being launched.
(In reply to comment #6) > Ideally, we'd add the -d64 automatically when launching 64 bit SWT libraries. > Not sure how we know what version of SWT libraries are being launched. You could check the property sun.arch.data.model. It returns '32' or '64' depending on the JVM in use. That property is available on all Sun-based JVMs, including Mac OS X's.
I figured you would have have to check the java.library.path for an swt library, detect that it's 64 bit, and then start java with -d64. This approach would only solve the swt case. If you're launching with any other 64 bit library you'd have to add -d64 to the launch config yourself. I think it's probably sufficient to make this an FAQ item.
(In reply to comment #5) > (In reply to comment #4) > > > If possible, JRE detection should identify 32- and 64-bit JVMs separately. > > Do you know how one would distinguish which VMs are 32/64 bit? > For JRE detection Apple just added a new feature in the latest Java developer preview (4/23/09) /usr/libexec/java_home will give you a valid path for JAVA_HOME but also has options to return all available JVM versions and architectures. If it's there you can definitively detect and create JRE entries for all installed JRE versions. If this tool isn't there you have to guess based on OS and JVM information, unfortunately.
*** Bug 275064 has been marked as a duplicate of this bug. ***
FYI the default preferences (out of the box on a new 10.5 machine) are: J2SE 5.0 32-bit Java SE 6 64-bit J2SE 5.0 64-bit
