RFC: add starred module(s)

[Jonathan Gibbons]

Jiri, Mila,

There are three significant questions here.

1. @modules all-needed

This is a non-starter. @modules participates in a relatively 
light-weight test selection mechanism ... i.e. tests are not selected if 
the specified modules are not available in the system image. Having 
jtreg analyse the source code to determine the set of necessary modules 
is just not practical.

2. Starred modules, as in @modules 
java.security.jgss/sun.security.krb5.internal.*

Setting aside whether this is desirable or not, this is not necessarily 
an easy thing to do. It requires that we can list the (internal) 
packages of a module. Yes, there may be a attribute that provides the 
info, but the attribute is not guaranteed to be available, and if it's 
not, you're reduced to scanning the module contents.  On the 
desirability point of view, the use of this sort of syntax was 
discussed, and rejected, for module declarations, and while that is 
separate from what is proposed here, it does lend guidance.  Neither is 
the '*' syntax supported by the options for the Java launcher or javac, 
and this construct is intended to be a thinly-veiled wrapper for those 
options.

One minor comment ... you can reduce the "wordiness" of your examples by 
almost 50% by just having a single @modules directive with many arg 
values, possibly spanning many lines, as in ...

   * ....
   * @modules java.security.jgss/sun.security.krb5.internal
   * java.security.jgss/sun.security.krb5.internal.ccache
   * java.security.jgss/sun.security.krb5.internal.crypto
   * java.security.jgss/sun.security.krb5.internal.ktab
   * java.base/sun.security.util
   * java.security.jgss/sun.security.jgss

3. Shell scripts.

Using shell scripts for jtreg tests is generally discouraged, these 
days, to the point that we have made efforts to convert many/most JDK 
shell tests to Java code. The general experience was that such tests 
were very fragile, and were often wrong/broken. They typically execute 
slower than equivalent Java code, especially when using libraries 
providing commonly-used or domain-specific functionality. And as you 
note below, processing variables like TESTMODULES is problematic. (It is 
a bug if present for JDK 8 tests).

When using Java code instead of shell scripts, you can look to libraries 
in the various test suites for suggestions on useful methods to provide, 
such as invoking generating and compiling source code, providing simple 
equivalents for regex search (simple grep), comparison (simple diff), 
etc, as well as support for running subprocesses when necessary. One 
common pattern is to use Java code to validate whether it is appropriate 
to run a test in the current configuration and to then launch a JVM with 
a selected combination of options. This sort of mode has explicit 
support in jtreg:  "@run driver" is similar to "@run main" for running a 
class, but it is not run with any JVM options intended for test JVMs. 
This makes it suitable for running "test driver" classes which spawn 
JVMs to run the "real" test code.  And if you're just writing API tests, 
then I recommend using plain old Java code and "agentvm" mode to have 
the tests as fast as possible.

-- Jon


On 12/05/2017 02:01 AM, Jiri Vanek wrote:
> Hi Jonathan!
>
> I think this proposal have quite a sense.  I was moving our old jtreg 
> tests to work with jdk9 too, and copy pasting on module level is 
> terrible.
>
> This proposal is cool. It is keeping encapsulation in place and 
> lowering the writing a lot.
> I would go even more deep, eg " @modules all-needed", and jtreg will 
> deduct necessary --add-whatever on its own.
>
> The shell part is even more worse. And especially the shell part is 
> where jtreg is hard to replace (read: I like jtreg here very much :) )
> Here you get only TESTMODULES variable which is not enough, and 
> (unlike in java file) it is here even for jdk8 and older.
> So maybe there can be one more variable, containing full 
> --add-whatever string  which got filled only for modular jdk?
>
> I will be happy to implement those features if you agree with the 
> principle.
>
>
> Thanx!
>   J.
>
>
>
> On 11/30/2017 02:21 PM, Miloslav Zezulka wrote:
>> Hello,
>>
>> when working with @modules tag, it might be sometimes beneficial to have
>> the ability to open multiple packages from the same parent using one
>> @modules tag only (for example via star notation as in regular java
>> imports). The idea came to my mind when modifying some CPU 
>> reproducers to
>> be compatible with JDK9. Let's consider a JTreg comment for one of them:
>>
>>   * ....
>>   * @modules java.security.jgss/sun.security.krb5.internal
>>   * @modules java.security.jgss/sun.security.krb5.internal.ccache
>>   * @modules java.security.jgss/sun.security.krb5.internal.crypto
>>   * @modules java.security.jgss/sun.security.krb5.internal.ktab
>>   * @modules java.base/sun.security.util
>>   * @modules java.security.jgss/sun.security.jgss
>>   */
>>
>> Although this has the advantage thta we explicitly know which internal
>> packages are being opened for the given test, someone might prefer to 
>> use
>> the @modules tag the folllowing way to make the JTreg comment more 
>> readable
>> and less wordier:
>>
>>   * ....
>>   * @modules java.security.jgss/sun.security.krb5.internal.*
>>   * @modules java.base/sun.security.util
>>   * @modules java.security.jgss/sun.security.jgss
>>   */
>>
>> As a JTreg newbie, I wasn't able to find such feature in the current
>> version. The attached patch is a draft of how this might be implemented.
>>
>> Thoughts?
>>
>> Thanks,
>> Míla
>>
>
>