> 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. >
