RFR: 7134701 [macosx] Support legacy native library names
David Holmes
david.holmes at oracle.com
Sun Apr 1 13:28:24 UTC 2012
Alan, Michael,
This sounds like a case where a property to control what the preferred
library suffix is might be useful as a migration aid. Though the
fundamental flaw in the API is assuming there is only a single suffix.
David
On 1/04/2012 11:16 PM, Alan Bateman wrote:
> On 28/03/2012 10:52, Michael McMahon wrote:
>>
>> 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.
>>
>> - Michael
> I checked Apple's JDK6 and it looks to me that they always favor .jnilib
> over .dylib. If I compile some native code to two shared libraries, one
> with the .dylib suffix and the other with .jnilib then with Apple's JDK6
> it always seems to load the .jnilib version. If only the .dylib library
> exists then it loads that. Also, as per a previous post, the
> System.mapLibraryName method with Apple's JDK6 seems to favor .jnilib
> too. This makes wonder about the original patches in the bsd-port and
> macosx forest as the comments there suggest that ".jnilib" is legacy
> when it seems to have been the favored suffix in JDK6 at least.
>
> Anyway, for jdk7 & jdk8 it looks like we are making a break from the
> past and supporting .jnilib is just to give developers a chance to
> migrate. In that context Dan's suggestion and your latest patch seems
> reasonable but does lead a few anomalies - for example
> System.loadLibrary with an absolute path might succeed even though the
> library will appear to not exist if tested separately. Also I wonder
> about System.mapLibraryName where someone tests to see if the library
> exists before then invoke System.loadLibrary. My guess is that there
> isn't a perfect solution to this as there will always been anomalies in
> a migration like this.
>
> On the latest webrev then the use of final at L1867 is a bit odd and can
> be removed. For the jdk8 version then the fromClass needs to be Class<?>.
>
> -Alan
>
>
>
>
>
More information about the core-libs-dev
mailing list