New candidate JEP: 403: Strongly Encapsulate JDK Internals

https://openjdk.java.net/jeps/403 Summary: Strongly encapsulate all internal elements of the JDK, except for critical internal APIs such as sun.misc.Unsafe. It will no longer be possible to relax the strong encapsulation of internal elements via a single command-line option, as was

New candidate JEP: 396: Strongly Encapsulate JDK Internals by Default

https://openjdk.java.net/jeps/396 - Mark

Re: RFR: 8242039: Improve jlink VersionPropsPlugin

2020/4/3 6:36:53 -0700, christoph.lan...@sap.com: > 2020/4/2 14:12:54 -0700, mark.reinh...@oracle.com: >> I thought about doing this when I originally wrote that plugin, but it’s >> so awkward to achieve with ASM -- as demonstrated by your patch -- that >> I concluded it wasn’t worth it. Who will

Re: RFR: 8242039: Improve jlink VersionPropsPlugin

2020/4/2 8:01:28 -0700, christoph.lan...@sap.com: > please review a small improvement for the jlink > VersionPropsPlugin. The Plugin modifies the bytecode of > java/lang/VersionProps.class to replace the initializion of certain > vendor specific system properties with custom values. This >

The baby and the bathwater

Stephen Colebourne's recent blog entry [1] contains many true statements, along with some reasonable advice for library maintainers. To summarize: - As of Java 9, with Jigsaw, there are two ways in which a library can be used: Either on the traditional class path, or on the newfangled

Re: Signing jlink code for macOS on other platforms

2018/2/12 3:44:07 -0800, Mark Raynsford : > ... > > Are there any plans to implement anything that's capable of signing > macOS binaries and resources in a platform-independent way so that > jlink-produced distributions can work without warnings? No. >

Re: RFR JDK-8170114 jimage extract to not an empty directory overwrites content of the directory

2018/2/11 23:10:46 -0800, Michal Vala : > On 02/10/2018 11:25 AM, Alan Bateman wrote: >> ... >> >> I think the `jimage extract --dir ` scenario >> needs >> discussion. If is a non-directory file then jimage has to >> fail, >> I don't expect disagreement on that. For the

Re: Definitive list of modules that go into bootstrap class loader?

2017/12/6 17:55:52 -0500, sst...@redhat.com: > Is there a definitive list of modules that go into bootstrap class loader? http://openjdk.java.net/jeps/261#Class-loaders - Mark

Re: Using legacy jar files with jlink

2017/11/16 15:03:37 -0800, Thomas Brand : > this is my first post here, I hope this is the right place to ask a > question about how to use jlink. Yes, it is! > For a given scenario with modules a and b, a using methods of b, following > instructions I managed to create a

Re: Retrieving the bytes of platform classes

2017/10/23 10:55:15 -0700, alan.bate...@oracle.com: > On 23/10/2017 18:48, Mark Raynsford wrote: >> : >> >> In the olden days, we'd probably have gone rummaging in rt.jar, but >> that was obviously a hack and wasn't future-proof. My tool is only >> designed to work with JDK 9 and up. >> >> Note

Project Jigsaw: Complete!

As you all probably know by now, yesterday we shipped the GA release of JDK 9, and so at last the Jigsaw is complete. I wrote a bit more about this milestone on my blog: https://mreinhold.org/blog/jigsaw-complete I've updated the project page (http://openjdk.java.net/projects/jigsaw/), and

Re: Proper term for non-automatic modules

2017/8/28 23:56:44 -0700, alan.bate...@oracle.com: > ... > > We've been using term "explicit". You'll see it used in the > ModuleFinder.of(Path...) spec for example where it describes a modular > JAR as defining an explicit module. Yes -- "explicit" is the appropriate term here. We've used it

Re: "The State of the Module System" should be marked as outdated

2017/7/27 6:31:19 -0700, volker.simo...@gmail.com: > I think this has been mentioned before, but "The State of the Module > System" under http://openjdk.java.net/projects/jigsaw/spec/sotms/ is > outdated and constantly keeps confusing people. E.g. it still uses > "requires public" instead of

Re: RFR 8182776/8183161/8183251: Miscellaneous API doc fixes

