Re: RFR: JDK-8285497: Add system property for Java SE specification maintenance version [v7]

On Wed, 4 May 2022 23:10:06 GMT, Joe Darcy wrote: >> Add a new system property, java.specification.maintenance.version, to return >> the maintenance release number of the Java SE specification being >> implemented. The property is unset, optional in the terminology of >> System.getProperties,

Re: RFR: JDK-8285497: Add system property for Java SE specification maintenance version [v6]

On Mon, 2 May 2022 20:31:18 GMT, Joe Darcy wrote: >> Add a new system property, java.specification.maintenance.version, to return >> the maintenance release number of the Java SE specification being >> implemented. The property is unset, optional in the terminology of >> System.getProperties,

Re: RFR: JDK-8285497: Add system property for Java SE specification maintenance version [v5]

On Tue, 3 May 2022 01:20:10 GMT, Joe Darcy wrote: >> In the latest push, to address the concerns raised updated the proposed >> wording to, in plain text: >> >> Java Runtime Environment specification maintenance version, not defined >> before the specification implemented by this runtime has

Re: RFR: JDK-8285497: Add system property for Java SE specification maintenance version [v5]

On Fri, 29 Apr 2022 02:12:19 GMT, Iris Clark wrote: >> Joe Darcy has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Change punctuation from review feedback. > > src/java.base/share/classes/java/lang/System.java line 743: > >> 741: *

Re: RFR: JDK-8285497: Add system property for Java SE specification maintenance version [v4]

On Thu, 28 Apr 2022 20:54:29 GMT, Joe Darcy wrote: >> Add a new system property, java.specification.maintenance.version, to return >> the maintenance release number of the Java SE specification being >> implemented. The property is unset, optional in the terminology of >>

Re: RFR: JDK-8285497: Add system property for Java SE specification maintenance version [v3]

On Thu, 28 Apr 2022 20:15:36 GMT, Joe Darcy wrote: >> Add a new system property, java.specification.maintenance.version, to return >> the maintenance release number of the Java SE specification being >> implemented. The property is unset, optional in the terminology of >>

Re: RFR: JDK-8285764: Add system property for Java SE specification maintenance version [v2]

On Thu, 28 Apr 2022 17:36:32 GMT, Joe Darcy wrote: >> Add a new system property, java.specification.maintenance.version, to return >> the maintenance release number of the Java SE specification being >> implemented. The property is unset, optional in the terminology of >>

[jdk18] Integrated: 8276826: Clarify the ModuleDescriptor.Version specification’s treatment of repeated punctuation characters

On Thu, 16 Dec 2021 22:16:26 GMT, Mark Reinhold wrote: > Please review this tiny specification clarification. This pull request has now been integrated. Changeset: f5d7c777 Author: Mark Reinhold URL: https://git.openjdk.java.net/jdk18/commit/f5d7c777bc516fa2e711c19d5281ebf32384b

Re: [jdk18] RFR: 8276826: Clarify the ModuleDescriptor.Version specification’s treatment of repeated punctuation characters

On Thu, 16 Dec 2021 22:16:26 GMT, Mark Reinhold wrote: > Please review this tiny specification clarification. Drat, used the wrong bug id. - PR: https://git.openjdk.java.net/jdk18/pull/39

[jdk18] RFR: 8276826: Clarify the ModuleDescriptor.Version specification’s treatment of repeated punctuation characters

Please review this tiny specification clarification. - Commit messages: - 8278465: Clarify the ModuleDescriptor.Version specification’s treatment of repeated punctuation characters Changes: https://git.openjdk.java.net/jdk18/pull/39/files Webrev:

Re: RFR: 8276766: Enable jar and jmod to produce deterministic timestamped content [v4]

On Tue, 23 Nov 2021 20:29:15 GMT, Andrew Leonard wrote: >> Add a new --source-date (epoch seconds) option to jar and jmod >> to allow specification of time to use for created/updated jar/jmod entries. >> This then allows the ability to make the content deterministic. >> >> Signed-off-by:

New candidate JEP: 421: Deprecate Finalization for Removal

https://openjdk.java.net/jeps/421 Summary: Deprecate finalization for removal in a future release. Finalization remains enabled by default for now, but can be disabled to facilitate early testing. In a future release it will be disabled by default, and in a later release it will be

