hg: jigsaw/jake/nashorn: requires jtreg 4.2 b04

Changeset: 527b3a15b412 Author:mchung Date: 2016-11-28 21:43 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/527b3a15b412 requires jtreg 4.2 b04 ! test/TEST.ROOT

hg: jigsaw/jake/jdk: requires jtreg 4.2 b04

Changeset: b7ddd95fd610 Author:mchung Date: 2016-11-28 21:42 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b7ddd95fd610 requires jtreg 4.2 b04 ! test/TEST.ROOT

hg: jigsaw/jake/langtools: requires jtreg 4.2 b04

Changeset: dd31ba802575 Author:mchung Date: 2016-11-28 21:43 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/dd31ba802575 requires jtreg 4.2 b04 ! test/TEST.ROOT

hg: jigsaw/jake/hotspot: requires jtreg 4.2 b04

Changeset: e9fe2fec61f7 Author:mchung Date: 2016-11-28 21:43 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e9fe2fec61f7 requires jtreg 4.2 b04 ! test/TEST.ROOT

hg: jigsaw/jake: requires jtreg 4.2 b04

Changeset: 51f97296402c Author:mchung Date: 2016-11-28 21:43 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/51f97296402c requires jtreg 4.2 b04 ! common/conf/jib-profiles.js

Re: Code review for jigsaw/jake -> jdk9/dev sync up

