Re: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

On 03/04/2017 19:41, Mandy Chung wrote: Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ I went through the updates to jlink, assuming test SystemModulesTest will be aligned to the recent mails. In DefaultImageBuilder.storeFiles then map(ResourcePoolModule::osNa

Re: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

On 2017-04-03 23:50, Mandy Chung wrote: On Apr 3, 2017, at 2:39 PM, mark.reinh...@oracle.com wrote: 2017/4/3 13:35:30 -0700, si...@cjnash.com: On 03/04/2017 21:15, mark.reinh...@oracle.com wrote: 2017/4/3 11:41:03 -0700, mandy.ch...@oracle.com: Webrev: http://cr.openjdk.java.net/~mchung/jdk9

Re: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

On 03/04/17 19:41, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ > > This revisits the OS name and arch in packaging JDK modules > to extend the module descriptor with ModuleTarget class file > attribute. We considered matching with the system

Re: Disallowing the dynamic loading of agents by default

On 03/04/17 21:56, John Rose wrote: > On Apr 3, 2017, at 12:03 PM, Gregg Wonderly > wrote: >> >> Alan, it is exactly this kind of comment from the team which just >> tears apart the whole view that you might actually be considering >> what everyone in the Java community needs. > > I think *this*

Re: Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames)

Mark I think some of the assertions on the prevalence of the pom.properties is wrong. We pulled our own top 20 list based on download popularity and you can see it lines up well with your cited article: count | group_name |artifact_name -+

Re: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

Hello, I don't quite understand this. In the proposition below it says osx, and x64, but in platform.m4 you generate macos and amd64. Does this then get translated again and why are we introducing yet another name for the operating system on Apple computers? /Erik On 2017-04-03 20:41, Mand

Re: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

Oh, I missed the further discussion before I posted this and the webrev was apparently updated in place to reflect that discussion. Please ignore my comment below. /Erik On 2017-04-04 11:57, Erik Joelsson wrote: Hello, I don't quite understand this. In the proposition below it says osx, an

Re: Disallowing the dynamic loading of agents by default

Hi Mark, Thanks again for another thoughtful and well-reasoned response. On 03/04/17 23:36, mark.reinh...@oracle.com wrote: > 2017/4/3 9:44:43 -0700, Andrew Dinn : >> One thing I am not clear on as regards that 'really nice' is whether >> anything in the JVM wants -- or even hopes -- to rely on m

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. . . . Ye

Re: Disallowing the dynamic loading of agents by default

Hi Mark, hi Alan, hi all, I am one of the developers of JProfiler and would like to share our thoughts and suggestions regarding this change. My understanding is that the goal is to prevent libraries from using agents to break access checks while not disrupting all other agent use cases as far as

Re: Disallowing the dynamic loading of agents by default

> On Apr 3, 2017, at 6:59 PM, mark.reinh...@oracle.com wrote: > > 2017/4/3 10:52:02 -0700, alasdair.notting...@gmail.com: >> I’m the lead for WebSphere Liberty at IBM. Liberty uses a java agent, >> and this proposal will affect us. Our Java Agent is used to update the >> bytecode of our classes t

hg: jigsaw/jake/langtools: 2 new changesets

Changeset: b9942e7d5689 Author:jlahoda Date: 2017-04-04 15:08 +0200 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/b9942e7d5689 Resolving one automatic module should resolve all automatic modules. ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! t

hg: jigsaw/jake/jdk: 2 new changesets

Changeset: 50b26c0e7cd8 Author:alanb Date: 2017-04-04 13:17 +0100 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/50b26c0e7cd8 Patching doesn't need to drop hasher ! src/java.base/share/classes/jdk/internal/module/ModulePatcher.java Changeset: e047e62da9f8 Author:alanb Dat

Re: Disallowing the dynamic loading of agents by default

> On Apr 4, 2017, at 8:02 AM, Alasdair Nottingham > wrote: > One of the problems Java has today is that it is very easy to end up > depending on internals > because the JVM has no modularity. It is one thing to end up using a Java API > that is > visible, but not intended to be used by an app

Re: Disallowing the dynamic loading of agents by default

> On Apr 4, 2017, at 4:36 AM, Andrew Dinn wrote: > > On 03/04/17 21:56, John Rose wrote: >> On Apr 3, 2017, at 12:03 PM, Gregg Wonderly >> wrote: >>> >>> Alan, it is exactly this kind of comment from the team which just >>> tears apart the whole view that you might actually be considering >>>

Re: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

2017/4/4 1:04:22 -0700, magnus.ihse.bur...@oracle.com: > On 2017-04-03 23:50, Mandy Chung wrote: >> ... >> >>JDK 8 JDK 9 >>- - >> OS_NAMELinux linux >>SunOS solaris >>Darwin

Re: Disallowing the dynamic loading of agents by default

> On Apr 3, 2017, at 3:36 PM, mark.reinh...@oracle.com wrote: > >> The sort of thing I am thinking about is, say, a module-wide >> global analysis in the JIT guaranteeing that a call argument will only >> ever be non-NULL, a positive int, or some such invariant that can fed >> into an optimizatio