Re: RFR: 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently

On Thu, 30 Sep 2021 11:26:12 GMT, Masanori Yano wrote: > @mbreinhold Could you comment on this pull request? This is somewhat tricky code. I’ll take a look, but give me a few days. - PR: https://git.openjdk.java.net/jdk/pull/5679

Re: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17

On Thu, 5 Aug 2021 21:40:40 GMT, Naoto Sato wrote: >> According to the comments in the makefile >> (`closed/make/UpdateOpenManPages.gmk`) the copyright line is taken from the >> original Markdown file, so if the year is wrong there, it will be wrong in >> the generated nroff file. >> >> I

Re: [jdk17] RFR: JDK-8270872: Final nroff manpage update for JDK 17

On Thu, 5 Aug 2021 19:20:50 GMT, Jonathan Gibbons wrote: > Please review a semi-automatic update of the nroff man pages from the > upstream files. Marked as reviewed by mr (Lead). - PR: https://git.openjdk.java.net/jdk17/pull/303

New candidate JEP: 416: Reimplement Core Reflection with Method Handles

https://openjdk.java.net/jeps/416 Summary: Reimplement java.lang.reflect.Method, Constructor, and Field on top of java.lang.invoke method handles. Making method handles the underlying mechanism for reflection will reduce the maintenance and development cost of both the java.lang.reflect

Integrated: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals

On Thu, 13 May 2021 17:14:36 GMT, Mark Reinhold wrote: > Please review this implementation of JEP 403 > (https://openjdk.java.net/jeps/403). > Alan Bateman is the original author of almost all of it. Passes tiers 1-3 on > {linux,macos,windows}-x64 and {linux,macos}-aarch64. This

Re: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v3]

On Fri, 14 May 2021 08:54:23 GMT, Alan Bateman wrote: >> Mark Reinhold has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Remove now-unnecessary uses and mentions of the --illegal-access option > > t

Re: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v4]

> Please review this implementation of JEP 403 > (https://openjdk.java.net/jeps/403). > Alan Bateman is the original author of almost all of it. Passes tiers 1-3 on > {linux,macos,windows}-x64 and {linux,macos}-aarch64. Mark Reinhold has updated the pull request incrementa

Re: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v2]

On Thu, 13 May 2021 18:16:23 GMT, Mandy Chung wrote: >> Mark Reinhold has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Remove stray mentions of the jdk.module.illegalAccess property > > There are a few tes

Re: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v3]

> Please review this implementation of JEP 403 > (https://openjdk.java.net/jeps/403). > Alan Bateman is the original author of almost all of it. Passes tiers 1-3 on > {linux,macos,windows}-x64 and {linux,macos}-aarch64. Mark Reinhold has updated the pull request incrementa

Re: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v2]

On Thu, 13 May 2021 17:37:42 GMT, Harold Seigel wrote: >> Mark Reinhold has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Remove stray mentions of the jdk.module.illegalAccess property > > src/hotspot/share/r

Re: RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals [v2]

