RFC: add starred module(s)

Wed Feb 7 21:17:33 UTC 2018

Understood.  I was just explaining that rationale for suggesting a 
separate utility.

-- Jon

On 02/07/2018 01:01 PM, Alexandre (Shura) Iline wrote:
>
>> On Feb 7, 2018, at 9:57 AM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
>>
>> I think it would be a challenge to fit such a utility into the jtreg command line,
> This is what I meant saying that the tool would not be a part of JTReg itself. Sorry if I was not clear.
>
> Shura
>
>> and so at least to begin with, a separate utility would be a better sandbox for experimentation.
>>
>> -- Jon
>>
>> On 02/07/2018 08:57 AM, Alexandre (Shura) Iline wrote:
>>> +1
>>>
>>> We have (at least Jon and myself) in the past discussed an idea to have a separate tool to verify @module tags in tests. I too was originally suggesting to change JTReg for that and Jon convinced me that is not the best way to go. Last time we discussed that perhaps such tool could be a part of JTReg source repository, and even a part of JTReg distribution (?) but not the JTReg itself.
>>>
>>> I think it is important to agree on what this tool would be doing exactly, before proceeding to an implementation. I have some internal code which is doing some of the things - I would be glad to contribute that if it helps others.
>>>
>>> Shura
>>>
>>>> On Feb 7, 2018, at 8:14 AM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
>>>>
>>>> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>