Post by Chris Hegarty Post by Alexandre (Shura) Iline
Taking another look over this before sponsoring….
The test library dependency seems to be on java.compiler, and not jdk.compiler,
right ? Also, I see no reason for the addition of jdk.zipfs.
java.compiler is just the API module, the runtime image needs to have jdk.compiler linked in to be useful.
So the test depends on both the compiler API and impl, which is implicit
with the 'requires public java.compiler’ in the jdk.compiler module. That’s
fine, and makes sense.
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.
with the addition of jdk.httpserver for MultiReleaseJarHttpProperties.