RFR: JDK-8213362 : Could not find libjava.dylib error when initializing JVM via JNI_CreateJavaVM
kevin.rushforth at oracle.com
Wed Nov 28 13:03:13 UTC 2018
This is related to a bug I filed back in October, JDK-8211959 , in
which JLI_Launch is failing for the same reason. The fix to
java_md_macosx.m is the same one I identified in that bug. You might
consider adding a test that calls JLI_Launch, but either way,
JDK-8211959 can be closed as a duplicate of JDK-8213362.
On 11/28/2018 12:46 AM, Alan Bateman wrote:
> On 27/11/2018 23:05, Henry Jen wrote:
>> Please review a follow up webrev based on Priyanka’s patch, it
>> simply added a test case for Mac only that will link with libjli.
>> Note that, to use invoke API, one should probably link with libjvm,
>> which works for all supported platforms, not just Mac.
>>  http://cr.openjdk.java.net/~henryjen/jdk12/8213362.0/webrev/
> The changes to java_md_macosx.m looks okay although the issue as to
> how Eclipse runs into this have not been established. If Eclipse
> dlopen's libjvm then it should have no issue locating and calling
> JNI's CreateJavaVM. It may be that Eclipse is using libjli directly
> but it shouldn't do that because it's not a documented/supported
> interface. It might be that it's using the CFBundleExecutable key in
> Info.plist. Henry, Priyanka and I discussed this a bit and were not
> able to able to establish what it is doing.
> On the test: it's clear whether you've moved or copied
> test/hotspot/jtreg/runtime/jni/CalleeSavedRegisters/FPRegs.java. The
> webrev suggests you've moved it but it's doesn't handle hg copy.
> Either way, it needs clean up, e.g. it shouldn't need @modules
> java.base/jdk.internal.misc, the really long lines make it difficult
> to look at side-by-side changes, why does it check for Windows when
> the @requires means it runs on Mac only. I assume we can find a better
> name for exeJNILauncher.c. It will also need a copyright header.
More information about the core-libs-dev