On Thu, 24 Feb 2022 18:51:08 GMT, Roger Riggs <rri...@openjdk.org> wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Add null check > > The piece I was missing is that the HotSpot AIX specific code, computes and > sets LIBPATH based on > the path to the java executable. This computed LIBPATH value is set in the > environment unless > it is overridden by an existing LIBPATH in the environment. > > The test cases that failed, do not supply a value for LIBPATH so the launcher > provided value is inserted > and thereafter reported as the environment from the child process. > > Since both of these tests are testing a different condition not related to > LIBPATH, > the presence/accuracy of LIBPATH is not the point of the test. > > The current solution to remove `test.nativepath` works and is ok by me. > > (The alternative used by #7581, to include LIBPATH in the environment when > launching might be slightly more robust to future changes.) > > Thanks for the followup. > Thanks @RogerRiggs and @tstuefe . I appreciate your deeper investigations. > Could you give me some advice on what to do next? Hi @takiguc, My preference would be to spawn `sh -c env` instead of java, since it removes all need for second-guessing what the java child does with the environment (java modifies the environment and also conceivably System.getenv() may lie to us at some point in the future since it seems a convenient way to filter environment variables for java programs). That is if my reasoning was correct in the first place. But I do not have a strong preference and defer to Roger and Tyler. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/7574
