Re: RFR: 8268974: GetJREPath() JLI function fails to locate libjava.so if not standard Java launcher is used [v4]
> 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(). Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into JDK-8268974 - Test added - - Comments updated. - pathisso -> pathisdll. - 8268974: jpackage fails to handle --dest option containing "bin" folder - Changes: - all: https://git.openjdk.java.net/jdk/pull/4534/files - new: https://git.openjdk.java.net/jdk/pull/4534/files/19ac6551..7934b977 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=4534=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4534=02-03 Stats: 88952 lines in 1561 files changed: 47547 ins; 34348 del; 7057 mod Patch: https://git.openjdk.java.net/jdk/pull/4534.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4534/head:pull/4534 PR: https://git.openjdk.java.net/jdk/pull/4534
Re: RFR: 8268974: GetJREPath() JLI function fails to locate libjava.so if not standard Java launcher is used [v3]
On Wed, 7 Jul 2021 18:54:23 GMT, Alexey Semenyuk 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(). > > Alexey Semenyuk has updated the pull request incrementally with one > additional commit since the last revision: > > Test added Marked as reviewed by herrick (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/4534
Re: RFR: 8268974: GetJREPath() JLI function fails to locate libjava.so if not standard Java launcher is used
On Sat, 3 Jul 2021 07:41:40 GMT, Alan Bateman wrote: >> 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. @AlanBateman jpackage test reproducing the issue added. - PR: https://git.openjdk.java.net/jdk/pull/4534
Re: RFR: 8268974: GetJREPath() JLI function fails to locate libjava.so if not standard Java launcher is used [v3]
> 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(). Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: Test added - Changes: - all: https://git.openjdk.java.net/jdk/pull/4534/files - new: https://git.openjdk.java.net/jdk/pull/4534/files/18aa7427..19ac6551 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=4534=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4534=01-02 Stats: 50 lines in 1 file changed: 50 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/4534.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/4534/head:pull/4534 PR: https://git.openjdk.java.net/jdk/pull/4534
Re: RFR: 8268974: GetJREPath() JLI function fails to locate libjava.so if not standard Java launcher is used
On Sun, 20 Jun 2021 07:25:54 GMT, Alan Bateman 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
Re: RFR: 8268974: GetJREPath() JLI function fails to locate libjava.so if not standard Java launcher is used
On Sun, 20 Jun 2021 07:25:54 GMT, Alan Bateman 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? - PR: https://git.openjdk.java.net/jdk/pull/4534
