On 05/05/16 19:42, Alexandre (Shura) Iline wrote:
Chris, could you please take another look:
http://cr.openjdk.java.net/~shurailine/8151914/webrev.02/
This looks ok to me Shura, maybe just 'mrjar' for the directory
name?
Since there are file moves can you please prepare the changeset,
and I will push it for you.
-Chris.
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 <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.