For the JDK patch: MethodHandles — 176 public static Lookup privateLookupIn(Class targetClass, Lookup lookup) throws IllegalAccessException { 177 SecurityManager sm = System.getSecurityManager(); 178 if (sm != null) sm.checkPermission(ACCESS_PERMISSION); 179 if

Re: Code review for jigsaw/jake -> jdk9/dev sync up

On 11/28/16 3:28 AM, Maurizio Cimadamore wrote: Hi, the langtools code looks generally ok. Few questions: * Why doesn't 'open' get its own directive in Directive.java - instead of relying on a 'mode' set on an export directive? I agree that "opens" leveraging a type named "Exports..." is

hg: jigsaw/jake/langtools: Reject module-info classfiles for open modules that have non-zero number of opens directives.

Changeset: 425abd8ac1eb Author:jlahoda Date: 2016-11-28 21:08 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/425abd8ac1eb Reject module-info classfiles for open modules that have non-zero number of opens directives. !

Re: How many modules per jar?

If you're writing new code, then packaging each module into its own JAR file (a "modular JAR") is the right thing to do. If you're modularizing old code that is already delivered as JAR files, then you might have some difficulties. One difficulty is cyclic dependencies between code in

hg: jigsaw/jake/jdk: 4 new changesets

Changeset: 8a69f4602580 Author:alanb Date: 2016-11-28 15:25 + URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8a69f4602580 Expand test for open modules and packages ! test/jdk/modules/open/Basic.java Changeset: b71703fea51b Author:alanb Date: 2016-11-28 15:26

Re: Can't call certain accessible methods using reflection

It might be worth noting that invoking it using MethodHandles works: MethodHandle mh = MethodHandles.lookup().findVirtual(Public.class, "m", MethodType.methodType(void.class)); mh.invoke(p); /Michael On 28 November 2016 at 15:17, Jochen Theodorou wrote: > > > On 28.11.2016

Re: Code review for jigsaw/jake -> jdk9/dev sync up

On 28/11/16 14:53, Jan Lahoda wrote: Thanks for the comments Maurizio. On 28.11.2016 12:28, Maurizio Cimadamore wrote: Hi, the langtools code looks generally ok. Few questions: * Why doesn't 'open' get its own directive in Directive.java - instead of relying on a 'mode' set on an export

Re: Code review for jigsaw/jake -> jdk9/dev sync up

Thanks for the comments Maurizio. On 28.11.2016 12:28, Maurizio Cimadamore wrote: Hi, the langtools code looks generally ok. Few questions: * Why doesn't 'open' get its own directive in Directive.java - instead of relying on a 'mode' set on an export directive? It seemed to me that having

Re: Code review for jigsaw/jake -> jdk9/dev sync up

Reviewed Nashorn changes. All fine. -Sundar On 11/28/2016 8:17 PM, Chris Hegarty wrote: > On 24 Nov 2016, at 15:25, Alan Bateman wrote: >> ... >> To get going, I've put the webrevs with a snapshot of the changes in jake >> here: >>

Re: Code review for jigsaw/jake -> jdk9/dev sync up

On 24 Nov 2016, at 15:25, Alan Bateman wrote: > > ... > To get going, I've put the webrevs with a snapshot of the changes in jake > here: >http://cr.openjdk.java.net/~alanb/8169069/0/ Overall this look very good. I ran through most of the changes in the jdk repo,

hg: jigsaw/jake/hotspot: 8170397: hotspot gc/stress/gcbasher tests fail in Jake

Changeset: 756aeaa66545 Author:hseigel Date: 2016-11-28 09:30 -0500 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/756aeaa66545 8170397: hotspot gc/stress/gcbasher tests fail in Jake Summary: Don't parse "module-info.class" files Reviewed-by: alanb !

Re: Code review for jigsaw/jake -> jdk9/dev sync up

Hi Alan, I have reviewed the hotspot changes and they look good. Minor nit, src/share/vm/classfile/javaClasses.cpp only differs by the addition of a blank line. Thanks, Lois On 11/24/2016 10:25 AM, Alan Bateman wrote: Folks on jigsaw-dev will know that we are on a mission to bring the

Re: Can't call certain accessible methods using reflection

On 28.11.2016 12:23, Peter Levart wrote: [...] // Module m1: module m1 { exports pkg1; } package internal; public class InternalImpl { public void m() { System.out.println("m()"); } } package pkg1; public class Public extends internal.InternalImpl { } is it legal for

Re: Replacement for JDK8 APIs

On Mon, Nov 28, 2016 at 11:49 AM, Alan Bateman wrote: > On 28/11/2016 10:36, Stéphane Nicoll wrote: > > Peter, >> >> Thanks a lot, that helped! [1] >> >> Cheers, >> S. >> >> [1] >> https://github.com/spring-projects/spring-boot/commit/e15b3e >>

hg: jigsaw/jake/langtools: Removing 'dynamic' name, which is not needed anymore

Changeset: 8156e205fcb4 Author:jlahoda Date: 2016-11-28 13:02 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/8156e205fcb4 Removing 'dynamic' name, which is not needed anymore ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java

Re: Code review for jigsaw/jake -> jdk9/dev sync up

Hi, the langtools code looks generally ok. Few questions: * Why doesn't 'open' get its own directive in Directive.java - instead of relying on a 'mode' set on an export directive? * ClassReader: should we have checks regarding an open module containing no open directives in the classfile?

Can't call certain accessible methods using reflection

Hi, I encountered a situation in which calling a method using reflection is not possible, while the same method can be called with bytecode instruction. Here's an example: // Module m1: module m1 { exports pkg1; } package internal; public class InternalImpl { public void m() {

Re: Code review for jigsaw/jake -> jdk9/dev sync up

On 27/11/2016 11:15, Peter Levart wrote: Hi Alan, Overall this looks very good. I noticed a couple of nits... Thanks for going through the changes. : So should Provider rather declare the following? Class type(); Or alternatively, should ServiceLoader rather declare the following?

Re: Replacement for JDK8 APIs

On 28/11/2016 10:36, Stéphane Nicoll wrote: Peter, Thanks a lot, that helped! [1] Cheers, S. [1] https://github.com/spring-projects/spring-boot/commit/e15b3e463f312524495349673a16cb67cfaa2eae The reflection has come up a number of things so great that Peter tracked this down. So I'm

Re: Replacement for JDK8 APIs

Peter, Thanks a lot, that helped! [1] Cheers, S. [1] https://github.com/spring-projects/spring-boot/commit/e15b3e463f312524495349673a16cb67cfaa2eae On Mon, Nov 28, 2016 at 10:50 AM, Peter Levart wrote: > > > On 11/28/2016 10:39 AM, Peter Levart wrote: > >> final class

Re: Replacement for JDK8 APIs

On 11/28/2016 10:39 AM, Peter Levart wrote: final class Trees extends ReflectionWrapper { private Trees(Object instance) { super(com.sun.source.util.Trees.class, instance); } ...ah, you would probably want to use Class.forName("com.sun.source.util.Trees") above... Peter

Re: Replacement for JDK8 APIs

Hi Stephan, I thin this is a classical problem with reflection access checking that existed before jigsaw, but is now encountered even more frequently. The problem is that your ReflectionWrapper, given an instnace of some object, takes its runtime Class and searches methods in that class. The

Re: Replacement for JDK8 APIs

Jon, We invoke `com.sun.source.util.Trees#instance(ProcessingEnvironment)` reflectively[1] as this class may not be available. This gives us access to `Tree` that we handle reflectively as well[2]. There is no reference anywhere to com.sun.tools.javac.api.JavacTrees in our codebase so I guess