Community
Participate
Working Groups
Created attachment 275996 [details] Installed JREs With the newest JDT 4.9 the "Search..." button on the "Installed JREs" preference page detects all installed JRE but their name show up as "Home". In previous version the default naming was much more reasonable. Also I didn't explicitly had to set a root directory to look for JREs.
I recall we had a similar bug, but I have trouble finding that now. Moving to JDT debug.
Yes, this has changed as a result of Bug 526815. Previously Mac used to provide the specific JRE so there was no use of allowing user to select the directory to search. No Mac allows to place the JRE in any folder.
Even though selecting a root folder may be fine and actually intended I still think having the folder name as the name of the JRE is not a good choice. For 99% of the cases where Mac OS X users have just installed several Oracle JDK versions the folder is just named "Home". That is due to the standard folder layout of Oracle/OpenJDK. Why can't you instead just take the version which is returned from "java --version" within that JRE as default name?
Actually the /usr/libexec/java_home command somehow figures out the version of installed jdks without executing it (it is fast). I wonder if this is done via some documented mechanism. This also works for OpenJDK installed into the user's home folder, e.g. % /usr/libexec/java_home -V Matching Java Virtual Machines (10): 11, x86_64: "OpenJDK 11-ea" /Users/till/Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home 10, x86_64: "Java SE 10" /Library/Java/JavaVirtualMachines/jdk-10.jdk/Contents/Home 9.0.4, x86_64: "Java SE 9.0.4" /Library/Java/JavaVirtualMachines/jdk-9.0.4.jdk/Contents/Home 9.0.1, x86_64: "Java SE 9.0.1" /Library/Java/JavaVirtualMachines/jdk-9.0.1.jdk/Contents/Home 9, x86_64: "Java SE 9" /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home 1.8.0_162, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home 1.8.0_151, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home 1.8.0_112, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_112.jdk/Contents/Home 1.8.0_60, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home 1.7.0_71, x86_64: "Java SE 7" /Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Home
Grepping just finds it in the Info.plist: % fgrep -rl 'OpenJDK 11-ea' ~/Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/ /Users/till/Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents//Info.plist So I guess java_home simply reads that.
I will not have time to work on this, if we get a quality patch to fix this, we can look into it.
I think executing "./java -XshowSettings:properties -version" makes more sense instead of relying on some PList entries. That would be even cross-platform compatible. From that output you can pick e.g. the "java.vendor", the version and much more to generate a reasonable JRE name.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
