RFR: JDK-8238225: Issues reported after replacing symlink at Contents/MacOS/libjli.dylib with binary
erik.joelsson at oracle.com
Tue Feb 4 17:45:26 UTC 2020
Does anyone have an opinion on this?
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
> But, at least in Oracle's distributed testing, the JDK on MacOS is
> distributed in the bundle layout, so there this functionality will be
> Bug: https://bugs.openjdk.java.net/browse/JDK-8238225
> Webrev: http://cr.openjdk.java.net/~erikj/8238225/webrev.01/
More information about the core-libs-dev