2017/6/30 16:08:09 -0700, jonathan.gibb...@oracle.com: > Mark, > > The font-family settings in the nodes were deliberate, and a > workaround for not having time to create a proper taglet for tool guides. > > If you remove the style attribute, you'll see in your sample output that > the "Tool

RFR 8182776/8183161/8183251: Miscellaneous API doc fixes

8182776: Fix typo "upgradeble" in the javadoc of upgradeable modules 8183161: Remove extraneous font-family style attributes from module declarations 8183251: Meta "keywords" tag malformed in overview-summary.html and related pages http://cr.openjdk.java.net/~mr/rev/8182776/jdk9-dev.patch

Re: 8182482: Module System spec updates

2017/6/20 12:20:16 +0200, alan.bate...@oracle.com: > ... > > The webrev with the proposed (docs only, no implementation) changes is here: >http://cr.openjdk.java.net/~alanb/8182482/webrev/index.html > > The ServiceLoader diffs are hard to read. It might be easier to read the > generated

Re: Annotation-based syntax for module-info.java

2017/6/12 6:26:10 -0700, markus_kel...@ch.ibm.com: > [I know this is coming way too late, and my recent accident that > incapacitated me for several week didn't help either. Nevertheless, I > think the current module-info.java syntax was a snap decision that should > not end up in the Java 9

Proposal (revised): Allow illegal access to internal APIs by default in JDK 9

(Thanks for all the feedback on the initial proposal [1]. Here's a revised version, which incorporates some of the suggestions received and includes a bit more advice. An implementation is already available for testing in the Jigsaw EA builds [2]. Further comments welcome!) Over time, as

Proposal: Allow illegal reflective access by default in JDK 9

Over time, as we've gotten closer and closer to the JDK 9 GA date, more and more developers have begun paying attention the actual changes in this release. The strong encapsulation of JDK-internal APIs has, in particular, triggered many worried expressions of concern that code that works on JDK 8

Re: Views on JSR 376 from the Eclipse JDT team

2017/5/6 14:27:27 -0700, mike.milinkov...@eclipse.org: > Mark, > > You are comparing apples to oranges. The Eclipse Compiler for Java is > neither a tool, nor a framework. A compiler is a particular kind of software-development tool, last I checked. An important one, certainly, but a tool

Re: Views on JSR 376 from the Eclipse JDT team

2017/5/6 13:51:32 -0700, stephan.herrm...@berlin.de: > Mark, > > I am honestly glad that my role in all this is not at a management level, > but at the technical level, so I humbly refrain from answering your questions. Understood. > Still, I feel qualified and obliged to add my share of

Re: Views on JSR 376 from the Eclipse JDT team

2017/5/6 9:56:12 -0700, stephan.herrm...@berlin.de: > Alex, > > I appreciate your answers to our questions, which give hope > that a future version - incorporating all this - will be sufficient > for defining what is Java 9 from a compiler's perspective. > > The post sent by Markus explicitly

Re: Revised proposal for #AutomaticModuleNames

2017/5/5 3:04:15 -0700, Robert Scholte : > thanks for these adjustments. In general they look good, but it all > depends on the details: > > Define a JAR-file manifest attribute, `Automatic-Module-Name`, whose > value is used as the name of the automatic module

Re: Revised proposal for #AutomaticModuleNames

2017/5/4 14:21:38 -0700, Stephen Colebourne : > On 4 May 2017 at 18:38, mark.reinh...@oracle.com wrote: >> ... >> >> - Define a JAR-file manifest attribute, `Automatic-Module-Name`, whose >>value is used as the name of the automatic module defined by that JAR >>file

Revised proposal for #AutomaticModuleNames

Thanks to everyone, and especially Stephen Colebourne, Brian Fox, and Robert Scholte, for the extensive feedback. http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-May/000687.html TL;DR: Keep automatic modules, bring back the module-name JAR-file manifest attribute, and strongly

Re: Auto-modules vs. the unnamed module

2017/4/27 8:16:50 -0700, Andrew Dinn : > On 27/04/17 15:58, Ceki Gulcu wrote: >> Please forgive my possibly silly question but can someone kindly explain >> the advantages of placing a non-modular artifact on the module path >> instead of the class path? In other words, why

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

2017/4/25 5:08:21 -0700, Stephen Colebourne : > On 24 April 2017 at 19:54, wrote: >> An explicit module that depends upon one or more modules that are >> automatic today is, itself, no more stable than those automatic modules. >> It could be broken

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

2017/4/25 6:53:45 -0700, bri...@infinity.nu: > ... > > While it's technically true you can consider all the exports to be part of > the API, the reality is that most libraries aren't used that way. In fact, > there are commonly accepted tools to detect when you are depending on a > transitive

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

2017/4/24 10:39:25 -0700, Brian Fox : > On Mon, Apr 24, 2017 at 12:14 PM, mark.reinh...@oracle.com wrote: >> The problem with any approach that allows you to give a stable name to >> what is otherwise an automatic module is that the API of that module is >> inherently unstable.

Re: Java Platform Module System

2017/4/24 9:14:31 -0700, ja...@outlook.in: > The JLS makes references to the "Java Platform Module System" in > several places but we are not sure where this is specified. The > Eclipse JDT team has been making do with whatever informal documents > we can get our hands on such as "State of the

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

2017/4/3 10:34:14 -0700, Stephen Colebourne : > On [1] the conclusion given the premise is not unreasonable. The file > name can be easily changed by a developer or build tool to match the > expected module name. However, it is the premise I strongly object to: > > "The

Re: Disallowing the dynamic loading of agents by default (revised)

2017/4/6 10:48:12 -0700, alasdair.notting...@gmail.com: > On Apr 5, 2017, at 12:15 PM, mark.reinh...@oracle.com wrote: >> >> Thanks to everyone for the quick feedback on this topic, and especially >> to Andrew for the constructive dialogue. >> >> Here's a revised proposal: >> >> - Define a new

Re: Disallowing the dynamic loading of agents by default (revised)

2017/4/6 3:09:49 -0700, Andrew Dinn : > On 05/04/17 17:15, mark.reinh...@oracle.com wrote: >> Thanks to everyone for the quick feedback on this topic, and especially >> to Andrew for the constructive dialogue. >> >> Here's a revised proposal: >> >> - Define a new VM option,

Re: Disallowing the dynamic loading of agents by default (revised)

2017/4/6 2:07:27 -0700, michael.rasmus...@zeroturnaround.com: > On 6 April 2017 at 02:34, wrote: >> Interesting. Perhaps we need a `Self-Premain-Class` attribute, or some >> such. >> >> Out of curiosity, would it do any harm in your `java -jar` case if the >> agent is

hg: jigsaw/jake/nashorn: Added tag jpms-pr2 for changeset b3ea15f8d67d

Changeset: ee4c180e7758 Author:mr Date: 2017-04-09 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/ee4c180e7758 Added tag jpms-pr2 for changeset b3ea15f8d67d ! .hgtags

hg: jigsaw/jake/jaxws: Added tag jpms-pr2 for changeset af75b2041f87

Changeset: 62cdc22fb741 Author:mr Date: 2017-04-09 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/62cdc22fb741 Added tag jpms-pr2 for changeset af75b2041f87 ! .hgtags

hg: jigsaw/jake/jdk: Added tag jpms-pr2 for changeset b2160414fe8c

Changeset: 89da9f6d9b30 Author:mr Date: 2017-04-09 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/89da9f6d9b30 Added tag jpms-pr2 for changeset b2160414fe8c ! .hgtags

hg: jigsaw/jake/hotspot: Added tag jpms-pr2 for changeset 3ef5cda929ab

Changeset: 4129a3cc9339 Author:mr Date: 2017-04-09 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4129a3cc9339 Added tag jpms-pr2 for changeset 3ef5cda929ab ! .hgtags

hg: jigsaw/jake/langtools: Added tag jpms-pr2 for changeset ff80ebf4ace6

Changeset: 37f6bf474928 Author:mr Date: 2017-04-09 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/37f6bf474928 Added tag jpms-pr2 for changeset ff80ebf4ace6 ! .hgtags

hg: jigsaw/jake: Added tag jpms-pr2 for changeset 4749335f788f

Changeset: a787dca95191 Author:mr Date: 2017-04-09 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/a787dca95191 Added tag jpms-pr2 for changeset 4749335f788f ! .hgtags

hg: jigsaw/jake/corba: Added tag jpms-pr2 for changeset 9bc5ee131c5b

Changeset: f79c55d85600 Author:mr Date: 2017-04-09 13:57 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/f79c55d85600 Added tag jpms-pr2 for changeset 9bc5ee131c5b ! .hgtags

Re: Disallowing the dynamic loading of agents by default (revised)

2017/4/5 10:00:13 -0700, michael.rasmus...@zeroturnaround.com: > On 5 April 2017 at 19:15, wrote: >> ... >> >> - Enhance the `-jar` launcher option so that if the JAR file being >>launched contains a `Premain-Class` attribute then it's launched >>as both an

Disallowing the dynamic loading of agents by default (revised)

Thanks to everyone for the quick feedback on this topic, and especially to Andrew for the constructive dialogue. Here's a revised proposal: - Define a new VM option, `-XX:+EnableDynamicAgentLoading`, that's on by default in JDK 9 but off by default in JDK 10. This will allow launch

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,

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.

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

2017/4/2 23:28:02 -0700, ch...@hazelcast.com: > First of all, I understand the idea behind this change and I think it > certainly makes sense but from my impression the default is wrong, as > Volker already pointed out. > > Over the last few days I (with the help of others) put together a >

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

2017/4/3 14:50:52 -0700, mandy.ch...@oracle.com: >> On Apr 3, 2017, at 2:39 PM, mark.reinh...@oracle.com wrote: >> 2017/4/3 13:35:30 -0700, si...@cjnash.com: >>> ... >>> >>> I am not sure why we would change to osx for Mac when the Mac developers >>> have recently dropped the Mac OS X terminology

Re: Disallowing the dynamic loading of agents by default

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 to add in instrumentation for debug logging > and performance

Re: Disallowing the dynamic loading of agents by default

2017/4/3 9:44:43 -0700, Andrew Dinn : > On 03/04/17 16:50, Alan Bateman wrote: >> ... >> >> Java SE 9 / JDK 9 brings strong encapsulation. The access control for >> the Java Language and VM has been extended to modules so that modules >> that don't want their internals to be

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

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/webrevs/8175819/webrev.00/ >>> >>> ... >>> >>> This shows the old and new value of

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

2017/4/3 11:41:03 -0700, mandy.ch...@oracle.com: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/ > > ... > > This shows the old and new value of OS_NAME/OS_ARCH properties > in the `release` file: > > JDK 8 JDK 9 > -

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

Thanks for the continued feedback on this difficult issue. FYI: http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-April/000666.html http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-April/000667.html - Mark

Disallowing the dynamic loading of agents by default

// Moving the general discussion to jigsaw-dev for the record; // bcc'ing {hotspot-runtime,serviceability}-dev for reference. Andrew, Thanks for your feedback on this topic [1][2][3]. First, we apologize for the way in which this topic was raised. Our intent was to post a proposal for

Re: Better tools for adjusting to strong encapsulation

Thanks to everyone for all the feedback on this topic. It appears that issuing warning messages for illegal-access operations enabled by the precise `--add-opens` and `--add-exports` options is a bit too aggressive, at least for JDK 9. Perhaps we can enable that in JDK 10 after there's been more

hg: jigsaw/jake/jdk: Add an #automatic-modules anchor to the ModuleFinder specification

Changeset: 808775b91969 Author:mr Date: 2017-03-22 16:19 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/808775b91969 Add an #automatic-modules anchor to the ModuleFinder specification ! src/java.base/share/classes/java/lang/module/ModuleFinder.java

Better tools for adjusting to strong encapsulation

By now we've heard quite a bit of feedback, both publicly and privately, from developers who've migrated existing applications to JDK 9. This can be a non-trivial task, involving the iterative construction of a set of command-line workarounds, since some popular libraries and frameworks use the

Re: Alternatives to automatic modules as a concept

2017/3/20 2:29:12 -0700, c...@qos.ch: > On March 20, 2017 1:44 AM Alam Bateman wrote: >> There isn't any notification/callback. Also it's not clear to me that >> injecting code into SLF4J is the right thing to do (it feels like hacking). >> >> If I were a SLF4J maintainer then I think I would

hg: jigsaw/jake/nashorn: Added tag jpms-pr for changeset 4f1524113615

Changeset: 8cae992eb1eb Author:mr Date: 2017-03-14 17:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/8cae992eb1eb Added tag jpms-pr for changeset 4f1524113615 ! .hgtags

hg: jigsaw/jake/langtools: Added tag jpms-pr for changeset a1af3e797767

Changeset: 78617568c853 Author:mr Date: 2017-03-14 17:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/78617568c853 Added tag jpms-pr for changeset a1af3e797767 ! .hgtags

hg: jigsaw/jake/jaxp: Added tag jpms-pr for changeset c089440c555a

Changeset: 19ccfbe2bff5 Author:mr Date: 2017-03-14 17:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/19ccfbe2bff5 Added tag jpms-pr for changeset c089440c555a ! .hgtags

hg: jigsaw/jake/hotspot: Added tag jpms-pr for changeset 1b26ff0b6e34

Changeset: 8c378471e336 Author:mr Date: 2017-03-14 17:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8c378471e336 Added tag jpms-pr for changeset 1b26ff0b6e34 ! .hgtags

hg: jigsaw/jake/jaxws: Added tag jpms-pr for changeset 6bd03b652316

Changeset: 23d120d1b411 Author:mr Date: 2017-03-14 17:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/23d120d1b411 Added tag jpms-pr for changeset 6bd03b652316 ! .hgtags

hg: jigsaw/jake/jdk: 2 new changesets

Changeset: 59f5e8df6794 Author:mr Date: 2017-03-14 17:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/59f5e8df6794 Added tag jpms-pr for changeset 7d1036e8cca7 ! .hgtags Changeset: 4db5bc28fa87 Author:mr Date: 2017-03-14 17:03 -0700 URL:

hg: jigsaw/jake/corba: Added tag jpms-pr for changeset 06060e841882

Changeset: d350183f382e Author:mr Date: 2017-03-14 17:03 -0700 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/d350183f382e Added tag jpms-pr for changeset 06060e841882 ! .hgtags

hg: jigsaw/jake/jdk: Add missing @spec/@revised tags for JPMS PR

Changeset: afa342473815 Author:mr Date: 2017-02-26 15:23 + URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/afa342473815 Add missing @spec/@revised tags for JPMS PR ! src/java.base/share/classes/java/lang/ClassLoader.java !

How to name modules, automatic and otherwise

Thanks to everyone for all the feedback on this topic. I've posted my conclusions here: http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-February/000582.html - Mark

Re: Java SE JSR 250 annotations module renamed to java.xml.ws.annotation?

2017/2/13 9:17:47 -0800, Guillaume Smet : > On Mon, Feb 13, 2017 at 6:10 PM, alan.bate...@oracle.com wrote: >> On 13/02/2017 16:58, Guillaume Smet wrote: >>> On Mon, Feb 13, 2017 at 5:12 PM, alan.bate...@oracle.com wrote: I agree that @Generated is awkward but I

hg: jigsaw/jake/jdk: 4 new changesets

Changeset: d6eee62a15ca Author:mr Date: 2017-01-09 14:12 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d6eee62a15ca Add @revised and @spec tags for the JPMS specification ! src/java.base/share/classes/java/lang/Class.java !

hg: jigsaw/jake/jaxws: 3 new changesets

Changeset: f3a9335f6f44 Author:mr Date: 2017-01-12 17:46 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxws/rev/f3a9335f6f44 Added tag jpms-edr for changeset b148ffe87b58 ! .hgtags Changeset: 4c46cd09f7eb Author:mr Date: 2017-01-12 18:05 -0800 URL:

hg: jigsaw/jake/langtools: 4 new changesets

Changeset: ff59f4589b3e Author:mr Date: 2017-01-09 14:12 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/ff59f4589b3e Add @revised and @spec tags for the JPMS specification ! src/java.compiler/share/classes/javax/lang/model/element/Element.java !

hg: jigsaw/jake: 3 new changesets

Changeset: 6bdef88dea24 Author:mr Date: 2017-01-12 17:46 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/rev/6bdef88dea24 Added tag jpms-edr for changeset 88094de8a4cc ! .hgtags Changeset: 4692b5e8bfec Author:mr Date: 2017-01-12 18:05 -0800 URL:

hg: jigsaw/jake/nashorn: 3 new changesets

Changeset: 64bc77a70efe Author:mr Date: 2017-01-12 17:46 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/nashorn/rev/64bc77a70efe Added tag jpms-edr for changeset 9488d434850a ! .hgtags Changeset: 47d6631559bc Author:mr Date: 2017-01-12 18:05 -0800 URL:

hg: jigsaw/jake/hotspot: 3 new changesets

Changeset: 8b7a77a3986f Author:mr Date: 2017-01-12 17:46 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/8b7a77a3986f Added tag jpms-edr for changeset 8ff4522d2ecb ! .hgtags Changeset: fb1033843eb0 Author:mr Date: 2017-01-12 18:05 -0800 URL:

hg: jigsaw/jake/jaxp: 3 new changesets

Changeset: c3d7cb8b08da Author:mr Date: 2017-01-12 17:46 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jaxp/rev/c3d7cb8b08da Added tag jpms-edr for changeset bddea134df23 ! .hgtags Changeset: fa0981755c22 Author:mr Date: 2017-01-12 18:05 -0800 URL:

hg: jigsaw/jake/corba: 3 new changesets

Changeset: aa59b6e3002d Author:mr Date: 2017-01-12 17:46 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/corba/rev/aa59b6e3002d Added tag jpms-edr for changeset c7995982569d ! .hgtags Changeset: 37c94d33c7bf Author:mr Date: 2017-01-12 18:05 -0800 URL:

Re: 8170987: Module system implementation refresh (12/2016)

2016/12/14 15:31:18 -0800, claes.redes...@oracle.com: > ... > > WARNING could be a local anonymous class inside > printStackTraceIfExposedReflectively. ;-) Good point -- fixed. - Mark

hg: jigsaw/jake/jdk: DEBUG_ADD_OPENS: Anonymize the WARNING exception class

Changeset: 7224d3b718ed Author:mr Date: 2016-12-15 07:15 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/7224d3b718ed DEBUG_ADD_OPENS: Anonymize the WARNING exception class ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java

hg: jigsaw/jake/jdk: DEBUG_ADD_OPENS: Further message tweaks

Changeset: d435ff62fe7e Author:mr Date: 2016-12-14 11:58 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/d435ff62fe7e DEBUG_ADD_OPENS: Further message tweaks ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java

hg: jigsaw/jake/jdk: DEBUG_ADD_OPENS: s/RESOLVED/ALL-RESOLVED/; tweak warning messages

Changeset: b2442ace41dd Author:mr Date: 2016-12-14 11:15 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/b2442ace41dd DEBUG_ADD_OPENS: s/RESOLVED/ALL-RESOLVED/; tweak warning messages ! src/java.base/share/classes/java/lang/reflect/AccessibleObject.java !

Re: Services and Bindings - expected usage scenarios

2016/11/29 9:30:29 -0800, vitaliy.pisa...@hpe.com: > Thank you mark, this goes far to answer my question. > > I do want to ask you 3 follow-up questions: > > ... > > By promoting the SL pattern, aren’t you effectively taking a stand in > this debate? An SL proponent might say: "Look! The Java

Re: Services and Bindings - expected usage scenarios

2016/11/29 6:54:35 -0800, vitaliy.pisa...@hpe.com: > ... > > I am looking at the great features in Java 9 and I know that we are > going to "jump" on the new module system with all the encapsulation it > gives us. But I and my fellow Architects are very unsure what to > think of the

hg: jigsaw/jake/jdk: Add --{help, help-extra, version, full-version, show-version} launcher options to print to stdout

Changeset: 9e5ecc1ee202 Author:mr Date: 2016-11-29 07:35 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/9e5ecc1ee202 Add --{help,help-extra,version,full-version,show-version} launcher options to print to stdout !

Re: Apache Maven Compiler Plugin 3.6.0 Released

2016/10/30 10:41:36 -0700, Robert Scholte : > The Apache Maven team is pleased to announce the release of the Apache > Maven Compiler Plugin, version 3.6.0 > > The Compiler Plugin is used to compile the sources of your project. > > This version introduces support of

New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

Thanks to everyone who commented on the weak-modules proposal. I've just posted a third proposal for #ReflectiveAccessToNonExportedTypes, along with an analysis of the proposals presented thus far: http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-October/000430.html

Re: Proposal: #ServiceLoaderEnhancements

2016/9/12 15:08:41 -0700, Stephen Colebourne : > My preference of these three options is option 2. Sorry if I wasn't clear, but this isn't meant to be a "choose one" proposal. It's a set of check boxes, not radio buttons. The proposal is to implement suggestions (2) and

More proposals for open JPMS issues

FYI, I've just posted new or revised proposals for some of the open issues in the JPMS specification: #ReflectiveAccessToNonExportedTypes & #AwkwardStrongEncapsulation http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/000390.html #AddExportsInManifest

Re: Proposal for JPMS issue #ReflectiveAccessByInstrumentationAgents

2016/7/27 4:33:11 -0700, Andrew Dinn : > Regarding the proposed solution of adding method redefineModule to class > Instrumentation: > > I have a Proof Of Concept implementation which shows that that this > solution works for my agent and does not impose unworkable

Re: Any word on the updated spec

2016/9/7 7:50:54 -0700, Jayaprakash Artanareeswaran : > Now that JDK 9 is feature complete, I was wondering if > the JSR 376 has been updated recently. Specifically, I am interested in > many of the useful information found in the "State of the Module", such > as module graph.

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

(Finally getting back to this thread, now that vacation season is over.) 2016/7/21 10:01:11 -0700, jason.gre...@redhat.com: > On Jul 18, 2016, at 4:30 PM, mark.reinh...@oracle.com wrote: >> 2016/7/13 20:27:45 -0700, jason.gre...@redhat.com: >>> ... >>> >>> Sorry for the confusion, what I was

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

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: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

2016/7/13 20:27:45 -0700, jason.gre...@redhat.com: > Thanks for you reply! My thoughts are inline. I apologize in advance for > the length/verbosity. Also, as a general disclaimer, I realize that you > are all experts; in many of my arguments, I occaisionally restate certain > concepts that I know

Re: Feedback on proposal for #ReflectiveAccessToNonExportedTypes

Jason -- thanks for your feedback on this topic. To put what Alex wrote in a somewhat different way, I'd say that the tension here is between explicit configuration (as one finds today in, e.g., the Maven world) and implicit configuration (IoC). Both approaches are important. The former is

Re: Unnamed module .. singular or plural?

2016/7/13 9:53:04 -0700, pbened...@apache.org: > 1) I think 5.4 clearly contradicts 3.1 on the surface. I don't think it > serves readers any good (it didn't me) to first assert there is just "one > unnamed module" and then, if you keep on reading to the advanced topics, > find out there's many

