Bugfix: do not set TESTMODULES environment variable if JDK is not modular

[Miloslav Zezulka]

Hello Jonathan,

> So, given that (versions of) test suites are generally specific to a
version of the JDK...

That is correct for most of the test cases. However, there could be (and
are in the reproducers we work with) tests common for non-modular and
modular JDKs which are based on this scenario:

Test123.java
Test123.sh <- jtreg test which calls javac and java of Test123

So. to avoid copy and pasting the same test for different JDKs, it would be
nicer to rely on the fact that the TESTMODULES property will not be
exported for non-modular ones. Of course, we could also rewrite all the
shell tests to the point when they would not require shell jtregs
whatsoever, but my suggested solution would require very few changes to the
already existing tests (and would not enforce copy and pasting). It is also
worth mentioning that this "hack" already works with Java jtregs where it
is possible to run tests, containing @modules entry, with a non-modular JDK.

> And, if there is a plausible test case for such tests, the fix is
arguably incomplete, because the TEST* environment variables for shell
> tests mirror the test.* system properties for Java tests.

I guess you are right. Attached is the script which deals with the root
cause.

On Tue, Feb 6, 2018 at 5:36 PM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> Jiri, Mila,
>
> I wonder why the fix is necessary.
>
> TESTMODULES contains a property of the test description (the @modules
> entry).  The env variable will not be set if the value is empty.
>
> So, given that (versions of) test suites are generally specific to a
> version of the JDK, I wonder why you are trying to run tests with @module
> entries on a non-modular JDK.
>
> And, if there is a plausible test case for such tests, the fix is arguably
> incomplete, because the TEST* environment variables for shell tests mirror
> the test.* system properties for Java tests.
>
> I think a better direction would be to warn against the use of @modules on
> a non-modular JDK.
>
> -- Jon
>
>
> On 2/6/18 2:55 AM, Jiri Vanek wrote:
>
>> On 12/20/2017 05:35 PM, Jiri Vanek wrote:
>>
>>> On 12/15/2017 11:37 AM, Miloslav Zezulka wrote:
>>>
>>>> This is a very small patch fixing the issue pointed out in $subject.
>>>> I've
>>>> added checks for both compile and test JDK - is this an overkill, since
>>>> most of the time the implication goes COMPILEJDK.modular =>
>>>> TESTJDK.modular, or a necessary thing to have for foolproofness?
>>>>
>>>
>>> ping?
>>
>>>
>>> Works fine. Johnatan, can you push it? Or do you wont mila to create
>>> regular webrev? Is there some place to add test for it?
>>>
>>> Tahnx a lot!
>>>    J.
>>>
>>>
>>>
>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testmodulesenv.patch
Type: text/x-patch
Size: 729 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/jtreg-dev/attachments/20180207/a62c0821/testmodulesenv.patch>