RFR: JDK-8238225: Issues reported after replacing symlink at Contents/MacOS/libjli.dylib with binary

[Erik Joelsson]

In JDK-8235687 the MacOS bundle distribution of the JDK was changed to 
conform to Apple requirements by changing Contents/MacOS/libjli.dylib 
from a symlink into ../Home/lib/libjli.dylib to a copy of that file. The 
problem with having a symlink there is that Contents/MacOS/libjli.dylib 
is the declared CFBundleExecutable of the bundle and that executable may 
not be a symlink. The history around why that particular library was put 
there seems lost in ancient history. All we know is that it was there 
when Apple donated the Mac port and according to this bug report, there 
are users out there relying on it.

When changing Contents/MacOS/libjli.dylib to a copy, loading that dylib 
and using it to launch a JVM no longer works. This patch fixes that by 
making libjli.dylib aware of potentially being located there and if so, 
finding the JDK home dir in ../Home.

I've also expanded the existing test for launching a JVM through 
libjli.dylib directly to also test this location when possible. In local 
testing, this will not be covered unless the user explicitly specifies 
that the JDK under test should be the bundle image on the command line 
like this:

$ make test-only TEST=open/test/jdk/tools/launcher/JliLaunchTest.java 
JDK_IMAGE_DIR=$PWD/build/macosx-x64/images/jdk-bundle/jdk-15.jdk/Contents/Home

But, at least in Oracle's distributed testing, the JDK on MacOS is 
distributed in the bundle layout, so there this functionality will be 
tested.

Bug: https://bugs.openjdk.java.net/browse/JDK-8238225

Webrev: http://cr.openjdk.java.net/~erikj/8238225/webrev.01/

/Erik