RFR: 8352046: Test testEcoFriendly() in jdk tools launcher ExecutionEnvironment.java for AIX and Linux/musl is brittle [v3]

[Christoph Langer]

On Wed, 26 Mar 2025 09:52:27 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> The test `testEcoFriendly()` checks if the launcher pollutes the `LD_LIBRARY_PATH` environment variable.
>> Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does not make sense to make this test somehow passing with crude workarounds, which even do not work in any case. It only works when the test is executed by jtreg without explicitly setting `LD_LIBRARY_PATH`.
>> 
>> The problem occurs if the `LD_LIBRARY_PATH` is set from outside, so the test is called with an already set `LD_LIBRARY_PATH`. This means internally the `LD_LIBRARY_PATH` is polluted with the generic pollution on AIX/musl  (called A) and the additional jtreg set `LD_LIBRARY_PATH` (called B).
>> The result is, the test has A:B in its `LD_LIBRARY_PATH`. Then the test launched a new VM also with an explicitly given `LD_LIBRARY_PATH` (called C). This VM has the resulting `LD_LIBRARY_PATH` A:C which is being reported to the calling Test.
>> Now the test compares the returned A:C against the A:B from the test adding the known C. `if (A:C == A:B:C)`.
>> Because the test neither knows A nor B, but only C there is now way to program a working comparison. It only works if B is empty meaning the test is not called by jtreg with a preset `LD_LIBRARY_PATH`
>> 
>> Unfortunately we now have to call all tests with a given runtime search path provided in `LD_LIBRARY_PATH`.
>> So my proposal is to skip this sub test for aix and musl.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup

test/jdk/tools/launcher/ExecutionEnvironment.java line 31:

> 29:  * @modules jdk.compiler
> 30:  *          jdk.zipfs
> 31:  * @compile -XDignore.symbol.file ExecutionEnvironment.java

One addition as for cleaning: I'm wondering whether we need this @compile directive with `-XDignore.symbol.file`. I guess this can be removed, too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24055#discussion_r2015784618