RFR: 8268974: GetJREPath() JLI function fails to locate libjava.so if not standard Java launcher is used

Alan Bateman alanb at openjdk.java.net
Sat Jul 3 07:44:55 UTC 2021


On Sun, 20 Jun 2021 07:25:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> GetApplicationHomeFromDll() fails if the path to libjli.so contains "bin" component (/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so). TruncatePath() looks for "/bin/" first in "/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so" string and then it looks for "/lib/". But this is wrong order as it should look for "/lib/" first. I.e. TruncatePath() should look for "/bin/" and then for "/lib/" if called from GetApplicationHome() and for "/lib/" first and then for "/bin/" if called from GetApplicationHomeFromDll().
>
> Is it possible to add a test for this that is completely independent of jpackage? I think there are a few existing tests that copy the run-time image to a new location for testing purposes.
> 
> We may need to rename the JBS description to make it clearer what this issue is about.
> 
> A minor nit is that "pathisso" will be confusing to anyone looking at this code, maybe find a better name or put a comment in TruncatePath to explain it. I assume the comments at the findLastPathComponent use site will also need to be clarified.

> @AlanBateman any input on this issue from you?

Same comment as before, I think we should try to add a test.  If a native test that links to libjli isn't feasible then a jpackage test that creates the scenario that Maurizio ran should be okay.

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

PR: https://git.openjdk.java.net/jdk/pull/4534


More information about the core-libs-dev mailing list