> On May 5, 2016, at 12:12 PM, Jonathan Gibbons <jonathan.gibb...@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.il...@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.hega...@oracle.com> wrote: >>>> >>>> On 4 May 2016, at 14:32, Alan Bateman <alan.bate...@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. >
