RE: How to actually ship JSR-250?

Yes, you are correct that Java EE 8 won't require Java SE 9. This will be the first time that two versions of Java SE ship before the next Java EE. There are a bunch of JDK 9 bugs against the RI but they are generally for internal API's. However, the RI won't be able to run on JDK9 until the

Re: RFR 8178323: Add negative tests for bind services Jlink feature

> On Apr 20, 2017, at 5:12 PM, Andrey Nazarov > wrote: > > HI Mandy, > > I’ve update patch > http://cr.openjdk.java.net/~anazarov/8178323/webrev.03/webrev/ > Nit: use 4-space indent e.g.

Re: RFR 8178323: Add negative tests for bind services Jlink feature

HI Mandy, I’ve update patch http://cr.openjdk.java.net/~anazarov/8178323/webrev.03/webrev/ I’ve removed some tests since you pushed them with fix for https://bugs.openjdk.java.net/browse/JDK-8178404 —Andrey > On 11 Apr 2017, at

Re: How to actually ship JSR-250?

To address the first point only... I think if Java EE 8 required Java SE 9, that would be surprising news for all. For the last few Java EE releases at least, each Java EE release has required the Java SE version of the same number. And there has been plenty of talk over the past couple

hg: jigsaw/jake/jdk: 42 new changesets

Changeset: cd268728d178 Author:weijun Date: 2017-04-11 10:12 +0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/cd268728d178 8177969: Faster FilePermission::implies by avoiding the use of Path::relativize Reviewed-by: rriggs, mullan !

hg: jigsaw/jake: 7 new changesets

Changeset: 7d5d7ae50c72 Author:rriggs Date: 2017-04-11 14:20 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/7d5d7ae50c72 8178347: Process and ProcessHandle getPid method name inconsistency Reviewed-by: alanb, bpb ! test/lib/jdk/test/lib/apps/LingeredApp.java !

hg: jigsaw/jake/corba: 2 new changesets

Changeset: 43de67f51801 Author:lana Date: 2017-04-20 18:14 + URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/43de67f51801 Added tag jdk-9+166 for changeset 934c18145915 ! .hgtags Changeset: d072e5afa03f Author:alanb Date: 2017-04-20 20:16 +0100 URL:

hg: jigsaw/jake/langtools: 13 new changesets

Changeset: 151bc67acf92 Author:mcimadamore Date: 2017-04-11 14:03 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/151bc67acf92 8178414: T8177933.java fails even after fix for JDK-8178283 Summary: add T8177933.java to problem list Reviewed-by: jlahoda !

hg: jigsaw/jake/nashorn: 2 new changesets

Changeset: 85bf1d0aeb09 Author:lana Date: 2017-04-20 18:14 + URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/85bf1d0aeb09 Added tag jdk-9+166 for changeset 5b2e7b2101c0 ! .hgtags Changeset: e89bf7fa0a32 Author:alanb Date: 2017-04-20 20:16 +0100 URL:

hg: jigsaw/jake/hotspot: 9 new changesets

Changeset: e8699be63872 Author:iveresov Date: 2017-04-11 11:34 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e8699be63872 8176887: AOT: SIGSEGV in AOTCodeHeap::next when using specific configuration Summary: Derive MethodCounters from Metadata Reviewed-by: kvn,

hg: jigsaw/jake/jaxp: 4 new changesets

Changeset: 37cdb2871070 Author:rriggs Date: 2017-04-12 10:53 -0400 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/37cdb2871070 8178347: Process and ProcessHandle getPid method name inconsistency Reviewed-by: alanb, bpb !

hg: jigsaw/jake/jaxws: 2 new changesets

Changeset: eea021f7411c Author:lana Date: 2017-04-20 18:14 + URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/eea021f7411c Added tag jdk-9+166 for changeset b1f30c27367b ! .hgtags Changeset: 32200acaad50 Author:alanb Date: 2017-04-20 20:15 +0100 URL:

Re: RFR: 8177845: Need a mechanism to load Graal

I've had to update the webrev again to support selection of a "null" compiler (i.e. one that raises an exception upon a compilation request) and added -Djvmci.Compiler=null to a large number of JVMCI jtreg tests to prevent Graal being selected and initialized by the JVMCI compiler

