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

[Erik Joelsson]

Does anyone have an opinion on this?

/Erik

On 2020-01-31 07:31, Erik Joelsson wrote:
> 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
>