Re: Unnamed module .. singular or plural?

2016/7/13 7:35:08 -0700, pbened...@apache.org: > Given that ClassLoader#getUnnamedModule is not a static method, the > signature implies different class loaders can have different unnamed > modules. I only say "imply" because I would expected a static method to be > the source of a singleton

Please do not cross-post to jpms-spec-comme...@openjdk.java.net

The jpms-spec-comments list is meant to be the JSR 376 EG's "suggestion box" rather than a discussion forum. Please do not cross post to that list. I've enabled moderation on that list and, going forward, I'll reject any cross-posted messages. - Mark

Re: Updated EA builds with initial implementations of current proposals

2016/7/7 7:58:29 -0700, ad...@redhat.com: > On 07/07/16 15:52, Paul Benedict wrote: >> Hi Mark. Do these set of changes mean those alternative proposals are now >> set in stone? I didn't know feedback was finished. ... > > I though Alan's note made this clear > > "The jigsaw/jake forest has been

Re: New EA builds, contains initial implementation of current proposals

2016/7/6 11:36:41 -0700, alan.bate...@oracle.com: > ... > > One other significant change in this build is that it has the new forms > for the command line options. As has been mentioned in a number of > threads here, we are proposing that the new command line options for > modules use the GNU

Proposals for some open JPMS issues

FYI, I've just posted proposals for some of the open issues in the draft JPMS specification, including: #CompileTimeDependences #ReflectiveAccessToNonExportedTypes #ModuleAnnotations and #ModuleDeprecation #ResourceEncapsulation and #ClassFilesAsResources

  1   2   >