JDK-7158157 : [macosx] Can't find native libraries with .jnilib in Web Start apps
- Type: Bug
- Component: deploy
- Sub-Component: webstart
- Affected Version: 7u6
- Priority: P2
- Status: Closed
- Resolution: Fixed
- OS: os_x
- CPU: x86
- Submitted: 2012-03-30
- Updated: 2013-12-09
- Resolved: 2012-04-12
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.
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 |
|---|---|
7u6Fixed  |
8 b34Fixed |
Description
Beginning with 7u4, .dylib is the correct extension for native libraries, but many Mac OS X-based Web Start apps and signed applets still use the old but equally valid .jnilib.
JNLPClassLoader and its variants now assume that native libraries will be named .dylib on mac OS X in findLibrary() when searching for them in the cached resources, so apps that call System.loadLibrary("xxx") will now fail if the library 'xxx' is named libxxx.jnilib.
JNLPClassLoader, JNLP2ClassLoader and JNLPPreVerifyClassLoader all need to look for both dylib and jnilib on Mac OS X. Also, Platform defines two methods for the prefix and suffix of native libraries, but instead we should just use System.mapLibraryName() to return the proper name instead of doing it ourselves.
Comments
|