RFR: 7134701 [macosx] Support legacy native library names

[Scott Kovatch]

With this patch in place I can load the applet at Runescape.com now. I can't log in yet due to an AWT bug I probably haven't patched yet, but this is better than what it was. 

Minecraft.net is still giving me problems because it's bailing out before this change takes place. Here's the method in question:

private static void doLoadLibrary(final String lib_name) {
	AccessController.doPrivileged(new PrivilegedAction<Object>() {
		public Object run() {
			String library_path = System.getProperty("org.lwjgl.librarypath");
			if (library_path != null) {
				System.load(library_path + File.separator +
					System.mapLibraryName(lib_name));
			} else {
				System.loadLibrary(lib_name);
			}
			return null;
		}
	});
}

It's failing because System.mapLibraryName is constructing a library named liblwjgl.dylib, but lwjgl only has 'liblwjgl.jnilib'. Apple's JDK 6 (and I suspect macosx-port) gives me 'liblwjgl.jnilib' for System.mapLibraryName("lwjgl").

I can't even get this far with Apple's JDK 6 on minecraft.net, so it's hard to say this is a pure regression. I'm hesitant to suggest that we have mapLibraryName start returning a library named lib<xxx>.jnilib at this point. 

Any ideas for a workaround? I think your ClassLoader/System change shown here should still go in, but in this particular case we still have problems. I don't know how much code is out there that uses mapLibraryName in this way.

-- Scott

On Mar 27, 2012, at 2: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.
> 
> - Michael.