RFR: 7134701 [macosx] Support legacy native library names

[Michael McMahon]

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.

- Michael.