-
Bug
-
Resolution: Fixed
-
P2
-
7u4
-
b20
-
generic, unknown
-
os_x
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2222679 | 8 | Michael McMahon | P4 | Closed | Fixed | b34 |
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.
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.
- backported by
-
JDK-2222679 [macosx] Support legacy native library names
-
- Closed
-
- duplicates
-
JDK-7143005 [macosx] Re-introduce .jnilib support
-
- Closed
-
- relates to
-
JDK-7157665 Use ClassLoaderHelper for all native library loads [macosx]
-
- Open
-