New candidate JEP: 385: Deprecate RMI Activation for Removal

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

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) ... >> >> ? >

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

New candidate JEP: 392: Packaging Tool

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

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

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

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

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

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

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

Lance, Mandy, Christoph -- thanks for the reviews! - 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

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

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

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

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

New candidate JEP: 358: Helpful NullPointerExceptions

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

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

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

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

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

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

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

New candidate JEP: 370: Foreign-Memory Access API

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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: [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] 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: 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,

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-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 [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 [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 [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 [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: Constants for standard charsets -- CR #4884238

2011/4/12 10:38 -0700, mike.dui...@oracle.com: > On Apr 12 2011, at 03:33 , Alan Bateman wrote: >> ... >> >> 2. @see Charsets.DEFAULT, I assume this should be @see >> Charsets#DEFAULT_CHARSET > > Correct. I changed it to DEFAULT_CHARSET and forgot to fix this link. Why is forcing people to type

Re: Review (Updated) : 4884238 : Constants for Standard Charsets

(just saw your message; more e-mail delays I suppose) 2011/4/19 17:22 -0700, mike.dui...@oracle.com: > My sentiment is for StandardCharset. > > I received offlist feedback which would support this. The pattern for > enum like collections of constants has been to use the singular form; > java.math

Re: Are emails arriving late to core-libs-dev

2011/4/27 9:45 -0700, stuart.ma...@oracle.com: > Yes, yesterday evening I also received around 60 old emails destined for > core-libs-dev, plus bunches of emails for other openjdk lists. So it > apparently > affected all the openjdk lists, not just core-libs-dev. > > Interestingly, a message I se

StandardCharset vs. StandardCharsets

2011/4/29 16:28 -0700, mike.dui...@oracle.com: > Hi Mark; > > I'm still not on your wavelength on this issue. For two reasons: > > - Collections, Arrays, Channels, Objects aren't typically used for > holding constants. They are either factories or collections of static > utility methods. Only Col

JEP 102: Process API updates

Posted: http://openjdk.java.net/jeps/102 - Mark

JEP 103: Parallel Array Sorting

Posted: http://openjdk.java.net/jeps/103 - Mark

JEP 108: Collections Enhancements from Third-Party Libraries

Posted: http://openjdk.java.net/jeps/108 - Mark

JEP 109: Enhance Core Libraries with Lambda

Posted: http://openjdk.java.net/jeps/109 - Mark

Re: JEP 108: Collections Enhancements from Third-Party Libraries

2011/9/29 23:13 -0700, pdoubl...@gmail.com: > Mark, > > in comparison to the other JEPs proposed recently, this seems quite > vague. There is a brief list of candidate collections nestled in the > very middle of the JEP, but that's it. Given that the "alternative > collection libraries" have exist

JEP 111: Additional Unicode Constructs for Regular Expressions

Posted: http://openjdk.java.net/jeps/111 - Mark

JEP 112: Charset Implementation Improvements

Posted: http://openjdk.java.net/jeps/112 - Mark

Re: Benchmarks for NIO buffer performance

2011/11/1 17:07 -0700, david.hol...@oracle.com: > I'm looking into refactoring all the generated buffer classes to reduce the > number of classes created. Part of that requires a performance comparison > between the old and new classes. So I'm looking for any benchmarks that may > exist to measure

Re: CFV: New core-libs Group Member: David Holmes

Vote: yes - Mark

Re: CFV: New core-libs Group Member: Brian Goetz

Vote: yes - Mark

JEP 134: Intuitive Semantics for Nested Reference Objects

Posted: http://openjdk.java.net/jeps/134 - Mark

JEP 135: Base64 Encoding and Decoding

Posted: http://openjdk.java.net/jeps/135 - Mark

JEP 149: Reduce Core-Library Memory Usage

Posted: http://openjdk.java.net/jeps/149 - Mark

JEP 150: JSR 310: Date and Time API

Posted: http://openjdk.java.net/jeps/150 - Mark

JEP 153: Launch JavaFX Applications

Posted: http://openjdk.java.net/jeps/153 - Mark

JEP 154: Remove Serialization

Posted: http://openjdk.java.net/jeps/154 - Mark

JEP 155: Concurrency updates (jsr166e)

Posted: http://openjdk.java.net/jeps/155 - Mark

Re: Time format in jar and jarsigner output (was Re: Code review request: 7163483 JarSigner -verify -verbose does not format date string according to locale)

2012/7/6 3:27 -0700, weijun.w...@oracle.com: > I have these questions: > > ... > > Well, if you really think the current "Fri Jul" output is too English, instead > of localizing the string, how about we de-localize it totally and choose a > neutral format? Excellent idea! > There are several fl

  1   2   3   >