Rather than naming the enum for the test cases as "CASE", more
conventional naming would be "TestCase" or "Case" for the type itself.
-Joe
On 1/16/2019 9:30 AM, mark.reinh...@oracle.com wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8216532
Webrev: https://cr.openjdk.java.net/~mr/rev/8216532/
The fix for 8210669 [1] enabled some tests to run that had not been
running, and perhaps had never run.
Amongst these tests was tools/launcher/Test7029048.java, which is meant
to ensure that the Java launcher defends itself against interfering
settings of the LD_LIBRARY_PATH environment variable, as implemented in
the fix for 7029048 [2].
It took me quite a while to understand exactly what this test was doing,
but in the end the root cause was that the test could not distinguish
between an LD_LIBRARY_PATH value that’s empty from one that contains
just a single path. This is important on Solaris, where the test also
checks that setting LD_LIBRARY_PATH_64 does not interfere with the
launcher. In this context the environment variable can contain either
no path or just one path, depending upon which case is being tested.
I fixed this accounting problem and, while I was at it, made a few other
changes to clarify the test for future maintainers.
In a cruel twist of fate, it turns out that the behavior implemented for
7029048, and verified by this test, is incorrect. On Solaris, if you
set LD_LIBRARY_PATH_64 then that completely overrides any setting of
LD_LIBRARY_PATH. The launcher tries to defend itself against a setting
of LD_LIBRARY_PATH_64 by setting LD_LIBRARY_PATH, but that will have no
effect -- it should really set LD_LIBRARY_PATH_64. I’ve filed 8217216
[3] to record this.
Passes tiers 1-4 on {linux,macosx,windows}-x64 and solaris-sparcv9.
Thanks,
- Mark
[1] https://bugs.openjdk.java.net/browse/JDK-8210669
[2] https://bugs.openjdk.java.net/browse/JDK-7029048
[3] https://bugs.openjdk.java.net/browse/JDK-8217216
