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

[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. CODETOOLS-7901761 
> has been fixed in 4.2/b05, workaround in tests should be reverted.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8167525
> webrev: http://cr.openjdk.java.net/~amlu/8167525/webrev.00/
> 
> Note that sun/nio/cs/OLD/TestIBMDB.java was added to ProblemList.txt in 
> JDK-8169231, indicate this (JDK-8167525) as related bug. But now this test 
> pass, so removed it from ProblemList.txt

Looks good.  Thanks for cleaning this up.

Mandy

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

[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.


bug: https://bugs.openjdk.java.net/browse/JDK-8167525
webrev: http://cr.openjdk.java.net/~amlu/8167525/webrev.00/

Note that sun/nio/cs/OLD/TestIBMDB.java was added to ProblemList.txt in 
JDK-8169231, indicate this (JDK-8167525) as related bug. But now this 
test pass, so removed it from ProblemList.txt


Thanks,
Amy

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

[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  wrote:
> 
> 
> 
> 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 jdk.internal.vm.ci.jar:jdk.unsupported_sun.misc.Unsafe.jar -d bin/ 
>> --release 8 
>> graal/org.graalvm.compiler.api.runtime/src/org/graalvm/compiler/api/runtime/*.java
>> 
>> where:
>> 
>> dsimon@kurz-3 ~/h/graal-core> ls 
>> graal/org.graalvm.compiler.api.runtime/src/org/graalvm/compiler/api/runtime/*.java
>> graal/org.graalvm.compiler.api.runtime/src/org/graalvm/compiler/api/runtime/GraalJVMCICompiler.java
>> graal/org.graalvm.compiler.api.runtime/src/org/graalvm/compiler/api/runtime/GraalRuntime.java
>> 
>> I expect 2 class files to be written to bin/. However, I see a number of 
>> files from jdk.internal.vm.ci.jar in bin:
>> 
>> dsimon@kurz-3 ~/h/graal-core> jar tf jdk.internal.vm.ci.jar | wc -l
>>  444
>> dsimon@kurz-3 ~/h/graal-core> find bin/jdk/vm/ci | wc -l
>>   55
>> 
>> I'm guessing that these are the classes in jdk.internal.vm.ci.jar referenced 
>> (transitively?) from the Graal sources.
>> 
>> Why is this happening? That is, why is javac extracting classes from a jar 
>> on the classpath and putting them in the output directory?
>> 
>> -Doug
> 
> Doug,
> 
> Can you provide a more complete test case?
> 
> -- Jon

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

[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() has been changed in jdk9 to always return
> false (although the VM still supports -Xbootclasspath/a) no additional
> methods have been added to RuntimeMXBean to query the new module path.
> 
> Is this intentional? I think RuntimeMXBean should contain at least a
> new method getModulePath() wich returns the VMs module path. Looking
> at the latest spec [1] I couldn't find such an addition. Will this be
> added in the final version or are there some reasons against having
> getModulePath() in RuntimeMXBean?
> 
> Exposing further information trough RuntimeMXBean like the one
> provided by the --upgrade-module-path, --add-modules, --limit-modules,
> --list-modules could be interesting/useful as well.
> 

I file https://bugs.openjdk.java.net/browse/JDK-8176314 to track this and I 
agree that certain modular runtime information such as the module graph would 
be useful for a management tool to monitor.  As Alan mentions, 
RuntimeMXBean::getInputArguments and getSystemProperties could be used to get 
the module path, upgrade module path, etc in the time being.

Mandy  

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

[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 jdk.internal.vm.ci.jar:jdk.unsupported_sun.misc.Unsafe.jar -d bin/ 
--release 8 
graal/org.graalvm.compiler.api.runtime/src/org/graalvm/compiler/api/runtime/*.java

where:

dsimon@kurz-3 ~/h/graal-core> ls 
graal/org.graalvm.compiler.api.runtime/src/org/graalvm/compiler/api/runtime/*.java
graal/org.graalvm.compiler.api.runtime/src/org/graalvm/compiler/api/runtime/GraalJVMCICompiler.java
graal/org.graalvm.compiler.api.runtime/src/org/graalvm/compiler/api/runtime/GraalRuntime.java

I expect 2 class files to be written to bin/. However, I see a number of files 
from jdk.internal.vm.ci.jar in bin:

dsimon@kurz-3 ~/h/graal-core> jar tf jdk.internal.vm.ci.jar | wc -l
  444
dsimon@kurz-3 ~/h/graal-core> find bin/jdk/vm/ci | wc -l
   55

I'm guessing that these are the classes in jdk.internal.vm.ci.jar referenced 
(transitively?) from the Graal sources.

Why is this happening? That is, why is javac extracting classes from a jar on 
the classpath and putting them in the output directory?

-Doug


Doug,

Can you provide a more complete test case?

-- Jon

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

[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

[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 (although the VM still supports -Xbootclasspath/a) no additional
methods have been added to RuntimeMXBean to query the new module path.

Is this intentional? I think RuntimeMXBean should contain at least a
new method getModulePath() wich returns the VMs module path. Looking
at the latest spec [1] I couldn't find such an addition. Will this be
added in the final version or are there some reasons against having
getModulePath() in RuntimeMXBean?

Exposing further information trough RuntimeMXBean like the one
provided by the --upgrade-module-path, --add-modules, --limit-modules,
--list-modules could be interesting/useful as well.

Fair point although many of the existing methods are just convenience 
methods (they are equivalent to invoking System.getProperty). 
RuntimeMXBean also defines getSystemProperties to get all the system 
properties and so a management tool does have a way to get the module 
path, upgrade module path, and main module/main class if needed. 
RuntimeMXBean also defines getInputArguments so there is a way (where 
supported) to see VM options such as --limit-options.


That said, I could see one of the platform MXBeans (maybe RuntimeMXBean) 
exposing access to the modules in the runtime. It's an area that was 
looked at briefly in the early exploratory phase of Project Jigsaw but 
not in recent time.


-Alan.

java.lang.management.RuntimeMXBean not module aware

[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) no additional
methods have been added to RuntimeMXBean to query the new module path.

Is this intentional? I think RuntimeMXBean should contain at least a
new method getModulePath() wich returns the VMs module path. Looking
at the latest spec [1] I couldn't find such an addition. Will this be
added in the final version or are there some reasons against having
getModulePath() in RuntimeMXBean?

Exposing further information trough RuntimeMXBean like the one
provided by the --upgrade-module-path, --add-modules, --limit-modules,
--list-modules could be interesting/useful as well.

Thank you and best regards,
Volker

[1] http://cr.openjdk.java.net/~mr/jigsaw/spec/