Re: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may be shared [v9]

On Wed, 19 Jul 2023 14:04:59 GMT, Jim Laskey wrote: >> java.lang.runtime.ReferencedKeyMap was introduced to provide a concurrent >> caching scheme for Carrier objects. The technique used is generally useful >> for a variety of caching schemes and is being moved to be shared in other >> parts

Re: RFR: 8312164: Refactor Arrays.hashCode for long, boolean, and Object arrays [v3]

On Wed, 19 Jul 2023 13:14:23 GMT, Pavel Rappo wrote: >> Please review this PR to refactor Arrays.hashCode for long[], boolean[], and >> Object[]. I've been told elsewhere that it shouldn't have significant >> performance implications. > > Pavel Rappo has updated the pull request incrementally

Re: RFR: 8311188: Simplify and modernize equals and hashCode in java.text [v5]

On Mon, 17 Jul 2023 23:33:37 GMT, Pavel Rappo wrote: >> Please review this PR to use modern APIs and language features to simplify >> `equals` and `hashCode` in the java.text area. >> >> * Some changes to `equals` and `hashCode` are refactoring rather than >> modernization. Such changes can

Re: RFR: JDK-8310814: Clarify the targetName parameter of Lookup::findClass [v2]

On Mon, 26 Jun 2023 23:13:19 GMT, Mandy Chung wrote: >> This PR updates the spec of `Lookup::findClass` to reflect the current >> behavior that requires a binary name or a string representing an array class >> in the form as returned by `Class::getName`. >> >>

Re: RFR: 8310929: Optimization for Integer.toString [v12]

On Mon, 3 Jul 2023 03:49:01 GMT, 温绍锦 wrote: >> Optimization for: >> Integer.toString >> Long.toString >> StringBuilder#append(int) >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make test

Re: Integrated: JDK-8312195: Changes in JDK-8284493 use wrong copyright syntax

On Mon, 17 Jul 2023 19:40:42 GMT, Joe Darcy wrote: > Update to conform to accepted syntax. Marked as reviewed by rriggs (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/14908#pullrequestreview-1533548769

Re: RFR: 8312164: Refactor Arrays.hashCode for long, boolean, and Object arrays

On Mon, 17 Jul 2023 09:36:35 GMT, Pavel Rappo wrote: > Please review this PR to refactor Arrays.hashCode for long[], boolean[], and > Object[]. I've been told elsewhere that it shouldn't have significant > performance implications. Marked as reviewed by rriggs (Reviewer). - PR

Re: RFR: 8310201: Reduce verbose locale output in -XshowSettings launcher option [v2]

On Fri, 14 Jul 2023 11:21:02 GMT, Sean Coffey wrote: >> Simple tweak to remove the "available locales" section from default >> `-XshowSettings` output. >> >> Instead, it remains available with the `-XshowSettings:locale` option > > Sean Coffey has updated the pull request incrementally with

Re: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may be shared [v8]

On Thu, 13 Jul 2023 15:07:35 GMT, Jim Laskey wrote: >> java.lang.runtime.ReferencedKeyMap was introduced to provide a concurrent >> caching scheme for Carrier objects. The technique used is generally useful >> for a variety of caching schemes and is being moved to be shared in other >> parts

Re: RFR: JDK-6361826: (reflect) provide method for mapping strings to class object for primitive types [v3]

On Fri, 14 Jul 2023 02:54:59 GMT, Joe Darcy wrote: >> Going over some old issues and found this RFE, posting without any tests or >> a CSR first to get some feedback on the overall API. > > Joe Darcy has updated the pull request with a new target base due to a merge > or a rebase. The

Re: RFR: 8311864: Add ArraysSupport.hashCode(int[] a, fromIndex, length, initialValue)

On Tue, 11 Jul 2023 16:35:51 GMT, Pavel Rappo wrote: > This PR adds an internal method to calculate hash code from the provided > integer array, offset and length into that array, and the initial hash code > value. > > Current options for calculating a hash code for int[] are inflexible. It's

Re: RFR: 8312019: Simplify and modernize java.util.BitSet.equals

On Thu, 13 Jul 2023 10:50:30 GMT, Pavel Rappo wrote: > Please review this PR to use modern APIs and language features to simplify > equals for BitSet. > > I couldn't see how to refactor hashCode using Arrays utility methods in a way > that preserves its specification. So, aside from

Re: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v21]

