hg: jigsaw/jake/jdk: Add @apiNote in ClassLoader::getPackage(s) about platform class loader

Changeset: fa1e20c4e6c1 Author:mchung Date: 2017-05-02 17:20 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/fa1e20c4e6c1 Add @apiNote in ClassLoader::getPackage(s) about platform class loader ! src/java.base/share/classes/java/lang/ClassLoader.java

Re: Java Platform Module System

On 5/2/2017 7:07 AM, Jayaprakash Arthanareeswaran wrote: Chapter 2 in [1] describes context-free grammars. The addition to "3.9 Keywords" defines "restricted keywords", which prevent the grammar for ModuleDeclaration from being context-free. This prevents compilers from using common parser genera

Re: Java Platform Module System

On 5/2/2017 5:13 AM, Stephan Herrmann wrote: Thanks, Alex, for promising improvements in various places of the spec. Re: Multiple packages with the same name can be "visible" (helpful terminology for program analysis) but exactly one of these packages must be identified as the meaning of the

Re: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline

> On May 2, 2017, at 2:22 PM, Kevin Rushforth > wrote: > > Here is the message: > > IllegalAccessException: class com.sun.javafx.property.MethodHelper cannot > access class com.foo (in module foo.app) because module foo.app does not open > com.foo to javafx.base > It would be better to em

Re: Review Request: JDK-8020801: Apply the restriction of invoking MethodHandles.lookup to j.l.r.Method.invoke

Hi Peter, Looking at it again, you are right that no need to skip inflation. The change is simplified. I have verified with and without -Dsun.reflect.noInflation=true. http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8020801/webrev.01/ thanks Mandy > On May 2, 2017, at 1:17 PM, Peter Levart

Re: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline

inline Mandy Chung wrote: Hi Kevin, On May 1, 2017, at 5:21 PM, Kevin Rushforth wrote: This review is being cross-posted to both openjfx-dev and jigsaw-dev. Please review the proposed fix for: https://bugs.openjdk.java.net/browse/JDK-8177566 http://cr.openjdk.java.net/~kcr/8177566/webre

Re: Accessing module internals from bytecode rewriting agent

Hi Alan, One of the techniques that I’ve used in the past for troubleshooting is to prepend modified classes to the bootstrap class path. I fear all this mucking about with modularization is going to leave the road to diagnostics littered with a ton of tools that will not longer work. As it is,

hg: jigsaw/jake/jdk: Remove JAVA_FULL_VERSION from release file. Not present in JDK 8

Changeset: 79750f9d95d5 Author:mchung Date: 2017-05-02 14:14 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/79750f9d95d5 Remove JAVA_FULL_VERSION from release file. Not present in JDK 8 ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ReleaseInfoPlugin.ja

Re: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline

Hi Kevin, > On May 1, 2017, at 5:21 PM, Kevin Rushforth > wrote: > > This review is being cross-posted to both openjfx-dev and jigsaw-dev. > > Please review the proposed fix for: > > https://bugs.openjdk.java.net/browse/JDK-8177566 > http://cr.openjdk.java.net/~kcr/8177566/webrev.00/complete-

Re: Accessing module internals from bytecode rewriting agent

On 02/05/2017 19:00, Remi Forax wrote: Hi Kirk, --patch-module both at compile time and at runtime is what your are looking for. Right, and more details in the "Patching module content" section of JEP 261 [1]. -Alan [1] http://openjdk.java.net/jeps/261#Patching-module-content

Re: 8178380: Module system implementation refresh (5/2017 update)

On 02/05/2017 20:21, stanislav lukyanov wrote: Hi Alan, In the Launcher-Agent-Class, would it make sense to use 'premain' instead of 'agentmain' to align it with Premain-Class rather than with Agent-Class? (maybe even rename Launcher-Agent-Class to Launcher-Premain-Class?) AFAIU Launcher-Age

Re: Review Request: JDK-8020801: Apply the restriction of invoking MethodHandles.lookup to j.l.r.Method.invoke

