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

[Suchismith Roy]

On Mon, 25 Mar 2024 18:43:33 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Do you expect if developers start to package shared objects in the format of archive objects? If so, it would be reasonable to support #1 for compatibility.

Yes. I agree. We should keep this compatibility for entire flow from classloader to the hotspot code. And it has been in J9 for long time for the exact same reason, which actually brought out the issue for dcstartup in OpenJDK.

> For #2, `System::loadLibrary("foo(libfoo.so.1)"`, `System::load("/usr/lib/libfoo.so((libfoo.so.1)")` and `System::load("/usr/lib/libfoo.a((libfoo.so.1)")` are never supported. I think applications should use `SymbolLookup::libraryLookup` instead on Java 22 and later. I don't use `libclang` as the example here because that's related to jextract and has nothing to do with `System::load` as Maurizio said.

I just feel keeping load functionality is still applicable, which does not expect a deterministic mapping (or does it ? ). if loadLibrary expects this to be deterministic, then i agree, we should drop that.

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

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