Re: JDK 9 RFR of JDK-8167525: update jdk tests to remove @compile --add-modules workaround

2017-03-07 Thread Mandy Chung
> On Mar 7, 2017, at 7:13 PM, Amy Lu wrote: > > Please review the patch to remove the @compile --add-modules workaround. > > In the past, tests added --add-modules to @compile (JDK-8169231) or to @run > (JDK-8156579) to workaround jtreg issue CODETOOLS-7901761.

JDK 9 RFR of JDK-8167525: update jdk tests to remove @compile --add-modules workaround

2017-03-07 Thread Amy Lu
Please review the patch to remove the @compile --add-modules workaround. In the past, tests added --add-modules to @compile (JDK-8169231) or to @run (JDK-8156579) to workaround jtreg issue CODETOOLS-7901761. CODETOOLS-7901761 has been fixed in 4.2/b05, workaround in tests should be reverted.

Re: javac unzips class files from jars on class path into output directory

2017-03-07 Thread Doug Simon
Hi Jon, I've attached bug.zip which should reproduce the issue (assuming jdk 9 javac is on your path): unzip bug.zip cd bug ./run.sh find bin The last command above should show the extra class files from jdk.internal.vm.ci.jar in bin. -Doug > On 7 Mar 2017, at 18:55, Jonathan Gibbons

Re: java.lang.management.RuntimeMXBean not module aware

2017-03-07 Thread Mandy Chung
> > On Mar 7, 2017, at 12:32 AM, Volker Simonis wrote: > > Hi, > > java.lang.management.RuntimeMXBean offers methods like getClassPath(), > getLibraryPath() and even getBootClassPath() if > isBootClassPathSupported() returns true. While > isBootClassPathSupported()

Re: javac unzips class files from jars on class path into output directory

2017-03-07 Thread Jonathan Gibbons
On 03/07/2017 08:06 AM, Doug Simon wrote: To be able to develop Graal on JDK 9, we're using the `--release 8` javac option and providing jar files for API that is either not in 9 or is not exported in 9. Here is a simplified form of a javac command: javac -cp

hg: jigsaw/jake/hotspot: Clean-up of --force-open-all-module-packages

2017-03-07 Thread alan . bateman
Changeset: a581f6ce5223 Author:alanb Date: 2017-03-07 12:37 + URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a581f6ce5223 Clean-up of --force-open-all-module-packages ! src/share/vm/runtime/arguments.cpp

Re: java.lang.management.RuntimeMXBean not module aware

2017-03-07 Thread Alan Bateman
On 07/03/2017 08:32, Volker Simonis wrote: Hi, java.lang.management.RuntimeMXBean offers methods like getClassPath(), getLibraryPath() and even getBootClassPath() if isBootClassPathSupported() returns true. While isBootClassPathSupported() has been changed in jdk9 to always return false

java.lang.management.RuntimeMXBean not module aware

2017-03-07 Thread Volker Simonis
Hi, java.lang.management.RuntimeMXBean offers methods like getClassPath(), getLibraryPath() and even getBootClassPath() if isBootClassPathSupported() returns true. While isBootClassPathSupported() has been changed in jdk9 to always return false (although the VM still supports -Xbootclasspath/a)