On 05/02/2017 06:56 PM, Mandy Chung wrote: On May 2, 2017, at 3:14 AM, Peter Levart wrote: I don't quite understand the need for bypassing the inflation of native into generated method accessor The VM native reflection implementation does not know about this alternate `reflected$XXX` mechan

Re: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline

Is this any better? It adds an example module-info.java file to JavaBeanXXX as is done in the FXML class. -- NOTE: If the Java Bean class is in a named module, then it must be reflectively accessible to the

Re: 8178380: Module system implementation refresh (5/2017 update)

Hi Alan, In the Launcher-Agent-Class, would it make sense to use 'premain' instead of 'agentmain' to align it with Premain-Class rather than with Agent-Class? (maybe even rename Launcher-Agent-Class to Launcher-Premain-Class?) AFAIU Launcher-Agent-Class is meant to replace a particular use cas

Re: Accessing module internals from bytecode rewriting agent

Hi Kirk, --patch-module both at compile time and at runtime is what your are looking for. cheers, Rémi - Mail original - > De: "Kirk Pepperdine" > À: "Alan Bateman" > Cc: "jigsaw-dev" , core-libs-...@openjdk.java.net > Envoyé: Mardi 2 Mai 2017 19:50:50 > Objet: Re: Accessing module inte

Re: Accessing module internals from bytecode rewriting agent

On Tue, May 2, 2017 at 2:15 PM, Paul Sandoz wrote: > At one point we were mulling back porting the Java 9 runtime changes to > Java 8 and therefore we could go back to Java 7, but we decided not to > proceed with that, which is what i suspect you may be thinking about. > > Yes, I was hopeful abou

Re: Accessing module internals from bytecode rewriting agent

> On 2 May 2017, at 09:45, Michael Nascimento wrote: > > On Tue, May 2, 2017 at 11:51 AM, Brian Goetz wrote: > >> 8 can deal with multi-release JARs. >> > > I missed that. Starting with what update? Is there any link I could use to > share this info? > There have been no modifications to t

Re: Review Request: JDK-8020801: Apply the restriction of invoking MethodHandles.lookup to j.l.r.Method.invoke

> On May 2, 2017, at 3:14 AM, Peter Levart wrote: > > I don't quite understand the need for bypassing the inflation of native into > generated method accessor The VM native reflection implementation does not know about this alternate `reflected$XXX` mechanism. No VM change in this patch and

Re: Accessing module internals from bytecode rewriting agent

On Tue, May 2, 2017 at 11:51 AM, Brian Goetz wrote: > 8 can deal with multi-release JARs. > I missed that. Starting with what update? Is there any link I could use to share this info? Regards, Michael

Re: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline

David Hill wrote: Current: All classes and properties used in a select-binding have to be declared public. Additionally, if any class is in a named module, then the module must |open|

Re: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline

Current: All classes and properties used in a select-binding have to be declared public. Additionally, if any class is in a named module, then the module must |open| t

Re: 8178380: Module system implementation refresh (5/2017 update)

