United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7134701 [macosx] Support legacy native library names
JDK-7134701 : [macosx] Support legacy native library names

Details
Type:
Bug
Submit Date:
2012-01-27
Status:
Closed
Updated Date:
2012-04-13
Project Name:
JDK
Resolved Date:
2012-04-13
Component:
core-libs
OS:
os_x
Sub-Component:
java.net
CPU:
unknown,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
7u4
Fixed Versions:
7u4 (b20)

Related Reports
Backport:
Duplicate:

Sub Tasks

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
WORK AROUND

Rename .jnilib files to .dylib
                                     
2012-01-27
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.
                                     
2012-03-25
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.
                                     
2012-03-25



Hardware and Software, Engineered to Work Together