RFR: 8352046: Test testEcoFriendly() in jdk tools launcher ExecutionEnvironment.java makes no sense for aix and musl

[Christoph Langer]

On Fri, 21 Mar 2025 09:46:02 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.
>
> @vidmik @axel7born Can please someone take a look at this PR, because I want to change something you implemented 5 years ago. Maybe @dholmes-ora @alanb @erikj who did the review may also take a look.

Thanks for enhancing the PR description @JoKern65. So, the problem appears because in our test scenario we now pass a certain LD_LIBRARY_PATH option, which we didn't do before.

So, I agree that the test for AIX and MUSL could be skipped because the assumption of a pristine LD_LIBRARY_PATH doesn't hold there since the launcher sets an LD_LIBRARY_PATH on purpose. However, can't we construct exactly this path in the test with the information that we have, e.g. the java.home system property?

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

PR Comment: https://git.openjdk.org/jdk/pull/24055#issuecomment-2743116596