RFC: add starred module(s)

Wed Feb 7 16:14:54 UTC 2018

Jiri,

I would not expect to see functionality like this available while tests 
are running. It might be reasonable to provide it as a separate utility, 
such that a test author can run it, and decide whether to incorporate or 
augment the output from such a utility in the test code, in the same way 
that import statements are not inferred by javac, but can be generated 
by an IDE.

-- Jon

On 2/6/18 2:54 AM, Jiri Vanek wrote:
> Hi guys!
>
> Thank you for all you detailed answers. Really appreciated.
> We created generator of @module tag from javac+java output to 
> workaround it.
>
> Is there possible desire to include something like it into jtreg itself?
>
> Thanx again!
>   J.
> On 12/20/2017 06:27 PM, Jonathan Gibbons wrote:
>>
>>
>> On 12/20/17 9:14 AM, Jiri Vanek wrote:
>>> On 12/18/2017 10:13 PM, Alexandre (Shura) Iline wrote:
>>>> Hi.
>>>>
>>>> I just wanted to commend on enhancing JTreg to automatically 
>>>> calculate module dependencies. Yes, compiler knows the direct 
>>>> static dependencies of the compiler code, but that is not all that 
>>>> is needed to be known. @module annotation is used for a few not 
>>>> completely related things. Besides requesting "--add-exports”, it 
>>>> can also request "--add-opens" and it can influence test selection 
>>>> during execution. Of this three usages, only one could be covered 
>>>> by static dependency analysis.
>>>>
>>>
>>>
>>> Thank you very much for this input!
>>>
>>> From what you are saying, the need for more support of 
>>> @module-whatever is needed - and doable.
>>> Current @modules is adding --add-exports and --add-opens  of the 
>>> modules you specified to the  command.
>>> If there will be way to add exports and opens of those, which can be 
>>> covered by static analyse, then it will be already more then 
>>> helpfull! Especially if you will be able to add some more manually.
>>> Of course more granular support like @modules-export and 
>>> @modules-opens and similar would be nice, but Thats more far away 
>>> from this proposal.
>>>
>>> J.
>>
>> Jiri,
>>
>> To be clear ... it is not reasonable to add such support for an 
>> enhanced @modules for use at the time the test is selected for 
>> execution and then subsequently executed.  If nothing else, there is 
>> a big chicken-and-egg problem here  ... you cannot analyse the test 
>> code until it has been compiled, and you cannot compile it until you 
>> know the module dependencies.
>>
>> In general, for existing JDK tests, the @modules have been 
>> determined. For new tests, I recommend you look to your IDE or other 
>> development-time tools, to help determine the dependencies of the 
>> test code, and then record the results in an @modules tag in the test 
>> description.
>>
>> -- Jon
>>
>>>
>>>>
>>>>> On Dec 14, 2017, at 7:56 AM, Jiri Vanek <jvanek at redhat.com> wrote:
>>>>>
>>>>> Hi Jonathan!
>>>>>
>>>>> Thank you very much for great answer. Few remarks inline.
>>>>>
>>>>>
>>>>> On 12/09/2017 02:51 AM, Jonathan Gibbons wrote:
>>>>>> 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
>>>>>
>>>>> Sure. It is last step, if it will be ever started.
>>>>>
>>>>>> ... 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
>>>>> terrible truth. see at bottom.
>>>>>
>>>>>> 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
>>>>>
>>>>> I was reading most of this discussion, and I can agree with it for 
>>>>> final deployment, but not for testing.
>>>>>> 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.
>>>>>
>>>>> This is probably the only sentence I moreover disagree with you. 
>>>>> Jtreg is far away fro being tinny wrapper, and it always did huge 
>>>>> help for tests authors.  So helping testers with setting up module 
>>>>> path a bit, may be good step.
>>>>>> 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
>>>>>
>>>>> Still you need to enumerate them all. That mean to run javac and 
>>>>> jmod in loops  one by one, untill you get collect them.
>>>>>> 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.
>>>>>
>>>>> Well, shell lunchers have theirs dark sides, thats right. But are 
>>>>> awesome feature without replacement.
>>>>>> And as you note below, processing variables like TESTMODULES is 
>>>>>> problematic. (It is a bug if present for JDK 8 tests).
>>>>>
>>>>> Its a bug :)
>>>>>> 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.
>>>>>
>>>>>
>>>>> You are mostly right. But consider this: The locating of modules 
>>>>> is painful when you are dealing with private apis. And that is 
>>>>> what you do in jtregs for half of the time...
>>>>> So naturally, the help would be easy.
>>>>> On contrary, the help do not come from JDK itself in any 
>>>>> "supported" way (or am I missing something?)
>>>>> Still the javac can do so. So it would be natural to enahnce javac 
>>>>> to help with this a bit more via some more solid api. Maybe you 
>>>>> know something here?
>>>>>
>>>>> One would say, that writing private api jtreg is one or two 
>>>>> modules usage only. Unluckily, oposite is true, and Mila's * idea 
>>>>> is another proof of it. And If I look to past to my recent work, I 
>>>>> was facing the same. Just got angry later.
>>>>>
>>>>>
>>>>> So generally - some help should be provided in JDK to deal with 
>>>>> it. And as JDK looks to have its reasons to not to do so, Jtregs 
>>>>> should.
>>>>>
>>>>>
>>>>> Thanx for again for your reply!
>>>>>   J.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>