Re: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

On 04/04/2017 10:12 AM, mark.reinh...@oracle.com wrote: 2017/4/4 1:04:22 -0700, magnus.ihse.bur...@oracle.com: On 2017-04-03 23:50, Mandy Chung wrote: ... JDK 8 JDK 9 - - OS_NAMELinux linux SunOS

Re: [aarch64-port-dev ] Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

On 04/04/17 16:12, mark.reinh...@oracle.com wrote: > The trouble here is that "arm64" and "aarch64" are effectively synonyms > for the ISA, but in the JDK we've wound up using them as the names of > two different ports. > > A JMOD file built for the 64-bit ARM architecture will (one hopes) run > e

Re: Disallowing the dynamic loading of agents by default

On 04/04/17 15:58, Gregg Wonderly wrote: > Alan said: > >> The issue here is nothing to do with the security manager, assume >> no security manager in the picture. > > But, I always have a security manager in the picture. It’s how I > always grant access to various pieces of the JDK features to

what is undesired usage of the Java API?

Hi, I think the recent discussion about the agent loading mechanism do show one fundamental problem that many have with the changes through the restricted module system. That is, it is unclear what undesired usage of the Java APIs actually is. So let me write down an unfinished list as discu

Re: [aarch64-port-dev ] Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

> On Apr 4, 2017, at 11:12 AM, mark.reinh...@oracle.com wrote: > > 2017/4/4 1:04:22 -0700, magnus.ihse.bur...@oracle.com: >> On 2017-04-03 23:50, Mandy Chung wrote: >>> ... >>> >>> JDK 8 JDK 9 >>> - - >>> OS_NAMELinux linu

Re: Disallowing the dynamic loading of agents by default

> On Apr 3, 2017, at 3:36 PM, mark.reinh...@oracle.com wrote: > > In addition to future performance improvements, let's not forget about > maintainability. Improved integrity allows those of us who maintain the > JDK to change internal implementation details without having to worry > about break

8177530: Module system implementation refresh (4/2017)

As I mentioned on jigsaw-dev yesterday, we have accumulated a number of changes in the jake forest and would like to bring the changes into jdk9/dev for jdk-9+165. Most of the changes in this update are the move of Module and friends from java.lang.reflect to java.lang. This is mostly a mechan

Re: [aarch64-port-dev ] Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

2017/4/4 8:22:50 -0700, a...@redhat.com: > On 04/04/17 16:12, mark.reinh...@oracle.com wrote: >> The trouble here is that "arm64" and "aarch64" are effectively synonyms >> for the ISA, but in the JDK we've wound up using them as the names of >> two different ports. >> >> A JMOD file built for the

Re: [aarch64-port-dev ] Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

On 04/04/17 17:35, mark.reinh...@oracle.com wrote: > This does raise another question, though: Should we use "aarch32" > instead of "arm32" for the 32-bit ARM architecture? Probably not. I believe that "aarch32" is historical revisionism coming from ARM: it didn't exist as a name before AArch64 c

Re: [aarch64-port-dev ] Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

> On Apr 4, 2017, at 12:35 PM, mark.reinh...@oracle.com wrote: > > 2017/4/4 8:22:50 -0700, a...@redhat.com: >> On 04/04/17 16:12, mark.reinh...@oracle.com wrote: >>> The trouble here is that "arm64" and "aarch64" are effectively synonyms >>> for the ISA, but in the JDK we've wound up using them a

Re: what is undesired usage of the Java API?

On 04/04/17 16:51, Jochen Theodorou wrote: > I think the recent discussion about the agent loading mechanism do show > one fundamental problem that many have with the changes through the > restricted module system. That is, it is unclear what undesired usage of > the Java APIs actually is. > > So

Re: 8177530: Module system implementation refresh (4/2017)

Hi Alan, Hotspot changes look good. One minor comment, can you move the definition of java/lang/Module at line #93 in hotspot/src/share/vm/classfile/vmSymbols.hpp up to a new line after #58 which is java/lang/Package? I wouldn't need to see another webrev for this. Thank you, Lois On 4/4/

Review Request: JDK-8177980: ResourceBundle.getBundle throws NoClassDefFoundError when fails to define a class

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8177980/webrev.00/ This is a simple fix. ResourceBundle::getBundle should handle LinkageError that may be thrown by Class.forName when finding a class. Mandy

Re: Review Request: JDK-8177980: ResourceBundle.getBundle throws NoClassDefFoundError when fails to define a class

+1 > On Apr 4, 2017, at 4:28 PM, Mandy Chung wrote: > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8177980/webrev.00/ > > This is a simple fix. ResourceBundle::getBundle should handle LinkageError > that may be thrown by Class.forName when finding a class. > > Mandy

Re: Review Request JDK-8175819: OS name and arch in JMOD files should match the values as in the bundle name