Re: RFR: 8177845: Need a mechanism to load Graal

> On 19 Apr 2017, at 22:29, Vladimir Kozlov wrote: > > ReflectionAccessJDK ? Based on your comment in the file. > > Vladimir > > On 4/19/17 1:02 PM, Doug Simon wrote: >> Sure - how about good old Util? ;-) I'm open to other suggestions. >> >> Sent from my iPhone

RE: How to actually ship JSR-250?

First, I'm not sure that Java EE 8 (corresponding to Java SE 9) will define modules. It seems that the RI will tolerate JDK9 (remove internal JDK API calls) as opposed to adopting the new module system. Since javax.annotation.* classes are now hidden in JDK 9, every project that uses these

hg: jigsaw/jake/jdk: Add @spec JPMS to ThreadInfo::from

Changeset: 31ed261df102 Author:mchung Date: 2017-04-20 09:00 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/31ed261df102 Add @spec JPMS to ThreadInfo::from ! src/java.management/share/classes/java/lang/management/ThreadInfo.java

hg: jigsaw/jake/hotspot: Dynamic loading of JMX or tool agent into modular application

Changeset: d2c2e33197d2 Author:alanb Date: 2017-04-20 16:56 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/d2c2e33197d2 Dynamic loading of JMX or tool agent into modular application ! src/share/vm/classfile/modules.cpp ! src/share/vm/classfile/vmSymbols.hpp !

hg: jigsaw/jake/jdk: Dynamic loading of JMX or tool agent into modular application

Changeset: ba4e9b37cd44 Author:alanb Date: 2017-04-20 16:56 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/ba4e9b37cd44 Dynamic loading of JMX or tool agent into modular application ! src/java.base/share/classes/java/lang/ClassLoader.java !

Re: How to actually ship JSR-250?

On 04/20/2017 08:18 AM, Alan Bateman wrote: On 20/04/2017 13:57, David M. Lloyd wrote: Let's say I want to create a module distribution with my own JSR 250 classes. Let's also assume that I or the spec team want the module to be named java.annotations.common. How do I properly upgrade the

Re: How to actually ship JSR-250?

On 20/04/2017 13:57, David M. Lloyd wrote: Let's say I want to create a module distribution with my own JSR 250 classes. Let's also assume that I or the spec team want the module to be named java.annotations.common. How do I properly upgrade the JDK's java.xml.ws.annotation module such

How to actually ship JSR-250?

Let's say I want to create a module distribution with my own JSR 250 classes. Let's also assume that I or the spec team want the module to be named java.annotations.common. How do I properly upgrade the JDK's java.xml.ws.annotation module such that java.xml.ws can see it, *and* I have my

Re: setAccessible() alternative with Jigsaw - feedback on Lookup

On 20/04/17 09:52, Alan Bateman wrote: > On 20/04/2017 07:43, Matej Novotny wrote: >> Another nasty thing is that the code of course needs to work with >> both, JDK 9 and 8. >> While it isn't impossible, it will add a not-so-nice reflection magic >> layer to the mix. >> > Multi-release JARs (JEP

Re: setAccessible() alternative with Jigsaw - feedback on Lookup

On 20/04/2017 07:43, Matej Novotny wrote: So I did some hacking and tried to make Weld use MethodHandles.Lookup and here is a bit of a feedback for you. But first of all, thanks for your quick advice on how to approach this. Thank you for writing down your experiences. So, how did Lookup

Re: RFR: 8177845: Need a mechanism to load Graal

> On 20 Apr 2017, at 00:31, Vladimir Kozlov wrote: > > Doug, > > Can you point (link) particular code which needs to be reviewed? And what > security issues could be? I believe Chris had possible concerns with Services.initializeJVMCI() (at

Re: setAccessible() alternative with Jigsaw - feedback on Lookup

So I did some hacking and tried to make Weld use MethodHandles.Lookup and here is a bit of a feedback for you. But first of all, thanks for your quick advice on how to approach this. Alright, I should say that I _somehow_ managed to make it work in simple cases (SE container for most part). I