RFR: 7134701 [macosx] Support legacy native library names

[Daniel D. Daugherty]

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.