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

[Alexandre (Shura) Iline]

> On May 5, 2016, at 12:12 PM, Jonathan Gibbons <jonathan.gibbons at oracle.com> wrote:
> 
> There is potentially a separate discussion here, as to whether javac should "force" the provision of a jar-fs provider.
> 
> Strictly speaking, javac does not inherently require it.  You can use javac just fine, with files in the system image, and source and class files in the default file system.  But I suspect most folk would be suprised if they ca across an image for which javac could not read jar files.

What would definitely help is a error message which specifies the jar name. At least in my case that would, as I would not miss the message.

Shura

> 
> -- Jon
> 
> On 05/05/2016 12:01 PM, Alexandre (Shura) Iline wrote:
>>> 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.
>