RFR: JDK-8319516 - Native library suffix impact on the library loading in AIX- Java Class Loader [v4]

[Suchismith Roy]

On Thu, 21 Mar 2024 22:23:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > (I'm pessimistic)
> 
> To summarize: I think that allowing version-specific names (even if surrounded by parenthesis) in `System::loadLibrary` would be very odd. After all, `System::loadLibrary` doesn't support versioned names, even on other systems (and adding support for versioned library names across different platforms is a much bigger effort).
> 
> For this reason, the only thing that would make sense for `loadLibrary` to support is `clang` which will be expanded (by `mapLibraryName`) to `clang(libclang.so)`. But, even assuming this works: wouldn't we still have an issue? As far as I understand (and given the code in this patch), we don't really know (before calling `dlopen`) whether the suffix is needed or not: whether it's an archive with an `.so` inside, or whether it's a plain `.so`. So how can the behavior of `mapLibraryName` be deterministic?

yes, i think the member needs to be specified in full. AIX archives can be both static and shared, so to mention the shared object member, we need to put the braces. 
But we also have cases, where a .so file when it doesn't exists will map deterministically to .a file , in which we use the loadlibrary. 
Specifying member objects is in addition to it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17945#issuecomment-2014741652