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 u

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 >> System.getProperties,

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 >> System.getProperties,

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 >> System.getProperties,

[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: https://webrevs.openjdk.java.net/?

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

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 remov

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 thi

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 a

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 Encapsulate

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 m

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 incremen

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. src/java.logging/s

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 be

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 maintai

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 linux-aa

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 the

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 increm

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 increm

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 increm

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 increm

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 increm

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

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: https://git.openjdk.java.net/jdk/pull/81

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

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 s

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

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 a

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? >>> >>> - ji

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, &patch_mod_javabase, > JVMFlag::INTERNAL); > + jint result = parse_each_v

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 supply

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 (e.g.

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 u

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 ma

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 wit

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 experie

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 r

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 `java.vendor.vers

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 con

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 na

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 t

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 that

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., `java.d

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 fixed

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 crea

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 ass

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

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 expande

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 `Referen

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 t

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 b

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 sho

  1   2   3   >