> Please review this implementation of JEP 403 > (https://openjdk.java.net/jeps/403). > Alan Bateman is the original author of almost all of it. Passes tiers 1-3 on > {linux,macos,windows}-x64 and {linux,macos}-aarch64. Mark Reinhold has updated the pull request incrementa

RFR: 8266851: Implement JEP 403: Strongly Encapsulate JDK Internals

Please review this implementation of JEP 403 (https://openjdk.java.net/jeps/403). Alan Bateman is the original author of almost all of it. Passes tiers 1-3 on {linux,macos,windows}-x64 and {linux,macos}-aarch64. - Commit messages: - 8266851: Implement JEP 403: Strongly

Re: RFR: 8266783: java\lang\reflect\Proxy\DefaultMethods.java fails with jtreg 6

On Tue, 11 May 2021 16:48:28 GMT, Mandy Chung wrote: > Data provider with varargs does not work on TestNG 7.4.0. Fix the test to > create an object array instead of varargs to workaround this issue. All those backslashes hurt my eyes. Could we please use forward slashes, both in the commit

New candidate JEP: 415: Context-Specific Deserialization Filters

https://openjdk.java.net/jeps/415 Summary: Allow applications to configure context-specific and dynamically-selected deserialization filters via a JVM-wide filter factory that is invoked to select a filter for each individual deserialization operation. - Mark

Re: RFR: 8265961: Fix comments in logging.properties [v2]

On Mon, 26 Apr 2021 17:14:29 GMT, Pavel Rappo wrote: >> I had been looking for an example of a "properties" file when spotted a typo >> in `logging.properties`. I decided to proofread the file. That resulted in >> finding a few other issues. > > Pavel Rappo has updated the pull request

Re: RFR: 8265961: Fix comments in logging.properties

On Mon, 26 Apr 2021 09:33:03 GMT, Pavel Rappo wrote: > I had been looking for an example of a "properties" file when spotted a typo > in `logging.properties`. I decided to proofread the file. That resulted in > finding a few other issues. Otherwise, these changes look fine.

Re: Dynamic Deserialization Filters - a JEP draft

2021/3/26 8:04:23 -0700, roger.ri...@oracle.com: > Please review a JEP to extend deserialization filtering (JEP 290) to > enable deserialization filters to be selected by the application based > on the runtime context. > > JDK-8263381 Dynamic

New candidate JEP: 400: UTF-8 by Default

https://openjdk.java.net/jeps/400 Summary: Use UTF-8 as the JDK's default charset, so that APIs that depend on the default charset behave consistently across all platforms and independently of the user’s locale and configuration. - Mark

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v14]

On Mon, 18 Jan 2021 16:45:00 GMT, Jim Laskey wrote: >> This PR is to introduce a new random number API for the JDK. The primary API >> is found in RandomGenerator and RandomGeneratorFactory. Further description >> can be found in the JEP https://openjdk.java.net/jeps/356 . >> >> javadoc can

Re: RFR: 8257733: Move module-specific data from make to respective module

2020/12/4 6:08:13 -0800, er...@openjdk.java.net: > On Fri, 4 Dec 2020 12:30:02 GMT, Alan Bateman wrote: >>> And I can certainly move jdwp.spec to java.base instead. That's the >>> reason I need input on this: All I know is that is definitely not >>> the responsibility of the Build Group to

Integrated: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default

On Thu, 19 Nov 2020 16:49:30 GMT, Mark Reinhold wrote: > Please review this implementation of JEP 396 > (https://openjdk.java.net/jeps/396). > Alan Bateman is the original author; I’ve credited him in the commit metadata. > Passes tiers 1-3 on {linux,macos,windows}-x64 and l

Re: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v6]

On Fri, 20 Nov 2020 13:08:11 GMT, Alan Bateman wrote: >> Looks good. > > testWithAddExportsInManifest create an executable JAR with "Add-Exports: > java.base/sun.security.x509" in the manifest. It runs it twice, once without > any options, the second with --illegal-access=permit, and checks

Re: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v6]

> Please review this implementation of JEP 396 > (https://openjdk.java.net/jeps/396). > Alan Bateman is the original author; I’ve credited him in the commit metadata. > Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64. Mark Reinhold has updated the pull request i

Re: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v5]

> Please review this implementation of JEP 396 > (https://openjdk.java.net/jeps/396). > Alan Bateman is the original author; I’ve credited him in the commit metadata. > Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64. Mark Reinhold has updated the pull request i

Re: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v4]

> Please review this implementation of JEP 396 > (https://openjdk.java.net/jeps/396). > Alan Bateman is the original author; I’ve credited him in the commit metadata. > Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64. Mark Reinhold has updated the pull request i

Re: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v3]

> Please review this implementation of JEP 396 > (https://openjdk.java.net/jeps/396). > Alan Bateman is the original author; I’ve credited him in the commit metadata. > Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64. Mark Reinhold has updated the pull request i

Re: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v3]

On Thu, 19 Nov 2020 19:51:59 GMT, Mandy Chung wrote: >> Mark Reinhold has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Add "Add-Exports" case for the >> setAccessibleNonPublicMemberNonExported

Re: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v2]

