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.
