JDK-7134701 : [macosx] Support legacy native library names
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 7u4
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: os_x
  • CPU: generic,unknown
  • Submitted: 2012-01-27
  • Updated: 2017-05-17
  • Resolved: 2012-04-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8
7u4 b20Fixed 8Fixed
Related Reports
Duplicate :  
JDK-7143005 - [macosx] Re-introduce .jnilib support
Relates :  
JDK-7157665 - Use ClassLoaderHelper for all native library loads [macosx]
Description
As part of 7134690 we are removing some ugly mac specific code from jdk:src/share/classes/java/lang/{System,ClassLoader}.java which searches for alternative (legacy) native
library names on the Mac. 

If someone wants to load "libfoo" then the default on the mac is to look for libfoo.dylib. The legacy
behavior meant we would also search for libfoo.jnilib if the other variant didn't exist.

Apple are pushing towards standardizing on .dylib anyway and we can live without this functionality in the short-term. But, it might be needed for legacy support and it looks like the best place for it might
be in the BSD os::dll_build_name() function.

Apparently, Minecraft on Mac might be affected by this. But since it uses the plugin we wouldn't be
supporting it anyway in the first release. But, we might need to support it some time in the future.
Comments
EVALUATION Quick note, the code changes are in System.java and ClassLoader.java on the JDK side. The aforementioned hotspot code is used to load native libraries used by hotspot, such as libverify, libzip, and libjava. So, the real solution for JNI libraries is in the JDK.
25-03-2012
EVALUATION After implementing a quick prototype to support additional JNI library suffixes, I rediscovered the Apple contribution and solution for this support. The two solutions are remarkably similar. Thus, the Apple solution appears to be the correct approach. :) I've started with the Apple solution and made a few improvements to make it more generic and performant. The two testcases I've been working with now pass with the libraries named *.jnilib or *.dylib. More rigorous testing required to ensure there are no regressions on other platforms.
25-03-2012
WORK AROUND Rename .jnilib files to .dylib
27-01-2012