> On Apr 4, 2017, at 12:42 AM, Alan Bateman wrote: > > On 03/04/2017 19:41, Mandy Chung wrote: > >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ >> > I went through the updates to jlink, assuming test SystemModulesTest will be > aligned to the recent mails.

Re: Review Request: JDK-8177980: ResourceBundle.getBundle throws NoClassDefFoundError when fails to define a class

Looks good to me. Naoto On 4/4/17 1:28 PM, Mandy Chung wrote: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8177980/webrev.00/ This is a simple fix. ResourceBundle::getBundle should handle LinkageError that may be thrown by Class.forName when finding a class. Mandy

Re: Disallowing the dynamic loading of agents by default

2017/4/4 3:45:02 -0700, Andrew Dinn : > Thanks again for another thoughtful and well-reasoned response. Thank you for the continued dialogue. > On 03/04/17 23:36, mark.reinh...@oracle.com wrote: >> 2017/4/3 9:44:43 -0700, Andrew Dinn : >>> ... >>> >>> I'm very happy to consider all sorts of half

Re: Disallowing the dynamic loading of agents by default

2017/4/4 6:02:28 -0700, alasdair.notting...@gmail.com: >> On Apr 3, 2017, at 6:59 PM, mark.reinh...@oracle.com wrote: >> 2017/4/3 10:52:02 -0700, alasdair.notting...@gmail.com: >>> ... However there is one case >>> where we do a dynamic attach of this agent. The

Re: Disallowing the dynamic loading of agents by default

2017/4/4 2:36:38 -0700, Andrew Dinn : > ... > > More generally, it certainly doesn't help anyone when constructive > comments made by OpenJDK developers garner inattentive criticisms that > fail to allow for honest intentions and/or acknowledge different and, > potentially, competing needs. It's e

Re: Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames)

2017/4/4 2:38:37 -0700, Brian Fox : > Mark I think some of the assertions on the prevalence of the pom.properties > is wrong. We pulled our own top 20 list based on download popularity and > you can see it lines up well with your cited article: > > count | group_name |artifa

hg: jigsaw/jake/jdk: Update jtreg required version to 4.2 b07

Changeset: 3f059be20ccb Author:mchung Date: 2017-04-04 22:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/3f059be20ccb Update jtreg required version to 4.2 b07 ! test/TEST.ROOT

hg: jigsaw/jake/hotspot: Update jtreg required version to 4.2 b07

Changeset: b0076c96fadc Author:mchung Date: 2017-04-04 22:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b0076c96fadc Update jtreg required version to 4.2 b07 ! test/TEST.ROOT

hg: jigsaw/jake/nashorn: Update jtreg required version to 4.2 b07

Changeset: f1d6cca3853b Author:mchung Date: 2017-04-04 22:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/f1d6cca3853b Update jtreg required version to 4.2 b07 ! test/TEST.ROOT

hg: jigsaw/jake/langtools: Update jtreg required version to 4.2 b07

Changeset: a564c0126103 Author:mchung Date: 2017-04-04 22:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/a564c0126103 Update jtreg required version to 4.2 b07 ! test/TEST.ROOT

hg: jigsaw/jake/jaxp: Update jtreg required version to 4.2 b07

Changeset: d44354fed774 Author:mchung Date: 2017-04-04 22:09 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/d44354fed774 Update jtreg required version to 4.2 b07 ! test/TEST.ROOT

Re: Disallowing the dynamic loading of agents by default

On Apr 3, 2017, at 3:36 PM, mark.reinh...@oracle.com wrote: > > If developers and deployers have to to opt-in to breaking encapsulation > on the command line then that at least makes it clear to someone trying > to diagnose a failing system that something fishy might be going on. It seems to me t

Re: Disallowing the dynamic loading of agents by default

Comments inlined Chris > On 5. Apr 2017, at 07:19, John Rose wrote: > > On Apr 3, 2017, at 3:36 PM, mark.reinh...@oracle.com wrote: >> >> If developers and deployers have to to opt-in to breaking encapsulation >> on the command line then that at least makes it clear to someone trying >> to dia

Re: 8177530: Module system implementation refresh (4/2017)

The hotspot part looks good to me. Some copyright comments need update: http://cr.openjdk.java.net/~alanb/8177530/1/hotspot/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.test/src/org/graalvm/compiler/test/ExportingClassLoader.java.frames.html http://cr.openjdk.java.net/~alanb/81

Re: 8177530: Module system implementation refresh (4/2017)

On 05/04/2017 07:42, serguei.spit...@oracle.com wrote: The hotspot part looks good to me. + It seems, all the modules are modifiable at this point. Is it right? That's right. On the copyright dates then Lana will be doing a bulk update soon. I expect it will update hundreds of files. I don't

Re: 8177530: Module system implementation refresh (4/2017)

Ok. Thanks, Alan Serguei On 4/4/17 23:52, Alan Bateman wrote: On 05/04/2017 07:42, serguei.spit...@oracle.com wrote: The hotspot part looks good to me. + It seems, all the modules are modifiable at this point. Is it right? That's right. On the copyright dates then Lana will be doing a bulk