RFR 8199193: jshell tool: Add support for preview features

Jonathan Gibbons jonathan.gibbons at oracle.com
Mon Apr 23 18:54:59 UTC 2018



On 04/23/2018 11:23 AM, Robert Field wrote:
>
>
> On 04/23/18 09:14, Jonathan Gibbons wrote:
>> You need @modules.    You may not need to export/open any internal 
>> API, but you certainly need the presence of certain modules.
>
> Thanks.
>
> Since tests are generally run with the full JDK, they do not verify 
> the correctness of the @modules tag.  Do we have a way to 
> verify/generate the correct entries?  Without testing, won't these 
> descend into meaningless cloning of @modules or missing @modules?

It is desirable that we should be able to run all appropriate tests on 
small systems created with jlink. Shura is looking at ways to validate 
the @modules tag. It is generally obvious when not enough @modules are 
specified; it it somewhat harder to check whether or not any unnecessary 
modules have been specified.

>
> The tag spec:
>
>    http://openjdk.java.net/jtreg/tag-spec.html
>
> Does not document :open, ...

I'll update that copy. The copy in the jtreg repo has been updated.

>
> @modules <module>[/<package>[:<flag>]]+
>
>     Express a dependence on modules in the system being tested, and
>     optionally, on selected internal packages in some or all of those
>     modules.
>
>     If no dependencies are specified explicitly, a default set of
>     dependencies will be read from the |modules| entry in test suite
>     configuration files <cid:part1.06070809.08030803 at oracle.com>.
>
>     The dependencies will be ignored if the version of JDK used to run
>     the tests does not support the use of modules. Otherwise, a test
>     will not be run if the system being tested does not contain all of
>     the specified modules. All of the specified modules will be
>     present in the configuration when the test is run.
>
>     A flag may be specified to indicate the desired access to a
>     specified package.
>
>     Flag 	Access
>     /none/ 	The package should be exported, so that its public types
>     will be available for use by the test at compile time and run time.
>     |open| 	The package should be opened, so that its types will be
>     available for use by the test at run time using deep reflection.
>     |+open| 	The package should be both exported and opened, so that
>     its public types will be available for use by the test at compile
>     time and run time, and other types will be available at run time
>     using deep reflection.
>
>

>
> It is not documented, can it be assumed that dependencies of a module 
> are included automatically?

:open and :+open are  about opening internal packages. That is different 
from assuming anything about dependencies of a module. The Java Platform 
Module System will ensure that the dependencies of a module are included 
automatically, assuming they are available on the overall module path.

>
> -Robert
>
>
>>
>> -- Jon
>>
>>
>> On 4/23/18 8:41 AM, Robert Field wrote:
>>> On 04/23/18 00:51, Sundararajan Athijegannathan wrote:
>>>
>>>> * On the new ToolEnablePreviewTest:
>>>>
>>>> 1) do you need to build KullTesting for this test?
>>>> 2) do you need those @module declarations for this test? Seems like 
>>>> this test stays within public APIs.
>>>
>>> All the tool tests clone, probably excess, @modules.  And neither 
>>> @build is, I believe, needed.
>>>
>>> I've changed the header to just:
>>>
>>>    /*
>>>      * @test
>>>      * @bug 8199193
>>>      * @summary Tests for the --enable-preview option
>>>      * @run testng ToolEnablePreviewTest
>>>      */
>>>
>>>
>>> New webrev, with only this header changed:
>>>
>>>     http://cr.openjdk.java.net/~rfield/8199193v1.webrev/
>>>
>>> Thanks,
>>> Robert
>>>
>>>>
>>>> -Sundar
>>>>
>>>> On 23/04/18, 12:10 AM, Robert Field wrote:
>>>>> Please review....
>>>>>
>>>>> Bug:
>>>>>
>>>>>     https://bugs.openjdk.java.net/browse/JDK-8199193
>>>>>
>>>>> Webrev:
>>>>>
>>>>>     http://cr.openjdk.java.net/~rfield/8199193v0.webrev/
>>>>>
>>>>> Thanks,
>>>>> Robert
>>>>>
>>>>>
>>>
>>
>



More information about the kulla-dev mailing list