Community
Participate
Working Groups
Build Identifier: I20100608-0911 Java for Mac OS X is transitioning to delivering the JDK as a bundle with the .jdk extension. The bundles cause the Contents/Home directory to be opaque and inaccessible to standard file chooser dialogs. A reasonable workaround (for Mac OS X VMs) would be to configure the dialog to select directories or .jdk "files", and tack on Contents/Home if it's a .jdk bundle. Ideally, JVM detection can be done by simply running /usr/libexec/java_home -X, which reports all JVMs detected by the OS as an XML plist. Reproducible: Always Steps to Reproduce: 1. Install <https://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware?bundleID=20703> 2. Launch Eclipse, and open Preferences. 3. Select Java > Installed JREs, and click Add... 4. Choose "Mac OS X VM" 5. Click "Directory..." 6. Attempt to select /Library/Java/JavaVirtualMachines/1.6.0_21-b07-298.jdk/Contents/Home (it's not possible with the current UI)
*** Bug 328375 has been marked as a duplicate of this bug. ***
Created attachment 181532 [details] sample XML
Created attachment 181876 [details] patch Work in progress to parse XML plist.
Created attachment 181877 [details] updated patch
Does anyone know if there's a way to tell which JRE is the current/default JRE? (I didn't see anything in the XML).
(In reply to comment #5) > Does anyone know if there's a way to tell which JRE is the current/default JRE? > (I didn't see anything in the XML). The list is ordered by preference. You should pick the first one that satisfies any criteria you need to match (like version, or architecture). If you have no criteria, it's the first one.
Created attachment 182063 [details] update
(In reply to comment #6) > The list is ordered by preference. You should pick the first one that satisfies > any criteria you need to match (like version, or architecture). If you have no > criteria, it's the first one. Thanks. Using the new approach (parsing output from java_home -X), I end up with a different number of installed JREs. I.e. on the box I'm testing with, using the new approach I end up with a 1.5 VM and a 1.6 VM. Using the old code, I also get a 1.4 VM. So, is it more correct to use the new approach and not admit to having the 1.4 VM, or why is the 1.4 VM missing from the XML?
What version of Mac OS X are you using? I would guess 10.5, since you're finding a 1.5 JVM. The '1.4' JVM was just a symlink that leads to in 1.5. There were applications that hard-linked against libraries in the 1.4 directory, and for backwards compatibility the symlink was necessary so they would continue to run, even when there was no 1.4.2 JVM on the computer.
(In reply to comment #8) > Thanks. > > Using the new approach (parsing output from java_home -X), I end up with a > different number of installed JREs. I.e. on the box I'm testing with, using the > new approach I end up with a 1.5 VM and a 1.6 VM. Using the old code, I also > get a 1.4 VM. So, is it more correct to use the new approach and not admit to > having the 1.4 VM, or why is the 1.4 VM missing from the XML? Because it's unchecked in Java Preferences.
(In reply to comment #9) > What version of Mac OS X are you using? I would guess 10.5, since you're > finding a 1.5 JVM. The '1.4' JVM was just a symlink that leads to in 1.5. There > were applications that hard-linked against libraries in the 1.4 directory, and > for backwards compatibility the symlink was necessary so they would continue to > run, even when there was no 1.4.2 JVM on the computer. Scott, the 1.4 JVM is still there - we just updated it's Info.plist so that it's disabled by default. Update 5 was the last release that shipped 1.4, which is why we require it for any subsequent updates on Leopard.
(In reply to comment #11) > Scott, the 1.4 JVM is still there - we just updated it's Info.plist so that > it's disabled by default. Update 5 was the last release that shipped 1.4, which > is why we require it for any subsequent updates on Leopard. Oh... I thought that update 5 removed it from the system altogether, but it looks like I remembered that wrong. I'll shut up now. :-)
Created attachment 182075 [details] more updates :-)
Created attachment 182085 [details] next
Created attachment 182757 [details] Updated patch This patch maintains installed JRE ID's. This way when using the new search function, an existing JRE installed at from the same location will not be duplicated/replaced by the new JRE (same JRE, but with an updated name as reflected in the plist XML).
Fixed. Installed JREs on Mac are now derived from the java_home -X plist. This does not add support for selecting "invisible .jdk" directories. However, that should no longer be required as the plist should contain those JREs. The user can "Search..." to get all installed JREs.
Developer Packages that include the src.jar, etc. are currently not easy to install, see bug 369524.
