Chris, could you please take another look: http://cr.openjdk.java.net/~shurailine/8151914/webrev.02/
What I have discovered is that jdk.zipfs was used to access jars on the classpath, which were JTreg jars: jtreg.jar, testing.jar, etc. Cleaning the class path through the environment removed dependency on the zipfs. 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. Thank you. Shura > On May 4, 2016, at 8:30 AM, Chris Hegarty <[email protected]> wrote: > > On 4 May 2016, at 14:32, Alan Bateman <[email protected]> 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.
