On Thu, 21 Mar 2024 17:06:23 GMT, Jaikiran Pai <j...@openjdk.org> wrote:
>>> But there is no actual file named libclang.a(libclang.so.16) in the >>> filesystem. >> So when the check is done if file exists, it fails,i.e it checks for >> libclang.a(libclang.so.16). >> >> I'll let Mandy and others more knowledgable of this area to correct me. From >> what I know, there was a change done a few releases back in the JDK >> (https://bugs.openjdk.org/browse/JDK-8275703) which accomodated macos >> platform where it too doesn't actually have the file on the filesystem in >> recent versions of macos. That change allowed platform specific code to >> dictate whether the file existence check needs to be done here in this >> loadLibrary code. That's done through the call to >> `jdk.internal.loader.ClassLoaderHelper.loadLibraryOnlyIfPresent()`. For >> macos, that implementation of that method resides in macos specific class >> here >> https://github.com/openjdk/jdk/blob/master/src/java.base/macosx/classes/jdk/internal/loader/ClassLoaderHelper.java#L41. >> For AIX too then, perhaps you could add an implementation which returns >> `false` (either always or in specific cases) and experiment with that to see >> if that's enough? > >> For AIX too then, perhaps you could add an implementation which returns >> false (either always or in specific cases) and experiment with that to see >> if that's enough? > > I see that you actually have a ClassLoaderHelper in this PR for AIX, but that > implementation in `loadLibraryOnlyIfPresent()` is currently returning `true` > and thus enforcing the file existence check. Was it intentional to have it to > `true`? Given the context of this change, shouldn't it be returning `false`? Correct. Had kept it as true, as it was in J9. but changing it to false works. So that would mean we are letting the java Runtime to handle paths that don't exist ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17945#discussion_r1535320320
