On 3/27/12 12:46 PM, Michael McMahon wrote:
On 27/03/12 16:03, Daniel D. Daugherty wrote:
On 3/27/12 8:05 AM, Michael McMahon wrote:
JDK 8 fix for this issue. For readers not familiar with Mac OS, this
is to
fix an issue which Apple's JDK 6 supports, but we broke in the jdk 7
initial port.
The preferred native library file suffix is .dylib on Mac, but some
legacy libraries
use the suffix .jnilib. Currently openjdk on mac does not recognise
the .jnilib suffix.
This change is to restore that behavior
http://cr.openjdk.java.net/~michaelm/7134701/webrev.1/
If this change is accepted, we will look for approval to make the
same change in 7u4.
Thanks,
Michael.
make/java/java/FILES_java.gmk
Please update the copyright year to 2012.
src/share/classes/java/lang/ClassLoader.java
Please update the copyright year to 2012.
The loadLibrary0() calls on lines 1826 and 1839 are not followed
by the new alternate name retry. It looks like these two locations
could benefit.
src/macosx/classes/java/lang/ClassLoaderHelper.java
No comments.
src/solaris/classes/java/lang/ClassLoaderHelper.java
No comments.
src/windows/classes/java/lang/ClassLoaderHelper.java
No comments.
Dan,
Thanks. Will update the copyright notices. The other loadLibrary0() calls
you refer to weren't included in the original macosx work from Apple.
So, I'm guessing they aren't in their JDK6 version.
In any case, the first one is invoked when an absolute path is provided
(including an explicit suffix). In that case we probably should not
substitute alternate filenames. For the second case, I'd argue the same,
since it is not the bootstrap classloader, and we are delegating to the
classloader's findLibrary() method, which has to return a full
absolute path as well.
Sounds reasonable to me. Might be worth a comment or two so
someone else doesn't wonder in a couple of years...
Dan
- Michael.
