Re: Strange test failure when referencing a class in a deprivileged module

On 7/5/2016 23:50, Mandy Chung wrote: Max - are you running the test with exploded image (see JDK-8155858 [1])? No. The test also fails with recent promoted builds (ever since java.sql is de-priveleged). --Max

Re: JDK9 Modules

-XaddExports=*/*=ALL-UNNAMED ;) Malachi de Ælfweald http://www.google.com/profiles/malachid On Tue, Jul 5, 2016 at 2:33 PM, Stephen Felts wrote: > Magic! > > > > Those options are processed by all invocations of java. > > Note that those options will likely change

RE: JDK9 Modules

Magic!   Those options are processed by all invocations of java. Note that those options will likely change to match the format of command line options (e.g., -addmods, -XaddExports). The current format is very painful unless you are programmatically generating them (imagine having 35

Re: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java

> On Jul 5, 2016, at 1:53 PM, Alexandre (Shura) Iline > wrote: > > >> On Jul 5, 2016, at 1:36 PM, Mandy Chung wrote: >> >> >>> On Jul 5, 2016, at 12:42 PM, Alexandre (Shura) Iline >>> wrote: >>> >>> This

Re: JDK9 Modules

With: export _JAVA_OPTIONS="-Djdk.launcher.addmods=ALL-SYSTEM -Djdk.launcher.addexports.0=java.base/sun.nio.ch=ALL-UNNAMED" no GRADLE_OPTIONS no options.compilerArgs in build.gradle 1. The dagger project compiles and runs 2. The neo4j project compiles and runs 3. a JDK8 project still compiles

RE: JDK9 Modules

That option is overkill.  It includes all modules.  Instead of using ALL-SYSTEM, add just the modules that you need comma separated or java.se.ee.     From: Malachi de Ælfweald [mailto:malac...@gmail.com] Sent: Tuesday, July 05, 2016 5:00 PM To: Stephen Felts Cc: Remi Forax;

Re: JDK9 Modules

oh lol! I thought you were just italicizing! ;) That seemed to fix the Dagger one. Now let me try to back off of all the changes and figure out what the minimal configuration is. Malachi de Ælfweald http://www.google.com/profiles/malachid On Tue, Jul 5, 2016 at 1:41 PM, Stephen Felts

RE: JDK9 Modules

Add -Djdk.launcher.addexports.0=java.base/sun.nio.ch=ALL-UNNAMED to _JAVA_OPTIONS. Also, kill the daemon before running. -Original Message- From: Malachi de Ælfweald [mailto:malac...@gmail.com] Sent: Tuesday, July 05, 2016 4:50 PM To: Alan Bateman Cc: jigsaw-dev@openjdk.java.net

Re: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java

> On Jul 5, 2016, at 1:36 PM, Mandy Chung wrote: > > >> On Jul 5, 2016, at 12:42 PM, Alexandre (Shura) Iline >> wrote: >> >> This made sense, than you, Mandy. >> >> Please review new version: >>

Re: JDK9 Modules

Regarding the Neo4j one, I tried adding '-XaddExports:java.base/sun.nio.ch=ALL-UNNAMED' to both build.gradle and jdk9args, but it still says: Caused by: java.lang.IllegalAccessError: class org.neo4j.io.pagecache.impl.SingleFilePageSwapper (in unnamed module @0x49070868) cannot access class

RE: JDK9 Modules

Well you need the leading underscore.   From: Malachi de Ælfweald [mailto:malac...@gmail.com] Sent: Tuesday, July 05, 2016 4:36 PM To: Stephen Felts Cc: Remi Forax; jigsaw-dev@openjdk.java.net Subject: Re: JDK9 Modules   adding that (without the leading underscore) I still get:

Re: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java

> On Jul 5, 2016, at 12:42 PM, Alexandre (Shura) Iline > wrote: > > This made sense, than you, Mandy. > > Please review new version: > http://cr.openjdk.java.net/~shurailine/8158670/webrev.02/ You can use Layer::findModule instead of Configuration::findModule.

Re: JDK9 Modules

adding that (without the leading underscore) I still get: NoClassDefFoundError: javax/annotation/Generated Malachi de Ælfweald http://www.google.com/profiles/malachid On Tue, Jul 5, 2016 at 12:58 PM, Stephen Felts wrote: > Try running with > > > > export

Re: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java

Jon, > On Jul 1, 2016, at 6:44 PM, Jonathan Gibbons > wrote: > > The test can also report which providers it is testing and/or skipping, so > that anyone checking the .jtr file can verify the behavior. I have added some debug output, pls take a look.

Re: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java

This made sense, than you, Mandy. Please review new version: http://cr.openjdk.java.net/~shurailine/8158670/webrev.02/ Shura > On Jul 2, 2016, at 3:26 PM, Mandy Chung wrote: > > >> On Jul 1, 2016, at 6:20 PM, Alexandre (Shura) Iline >>

Re: JDK9 Modules

That's a very useful command. Thanks for that. I fixed it to add the 's'. I also tried it without that module. I had to remove -verbose from the jdk9args due to https://discuss.gradle.org/t/cannot-run-build-with-jvm-argument-verbose-class/17734 'clean' works with -verbose removed from jdk9args

Re: JDK9 Modules

Adding the fork and forkOptions got me further on the Dagger test. I also added -verbose. I can see: [loading /modules/java.annotations.common/module-info.class] [loading /modules/java.se.ee/module-info.class] so it is finding the modules... The stack is a bit more helpful now: An annotation

Re: Strange test failure when referencing a class in a deprivileged module

> On Jul 5, 2016, at 8:11 AM, Alan Bateman wrote: > > On 05/07/2016 09:22, Wang Weijun wrote: > >>> On Jul 5, 2016, at 11:53 AM, Wang Weijun wrote: >>> >>> The exception is at the end of this mail. The test passes if I change >>> X.go() to

RE: JDK9 Modules

I sometimes find tracking down JDK9 related fixes difficult. Obviously some are easy like PermSize on the command line. Anything that depends on rt.jar or finding tools.jar is broken. Some tools validate the jdk directory by looking for rt.jar. Some like jython use it to resolve class names.

Re: Strange test failure when referencing a class in a deprivileged module

On 05/07/2016 09:22, Wang Weijun wrote: On Jul 5, 2016, at 11:53 AM, Wang Weijun wrote: The exception is at the end of this mail. The test passes if I change X.go() to calling a method inside this class Update: any call that triggers a permission check will do. For

Re: Questions on deprivileging a module

> On Jul 5, 2016, at 12:15 AM, Wang Weijun wrote: > >>> 1. How does updating /make/common/Modules.gmk affect an exploded build? >> The mappings are used for both exploded and images build so the >> configuration in this make file is for both. > > I see. BTW, which file

Re: RFR: JDK-8160829 - Remove ASMPool support from jlink

> On 5 Jul 2016, at 16:18, Jim Laskey (Oracle) wrote: > > Much of the removed code seems unnecessary since the same functionality can > be accomplished with much simpler code. An example is provided with > ClassForNamePlugin.java (temporary.) A shipping byte code

Proposal: #DefaultModule

I propose that the concept of "unnamed module" be dropped in favor of "default module". The main difference is that the class loader (or module finder or layer configuration or someone else) would be allowed to (but not required to) assign a free-form name and version string to this module.

Re: RFR: JDK-8160829 - Remove ASMPool support from jlink

Hi jim, This code had a dependency of the private copy of ASM, so +1 to remove it. Rémi - Mail original - > De: "Jim Laskey (Oracle)" > À: "jigsaw-dev" , "core-libs-dev" > > Envoyé: Mardi 5 Juillet

RFR: JDK-8160829 - Remove ASMPool support from jlink

Much of the removed code seems unnecessary since the same functionality can be accomplished with much simpler code. An example is provided with ClassForNamePlugin.java (temporary.) A shipping byte code optimizer plugin will be supplied later. Additional changes to the plugin API will supply

Re: JarLoader appears to be holding onto the resource longer than necessary

On 05/07/2016 12:39, Jayaprakash Arthanareeswaran wrote: Hello, Some of our new tests are hitting a case where JAR files appear to be kept open. I am not sure where the issue lies as I can't access some of the source code involved. I am attaching the stack trace at the end of the mail. We

JarLoader appears to be holding onto the resource longer than necessary

Hello, Some of our new tests are hitting a case where JAR files appear to be kept open. I am not sure where the issue lies as I can't access some of the source code involved. I am attaching the stack trace at the end of the mail. We obtain the ServiceLoader with the following code where

Re: Proposals for some open JPMS issues, #ReflectiveAccessByInstrumentationAgents

On 05/07/16 09:34, Alan Bateman wrote: > Just to expand on this. Java agents that are deployed via the -javaagent > command line option, or loaded into a running VM by means of the Attach > API, have their types loaded by the application class loader. Some > agents will also add to the boot class

Re: Proposals for some open JPMS issues, #ReflectiveAccessByInstrumentationAgents

- Mail original - > De: "Andrew Dinn" > À: "Remi Forax" > Cc: "mark reinhold" , jigsaw-dev@openjdk.java.net, > jpms-spec-comme...@openjdk.java.net > Envoyé: Mardi 5 Juillet 2016 11:18:04 > Objet: Re: Proposals for some open

Re: RFR 8153838/9, fix module dependency for java/io/Serializable/failureAtomicity/FailureAtomicity.java

Correct the test name -Felix On 2016/7/5 16:37, Felix Yang wrote: Hi there, please review the change for java/io/Serializable/failureAtomicity/FailureAtomicity.java to declare dependency to the module of "jdk.compiler" Bug: https://bugs.openjdk.java.net/browse/JDK-8153838 Webrev:

RFR 8153838/9, fix module dependency for java/lang/reflect/Layer/LayerAndLoadersTest.java

Hi there, please review the change for java/lang/reflect/Layer/LayerAndLoadersTest.java to declare dependency to the module of "jdk.compiler" Bug: https://bugs.openjdk.java.net/browse/JDK-8153838 Webrev: http://cr.openjdk.java.net/~xiaofeya/8153838/webrev.00/ Thanks, Felix

Re: Strange test failure when referencing a class in a deprivileged module

> On Jul 5, 2016, at 11:53 AM, Wang Weijun wrote: > > The exception is at the end of this mail. The test passes if I change X.go() > to calling a method inside this class Update: any call that triggers a permission check will do. For example: import

Re: JDK9 Modules

Hi Alan, On Tue, Jul 5, 2016 at 1:03 AM, Alan Bateman wrote: > On 05/07/2016 08:00, Malachi de Ælfweald wrote: > > : >> >> Neo4j fails due to internal Sun classes being used: >> cannot access class sun.nio.ch.FileChannelImpl (in module java.base) >> because module

Re: JDK9 Modules

Hi Remi, with: compileJava { options.compilerArgs += [ "-addmods", "java.se.ee" ] } It still says it can not find javax/annotation/Generated I'm on build 9-ea+123 Malachi de Ælfweald http://www.google.com/profiles/malachid On Tue, Jul 5, 2016 at 1:02 AM, Remi Forax

Re: Questions on deprivileging a module

On 05/07/2016 09:03, Remi Forax wrote: The other solution is to use a VarHandle instead of Unsafe for setting the final field, i don't think that letting unprivileged module to access to Unsafe is a good idea. Very true, I wasn't paying attending to why it is using Unsafe in the first

Re: JDK9 Modules

On 05/07/2016 08:00, Malachi de Ælfweald wrote: : Neo4j fails due to internal Sun classes being used: cannot access class sun.nio.ch.FileChannelImpl (in module java.base) because module java.base does not export sun.nio.ch to unnamed module @0x6166e06f In this case then I assume the exception

Re: JDK9 Modules

- Mail original - > De: "Malachi de Ælfweald" > À: jigsaw-dev@openjdk.java.net > Envoyé: Mardi 5 Juillet 2016 09:00:22 > Objet: JDK9 Modules > > While I understand the motivation behind making the system more modular, I > am having a bit of a problem understanding how

Re: Questions on deprivileging a module

On 05/07/2016 08:15, Wang Weijun wrote: : It's a runtime error. @CallerSensitive public static Unsafe getUnsafe() { Class caller = Reflection.getCallerClass(); if (!VM.isSystemDomainLoader(caller.getClassLoader())) throw new SecurityException("Unsafe"); << The exception

Re: Review request: JDK-8159596 Add java --dry-run

On 27/06/2016 18:36, Mandy Chung wrote: -XshowSettings would probably be a good place to include the VM arguments. $ java -XshowSettings:vm -—dry-run I file a JBS issue: https://bugs.openjdk.java.net/browse/JDK-8160389 and probably any additions here should be looked at in conjunction with

Re: Review request: JDK-8159596 Add java --dry-run

On 01/07/2016 05:44, David Holmes wrote: I had assumed that initialization was desirable as part of checking that everything was specified correctly. The original intention was that the initializer (if present) should be run but I see the discussion has gone the other way now. -Alan

Re: Questions on deprivileging a module

> On Jul 5, 2016, at 2:52 PM, Alan Bateman wrote: > > On 04/07/2016 07:03, Wang Weijun wrote: > >> I am working on >> >>JDK-8159528 Deprivilege java.security.jgss, jdk.security.jgss and >> jdk.security.auth >>https://bugs.openjdk.java.net/browse/JDK-8159528

Re: Review request: JDK-8159596 Add java --dry-run

On 04/07/2016 17:10, Mandy Chung wrote: : I feel the output is a bit verbose. Alan is also looking into some update to the service loader [1]. The diagnostic output may change and probably best to add the comment in JDK-8132026. We have JDK-8146370 [1] to re-examine the issue of resolver

JDK9 Modules

While I understand the motivation behind making the system more modular, I am having a bit of a problem understanding how to use it with existing 3rd party APIs. I saw the email thread with Alan and Stephen discussing how there was a need to test some of the tools. Over the last couple weeks, I

Re: No jrt-fs.jar in JRE?

On 25/06/2016 06:07, Jayaprakash Arthanareeswaran wrote: : I just downloaded the latest JDK and found the modules file along with jmod/*.jmod. Is this to remain? My experiment to use the jrt-fs.jar from the JDK to load the system classes in JRE failed. May be I am not doing something right.