On Thu, 13 Jul 2023 11:46:39 GMT, Jaikiran Pai wrote: >> Can I please get a review for this change which proposes to fix the issue >> reported in https://bugs.openjdk.org/browse/JDK-8206890? >> >> The `jlink` command allows a `--endian` option to specify the byte order in >> the generated

Re: [jdk21] RFR: 8306785: fix deficient spliterators for Sequenced Collections

On Thu, 13 Jul 2023 05:45:37 GMT, Stuart Marks wrote: > Hi all, > > This pull request contains a backport of commit > [743e8b8e](https://github.com/openjdk/jdk/commit/743e8b8e0a9fe032a0dd652a4fef1f761af66595) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit

Re: RFR: 8304006: jlink should create the jimage file in the native endian for the target platform [v19]

On Wed, 12 Jul 2023 10:58:49 GMT, Jaikiran Pai wrote: >> Can I please get a review for this change which proposes to fix the issue >> reported in https://bugs.openjdk.org/browse/JDK-8206890? >> >> The `jlink` command allows a `--endian` option to specify the byte order in >> the generated

Re: RFR: 8155902: DataOuputStream should clarify that it might write primitive types as multiple byte groups [v4]

On Tue, 11 Jul 2023 17:36:18 GMT, Brian Burkhalter wrote: >> Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes >> no guarantee as to how the underlying output stream actually writes the >> bytes provided to it. > > Brian Burkhalter has updated the pull request

Re: RFR: 8310033: Clarify return value of Java Time compareTo methods [v7]

th "less than zero" and "greater > than zero" in javadoc @return > The term "positive" is ambiguous, zero is considered positive and indicates > equality. Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The increme

Re: RFR: 8311645: Memory leak in jspawnhelper spawnChild after JDK-8307990

On Sat, 8 Jul 2023 02:05:27 GMT, Jenny Shivayogi wrote: > Free-ing 'buf' before two conditional return statements introduced by > JDK-8307990 Marked as reviewed by rriggs (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/14809#pullrequestreview-1524357337

Re: RFR: 8310033: Clarify return value of Java Time compareTo methods [v6]

th "less than zero" and "greater > than zero" in javadoc @return > The term "positive" is ambiguous, zero is considered positive and indicates > equality. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision

Re: RFR: 8155902: DataOutputStream writeInt creates 2 packets instead of 1 [v2]

On Fri, 7 Jul 2023 17:41:02 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/io/DataOutputStream.java line 44: >> >>> 42: * the underlying output stream, hence there is no guarantee as to >>> 43: * the details of how the bytes are written. >>> 44: * >> >> I'd drop "merely".

Re: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may be shared [v7]

On Fri, 7 Jul 2023 16:31:26 GMT, Jim Laskey wrote: >> java.lang.runtime.ReferencedKeyMap was introduced to provide a concurrent >> caching scheme for Carrier objects. The technique used is generally useful >> for a variety of caching schemes and is being moved to be shared in other >> parts

Re: RFR: 8311207: Cleanup for Optimization for UUID.toString [v6]

On Sat, 1 Jul 2023 14:42:07 GMT, 温绍锦 wrote: >> [PR 14578 ](https://github.com/openjdk/jdk/pull/14578) still has unresolved >> discussions, continue to make improvements. >> >> # Benchmark Result >> >> >> sh make/devkit/createJMHBundle.sh >> bash configure --with-jmh=build/jmh/jars >> make

Re: RFR: 8310033: Clarify return value of Java Time compareTo methods [v5]

th "less than zero" and "greater > than zero" in javadoc @return > The term "positive" is ambiguous, zero is considered positive and indicates > equality. Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The increme

Re: RFR: 8155902: DataOutputStream writeInt creates 2 packets instead of 1

On Thu, 6 Jul 2023 21:40:38 GMT, Brian Burkhalter wrote: > Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes no > guarantee as to how the underlying output stream actually writes the bytes > provided to it. src/java.base/share/classes/java/io/DataOutputStream.java

Re: [jdk21] RFR: 8310265: (process) jspawnhelper should not use argv[0]

On Thu, 6 Jul 2023 19:42:08 GMT, Thomas Stuefe wrote: > Hi all, > > Clean backport for JDK-83210265. > > Thanks! Marked as reviewed by rriggs (Reviewer). - PR Review: https://git.openjdk.org/jdk21/pull/103#pullrequestreview-1518889288

Re: RFR: 8310033: Clarify return value of Java Time compareTo methods [v2]

On Sun, 18 Jun 2023 20:26:04 GMT, Stephen Colebourne wrote: >> Roger Riggs has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contai

Re: RFR: 8066869: Add Closeable::closeUnchecked that is the equivalent of close but throws UncheckedIOException

On Thu, 6 Jul 2023 20:07:56 GMT, Brian Burkhalter wrote: > Add a default method `java.io.Closeable::closeUnchecked` which is equivalent > to `Closeable::close` except that it instead throws > `java.io.UncheckedIOException`. src/java.base/share/classes/java/io/Closeable.java line 60: > 58:

Re: RFR: 8281658: Add a security category to the java -XshowSettings option [v8]

On Tue, 27 Jun 2023 15:06:45 GMT, Sean Coffey wrote: >> New functionality in the -XshowSettings menu to display relevant information >> about JDK security configuration > > Sean Coffey has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev

Re: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may be shared [v3]

On Thu, 6 Jul 2023 13:27:15 GMT, Roger Riggs wrote: >> `WeakReferenceKey::equals` and `SoftReferenceKey::equals`: >> >> Instead of `return Objects.equals(get(), obj);`, suggest to do: >> >> >> return refersTo(obj); > >> @mlchung Not sur

Re: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may be shared [v3]

On Wed, 5 Jul 2023 19:33:28 GMT, Mandy Chung wrote: >> Jim Laskey has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update to use VirtualThread friendly stale queue. > > `WeakReferenceKey::equals` and `SoftReferenceKey::equals`: > >

Re: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may be shared [v3]

On Tue, 4 Jul 2023 12:55:22 GMT, Jim Laskey wrote: >> java.lang.runtime.ReferencedKeyMap was introduced to provide a concurrent >> caching scheme for Carrier objects. The technique used is generally useful >> for a variety of caching schemes and is being moved to be shared in other >> parts

Integrated: 8310999: Add @since info in jdk.jsobject files

On Wed, 5 Jul 2023 14:51:31 GMT, Roger Riggs wrote: > Source code cleanup. > Add @since, remove unused imports and remove unnecessary SuppressWarnings of > deprecation. This pull request has now been integrated. Changeset: 6eba096c Author: Roger Riggs URL: https://git.op

Re: RFR: 8311188: Simplify and modernize equals and hashCode in java.text [v3]

On Wed, 5 Jul 2023 16:39:58 GMT, Pavel Rappo wrote: >> src/java.base/share/classes/java/text/CompactNumberFormat.java line 2364: >> >>> 2362: return true; >>> 2363: } >>> 2364: >> >> Moving this before the `super.equals` call performance-wise would favor the >> equals

Re: RFR: 8311188: Simplify and modernize equals and hashCode in java.text [v3]

On Wed, 5 Jul 2023 16:27:38 GMT, Pavel Rappo wrote: >> src/java.base/share/classes/java/text/DecimalFormat.java line 2930: >> >>> 2928: DecimalFormat other = (DecimalFormat) obj; >>> 2929: return ((posPrefixPattern == other.posPrefixPattern && >>> 2930:

Re: RFR: 8310999: Add @since info in jdk.jsobject files [v2]

> Source code cleanup. > Add @since, remove unused imports and remove unnecessary SuppressWarnings of > deprecation. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Remove unneeded @SuppressWarnings - Changes

Re: RFR: 8310999: Add @since info in jdk.jsobject files [v2]

On Wed, 5 Jul 2023 16:05:25 GMT, Phil Race wrote: > unless my eyes deceive me the suppresswarnings is still present. Gack!, I removed it and then put it back to try to discover why it was there in the first place. Gone again and thanks - PR Comment:

Re: RFR: 8311188: Simplify and modernize equals and hashCode in java.text

On Mon, 3 Jul 2023 11:12:32 GMT, Pavel Rappo wrote: > Please review this PR to use modern APIs and language features to simplify > `equals` and `hashCode` in the java.text area. > > * Some changes to `equals` and `hashCode` are refactoring rather than > modernization. Such changes can be as

Re: RFR: 8311188: Simplify and modernize equals and hashCode in java.text

On Tue, 4 Jul 2023 22:03:58 GMT, John R Rose wrote: >>> Hmm, I think that issue refers to code that have explicit non-Object >>> parameter types (like `X::equals(Object)boolean` in the issue's sample). >>> This method already have both arguments as `Object`, so I don't think >>> there's any

Re: Adapt ArrayList Javadoc for sequenced collections

Hi Daniel, Core-libs-dev is indeed the correct alias for this documentation issue. Create an issue to track: JDK-8311517 Regards, Roger On 7/1/23 3:35 PM, Daniel Schmid wrote: The JEP for sequenced collection (https://openjdk.org/jeps/431)

RFR: 8310999: Add @since info in jdk.jsobject files

Source code cleanup. Add @since, remove unused imports and remove unnecessary SuppressWarnings of deprecation. - Commit messages: - 8310999: Add @since info in jdk.jsobject files Changes: https://git.openjdk.org/jdk/pull/14775/files Webrev:

Re: RFR: 8311290: Improve java.lang.ref.Cleaner rendered documentation

On Tue, 4 Jul 2023 12:40:26 GMT, Pavel Rappo wrote: > 1. Missing leading asterisk interferes with example indentation; nothing in > https://bugs.openjdk.org/browse/JDK-8276700 (or review thereof), which > introduced that line, suggests that the asterisk was omitted on purpose. > 2. link and

Integrated: 8310241: OffsetDateTime compareTo redundant computation

On Thu, 22 Jun 2023 19:03:03 GMT, Roger Riggs wrote: > Remove a redundant comparison in java.time `OffsetDateTime.compareTo()`. > If the `compareInstant` utility method returns 0 (equal), it compares the > `LocalDateTime`. > However, `compareInstant` has already done tha

Re: RFR: JDK-8310913 Move ReferencedKeyMap to jdk.internal so it may be shared [v2]

On Thu, 29 Jun 2023 18:24:33 GMT, Jim Laskey wrote: >> java.lang.runtime.ReferencedKeyMap was introduced to provide a concurrent >> caching scheme for Carrier objects. The technique used is generally useful >> for a variety of caching schemes and is being moved to be shared in other >> parts

Re: RFR: 8310813: Simplify and modernize equals, hashCode, and compareTo for BigInteger

On Fri, 23 Jun 2023 17:27:00 GMT, Pavel Rappo wrote: > Please review this PR to use modern APIs and language features to simplify > equals, hashCode, and compareTo for BigInteger. If you have any performance > concerns, please raise them. > > This PR is cherry-picked from a bigger,

Re: RFR: 8311030: ResourceBundle.handleKeySet() is racy

On Wed, 28 Jun 2023 11:05:11 GMT, Sergey Tsypanov wrote: > Double-checked locking should rely on local variable to avoid racy reads from > volatile field. Given all the comments, I don't think this is ready to integrate. - Changes requested by rriggs (Reviewer). PR Review:

Re: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v34]

On Thu, 29 Jun 2023 13:26:18 GMT, 温绍锦 wrote: >> By optimizing the implementation of java.lang.Long#fastUUID, the performance >> of the java.util.UUID#toString method can be significantly improved. >> >> The following are the test results of JMH: >> >> Benchmark Mode Cnt

Re: RFR: 8310033: Clarify return value of Java Time compareTo methods [v4]

th "less than zero" and "greater > than zero" in javadoc @return > The term "positive" is ambiguous, zero is considered positive and indicates > equality. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

Re: RFR: 8310241: OffsetDateTime compareTo redundant computation [v2]

On Wed, 28 Jun 2023 19:35:27 GMT, Naoto Sato wrote: >> Roger Riggs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Reopen to work on an improved fix >> Add a test for the specific condition being optim

Re: RFR: 8311030: ResourceBundle.handleKeySet() is racy

On Wed, 28 Jun 2023 11:05:11 GMT, Sergey Tsypanov wrote: > Double-checked locking should rely on local variable to avoid racy reads from > volatile field. Looks ok; was this a tool detected race? - Marked as reviewed by rriggs (Reviewer). PR Review:

Re: RFR: 8310241: OffsetDateTime compareTo redundant computation

On Thu, 22 Jun 2023 19:03:03 GMT, Roger Riggs wrote: > Remove a redundant comparison in java.time `OffsetDateTime.compareTo()`. > If the `compareInstant` utility method returns 0 (equal), it compares the > `LocalDateTime`. > However, `compareInstant` has already done tha

Re: RFR: 8310232: java.time.Clock$TickClock.millis() fails in runtime when tick is 1 microsecond [v2]

On Wed, 28 Jun 2023 10:12:18 GMT, Aleksey Shipilev wrote: >> Naoto Sato has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains four additional >>

Re: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to String::newStringLatin1NoRepl [v4]

On Tue, 27 Jun 2023 07:45:34 GMT, Glavo wrote: >> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`. >> >> Reasons: >> >> * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, >> creating a new shortcut can make writing shorter; >> * Since all possible values

Integrated: 8310982: jdk/internal/util/ArchTest.java fails after JDK-8308452 failed with Method isARM()

On Tue, 27 Jun 2023 19:55:02 GMT, Roger Riggs wrote: > Fix a test bug when run on aarch64, it was supposed to confirm it was not > running on Arm. This pull request has now been integrated. Changeset: 7f094353 Author: Roger Riggs URL: https://git.openjdk.org/jdk/

RFR: 8310982: jdk/internal/util/ArchTest.java fails after JDK-8308452 failed with Method isARM()

Fix a test bug when run on aarch64, it was supposed to confirm it was not running on Arm. - Commit messages: - Add bugid - 8310982: jdk/internal/util/ArchTest.java fails after JDK-8308452 failed with "Method isARM()..." Changes: https://git.openjdk.org/jdk/pull/14685/files

Re: RFR: JDK-8310830: typo in the parameter name in @throws of ClassDesc::ofDescriptor

On Tue, 27 Jun 2023 19:06:26 GMT, Joe Darcy wrote: > Typo fix. I didn't see any other instances of similar typos in the class. Marked as reviewed by rriggs (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/14683#pullrequestreview-1501695302

Re: RFR: 8310901: Convert String::newStringNoRepl with Latin-1 to String::newStringLatin1NoRepl [v4]

On Tue, 27 Jun 2023 07:45:34 GMT, Glavo wrote: >> Added a new method `newStringLatin1NoRepl` to the `JavaLangAccess`. >> >> Reasons: >> >> * Most use cases of `newStringNoRepl` use `ISO_8859_1` as the charset, >> creating a new shortcut can make writing shorter; >> * Since all possible values

Integrated: 8308452: Extend internal Architecture enum with byte order and address size

On Fri, 19 May 2023 19:19:40 GMT, Roger Riggs wrote: > The internal enum jdk.internal.util.Architecture does not provide information > about the big or little endianness or the address size (64 or 32 bits). The > endian-ness and address size are intrinsic to the architecture. >

Re: RFR: 8310232: java.time.Clock$TickClock.millis() fails in runtime when tick is 1 microsecond [v2]

On Tue, 27 Jun 2023 16:34:40 GMT, Naoto Sato wrote: >> Fixing the `/ by zero` exception with tick durations less than a millisecond. > > Naoto Sato has updated the pull request with a new target base due to a merge > or a rebase. The incremental webrev excludes the unrelated changes brought in

Re: [jdk21] RFR: 8310182: DateTimeFormatter date formats (ISO_LOCAL_DATE) separated with hyphen, not dash

> > The commit being backported was authored by Naoto Sato on 27 Jun 2023 and was > reviewed by Roger Riggs, Joe Darcy, Iris Clark and Lance Andersen. > > Thanks! Marked as reviewed by rriggs (Reviewer). - PR Review: https://git.openjdk.org/jdk21/pull/70#pullrequestreview-1501531725

Re: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v26]

On Tue, 27 Jun 2023 11:27:18 GMT, 温绍锦 wrote: >> By optimizing the implementation of java.lang.Long#fastUUID, the performance >> of the java.util.UUID#toString method can be significantly improved. >> >> The following are the test results of JMH: >> >> Benchmark Mode Cnt

Re: RFR: 8310182: DateTimeFormatter date formats (ISO_LOCAL_DATE) separated with hyphen, not dash [v2]

On Tue, 27 Jun 2023 03:39:30 GMT, Naoto Sato wrote: >> Replacing the ambiguous `dash` with `hyphen-minus` for more clarity. There >> are other locations than `ISO_LOCAL_DATE` that have the same description. >> Those are corrected too. > > Naoto Sato has updated the pull request incrementally

Re: RFR: 8310241: OffsetDateTime compareTo redundant computation

On Mon, 26 Jun 2023 18:28:47 GMT, Naoto Sato wrote: >> Remove a redundant comparison in java.time `OffsetDateTime.compareTo()`. >> If the `compareInstant` utility method returns 0 (equal), it compares the >> `LocalDateTime`. >> However, `compareInstant` has already done that comparison; if it

Withdrawn: 8310241: OffsetDateTime compareTo redundant computation

On Thu, 22 Jun 2023 19:03:03 GMT, Roger Riggs wrote: > Remove a redundant comparison in java.time `OffsetDateTime.compareTo()`. > If the `compareInstant` utility method returns 0 (equal), it compares the > `LocalDateTime`. > However, `compareInstant` has already done tha

Re: RFR: 8310241: OffsetDateTime compareTo redundant computation

On Thu, 22 Jun 2023 19:03:03 GMT, Roger Riggs wrote: > Remove a redundant comparison in java.time `OffsetDateTime.compareTo()`. > If the `compareInstant` utility method returns 0 (equal), it compares the > `LocalDateTime`. > However, `compareInstant` has already done tha

Re: RFR: 8310232: java.time.Clock$TickClock.millis() fails in runtime when tick is 1 microsecond

On Mon, 26 Jun 2023 17:31:29 GMT, Naoto Sato wrote: > Fixing the `/ by zero` exception with tick durations less than a millisecond. Marked as reviewed by rriggs (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/14657#pullrequestreview-1499140711

Re: RFR: 8310890: Normalize identifier names

On Mon, 26 Jun 2023 14:07:03 GMT, Pavel Rappo wrote: > Please review this cleanup PR to normalize names of identifiers which are > Java variables/fields or tokens in text files. Those names either contain a > pronoun that is very rarely used in code, or seem like they contain such a >

Re: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v25]

On Mon, 26 Jun 2023 09:57:31 GMT, 温绍锦 wrote: >> By optimizing the implementation of java.lang.Long#fastUUID, the performance >> of the java.util.UUID#toString method can be significantly improved. >> >> The following are the test results of JMH: >> >> Benchmark Mode Cnt

Re: RFR: 8308452: Extend internal Architecture enum with byte order and address size [v6]

On Thu, 22 Jun 2023 19:24:37 GMT, Roger Riggs wrote: >> The internal enum jdk.internal.util.Architecture does not provide >> information about the big or little endianness or the address size (64 or 32 >> bits). The endian-ness and address size are intrinsic t

Re: RFR: 8308452: Extend internal Architecture enum with byte order and address size [v7]

re will make the enum more useful > especially to identify a target platform in a cross-platform use case. A > method is added to map well known aliases for the platforms to the > Architecture enum. Roger Riggs has updated the pull request incrementally with one additional c

Re: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v24]

On Mon, 26 Jun 2023 09:52:10 GMT, 温绍锦 wrote: >> src/java.base/share/classes/java/util/UUID.java line 515: >> >>> 513: >>> 514: try { >>> 515: return jla.newStringNoRepl(buf, >>> StandardCharsets.ISO_8859_1); >> >> in java.base it's better to use `ISO_8859_1.INSTANCE`

Re: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v22]

On Sun, 25 Jun 2023 17:37:27 GMT, Glavo wrote: > To be honest, I have never seen anyone actually use the > `-XX:-CompactStrings`. Perhaps at some point in the future, we can > investigate its usage and consider deprecate it to reduce the maintenance > cost of JDK? The implementation should

Re: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer [v7]

On Fri, 23 Jun 2023 20:56:14 GMT, Brian Burkhalter wrote: >> Clarify the behavior of `java.lang.Readable` when the specified >> `java.nio.CharBuffer` parameter is empty but read-only, and when it is full. > > Brian Burkhalter has updated the pull request incrementally with one > additional

Re: RFR: 8310530: PipedOutputStream.flush() accesses sink racily [v2]

On Wed, 21 Jun 2023 15:03:12 GMT, Sergey Tsypanov wrote: >> Just a tiny clean-up to remove racy read within synchronized method > > Sergey Tsypanov has updated the pull request incrementally with one > additional commit since the last revision: > > Update

Re: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer [v6]

On Fri, 23 Jun 2023 17:19:10 GMT, Brian Burkhalter wrote: >> Clarify the behavior of `java.lang.Readable` when the specified >> `java.nio.CharBuffer` parameter is empty but read-only, and when it is full. > > Brian Burkhalter has updated the pull request incrementally with one > additional

Re: RFR: 8308694: Clarify reversed() default methods' implementation requirements [v2]

On Thu, 22 Jun 2023 22:07:19 GMT, Stuart Marks wrote: >> Can I get a preliminary review of the wording for Deque.reversed()? If the >> text is good, I'll make corresponding changes to the implSpecs of the other >> reversed() default methods, namely those in List, SortedMap, and SortedSet >>

Re: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer [v2]

On Thu, 22 Jun 2023 21:25:32 GMT, Brian Burkhalter wrote: >> For a buffer that is being written into, it sounds a bit odd to say "no >> remaining elements"; that phrasing is ok for reading/getting bytes but >> doesn't sound like there's free space to put anything. >> >> Would "no remaining

Re: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer [v2]

On Thu, 22 Jun 2023 19:39:16 GMT, Brian Burkhalter wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8222329: rephrase "full" to "no elements remaining" > > src/java.base/share/classes/java/io/Reader.java line

Re: RFR: 8310530: PipedOutputStream.flush() accesses sink racily [v2]

On Wed, 21 Jun 2023 15:03:12 GMT, Sergey Tsypanov wrote: >> Just a tiny clean-up to remove racy read within synchronized method > > Sergey Tsypanov has updated the pull request incrementally with one > additional commit since the last revision: > > Update

Re: RFR: 8310182: DateTimeFormatter date formats (ISO_LOCAL_DATE) separated with hyphen, not dash

On Thu, 22 Jun 2023 20:36:48 GMT, Naoto Sato wrote: > Replacing the ambiguous `dash` with `hyphen-minus` for more clarity. There > are other locations than `ISO_LOCAL_DATE` that have the same description. > Those are corrected too. Correcting the description of the delimiter seems like the

Re: RFR: 8308452: Extend internal Architecture enum with byte order and address size [v6]

re will make the enum more useful > especially to identify a target platform in a cross-platform use case. A > method is added to map well known aliases for the platforms to the > Architecture enum. Roger Riggs has updated the pull request with a new target base due to a merge or a rebase

RFR: 8310241: OffsetDateTime compareTo redundant computation

Remove a redundant comparison in java.time `OffsetDateTime.compareTo()`. If the `compareInstant` utility method returns 0 (equal), it compares the `LocalDateTime`. However, `compareInstant` has already done that comparison; if it found equal, the `compareTo` method unnecessarily does it again.

Re: RFR: 8222329: Readable read(CharBuffer) does not specify that 0 is returned when there is no remaining space in buffer

On Thu, 22 Jun 2023 18:22:35 GMT, Brian Burkhalter wrote: > Clarify the behavior of `java.lang.Readable` when the specified > `java.nio.CharBuffer` parameter is empty but read-only, and when it is full. Looks good. - Marked as reviewed by rriggs (Reviewer). PR Review:

Re: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v8]

On Thu, 22 Jun 2023 07:25:34 GMT, 温绍锦 wrote: >> 温绍锦 has updated the pull request incrementally with one additional commit >> since the last revision: >> >> fix compile error > >> I've tested the benchmarks and the patch and baseline (with extra stable >> annotation) with a slightly varied

Re: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v7]

On Thu, 22 Jun 2023 00:13:06 GMT, 温绍锦 wrote: >> By optimizing the implementation of java.lang.Long#fastUUID, the performance >> of the java.util.UUID#toString method can be significantly improved. >> >> The following are the test results of JMH: >> >> Benchmark Mode Cnt

Re: RFR: JDK-8310502 : Optimization for j.l.Long.fastUUID() [v7]

On Thu, 22 Jun 2023 00:13:06 GMT, 温绍锦 wrote: >> By optimizing the implementation of java.lang.Long#fastUUID, the performance >> of the java.util.UUID#toString method can be significantly improved. >> >> The following are the test results of JMH: >> >> Benchmark Mode Cnt

Re: RFR: 8310033: Clarify return value of Java Time compareTo methods [v3]

th "less than zero" and "greater > than zero" in javadoc @return > The term "positive" is ambiguous, zero is considered positive and indicates > equality. Roger Riggs has updated the pull request incrementally with one additional commit since the last revi

Re: RFR: 8310033: Clarify return value of Java Time compareTo methods [v2]

On Sun, 18 Jun 2023 20:24:07 GMT, Stephen Colebourne wrote: >> Roger Riggs has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contai

Re: RFR: 8310502 : optimization for UUID#toString [v4]

On Wed, 21 Jun 2023 14:31:20 GMT, Chen Liang wrote: >> Not sure if this can be applied but some months ago, I optimized Bits to use >> VarHandles rather than explicitly shifting bits around. This gave us a >> significant performance increase: >> >>

Re: RFR: 8310502 : optimization for UUID#toString [v4]

On Wed, 21 Jun 2023 14:39:18 GMT, 温绍锦 wrote: >> By optimizing the implementation of java.lang.Long#fastUUID, the performance >> of the java.util.UUID#toString method can be significantly improved. >> >> The following are the test results of JMH: >> >> Benchmark Mode Cnt

Re: RFR: 8310033: Clarify return value of Java Time compareTo methods [v2]

On Sun, 18 Jun 2023 19:33:07 GMT, Jens Lidestrom wrote: > Where did you get this idea? A "positive" means a number that is _greater_ > than zero. One of my colleagues with a strong math background has corrected many of my API javadoc comments seeking to avoid any ambiguity. See reference

Re: RFR: JDK-8310453: Update javadoc of java.lang.Object

On Tue, 20 Jun 2023 17:13:26 GMT, Joe Darcy wrote: > I had occasion to read over the javadoc sources in java.lang.Object recently > and noticed a few items that could be updated. > > There are some new or expanded API notes referring to methods in > java.util.Objects. I added these references

[jdk21] Integrated: 8310019: MIPS builds are broken after JDK-8304913

On Tue, 20 Jun 2023 17:02:04 GMT, Roger Riggs wrote: > Hi all, > > This pull request contains a backport of commit [33c6ec9d] from the > [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Roger Ri

[jdk21] RFR: 8310019: MIPS builds are broken after JDK-8304913

Hi all, This pull request contains a backport of commit [33c6ec9d] from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Roger Riggs on 19 Jun 2023 and was reviewed by Paul Hohensee, Aleksey Shipilev and Ao Qi. Thanks

Re: RFR: 8310019: MIPS builds are broken after JDK-8304913 [v3]

On Tue, 20 Jun 2023 16:26:58 GMT, Aleksey Shipilev wrote: >> Roger Riggs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Correct mps64el test case > > Hey @RogerRiggs, could you ask bots to backpo

Re: RFR: JDK-8310265: (process) jspawnhelper should not use argv[0] [v3]

On Tue, 20 Jun 2023 16:48:42 GMT, Thomas Stuefe wrote: >> Reported by [jarabe...@gmail.com](mailto:jarabe...@gmail.com) [1] >> >> jspawnhelper uses argv[0] to receive the fd string from the parent. That >> breaks with conventions and trips over certain tools like binfmt_misc. >> >> For

Re: RFR: JDK-8310265: (process) jspawnhelper should not use argv[0] [v2]

On Tue, 20 Jun 2023 15:08:13 GMT, Thomas Stuefe wrote: >> src/java.base/unix/native/jspawnhelper/jspawnhelper.c line 139: >> >>> 137: ChildStuff c; >>> 138: struct stat buf; >>> 139: /* argv[1] contains the fd number to read all the child info */ >> >> I would prefer to also fix

Re: RFR: JDK-8310265: (process) jspawnhelper should not use argv[0] [v2]

On Mon, 19 Jun 2023 06:07:26 GMT, Thomas Stuefe wrote: >> Reported by [jarabe...@gmail.com](mailto:jarabe...@gmail.com) [1] >> >> jspawnhelper uses argv[0] to receive the fd string from the parent. That >> breaks with conventions and trips over certain tools like binfmt_misc. >> >> For

Integrated: 8310019: MIPS builds are broken after JDK-8304913

On Wed, 14 Jun 2023 15:04:41 GMT, Roger Riggs wrote: > Add mipsel and mips64el to the Architecture enum. > (Later to be backported to JDK 21) This pull request has now been integrated. Changeset: 33c6ec9d Author: Roger Riggs URL: https://git.openjdk.org/jdk/

Re: RFR: 8281658: Add a security category to the java -XshowSettings option [v5]

On Mon, 19 Jun 2023 16:11:12 GMT, Sean Coffey wrote: >> src/java.base/share/classes/sun/launcher/SecuritySettings.java line 66: >> >>> 64: ostream.println("Unrecognized security subcommand. See >>> \"java -X\" for help"); >>> 65: ostream.println("Printing all

Re: RFR: 8310033: Clarify return value of Java Time compareTo methods [v2]

th "less than zero" and "greater > than zero" in javadoc @return > The term "positive" is ambiguous, zero is considered positive and indicates > equality. Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The increme

<    1   2   3   4   5   6   7   8   9   10   >