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

Suchismith Roy sroy at openjdk.org
Fri Mar 22 10:19:22 UTC 2024


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

> 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?

The behaviour is deterministic when we have a case where, a .so file maps to .a file without specifying any members. This was the original intention for mapAlternateName so that we can use loadLibrary to load shared objects with .so format, and on failure we fallback and check if .a exists.

But to mention the member object, it looks to me that we must specify the full name and there is no direct mapping. So then we restrict that to only System.load and not System.loadLibrary ?

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

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


More information about the core-libs-dev mailing list