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

[Alexandre (Shura) Iline]

> On May 5, 2016, at 11:42 AM, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
> Whether the java.tools API behavior is correct is a separate matter. I am planning to create a standalone test case and take it with javac ppl.
I take this ^^^^^^ back, as the error was there all along: "java.nio.file.ProviderNotFoundException: no provider found for .jar files”

The fix is valid, then, is and waiting for a review.

Shura

> 
> Thank you.
> 
> Shura
> 
>> On May 4, 2016, at 8:30 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>> 
>> On 4 May 2016, at 14:32, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>> 
>>> On 04/05/2016 11:24, Chris Hegarty wrote:
>>>> :
>>>> 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.
>>>> 
>>> or we could move the tests into their own MultiRelease sub-directory and create a TEST.properties with a module key. That would allow these tests to drop @modules, except the test that uses the HTTP server.
>> 
>> I think that would be better.
>> 
>> -Chris.
>