> Please review this implementation of JEP 396 > (https://openjdk.java.net/jeps/396). > Alan Bateman is the original author; I’ve credited him in the commit metadata. > Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64. Mark Reinhold has updated the pull request i

Re: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default [v2]

On Thu, 19 Nov 2020 17:03:54 GMT, Alan Bateman wrote: >> Mark Reinhold has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Remove unnecessary @module :open from ASN1FormatterTest.java > > test

RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default

Please review this implementation of JEP 396 (https://openjdk.java.net/jeps/396). Alan Bateman is the original author; I’ve credited him in the commit metadata. Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64. - Commit messages: - 8256299: Implement JEP 396:

Re: RFR: 8255989: Remove explicitly unascribed authorship from Java source files

On Fri, 6 Nov 2020 20:11:24 GMT, Pavel Rappo wrote: > This PR proposes to remove > 1. JavaDoc `@author` tags with unclear semantics: `@author > unascribed|unattributed|unknown` > 2. A couple of astray Form Feed (a.k.a. FF, `\f`, `0xC`, or `^L`) characters Marked as reviewed by mr (Lead).

Re: RFR: JDK-8255262: Remove use of legacy custom @spec tag

On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote: > The change is (just) to remove legacy usages of a JDK-private custom tag. As the creator of these tags many moons ago, I approve this change. - Marked as reviewed by mr (Lead). PR:

New candidate JEP: 392: Packaging Tool

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

Re: RFR 8251989: Hex encoder and decoder utility

2020/8/20 13:59:39 -0700, roger.ri...@oracle.com: > On 8/20/20 3:10 PM, mark.reinh...@oracle.com wrote: >> ... >> >> A few comments: >> >> - Why do the short-form `encoder` factory methods return encoders that >> produce upper-case hex strings? `Integer::toHexString` and other >>

Re: RFR 8251989: Hex encoder and decoder utility

2020/8/19 14:14:56 -0700, roger.ri...@oracle.com: > Please review a java.util.Hex API to encode and decode hexadecimal > strings to and from byte arrays. > > JavaDoc: > http://cr.openjdk.java.net/~rriggs/hex-javadoc/java.base/java/util/Hex.html This mostly looks good -- it’ll be nice to have a

Re: Review Request: JDK-8235521: Replacement API for Unsafe::ensureClassInitialized

2020/6/3 19:31:13 -0700, mandy.ch...@oracle.com: > On 6/3/20 5:16 PM, Paul Sandoz wrote: >> Did you consider an alternative name, such as: >> >> /** >> * Initializes {@code targetClass}, if not already initialized. >> * ... >> */ >> public Class initializeClass(Class targetClass) ... >> >> ? >

New candidate JEP: 385: Deprecate RMI Activation for Removal

https://openjdk.java.net/jeps/385 - 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 >

New candidate JEP: 370: Foreign-Memory Access API

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

Re: RFR: 8234335: Remove line break in class declaration in java.base

2019/11/19 11:17:22 -0800, john.r.r...@oracle.com: > On Nov 19, 2019, at 4:00 AM, Lance Andersen wrote: >> Seems to be a “your milage varies”. I am fine with whatever the >> final decision is. However, I do believe the comment above reads >> better and aligns the methods better. > > FWIW, and

Further comments on jpackage (JEP 343)

Today I took the jpackage tool for another spin, using build 14-jpackage+1-64 from https://jdk.java.net/jpackage. This looks much better! The simple command line $ jpackage -p lib -m org.openjdk.hello -n hello did exactly what I expected, and the resulting package installed (and uninstalled)

Re: RFR: JDK-8232806: The LambdaMetaFactory eagerly initializes generated lambdas

2019/10/28 11:10:25 -0700, vojin.jovano...@oracle.com: > This email proposes a change to the LambdaMetaFactory that allows to > disable eager initialization (with Unsafe) of generated lambdas. ... > > ... > > After the discussion with Brian Goetz, we have trimmed down to the > following change: >

Re: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

2019/10/23 12:37:56 -0700, bob.vande...@oracle.com: >> On Oct 23, 2019, at 3:07 PM, mark.reinh...@oracle.com wrote: >> ... >> >> Addendum: To keep things sane for JFR and the serviceability agent, >> I had to propagate this change through to those subsystems. >> >> Relative patch below; original

Re: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

2019/10/22 15:36:28 -0700, mark.reinh...@oracle.com: > 2019/10/22 12:43:42 -0700, bob.vande...@oracle.com: >>> On Oct 22, 2019, at 3:22 PM, mark.reinh...@oracle.com wrote: >>> 2019/10/22 10:31:55 -0700, bob.vande...@oracle.com: In arguments.cpp, could you use a new JVMFlag to declare options

Re: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

2019/10/22 14:12:18 -0700, mandy.ch...@oracle.com: > On 10/21/19 8:22 PM, mark.reinh...@oracle.com wrote: >> RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8232753 >> Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/ > > Looks good to me.

Re: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

2019/10/22 12:43:42 -0700, bob.vande...@oracle.com: >> On Oct 22, 2019, at 3:22 PM, mark.reinh...@oracle.com wrote: >> 2019/10/22 10:31:55 -0700, bob.vande...@oracle.com: >>> In arguments.cpp, could you use a new JVMFlag to declare options >>> that came from this resource as RESOURCE? >>> >>> -

Re: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

2019/10/22 7:15:10 -0700, alan.bate...@oracle.com: > On 22/10/2019 04:22, mark.reinh...@oracle.com wrote: >> RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8232753 >> Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/ > > I've read through

Re: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

2019/10/22 10:31:55 -0700, bob.vande...@oracle.com: > In arguments.cpp, could you use a new JVMFlag to declare options that came > from this resource as RESOURCE? > > - jint result = parse_each_vm_init_arg(vm_options_args, _mod_javabase, > JVMFlag::INTERNAL); > + jint result =

14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 CSR: https://bugs.openjdk.java.net/browse/JDK-8232753 Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/ This change implements jlink plugins, and associated changes in the VM and libraries, to support the following new jlink options: -

Re: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null.

2019/10/2 5:45:10 -0700, goetz.lindenma...@sap.com: > thanks for looking at my change! Can I add you as reviewer? Sure. >> This is very nice work! I especially appreciate the thorough tests. > > Thanks! But adapting the many tests to changed messages is > quite cumbersome :) Thanks for

Re: RFR (L, final): 8218626: Add detailed message to NullPointerException describing what is null.

2019/9/24 1:13:14 -0700, goetz.lindenma...@sap.com: > http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/19/ This is very nice work! I especially appreciate the thorough tests. Looking at the tests, and the details of the JEP, I noticed that the generated messages all end in a period

Re: Formatting rules for exception messages

2019/9/27 6:23:54 -0700, Florian Weimer : > * mark reinhold: > >> 2019/3/25 5:24:37 -0700, Florian Weimer : >>> Are there any guidelines for formatting exception messages? >>> >>> In particular, I'm interested in the case when the exception message >&

Re: CharsetEncoder.maxBytesPerChar()

2019/9/24 13:00:21 -0700, ulf.zi...@cosoco.de: > Am 21.09.19 um 00:03 schrieb mark.reinh...@oracle.com: >> To avoid this confusion, a more verbose specification might read: >> * Returns the maximum number of $otype$s that will be produced for each >> * $itype$ of input. This value may be

Re: Thread.suspend/resume - any reason not to deprecate forRemoval=true

2019/9/24 8:04:55 -0700, alan.bate...@oracle.com: > Thread.suspend/resume (and the corresponding methods in ThreadGroup) > have been deprecated since 1.2 (1998). I haven't see anything use these > methods in many years. Would anyone care if their deprecation is changed > to forRemoval=true with

Re: CharsetEncoder.maxBytesPerChar()

2019/9/20 13:25:38 -0700, naoto.s...@oracle.com: > I am looking at the following bug: > > https://bugs.openjdk.java.net/browse/JDK-8230531 > > and hoping someone who is familiar with the encoder will clear things > out. As in the bug report, the method description reads: > > -- > Returns the

Re: Comments on jpackage (JEP 343)

jlink’s -o/--output option names exactly the thing being output, rather than a container for the thing being output. The jpackage option we’re discussing here names a container for the thing being output, much like the -d option of javac and javadoc. Using -d/--dest for jpackage is consistent

Comments on jpackage (JEP 343)

I spent some time last week playing with the jpackage tool, using build 14-jpackage+1-35 from https://jdk.java.net/jpackage. Overall, I can see that you’ve made good progress, but there’s still some work to be done. I’ll start with high-level comments and questions, and then comment on my

New candidate JEP: 358: Helpful NullPointerExceptions

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

Re: New candidate JEP: 356: Enhanced Pseudo-Random Number Generators

2019/6/21 13:22:17 -0700, guy.ste...@oracle.com: > On Jun 21, 2019, at 2:36 PM, mark.reinh...@oracle.com wrote: >> By my count this JEP would add ten new public types to the java.util >> package. Is it time to consider creating a java.util.random subpackage? > > Sure, that would be a completely

Re: New candidate JEP: 356: Enhanced Pseudo-Random Number Generators

By my count this JEP would add ten new public types to the java.util package. Is it time to consider creating a java.util.random subpackage? - Mark

New candidate JEP: 356: Enhanced Pseudo-Random Number Generators

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

Re: JEP 343: Packaging Tool

2019/6/5 16:09:11 -0700, Alan Snyder : > I haven’t used recent versions of this tool, but I have found it > essential to be able to modify the image before the final package is > created. There is no way that this tool can anticipate all of the > custom configuration that might be needed, and I do

Re: 13 RFR (XXS) 8197927: Allow the system property `java.vendor.version` to be undefined

Lance, Mandy, Christoph -- thanks for the reviews! - Mark

13 RFR (XXS) 8197927: Allow the system property `java.vendor.version` to be undefined

Bug: https://bugs.openjdk.java.net/browse/JDK-8197927 CSR: https://bugs.openjdk.java.net/browse/JDK-8225381 Revise the specification of the `java.lang.System::getProperties` method to allow the values of specific system properties to be undefined, and to allow the system property

JEP 343: Packaging Tool

I saw that you moved JEP 343 to “Proposed to Target,” so I spent a couple of hours looking at it. You’ve made good progress but I don’t think this is in the “nearly finished” state that we ask of features in the six-month cadence. I suggest that you move this JEP back to Candidate for now and

New candidate JEP: 353: Reimplement the Legacy Socket API

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

New candidate JEP: 352: Non-Volatile Mapped Byte Buffers

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

Re: Formatting rules for exception messages

2019/3/25 5:24:37 -0700, Florian Weimer : > Are there any guidelines for formatting exception messages? > > In particular, I'm interested in the case when the exception message > is a (clipped) sentence. Is it supposed to start with a capital > letter? > > If the message refers to a parameter

Re: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null.

2019/3/14 8:00:20 -0700, maurizio.cimadam...@oracle.com: > I second what Mandy says. > > First let me start by saying that this enhancement will be a great > addition to our platform; back in the days when I was teaching some Java > classes at the university, I was very aware of how hard it is

Re: 12 RFR (S): 8216532: tools/launcher/Test7029048.java fails (Solaris)

2019/1/16 16:21:17 -0800, joe.da...@oracle.com: > Rather than naming the enum for the test cases as "CASE", more > conventional naming would be "TestCase" or "Case" for the type itself. Good point. The ALL_CAPS treatment was a holdover from the original. Changed to TestCase. - Mark

Re: 12 RFR (S): 8216532: tools/launcher/Test7029048.java fails (Solaris)

2019/1/16 11:45:05 -0800, roger.ri...@oracle.com: > Looks fine. Thanks! > Bump the Copyright to 2019. Will do. - Mark

12 RFR (S): 8216532: tools/launcher/Test7029048.java fails (Solaris)

Bug: https://bugs.openjdk.java.net/browse/JDK-8216532 Webrev: https://cr.openjdk.java.net/~mr/rev/8216532/ The fix for 8210669 [1] enabled some tests to run that had not been running, and perhaps had never run. Amongst these tests was tools/launcher/Test7029048.java, which is meant to ensure

12 RFR (XS) 8215301: Module-summary page is unreadably wide

Bug: https://bugs.openjdk.java.net/browse/JDK-8215301 Webrev: https://cr.openjdk.java.net/~mr/rev/8215301/ The `make generate-summary` target produces a handy tabular summary of all of the modules in a JDK build into `$BUILD/images/gengraphs/module-summary.html`. Several JDK modules (e.g.,

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

2018/12/11 16:38:32 -0800, stuart.ma...@oracle.com: > Adam, > > Starting from your patch, I've removed changes relating to "crap" and "damn" > and > the changes to upstream jszip.js. This leaves the patches appended below. The > SoftChannel.java change is most likely a typo that should be

Re: RFR: JDK-8215217: OpenJDK Source Has Too Many Swear Words

2018/12/11 7:03:57 -0800, adam.far...@uk.ibm.com: > I've spotted 12 instances of swear words in OpenJDK source comments, and > it seems appropriate to remove them. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215217 (webrev: http://cr.openjdk.java.net/~afarley/8215217/webrev/) > I've

Re: RFC: JEP JDK-8208089: Implement C++14 Language Features

2018/10/3 12:13:15 -0700, kim.barr...@oracle.com: > ... > > https://bugs.openjdk.java.net/browse/JDK-8208089 Or, more readably: https://openjdk.java.net/jeps/8208089 - Mark

Re: 8207690: Parsing API for classpath and similar path strings

2018/9/13 10:21:26 -0700, roger.ri...@oracle.com: > Consider: > > public class SearchPath { > public static SearchPath of(String searchPath) {...} > public static SearchPath of(List elements) {...} > public Stream stream() {...} > public List asList() {...} > public String toString() {...} >

New candidate JEP: 343: Packaging Tool

http://openjdk.java.net/jeps/343 - Mark

Re: RFR 8210670 (S): Accept double-dash VM-name options at launch time

2018/9/12 14:16:00 -0700, mark.reinh...@oracle.com: > ... > > 8210670: Accept double-dash VM-name options at launch time > > Per JEP 293 (Guidelines for JDK Command-Line Tool Options) [2], enhance > the Java launcher so that `--server` is accepted to select the server VM, > in addition to

RFR 8210670 (S): Accept double-dash VM-name options at launch time

To make this trivial enhancement I first had to fix some broken tests, so there are two issues and two webrevs here. 8210669: Some launcher tests assume a pre-JDK 9 run-time image layout Two launcher tests, ExecutionEnvironment.java and Test7029048.java (in test/jdk/tools/launcher), still

Re: 8207690: Parsing API for classpath and similar path strings

2018/9/11 4:50:49 -0700, chris.hega...@oracle.com: >> On 11 Sep 2018, at 10:24, Alan Bateman wrote: >> On 10/09/2018 21:55, Roger Riggs wrote: >>> Nope! there's quoting on Windows that gets short changed with that work >>> around. >>> >>> Other opinions?, Suggestions? >> >> One suggestion is

Re: 8207690: Parsing API for classpath and similar path strings

2018/9/11 8:05:23 -0700, roger.ri...@oracle.com: > Right, that is a description of the shell environment on Windows and how > the java launcher behaves. > On Windows the launcher expands wildcards when evaluating classpath from > the environment > and the command line args. After they are

Re: Long chains created by direct Buffer::slice

2018/7/20 10:55:52 -0700, Florian Weimer : > ... > > The constructor invoked: > > | // For duplicates and slices > | // > | Direct$Type$Buffer$RW$$BO$(DirectBuffer db, // package-private > |int mark, int pos, int lim, int cap, > |

Re: RFR: Small cleanups in java.lang.ref

2018/5/18 3:11:25 -0700, per.li...@oracle.com: > On 05/17/2018 10:03 PM, mark.reinh...@oracle.com wrote: >> 2018/5/16 18:31:15 -0700, marti...@google.com: >>> I've been confused by NULL vs null for years. >> >> That’s because `NULL` in ReferenceQueue.java refers to the singleton >> object

Re: RFR: Small cleanups in java.lang.ref

2018/5/16 18:31:15 -0700, marti...@google.com: > I've been confused by NULL vs null for years. That’s because `NULL` in ReferenceQueue.java refers to the singleton object `ReferenceQueue.NULL`, not the null value. See the long comment at the top of Reference.java for an explanation. To improve

Re: uploading of new code

2018/4/18 10:27:36 -0700, e...@zusammenkunft.net: > Hello, I would put it on a standalone Git repo on one of the public > hosting sites lile.Github, especially for a first discussion > (especially good if added JMH comparisions). I would not expect a id > quickly/easily and a in-tree webrev could

Re: Clean-room implementation of Double::toString(double) and Float::toString(float)

2018/4/12 1:12:36 -0700, raffaello.giulie...@gmail.com: > my code is now ready to be uploaded to the OpenJDK reps. Currently it > resides on GitHub and is under the "GPLv2 + Classpath Exception" > license, with myself as the copyright holder. > > I asked Oracle about how the copyright notice

  1   2   3   >