RFR: 8161203: ResourceBundle.getBundle performance regression

2016-07-20 Thread Masayoshi Okutsu
Hi, Please review the fix for JDK-8161203. The fix is to lazily load ResourceBundleProviders. It's not necessary to load providers before cache look-up. Issue: https://bugs.openjdk.java.net/browse/JDK-8161203 Webrev: http://cr.openjdk.java.net/~okutsu/9/8161203/webrev.01 Thanks, Masayoshi

Re: Issue with qualified exports

2016-07-20 Thread Gregg Wonderly
I agree, this is not very module like if we are building dependencies to export targets. This is another reason, for me, that this feels wrong. I am just not sure I understand why we care so deeply for “authorization” to use code when there are so many (nearly countless) ways to exploit the bu

Re: Issue with qualified exports

2016-07-20 Thread Paul Benedict
Thank you Alex. Sounds like good advice. I'll raise it over there. Thanks for chatting with me about it. Cheers, Paul On Wed, Jul 20, 2016 at 6:37 PM, Alex Buckley wrote: > Since A does not require B, you are quite right that the compiler doesn't > need B to compile A per se. It's solely the qu

Re: Issue with qualified exports

2016-07-20 Thread Alex Buckley
Since A does not require B, you are quite right that the compiler doesn't need B to compile A per se. It's solely the qualified export to B that drives the compiler to demand B when compiling A's module declaration. (I believe that javac should be disinterested in B when compiling A's type decl

Re: Issue with qualified exports

2016-07-20 Thread Paul Benedict
Alex, I must respectfully disagree with your analogy. We both agree that it is good for the compiler to check an "import" statement. I imagine we would also both agree that checking "requires" is good too. I would argue what makes this good is because the developer has the intention of locating and

Re: Issue with qualified exports

2016-07-20 Thread Alex Buckley
On 7/20/2016 3:07 PM, Paul Benedict wrote: Currently I am writing a module that another team will consume. Let's just call these modules A and B. Module A must export its packages to Module B and B alone. For reasons beyond my control, I do not have access to Module B. However, I don't need to c

Issue with qualified exports

2016-07-20 Thread Paul Benedict
My build is build 9-ea+125-2016-07-08-164610.javare.5260.nc Currently I am writing a module that another team will consume. Let's just call these modules A and B. Module A must export its packages to Module B and B alone. For reasons beyond my control, I do not have access to Module B. However, I

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

2016-07-20 Thread mark . reinhold
2016/7/13 16:15:33 -0700, peter.lev...@gmail.com: > On 07/13/2016 11:47 PM, mark.reinh...@oracle.com wrote: >> ... >> >> If the container is set up to provide, e.g., Hibernate to this particular >> application, then it could narrow the accessibility of the entity classes >> by rewriting the above

Re: RFR: JDK-8158407 - jimage: verify should do more extensive test

2016-07-20 Thread James Laskey
I had frame verification code. Since removed (required class loading). Will fix. Sent from my iPhone > On Jul 20, 2016, at 3:15 PM, Alan Bateman wrote: > > > >> On 20/07/2016 18:19, Jim Laskey (Oracle) wrote: >> http://cr.openjdk.java.net/~jlaskey/8158407/webrev/index.html >> https://bugs.o

Re: Concealed packages (was Re: Module API usage questions)

2016-07-20 Thread Alan Bateman
On 20/07/2016 20:13, Paul Benedict wrote: Yes, that's my concern, but it's really only secondary to something else. I am more concerned that specifying both seems redundant. The JVM should be able to infer at resolution time that what's not exported is concealed. There may be a grander design

Re: RFR(L) 8136930: Simplify use of module-system options by custom launchers

2016-07-20 Thread Daniel D. Daugherty
Sounds good to me. Thanks! Dan On 7/20/16 1:48 PM, harold seigel wrote: Hi Dan, This was discussed today and it was decided the the JVM will issue warnings if these specific properties are specified on the command line, provided that option PrintWarnings is TRUE. This will probably be don

Re: RFR(L) 8136930: Simplify use of module-system options by custom launchers

2016-07-20 Thread harold seigel
Hi Dan, This was discussed today and it was decided the the JVM will issue warnings if these specific properties are specified on the command line, provided that option PrintWarnings is TRUE. This will probably be done as a separate bug. Thanks, Harold On 7/20/2016 3:42 PM, Daniel D. Daug

Re: Concealed packages (was Re: Module API usage questions)

2016-07-20 Thread Chris Hegarty
> On 20 Jul 2016, at 20:13, Paul Benedict wrote: > > Yes, that's my concern, but it's really only secondary to something else. I > am more concerned that specifying both seems redundant. The JVM should be > able to infer at resolution time that what's not exported is concealed. > There may be a

Re: RFR(L) 8136930: Simplify use of module-system options by custom launchers

2016-07-20 Thread Daniel D. Daugherty
On 7/17/16 5:05 PM, harold seigel wrote: Hi, Please review these Hotspot VM only changes to process the seven module-specific options that have been renamed to have gnu-like names. JDK changes for this bug will be reviewed separately. Descriptions of these options are here

Re: Concealed packages (was Re: Module API usage questions)

2016-07-20 Thread Paul Benedict
Yes, that's my concern, but it's really only secondary to something else. I am more concerned that specifying both seems redundant. The JVM should be able to infer at resolution time that what's not exported is concealed. There may be a grander design at play which I yet to understand, but I don't

Re: Concealed packages (was Re: Module API usage questions)

2016-07-20 Thread Alan Bateman
On 20/07/2016 19:34, Paul Benedict wrote: Alan, is the JVM going to verify that what's listed in ConcealedPackages structure actually exists as packages in the module? If you asking if it scans the contents of the JAR file to check if the ConcealedPackages attribute is correct then "no". Are

Concealed packages (was Re: Module API usage questions)

2016-07-20 Thread Paul Benedict
Alan, is the JVM going to verify that what's listed in ConcealedPackages structure actually exists as packages in the module? Cheers, Paul On Tue, Jul 19, 2016 at 4:56 PM, Alan Bateman wrote: > On 19/07/2016 21:16, Paul Benedict wrote: > > > Can you into more about packages "not be package of y

Re: RFR: JDK-8158407 - jimage: verify should do more extensive test

2016-07-20 Thread Alan Bateman
On 20/07/2016 18:19, Jim Laskey (Oracle) wrote: http://cr.openjdk.java.net/~jlaskey/8158407/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8158407 Looks okay, just wondering about EXPAND_FRAMES as I assume that isn't needed (0 will do). -Alan

RFR: JDK-8158407 - jimage: verify should do more extensive test

2016-07-20 Thread Jim Laskey (Oracle)
http://cr.openjdk.java.net/~jlaskey/8158407/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8158407

hg: jigsaw/jake/jdk: Add JVM TI support for redefining a module

2016-07-20 Thread alan . bateman
Changeset: f9b96e96b953 Author:alanb Date: 2016-07-20 12:18 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/f9b96e96b953 Add JVM TI support for redefining a module Contributed-by: serguei.spit...@oracle.com ! src/java.base/share/native/include/jvmti.h

hg: jigsaw/jake/hotspot: Add JVM TI support for redefining a module

2016-07-20 Thread alan . bateman
Changeset: f0dfd8cfe4d2 Author:alanb Date: 2016-07-20 12:16 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/f0dfd8cfe4d2 Add JVM TI support for redefining a module Contributed-by: serguei.spit...@oracle.com ! make/test/JtregNative.gmk ! src/share/vm/classfile/vmSymbol