OS X 1.9 ea jdeps

Mandy Chung mandy.chung at oracle.com
Wed Apr 29 18:16:22 UTC 2015


On 4/13/15 1:32 AM, Michael Hall wrote:
> On Apr 13, 2015, at 2:32 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
>> On 12/04/2015 17:57, Michael Hall wrote:
>>> :
>>>
>>> Not exactly sure what you mean.
>>> But,
>>>
>>> which java
>>> /usr/bin/java
>>>
>>> ...
>>>
>> I think the issue is that the installation creates sym links in /usr/bin for most, but not all, of the tools/launchers. So if you have /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands or /Library/Java/JavaVirtualMachines/jdk1.8.0_20.jdk/Contents/Home/bin on your PATH, say after /usr/bin, then it would explain what you are seeing.
> This seems to be correct. Although for some reason right now it appears to be the 1.8.0_40 release in PATH and this is what 'which jdeps' returns. (usr/bin in path prior to this).
> So is the jdeps case to be considered not an error? Just something to be aware of if you use an early access?
> Or is it something that should be corrected? It seems like you are supporting two different ways to accomplish the same thing, /usr/bin sym links or PATH updates. Doesn’t this make things a little more difficult to keep track of?

jdeps is not the only JDK tool not in /usr/bin. The sym links from
/usr/bin are not created by the JDK installer.

/usr/bin/j* are linked to
/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands
probably part of OS install and I guess it's a snapshot of JDK 7
commands.

If a JDK tool is added or removed for a new version of JDK, it
won't be reflected in /usr/bin.  You may want to follow up your
question from macosx-port-dev mailing list.

Mandy



More information about the jigsaw-dev mailing list