RFR: 7134701 [macosx] Support legacy native library names

[Scott Kovatch]

On Mar 28, 2012, at 5:52 AM, Michael McMahon <michael.x.mcmahon at oracle.com> wrote:

> On 28/03/12 08:40, Alan Bateman wrote:
>> I just checked a Mac OSX 10.6.8 system with 6u29 installed and System.mapLibraryName("foo") returns foo.jnilib. Do you know if this was always the case? If so then I think there is an argument to be made that the default should be .jnilib and .dynlib be the fallback, especially if it's going to break anyone using mapLibraryName (my guess is that mapLibraryName usages are rare, at least compared to System.loadLibrary).

I don't know this for certain, but I suspect it's been that way for a long time.

> Maybe, we should be doing what Dan Daugherty suggested yesterday and re-mapping the native
> filename in the case where a full absolute path is passed in (which is the code-path
> when System.load() is called above)
> 
> My reasoning (for rejecting that) was that an absolute path is a request for an explicit name
> eg. System.load("/abs/path/libfoo.dylib") and it seems odd to go modifying the path that
> the user provided (as opposed to the System.loadLibrary("foo") case, where we have to
> construct the path internally). But, I hadn't considered the case above where the path
> is constructed by calling System.mapLibraryName().
> 
> So, I think a better approach might be to just to check for the old ".jnilib" suffix in all
> the cases, rather than changing System.mapLibraryName(). Otherwise, we'll have an inconsistency
> forever more between the output of that method and the library suffix that we want people
> to use.
> 
> I've attached the jdk8 diffs for doing this.

Thanks! I'll give it a try this morning. I have a couple of JNLP-based apps that were hitting this, too, so I'll do some extra testing.

-- Scott