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 h
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 tra
> 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
>>
>> Several questions:
>
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
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
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 t
- 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 to use it with exist
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 h
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.
cheers,
Rémi
- Mail original -
> De: "Alan Bateman"
> À: "Wang Weijun"
> Cc: "jigsaw-dev" , "OpenJDK"
>
> Envoyé
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 place.
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 wrote:
>
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 java.base does not export sun.
> 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 java.security.Permission;
import java.sql.
On 04/07/2016 13:26, Andrew Dinn wrote:
:
As I understand the current situation (after conversations with Alan
Bateman) all agent classes loaded from an agent jar -- whether the agent
is deployed on the command line or dynamically, using the VM_Attach API
-- will belong to the unnamed module _M.
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
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: http:
On 05/07/2016 09:51, Felix Yang wrote:
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.
Hi Remi,
On 05/07/16 00:00, Remi Forax wrote:
> Hi Andrew, for me it's another issue,
> currently you can not use a modular jar with the -javaagent on the command
> line,
> it's seems to be the root cause of your issue.
Yes, that's basically it. Although, I'll admit I'm not really keen on
making
- 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 JPMS issues,
> #ReflectiveAccessByInstrumentationAgents
>
> Hi
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 l
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 _procLoa
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 obta
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 a
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 2016 16:18:53
> Objet: RFR: JDK-8160829 - Remove ASMPool support from jlink
>
> Much o
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. T
> 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 optimizer plugin
> will be
> 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 contain the mappings?
I
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 example:
Yes, tricky iss
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.
T
> 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 calling a method inside this class
>> Update: any ca
- Mail original -
> De: "Stephen Felts"
> À: "Malachi de Ælfweald" , "Remi Forax"
>
> Cc: jigsaw-dev@openjdk.java.net
> Envoyé: Mardi 5 Juillet 2016 17:19:00
> Objet: RE: JDK9 Modules
>
> I sometimes find tracking down JDK9 related fixes difficult.
>
> Obviously some are easy like Perm
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 pro
You need to also pass the correct information to the daemon using something
like the following (you can replace the argument files with the in-line
information).
GRADLE_OPTS=@/mydir/jdk9args -Xmx2048m -Dorg.gradle.jvmargs="@/mydir/jdk9args
-Xmx2048m "
From: Malachi de Ælfweald [mailto:ma
Hi Stephen,
Here's the result of that change:
I tried this:
export GRADLE_OPTS="@/home/malachi/work/private/sandbox2/jdk9args -Xmx2048m
-Dorg.gradle.jvmargs=\"@/home/malachi/work/private/sandbox2/jdk9args
-Xmx2048m\""
with:
-addmods java.se.ee -addmods java.annotation.common -verbose
I should me
Remove -addmods java.annotation.common
Or change it to java.annotations.common
You should get use to using
jimage list --dir=. $JAVA_HOME/lib/modules > t
textedit t
From: Malachi de Ælfweald [mailto:malac...@gmail.com]
Sent: Tuesday, July 05, 2016 2:34 PM
To: Stephen Felts
Cc: Remi F
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
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
>> wrote:
>>
>> Please review the new version of the fix.
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.
http://cr.openjdk.java.net/~shurailine/815
Try running with
export _JAVA_OPTIONS=”-Djdk.launcher.addmods=ALL-SYSTEM”
From: Malachi de Ælfweald [mailto:malac...@gmail.com]
Sent: Tuesday, July 05, 2016 3:29 PM
To: Stephen Felts
Cc: Remi Forax; jigsaw-dev@openjdk.java.net
Subject: Re: JDK9 Modules
That's a very useful comman
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 _*JAVA*_OPTIONS=”-Djdk.launcher.addmod
> 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.
You can also use List::equals.
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:
NoClassDefFound
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 sun.nio
> 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:
>> http://cr.openjdk.java.net/~shurailine/8158670/webrev.02/
>
> You can use Layer::findModule ins
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
Subject
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
wrote:
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; jigsaw-dev@openjdk
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 and
> 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 made sense, than you, Mandy.
>>>
>>> Please review new version:
>>> http://cr.openj
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 exports
-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 to match the format of comma
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
52 matches
Mail list logo