Re: jake -> jdk9/dev

On 01/05/2017 12:48, Stephen Felts wrote: I think this statement is very misleading. As part of this "small changes", jdk.attach.allowAttachSelf will be set to false and everyone that has self-attaching agents will start failing. This is part of the revised proposal that Mark sent to the list

RE: jake -> jdk9/dev

e included in JDK9. -Original Message- From: Alan Bateman Sent: Saturday, April 29, 2017 7:46 AM To: Stephen Felts; jigsaw-dev Subject: Re: jake -> jdk9/dev On 29/04/2017 11:04, Stephen Felts wrote: > I think that the Java community made it clear that this feature should > not

RE: jake -> jdk9/dev

The default is currently false in Jake (at least it's failing for me). Is this going to be reversed in Jake so that Jake and JDK9 match behavior? -Original Message- From: Alan Bateman Sent: Saturday, April 29, 2017 7:46 AM To: Stephen Felts; jigsaw-dev Subject: Re: jake -> jdk9/

Re: jake -> jdk9/dev

On 29/04/2017 11:04, Stephen Felts wrote: I think that the Java community made it clear that this feature should not be included in JDK9, including going to the effort of writing a paper to that effect at

RE: jake -> jdk9/dev

way an API that was introduced publically in JDK 6 and obviously popular in usage. -Original Message- From: Alan Bateman Sent: Saturday, April 29, 2017 3:45 AM To: jigsaw-dev Subject: jake -> jdk9/dev We have again accumulated quite a few changes in the jake forest and I'd like to bring to jdk9/

jake -> jdk9/dev

We have again accumulated quite a few changes in the jake forest and I'd like to bring to jdk9/dev next week. It's all small changes this time, JDK-8178380 [1] has the summary. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8178380

Re: jake -> jdk9/dev

On 03/04/17 20:01, Alan Bateman wrote: > We have a number of changes accumulated in the jake forest that we need > to bring to jdk9/dev soon. > > The bulk of changes relate to #MoveModuleAndLayerClasses [1] and so a > bit disruptive for those using the JDK 9 EA builds and the new APIs. . . .

Re: jake -> jdk9/dev

On 03/04/2017 21:54, Stephen Felts wrote: The jlr.Module -> jl.Module can cause some other problems. It breaks source code compatibility That's right, it's a source incompatible change (one that arises whenever a new type is added to java.lang.). The impact section of the proposal [1] has

Re: jake -> jdk9/dev

{ return stream; } } catch (Exception e) { } Throw new Exception(“you lose”); -Original Message- From: Alan Bateman Sent: Monday, April 3, 2017 3:01 PM To: jigsaw-dev Subject: jake -> jdk9/dev We ha

RE: jake -> jdk9/dev

    -Original Message- From: Alan Bateman Sent: Monday, April 3, 2017 3:01 PM To: jigsaw-dev Subject: jake -> jdk9/dev   We have a number of changes accumulated in the jake forest that we need to bring to jdk9/dev soon.   The bulk of changes relate to #MoveModuleAndLayerClasse

jake -> jdk9/dev

We have a number of changes accumulated in the jake forest that we need to bring to jdk9/dev soon. The bulk of changes relate to #MoveModuleAndLayerClasses [1] and so a bit disruptive for those using the JDK 9 EA builds and the new APIs. The revised proposed for #VersionsInModuleNames

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

test/java/security/testlibrary/Proc.java: if (hasModules) { Stream.of(jdk.internal.misc.VM.getRuntimeArguments()) -.filter(arg -> arg.startsWith("--add-exports=")) +.filter(arg -> arg.startsWith("--add-exports=") || +

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

On 28/11/2016 14:47, Chris Hegarty wrote: : 2) jartool Main.java Maybe concealedPackages should have a comment about its use ( it is used in the Validator, and not by Main at all ). Just on this one, I think this was introduced when Steve added the MR JAR validation, I agree it's ugly

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

Thanks Lois. I removed the blank line. Mandy > On Nov 28, 2016, at 6:32 AM, Lois Foltan wrote: > > 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

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

dev@openjdk.java.net>; hotspot-runtime-...@openjdk.java.net runtime <hotspot-runtime-...@openjdk.java.net>; compiler-...@openjdk.java.net Subject: Code review for jigsaw/jake -> jdk9/dev sync up Folks on jigsaw-dev will know that we are on a mission to bring the changes accumulated in

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

Karen, Sorry for delay. I was on vacation last week. I plan to review the changes tomorrow. -Dmitry On 2016-11-28 17:47, Karen Kinnear wrote: > Alan, > > I reviewed all the hotspot runtime changes > - except the tests (Christian will review those) > - and jvmti - which Dmitry Samersoff will

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

Hi, I’ve reviewed Langtools code. There are various comment “//TODO”, “//FIXME”, “//XXX”. I think they should be revised. May be issues should be filed to track them. Unused import at 37 import java.io.IOException; in langtools/test/tools/javac/modules/ModuleInfoTest.java ASCII graphics issue

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

Thanks for going through the changes, a few comment/replies below. On 28/11/2016 22:22, Paul Sandoz wrote: : What happens if you pass a primitive array? I think you need to specify what happens if an array class is passed and how the target class is obtained, and an IAE if the "element

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

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,

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: 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?

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: Code review for jigsaw/jake -> jdk9/dev sync up

Hi Alan, Overall this looks very good. I noticed a couple of nits... 1. I wonder if the new ServiceLoader API signature should be tweaked a bit... There is a new method in ServiceLoader with the following signature: public Stream stream() ...where Provider declares the

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

Folks on jigsaw-dev will know that we are on a mission to bring the changes accumulated in the jake forest to jdk9/dev. We can think of this as a refresh of the module system in JDK 9, the last big refresh was in May with many small updates since then. The focus this time is to bring the