Re: RFR 8152742: jlink --include-locales th fails with ArrayIndexOutOfBoundsException

+1 Masayoshi On 4/2/2016 8:40 AM, Mandy Chung wrote: On Apr 1, 2016, at 2:20 PM, Naoto Sato wrote: Hello, Please review the fix for the following issue: https://bugs.openjdk.java.net/browse/JDK-8152742 The fix is located at:

Re: 8153370: Drop use of old style -XaddExports from tests

On 04/04/2016 19:41, Mandy Chung wrote: : One typo s/addExpots/addExports/ test/sun/security/tools/keytool/autotest.sh -XaddExpots:java.base/sun.security.x509=ALL-UNNAMED otherwise, looks okay. Well spotted! That test is on the exclude list so this is why I didn't notice in test runs.

Re: 8153370: Drop use of old style -XaddExports from tests

> On Apr 4, 2016, at 6:38 AM, Alan Bateman wrote: > > > We still have support in both javac and in the runtime for the old form of > -XaddExports and -XaddReads. > > A first step to removing support for the old form is to update the tests that > are still using the

8153370: Drop use of old style -XaddExports from tests

We still have support in both javac and in the runtime for the old form of -XaddExports and -XaddReads. A first step to removing support for the old form is to update the tests that are still using the old form. The webrev with the changes that I'd like to push to jdk9/dev is here:

Re: The root modules when compiling code in the unnamed module or where the initial class is loaded from the class path

On 04/04/2016 14:30, Remi Forax wrote: Trying to fully understand what it means, Does it means that adding -addmods java.se.ee is enough for applications that use packages from those modules but are not JavaEE applications ? Exactly.

Re: The root modules when compiling code in the unnamed module or where the initial class is loaded from the class path

Trying to fully understand what it means, Does it means that adding -addmods java.se.ee is enough for applications that use packages from those modules but are not JavaEE applications ? Rémi - Mail original - > De: "Alan Bateman" > À: "jigsaw-dev"

The root modules when compiling code in the unnamed module or where the initial class is loaded from the class path

Just an FYI that the "Root modules" section of JEP 261 has been updated with a revised policy on the modules to resolve when compiling code in the unnamed module, or at runtime when the main class is loaded from the class path. The key point is that "java.se" will be the only java.* root

Re: trouble with java -Xpatch

On 04/04/2016 12:47, Michael Rasmussen wrote: But retransform in this phase would still be subject to the same limitations about no structural changes I assume? Meaning no adding of members etc. My preferred solution would still be if adding (and changing) Xpatch would be possible during

Re: trouble with java -Xpatch

But retransform in this phase would still be subject to the same limitations about no structural changes I assume? Meaning no adding of members etc. My preferred solution would still be if adding (and changing) Xpatch would be possible during OnLoad, as that should solve all my problems.

Re: trouble with java -Xpatch

On 04/04/2016 12:09, Michael Rasmussen wrote: So in order to patch any of the well-known preloaded classes, I will need to prepatch them, put them in a folder/jar, and then need to ask the user to specify the -Xpatch jvm option, seeing as I don't have the option to neither patch them via CFLH,

Re: trouble with java -Xpatch

So in order to patch any of the well-known preloaded classes, I will need to prepatch them, put them in a folder/jar, and then need to ask the user to specify the -Xpatch jvm option, seeing as I don't have the option to neither patch them via CFLH, nor add -Xpatch myself from jvmti? If that is

Re: jdeps -check: add section on exports

On 04/04/2016 11:55, Anthony Vanelverdinghe wrote: For the record: I've filed this as JI-9034435 I've moved it to the JDK project: https://bugs.openjdk.java.net/browse/JDK-8153362

Re: trouble with java -Xpatch

On 04/04/2016 11:31, Michael Rasmussen wrote: Hi Alan Finally had time today to do some testing of can_generate_early_vmstart. Can you elaborate on which classes I should be able to patch using CFLH with early_vmstart enabled? From the quick testing I did, it appears that most of the core

Re: jdeps -check: add section on exports

For the record: I've filed this as JI-9034435 Anthony On 25/03/2016 21:08, Anthony Vanelverdinghe wrote: What's the next step? Will someone with JIRA access file a javac enhancement for this, or shall I do so myself through bugs.java.com? (I'm not sure what the preferred option is for issues

Re: trouble with java -Xpatch

Hi Alan Finally had time today to do some testing of can_generate_early_vmstart. Can you elaborate on which classes I should be able to patch using CFLH with early_vmstart enabled? From the quick testing I did, it appears that most of the core java.lang classes do not generate CFLH events? For

Re: Inner classes are allowed to be specified in 'uses' statement

Hi Georgiy, On 04/01/2016 04:52 PM, Georgiy Rakov wrote: Hello, currently inner classes are allowed to be specified in 'uses' statement, for instance following code is compiled successfully by JDKb111 javac: a/module-info.java: module a { uses pkg.Outer.Inner; }