RFR: JDK-8151914 java/util/jar/JarFile/MultiReleaseJar* tests do not declare module dependences

[Chris Hegarty]

On 4 May 2016, at 11:07, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 04/05/2016 09:40, Chris Hegarty wrote:
>> On 3 May 2016, at 16:10, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>> 
>>>>> Can you please take a look on:
>>>>> http://cr.openjdk.java.net/~shurailine/8151914/webrev.01/
>> Taking another look over this before sponsoring….
>> 
>> The test library dependency seems to be on java.compiler, and not jdk.compiler,
>> right ?  Also, I see no reason for the addition of jdk.zipfs.
>> 
> java.compiler is just the API module, the runtime image needs to have jdk.compiler linked in to be useful.

So the test depends on both the compiler API and impl, which is implicit
with the 'requires public java.compiler’ in the jdk.compiler module. That’s
fine, and makes sense.

> So I think @modules jdk.compiler is right here as otherwise the test will be selected when testing a "JRE". java. javac needs the zipfs provider in order to compiler against libraries that are packaged as JAR/zip files so I assume this is why it listed here.

The tests cause compilation of test library classes, but only some tests
actually use the methods that provoke compilation. Similar to above, tests
that don’t actually compile anything could depend on just java.compiler.

This is all to fragile and may cause problems with future refactoring. I
think we should add the same set of @moduels to all these tests, rather
than an individual set determined by intimate knowledge of the inner
workings of the test. 

 @modules java.compiler
                   jdk.compiler
                   jdk.zipfs
                   jdk.jartool

with the addition of jdk.httpserver for MultiReleaseJarHttpProperties.

-Chris