> On May 2, 2017, at 3:11 AM, Chris Hegarty wrote: > > Mandy, > > On 02/05/17 03:47, Mandy Chung wrote: >> >>> ... >> src/jdk.jartool/share/classes/sun/tools/jar/Main.java >> 619 if (dflag) { >> 620 // "--describe-module/-d" does not require

Re: 8178380: Module system implementation refresh (5/2017 update)

> On May 2, 2017, at 4:28 AM, Alan Bateman wrote: > > I think this would clutter the class description and it might be better if we > added a note to the getPackages method. > That’s an alternative. >> src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java >> >> 147 //

Re: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline

I presume you are talking about the short description I added to the beans classes and to the select binding methods (and, for that matter, the *PropertyValueFactory classes)? I agree that it does seem a bit terse, so you are right that developers may have a hard time understanding it. Withou

Re: Accessing module internals from bytecode rewriting agent

8 can deal with multi-release JARs. The extra goop is ignored. So a 7/8/9 MRJar is perfectly possible (and in fact, the whole point of doing them in the first place, so library writers could publish JARs that span 7/8/9.) On 5/2/2017 2:50 AM, Jeremy Manson wrote: Maybe when there's something

Re: Java Platform Module System

My previous email showed up blank. So, sending from another email account. Thanks Stephan for summing it up! And at the risk of repeating myself and Stephan, we are really blocked by these issues and eagerly waiting for the updated spec. I will also use this opportunity to add one more item tha

Re: Java Platform Module System

Re: [9] Review request: 8177566: FX user module gets IllegalAccessException from sun.reflect.misc.Trampoline

On 02/05/2017 01:21, Kevin Rushforth wrote: This review is being cross-posted to both openjfx-dev and jigsaw-dev. Please review the proposed fix for: https://bugs.openjdk.java.net/browse/JDK-8177566 http://cr.openjdk.java.net/~kcr/8177566/webrev.00/complete-webrev/ Details of the fix as well

Re: Java Platform Module System

Thanks, Alex, for promising improvements in various places of the spec. I recall several threads on this list ending in you saying "still being clarified" [1][2]. Are those issues settled by now and just need to be penned down? Otherwise it would be very helpful just to see the list of open quest

Re: 8178380: Module system implementation refresh (5/2017 update)

On 02/05/2017 03:47, Mandy Chung wrote: : src/share/vm/services/attachListener.cpp 355 // Dynamic loading agents is not default by default typo: s/not default/not enabled? I agree, the comment is confused and better to remove it. src/share/vm/services/diagnosticCommand.cpp 771 load

Re: Review Request: JDK-8020801: Apply the restriction of invoking MethodHandles.lookup to j.l.r.Method.invoke

Hi Mandy, On 02/05/17 03:37, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8020801/webrev.00/ > > . . . Not an official review, I am afraid, but the patch looks good and is much appreciated! regards, Andrew Dinn --- Senior Principal Software Engineer

hg: jigsaw/jake/hotspot: Remove confusing comment

Changeset: 1fc81a6c3d44 Author:alanb Date: 2017-05-02 08:50 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/1fc81a6c3d44 Remove confusing comment ! src/share/vm/services/attachListener.cpp

hg: jigsaw/jake/jdk: 2 new changesets

Changeset: f8e726766d59 Author:alanb Date: 2017-05-02 07:52 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f8e726766d59 ModuleFinder.of does not correcly handle JAR files in custom file systems ! src/java.base/share/classes/jdk/internal/module/ModulePath.java + test/java

Re: Review Request: JDK-8020801: Apply the restriction of invoking MethodHandles.lookup to j.l.r.Method.invoke

Hi Mandy, On 05/02/2017 04:37 AM, Mandy Chung wrote: Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8020801/webrev.00/ The big hammer check disallowing MethodHandles::lookup be called by system classes defined by the bootstrap class loader was added as defense-in-depth to prevent th

Re: 8178380: Module system implementation refresh (5/2017 update)

Mandy, On 02/05/17 03:47, Mandy Chung wrote: ... src/jdk.jartool/share/classes/sun/tools/jar/Main.java 619 if (dflag) { 620 // "--describe-module/-d" does not require file argument(s), 621 // but does accept -

Re: Accessing module internals from bytecode rewriting agent

On 25/04/17 09:19, Andrew Dinn wrote: > This discussion really ought to be happening on the Byteman forum but > anyway ... > > Yes, Alan is right that this is exactly what is going on. Byteman on > jdk9 (the 4.0.0-BETA release series) now uses method handles in place of > reflection. Unfortunately

Re: jake -> jdk9/dev

On 01/05/17 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. So to > repeat myself, I think that the Java community made it cl

Re: Accessing module internals from bytecode rewriting agent

On 02/05/2017 07:50, Jeremy Manson wrote: : If we follow this path, before we migrate to Java 9, we would need to make sure all of our code builds and the tests pass with Java 9 and Java 8. We can't make all of the code build and the tests pass with Java 9 as-is, because many of them use opt