RFR: 8316038: Fix doc typos in java.io.Console and java.util.Scanner

Please review this trivial PR. - Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/15667/files Webrev: https://webrevs.openjdk.org/?repo=jdk=15667=00 Issue: https://bugs.openjdk.org/browse/JDK-8316038 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7

Re: RFR: 8316187: Modernize an example in StringTokenizer

On Fri, 15 Sep 2023 16:20:15 GMT, Naoto Sato wrote: > No need to create another PR for such changes IMO. > Although it may be a bit odd to re-use the same variable names for different > types, I might keep the original `myDate`/`myNumber` that aligns with other > locations in the class

Re: RFR: 8316187: Modernize an example in StringTokenizer [v2]

ult` variable: I reckon it's good for a reader unfamiliar with > `String.split` to see the type it returns. > > Perhaps one additional thing to ponder is this: we could either add `@see` to > point to `String.split` or make the whole example a `@snippet`, which > `@link`s code to th

Integrated: 8316207: Fix typos in java.io.StreamTokenizer

On Wed, 13 Sep 2023 15:43:45 GMT, Pavel Rappo wrote: > This is a simple PR to fix a few typos in the doc comments of > java.io.StreamTokenizer. When reviewing it, please double-check my proposal > for L481. For this, you should ideally read the complete comment to the > `lowerCase

Integrated: 8316187: Modernize examples in StringTokenizer and {Date,Number}Format

On Wed, 13 Sep 2023 12:39:00 GMT, Pavel Rappo wrote: > This modernizes an example to use the extended for-statement introduced in > JDK 1.5. > > I understand that StringTokenizer is a legacy class. But legacy or not, a > class shouldn't promote older constructs when n

Integrated: 8316038: Fix doc typos in java.io.Console and java.util.Scanner

On Mon, 11 Sep 2023 17:58:20 GMT, Pavel Rappo wrote: > Please review this trivial PR. This pull request has now been integrated. Changeset: f55e7994 Author: Pavel Rappo URL: https://git.openjdk.org/jdk/commit/f55e799491c39dcaf7b3935b6d560ee0a3239191 Stats: 7 lines in 2 fi

RFR: 8316187: Modernize an example in StringTokenizer

This modernizes an example to use the extended for-statement introduced in JDK 1.5. I understand that StringTokenizer is a legacy class. But legacy or not, a class shouldn't promote older constructs when newer fit better. Especially when advising on preferred alternatives to itself. That

RFR: 8316207: Fix typos in java.io.StreamTokenizer

This is a simple PR to fix a few typos in the doc comments of java.io.StreamTokenizer. When reviewing it, please double-check my proposal for L481. For this, you should ideally read the complete comment to the `lowerCaseMode` method. Thanks! - Commit messages: - Initial commit

Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v7]

On Thu, 17 Aug 2023 09:23:30 GMT, Pavel Rappo wrote: >>> These benchmarks are all small arrays. We need to check for possible >>> regressions here. >> >> Sorry, all large arrays. I suspect that the average-length sort is not >> represented. >> &g

Re: RFR: 8316187: Modernize an example in StringTokenizer

On Wed, 13 Sep 2023 22:55:00 GMT, Naoto Sato wrote: >> This modernizes an example to use the extended for-statement introduced in >> JDK 1.5. >> >> I understand that StringTokenizer is a legacy class. But legacy or not, a >> class shouldn't promote older constructs when newer fit better.

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

rs. That latter PR will be published soon. Pavel Rappo 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 15 additional commits since the last revision: - Me

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

PKCS10.java#L356-L362 > > This PR adds such a method and provides tests for it. Additionally, this PR > adds tests for `null` passed to `java.util.Arrays.hashCode` overloads, > behaviour which was specified but untested. Pavel Rappo has updated the pull request with a new target base due

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

rs. That latter PR will be published soon. Pavel Rappo 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 14 additional commits since the last revision: - Me

Re: RFR: 8317678: Fix up hashCode() for ZipFile.Source.Key

On Tue, 10 Oct 2023 08:32:28 GMT, Sean Coffey wrote: > Fix up java.util.zip.ZipFile$Source hashCode() impl so that duplicate Source > objects aren't created for the same zip file. src/java.base/share/classes/java/util/zip/ZipFile.java line 1444: > 1442: } else { > 1443:

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

On Tue, 19 Sep 2023 09:49:53 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

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 i

@Incubating

Does anybody remember why {@Incubating}, a JDK-specific tag introduced in JDK-8173354, starts with an uppercase letter? Put differently, are there any reasons why we should not make it conform to implicit convention of camelCase, like all other standard and JDK tags do?

Re: Enrich the Lock interface

This is suggested every once in a while. I appreciate that openjdk mailing lists are not easily searchable, but with a bit of skill, you could find a few previous discussions on the topic. This has also been discussed on concurrency-interest (at cs.oswego.edu ), a

Re: Enrich the Lock interface

-Pavel > On 21 Aug 2023, at 14:24, John Hendrikx wrote: > > I couldn't find a discussion on openjdk, but for those interested (and to > save others some searching) there is a JBS ticket: > > https://bugs.openjdk.org/browse/JDK-8025597 > > --John > > On

Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v7]

On Thu, 17 Aug 2023 08:48:29 GMT, Andrew Haley wrote: > How does keep alive work? Will the data from that external web site still be > here for the reader in 15 years' time? Hm... I thought that at least full webrevs are stored somewhere on https://cr.openjdk.org/. Turns out they aren't. They

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 i

Integrated: 8314753: Remove support for @beaninfo, @ToDo, @since.unbundled, and @Note

On Tue, 22 Aug 2023 11:09:39 GMT, Pavel Rappo wrote: > Please review this trivial PR. This pull request has now been integrated. Changeset: a4e97aa4 Author: Pavel Rappo URL: https://git.openjdk.org/jdk/commit/a4e97aa4ebe6fcfc3ed9e45ed81df1d55e52d621 Stats: 4 lines in 1 f

RFR: 8314738: Remove all occurrences of and support for @revised

Please review this simple PR. - Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/15382/files Webrev: https://webrevs.openjdk.org/?repo=jdk=15382=00 Issue: https://bugs.openjdk.org/browse/JDK-8314738 Stats: 124 lines in 28 files changed: 0 ins; 116

Re: RFR: 8314753: Remove support for @beaninfo, @ToDo, @since.unbundled, and @Note

On Tue, 22 Aug 2023 11:09:39 GMT, Pavel Rappo wrote: > Please review this trivial PR. CC'ing core-libs-dev whose members might also have some recollection on tags in question. - PR Comment: https://git.openjdk.org/jdk/pull/15385#issuecomment-1687995105

Re: RFR: 8314753: Remove support for @beaninfo, @ToDo, @since.unbundled, and @Note

On Tue, 22 Aug 2023 11:09:39 GMT, Pavel Rappo wrote: > Please review this trivial PR. CC'ing client-libs-dev because @beaninfo and @Note and jmx-dev because of @since.unbundled, which might've been used for JMX before 2007. - PR Comment: https://git.openjdk.org/jdk/pull/15

Re: @Incubating

I've published a PR to change the name of that tag: https://github.com/openjdk/jdk/pull/15387 > On 21 Aug 2023, at 10:57, Pavel Rappo wrote: > > Does anybody remember why {@Incubating}, a JDK-specific tag introduced in > JDK-8173354, starts with an uppercase letter? Put

Re: RFR: 8314738: Remove all occurrences of and support for @revised

On Tue, 22 Aug 2023 12:23:18 GMT, Mark Reinhold wrote: > I wouldn’t update the copyright year as you have in some of these files. I was taught to do it every time when I change a file. Would you like me to revert those changes to copyright years in this case? - PR Comment:

Integrated: 8314738: Remove all occurrences of and support for @revised

On Tue, 22 Aug 2023 08:42:32 GMT, Pavel Rappo wrote: > Please review this simple PR. This pull request has now been integrated. Changeset: f39fc0aa Author: Pavel Rappo URL: https://git.openjdk.org/jdk/commit/f39fc0aa2de19332fa51af605ece0660891d8c7a Stats: 124 lines in 28 fi

Re: RFR: 8314753: Remove support for @beaninfo, @ToDo, @since.unbundled, and @Note [v2]

> Please review this trivial PR. Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into 8314753 - Initial commit - Changes: https://git.openjdk.org/jdk/pull/15385/fi

Re: RFR: 8314753: Remove support for @beaninfo, @ToDo, @since.unbundled, and @Note [v2]

On Tue, 22 Aug 2023 14:55:18 GMT, Pavel Rappo wrote: >> Please review this trivial PR. > > Pavel Rappo has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' into 831475

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

On Tue, 7 Nov 2023 07:58:40 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

Re: [jdk19] RFR: 8289779: Map::replaceAll javadoc has redundant @throws clauses

On Wed, 6 Jul 2022 00:32:00 GMT, Stuart Marks wrote: > Simple javadoc fix of an editorial nature. Thanks for doing this, Stuart. Not only does this PR remove duplication from the `Map` documentation, but it also ensures that when JDK-6509045 is integrated, that duplication won't spread to

Re: [jdk19] RFR: 8289779: Map::replaceAll javadoc has redundant @throws clauses [v2]

On Wed, 6 Jul 2022 23:03:42 GMT, Stuart Marks wrote: >> Simple javadoc fix of an editorial nature. > > Stuart Marks has updated the pull request incrementally with one additional > commit since the last revision: > > Reflow and adjust whitespace per Alan's & Iris' comments. Marked as

Re: RFR: 8294377: Prepare to stop auto-inheriting documentation for subclasses of exceptions whose documentation is inherited [v2]

On Wed, 28 Sep 2022 13:36:18 GMT, Daniel Fuchs wrote: > If you can assert that the generated docs are the same before and after the > proposed change then that's enough for me. Would it suffice if I show the result of the diff between JDK API Documentation built at the tip of this PR branch

Re: RFR: 8294377: Prepare to stop auto-inheriting documentation for subclasses of exceptions whose documentation is inherited [v2]

On Wed, 28 Sep 2022 13:34:08 GMT, Daniel Fuchs wrote: >> Pavel Rappo has updated the pull request incrementally with one additional >> commit since the last revision: >> >> revert an extraneous change to jdk.javadoc > > src/java.naming/share/

Re: RFR: 8294377: Prepare to stop auto-inheriting documentation for subclasses of exceptions whose documentation is inherited [v2]

ages. There's > one relatively significant change. This change is in jdk.jshell, where some > methods disappeared from "Methods declared in ..." section and other > irregularities. We are aware of this and have filed JDK-8291803 to fix the > root cause. > [^2]: In reality, th

RFR: 8294377: Prepare to stop auto-inheriting documentation for subclasses of exceptions whose documentation is inherited

This adds exception documentation to JDK methods that would otherwise lose that documentation once JDK-8287796 is integrated. While adding this exception documentation now does not change [^1] the JDK API Documentation, it will automatically counterbalance the effect that JDK-8287796 will have.

Re: RFR: 8294377: Prepare to stop auto-inheriting documentation for subclasses of exceptions whose documentation is inherited [v2]

On Fri, 30 Sep 2022 19:15:17 GMT, Phil Race wrote: > If the docs end up the same as you say that is fine by me since for the two > ImageIO classes that seems to be what we'd want. Since this change does not affect HTML pages for java.desktop, I take it as "approved". > But inheritDoc

Integrated: 8294377: Prepare to stop auto-inheriting documentation for subclasses of exceptions whose documentation is inherited

On Tue, 27 Sep 2022 11:43:08 GMT, Pavel Rappo wrote: > This adds exception documentation to JDK methods that would otherwise lose > that documentation once JDK-8287796 is integrated. While adding this > exception documentation now does not change [^1] the JDK API Docu

Integrated: 8295168: Remove superfluous period in @throws tag description

On Tue, 11 Oct 2022 17:11:49 GMT, Pavel Rappo wrote: > Please review this utmost trivial fix for an issue discovered while working > on something else in jdk.javadoc. As far as I can see, this is the only case > of `{@inheritDoc}` not being the sole content of a `@throws` description

RFR: 8295168: Remove superfluous period in @throws tag description

Please review this utmost trivial fix for an issue discovered while working on something else in jdk.javadoc. As far as I can see, this is the only case of `{@inheritDoc}` not being the sole content of a `@throws` description in JDK. - Commit messages: - Initial commit Changes:

Re: RFR: 8299852: Modernize ConcurrentHashMap

On Tue, 10 Jan 2023 10:32:34 GMT, Per Minborg wrote: > `java.util.concurrent.ConcurrentHashMap` is relatively old and has not been > updated to reflect the current state of Java and can be modernized: > > * Add `@Serial` annotations > * Seal classes and restrict subclassing for internal

Re: RFR: 8299444 java.util.Set.copyOf allocates needlessly for empty input collections

On Wed, 4 Jan 2023 14:41:20 GMT, Viktor Klang wrote: > Currently Set.copyOf allocates both a HashSet and a new empty array when the > input collection is empty. > > This patch avoids allocating anything for the case where the parameter > collection's isEmpty returns true. Curious: how bad

Re: RFR: JDK-8297298 - SequenceInputStream should override transferTo

On Sun, 20 Nov 2022 07:30:15 GMT, Alan Bateman wrote: > > I might be mistaken, but that vector is not temporary: the vector and the > > enumeration produced from it seems to be reachable for as long as the > > stream is. Both the enumeration and the vector are synchronized. That > >

Re: RFR: JDK-8296743: Tighten Class.getModifiers spec for array classes [v3]

On Fri, 18 Nov 2022 18:12:56 GMT, Joe Darcy wrote: >> Update the spec of Class.getModifiers to match long-standing behavior for >> primitive and array classes. Remove unneeded implementation flexibility with >> regard to setting other bit positions. This work was prompted to better >> support

Re: RFR: JDK-8297298 - SequenceInputStream should override transferTo

On Sat, 19 Nov 2022 16:36:28 GMT, Markus KARG wrote: > Since JDK 18 some implementations of InputStream.transferTo, namely > FileInputStream and ChannelInputStream, offload work to lower layers using > NIO channels. This provides shorter execution time and reduced resource > consumption.

Re: [jdk20] RFR: 8300719: JDK 20 RDP2 L10n resource files update [v5]

On Wed, 25 Jan 2023 18:00:33 GMT, Weijun Wang wrote: >> The translation tool didn't seem to translate this. Either because it >> couldn't or because it somehow missed it. I'm not sure which, but I'm open >> to replacing this with a translation suggestion you have. Or I can leave it >> as is.

Re: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments [v2]

to occur in infrequently updated third-party code (e.g. > javax.xml), which I assume we shouldn't touch unless necessary. > * I will update copyright years after (and if) the fix had been approved, as > required. Pavel Rappo has updated the pull request with a new target base due to a

Re: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future completes exceptionally [v2]

On Thu, 16 Mar 2023 20:51:37 GMT, Viktor Klang wrote: >> Addresses the situation where exceptional completion of `orTimeout`:ed >> CompletableFutures wouldn't cancel the timeout task which could lead to >> memory leaks if done frequently enough with long enough timeout durations. >> >> Fix

Re: RFR: JDK-8303742: CompletableFuture.orTimeout leaks if the future completes exceptionally [v3]

On Thu, 16 Mar 2023 21:21:51 GMT, Viktor Klang wrote: >> Addresses the situation where exceptional completion of `orTimeout`:ed >> CompletableFutures wouldn't cancel the timeout task which could lead to >> memory leaks if done frequently enough with long enough timeout durations. >> >> Fix

Re: RFR: JDK-8304557: java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java times out [v2]

On Thu, 23 Mar 2023 12:04:34 GMT, Alan Bateman wrote: >> If there isn't any value running this test with a debug build then you could >> have it skip (`@requires vm.debug == false`) to save resources. >> (fixed typo in original message) > >> @AlanBateman @pavelrappo Does the new approach seem

Integrated: 8303480: Miscellaneous fixes to mostly invisible doc comments

On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo wrote: > Please review this superficial documentation cleanup that was triggered by > unrelated analysis of doc comments in JDK API. > > The only effect that this multi-area PR has on the JDK API Documentation > (i.e. the ob

Re: JDK 20 EA builds (archive?)

Hi Chris, Would you not be able to bisect by tags? Checkout, build, and run your test(s) possibly (semi-) automatically using git bisect? What's the OS? -Pavel > On 24 Mar 2023, at 16:55, Chris Hegarty wrote: > > Hi, > > While definitely not the right list, someone here will surely know ...

Re: RFR: JDK-8304557: java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java times out

On Wed, 22 Mar 2023 11:21:14 GMT, Viktor Klang wrote: >> Hello Viktor, >> >>> @jaikiran Having a long timeout doesn't seem like a problem given that it >>> just needs enough time to run through the iterations (i.e. that's the max >>> duration of the test before giving up). >> >> Having a

Re: RFR: 8302818: Optimize wrapper sets and immutable sets of Enums [v5]

On Tue, 21 Mar 2023 15:23:53 GMT, Claes Redestad wrote: > An alternative design which would avoid adding more classes could be to add > package-private accessors to the existing `Unmodifiable/Synchronized` wrapper > classes so that `EnumSet/-Map` can retrieve the underlying set of an >

Re: RFR: JDK-8304557: java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java times out

On Wed, 22 Mar 2023 16:06:51 GMT, Viktor Klang wrote: > The other alternative I see would be to reach into the implementation of > CompletableFuture's `Delayer`'s `ScheduledThreadPoolExecutor delayer` and > make sure that it's `getQueue()` eventually goes empty. >From what I've seen, JDK

Re: RFR: 8302815 Use new Math.clamp method in core libraries [v3]

On Tue, 21 Feb 2023 20:39:53 GMT, Tagir F. Valeev wrote: >> For cleanup and dogfooding the new method, it would be nice to use >> Math.clamp where possible in java.base. See PR #12428. >> >> As Math.clamp performs an additional check that min is not greater than max, >> I conservatively

Re: RFR: 8302815 Use new Math.clamp method in core libraries [v3]

On Tue, 21 Feb 2023 20:39:53 GMT, Tagir F. Valeev wrote: >> For cleanup and dogfooding the new method, it would be nice to use >> Math.clamp where possible in java.base. See PR #12428. >> >> As Math.clamp performs an additional check that min is not greater than max, >> I conservatively

Re: RFR: JDK-8297605 DelayQueue javadoc is confusing [v2]

On Thu, 2 Mar 2023 11:17:10 GMT, Viktor Klang wrote: > Perhaps @pavelrappo has any suggestion for adding clarifying Javadoc to a > subclass without having to override the method? 樂 You cannot do that. - PR: https://git.openjdk.org/jdk/pull/12729

RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments

Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API. The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows: diff

Integrated: 8303473: Add implied {@code} in java.lang.invoke.MethodHandles

On Wed, 1 Mar 2023 18:47:14 GMT, Pavel Rappo wrote: > Please review this trivial fix for _comments_. While some affected comments > aren't doc comments and none of the affected comments partake in the API > Documentation, it seems reasonable to be consistent. This pull request has

Re: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments

On Fri, 3 Mar 2023 08:15:49 GMT, Alexey Ivanov wrote: >> Please review this superficial documentation cleanup that was triggered by >> unrelated analysis of doc comments in JDK API. >> >> The only effect that this multi-area PR has on the JDK API Documentation >> (i.e. the observable effect

Re: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments

On Thu, 2 Mar 2023 16:23:17 GMT, Alexey Ivanov wrote: >> Please review this superficial documentation cleanup that was triggered by >> unrelated analysis of doc comments in JDK API. >> >> The only effect that this multi-area PR has on the JDK API Documentation >> (i.e. the observable effect

RFR: 8303350: Fix mistyped {@code}

Please review this trivial fix. - Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/12784/files Webrev: https://webrevs.openjdk.org/?repo=jdk=12784=00 Issue: https://bugs.openjdk.org/browse/JDK-8303350 Stats: 6 lines in 3 files changed: 0 ins; 0 del;

Integrated: 8303350: Fix mistyped {@code}

On Tue, 28 Feb 2023 13:31:06 GMT, Pavel Rappo wrote: > Please review this trivial fix. This pull request has now been integrated. Changeset: dc5ea6ae Author: Pavel Rappo URL: https://git.openjdk.org/jdk/commit/dc5ea6aeb500d531b4ba49c8e95bf97744cc6c33 Stats: 6 lines in 3 fi

Re: RFR: 8303473: Add implied {@code} in java.lang.invoke.MethodHandles

On Wed, 1 Mar 2023 18:47:14 GMT, Pavel Rappo wrote: > Please review this trivial fix for _comments_. While some affected comments > aren't doc comments and none of the affected comments partake in the API > Documentation, it seems reasonable to be consistent. Inadvertently found one

Re: RFR: 8303473: Add implied {@code} in java.lang.invoke.MethodHandles [v2]

> Please review this trivial fix for _comments_. While some affected comments > aren't doc comments and none of the affected comments partake in the API > Documentation, it seems reasonable to be consistent. Pavel Rappo has updated the pull request incrementally with one additiona

RFR: 8303473: Add implied {@code} in java.lang.invoke.MethodHandles

Please review this trivial fix for _comments_. While some affected comments aren't doc comments and none of the affected comments partake in the API Documentation, it seems reasonable to be consistent. - Commit messages: - Initial commit Changes:

RFR: 8302981: Fix a typo in the doc comment for java.lang.Record.equals

Please review this trivial fix. - Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/12689/files Webrev: https://webrevs.openjdk.org/?repo=jdk=12689=00 Issue: https://bugs.openjdk.org/browse/JDK-8302981 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2

Integrated: 8302981: Fix a typo in the doc comment for java.lang.Record.equals

On Tue, 21 Feb 2023 12:09:51 GMT, Pavel Rappo wrote: > Please review this trivial fix. This pull request has now been integrated. Changeset: 8b20aa91 Author: Pavel Rappo URL: https://git.openjdk.org/jdk/commit/8b20aa919b810fc5b3856b392bd0d8b1f882c895 Stats: 2 lines in 1 f

Re: RFR: 8306075: Micro-optimize Enum.hashCode [v3]

On Mon, 17 Apr 2023 13:27:43 GMT, olivergillespie wrote: >> Improve the speed of Enum.hashCode by caching the identity hashcode on first >> use. I've seen an application where Enum.hashCode is a hot path, and this is >> fairly simple speedup. The memory overhead is low; in enums with no extra

Re: RFR: 8306075: Micro-optimize Enum.hashCode [v4]

On Mon, 17 Apr 2023 14:56:13 GMT, Roger Riggs wrote: > The @implNote is more appropriate for an internal comment. It is not needed > to be in the published javadoc; its only useful to someone viewing the source > code. Is it a comment to me or to the author? If it's the former, then I note,

Re: RFR: 8306075: Micro-optimize Enum.hashCode

On Mon, 17 Apr 2023 10:59:34 GMT, olivergillespie wrote: > Improve the speed of Enum.hashCode by caching the identity hashcode on first > use. I've seen an application where Enum.hashCode is a hot path, and this is > fairly simple speedup. The memory overhead is low; in enums with no extra >

Re: RFR: 8306075: Micro-optimize Enum.hashCode [v3]

On Mon, 17 Apr 2023 13:08:41 GMT, Aleksey Shipilev wrote: >> Yes, it is implementation-specific, that is why it says "Hotspot's identity >> hash code". The relevant code blocks are >>

Re: RFR: 8306075: Micro-optimize Enum.hashCode [v4]

On Mon, 17 Apr 2023 14:15:39 GMT, olivergillespie wrote: >> Improve the speed of Enum.hashCode by caching the identity hashcode on first >> use. I've seen an application where Enum.hashCode is a hot path, and this is >> fairly simple speedup. The memory overhead is low; in enums with no extra

Re: RFR: 8306075: Micro-optimize Enum.hashCode [v5]

On Mon, 17 Apr 2023 15:55:38 GMT, Aleksey Shipilev wrote: >> olivergillespie has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Switch to non-javadoc comment and remove markup > > src/java.base/share/classes/java/lang/Enum.java line 171: >

Re: RFR: 8306075: Micro-optimize Enum.hashCode [v3]

On Mon, 17 Apr 2023 13:49:11 GMT, Aleksey Shipilev wrote: >> From that impl note it seemed like it was a big deal for hash code to never >> return 0 for an object. Could you maybe de-emphasize the importance of that >> HotSpot behavior in the note? > > All right, we can change "This allows to

Re: RFR: 8306075: Micro-optimize Enum.hashCode [v6]

On Mon, 17 Apr 2023 16:44:24 GMT, Aleksey Shipilev wrote: > I am okay with this new version, thanks. (You need other commenters to > approve as well.) While there's already one more reviewer who approved this PR (@cl4es) and technically it can be already integrated, I'd leave it for a day or

Re: RFR: 8266571: Sequenced Collections [v7]

On Thu, 20 Apr 2023 04:13:57 GMT, Stuart Marks wrote: > I didn't know about the need to specify `@throws` in order to generate the > throws-clauses in the docs. You need to explicitly inherit `@throws` only for exceptions that aren't mentioned in the `throws` clause. > As an aside, I note

Re: RFR: 8266571: Sequenced Collections [v7]

On Wed, 19 Apr 2023 04:36:28 GMT, Chen Liang wrote: > Javadoc will automatically copy the specification from the overridden method, > so the javadoc block is not necessary and can be replaced by an `@Override` > to indicate inheritance. I guess, this PR has converged enough for us to discuss

Re: RFR: 8266571: Sequenced Collections [v7]

On Thu, 20 Apr 2023 16:19:05 GMT, Stuart Marks wrote: >>> I didn't know about the need to specify `@throws` in order to generate the >>> throws-clauses in the docs. >> >> You need to explicitly inherit `@throws` only for exceptions that aren't >> mentioned in the `throws` clause. >> >>> As

Re: RFR: 8306075: Micro-optimize Enum.hashCode [v6]

On Wed, 19 Apr 2023 13:50:49 GMT, Aleksey Shipilev wrote: > @AlanBateman, @apangin, @ExE-Boss, @liach, @pavelrappo -- you had comments on > this PR, could you please see if those are still relevant or not addressed? > If you are good with the current version, can you please formally approve

Re: RFR: 8304919: Implementation of Virtual Threads [v2]

On Tue, 28 Mar 2023 23:47:02 GMT, Leonid Mesnik wrote: >> Alan Bateman 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: 8305157: The java.util.Arrays class should be declared final

On Wed, 29 Mar 2023 09:03:58 GMT, Alan Bateman wrote: > > I thought the change would trigger a change in the public API as the > > modifiers are changed for the class. This would likely be picked up by > > compatibility checks and so, a CSR would be needed? > > It's not a compatibility issue

Re: RFR: 8285368: Overhaul doc-comment inheritance [v2]

On Wed, 7 Jun 2023 20:29:07 GMT, Jonathan Gibbons wrote: >> Pavel Rappo has updated the pull request incrementally with one additional >> commit since the last revision: >> >> feedback: make warning less scary > > test/langtools/jdk/javadoc/

Re: RFR: 8285368: Overhaul doc-comment inheritance [v2]

On Wed, 7 Jun 2023 19:13:55 GMT, Jonathan Gibbons wrote: >> Pavel Rappo has updated the pull request incrementally with one additional >> commit since the last revision: >> >> feedback: make warning less scary > > src/jdk.javadoc/share/classes/jdk/javadoc

Re: RFR: 8285368: Overhaul doc-comment inheritance [v2]

On Wed, 7 Jun 2023 19:16:51 GMT, Jonathan Gibbons wrote: >> Pavel Rappo has updated the pull request incrementally with one additional >> commit since the last revision: >> >> feedback: make warning less scary > > src/jdk.javadoc/share/classes/jdk/javadoc

Re: RFR: 8285368: Overhaul doc-comment inheritance [v9]

​{@inheritDoc S} > > Which is exactly what I did to counterbalance some of the JDK API > Documentation changes caused by the change to "methods comment algorithm". Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev exc

Re: RFR: 8285368: Overhaul doc-comment inheritance [v8]

On Thu, 8 Jun 2023 14:47:13 GMT, Pavel Rappo wrote: >> Please review this long-awaited change to documentation inheritance. >> >> This change improves "methods comment algorithm" and introduces directed >> documentation inheritance. While "methods com

Re: RFR: 8285368: Overhaul doc-comment inheritance [v10]

​{@inheritDoc S} > > Which is exactly what I did to counterbalance some of the JDK API > Documentation changes caused by the change to "methods comment algorithm". Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev exc

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

On Wed, 5 Jul 2023 15:33:13 GMT, Roger Riggs wrote: > I'd suggest replacing the calls to `valuesMatch` with `Objects.equals` and > remove the `valuesMatch` method as unnecessary. I'll do something about them soon, Roger. But first I need to understand JDK-8015417 better, as it also affects

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

On Thu, 6 Jul 2023 14:46:59 GMT, Pavel Rappo wrote: >> I'd suggest replacing the calls to `valuesMatch` with `Objects.equals` and >> remove the `valuesMatch` method as unnecessary. > >> I'd suggest replacing the calls to `valuesMatch` with `Objects.equals` and >&

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

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 trivial as rearranging, adding, or commenting checks. *

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

On Tue, 20 Jun 2023 18:23:09 GMT, Roger Riggs 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

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 contains five additional >>

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

On Thu, 6 Jul 2023 23:38:01 GMT, Stuart Marks wrote: > For me the issue here is that there is a bunch of lore about avoiding > `Objects::equals` and it's embodied in comments like this: > > > NB: Do not replace with Object.equals until JDK-8015417 is resolved. > > These comments are almost

Integrated: 8311122: Fix typos in java.base

On Thu, 29 Jun 2023 21:17:49 GMT, Pavel Rappo wrote: > Please review this IDE-assisted typo hunt, which I plan to backport to jdk21. This pull request has now been integrated. Changeset: 7b3c2dc5 Author: Pavel Rappo URL: https://git.openjdk.org/jdk/com

Re: RFR: 8311122: Fix typos in java.base

On Thu, 29 Jun 2023 21:17:49 GMT, Pavel Rappo wrote: > Please review this IDE-assisted typo hunt, which I plan to backport to jdk21. Alright, I think all the areas that this PR touches have been reviewed by area experts. - PR Comment: https://git.openjdk.org/jdk/pull/14

[jdk21] RFR: 8311122: Fix typos in java.base

Hi all, This pull request contains a backport of commit [7b3c2dc5](https://github.com/openjdk/jdk/commit/7b3c2dc5f45afc3646ff5cdc0f6efd68e0b70ea5) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Pavel Rappo on 4 Jul 2023

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

On Wed, 5 Jul 2023 12:57:19 GMT, Pavel Rappo wrote: > Unfortunately, we don't have mid-layer methods in between Arrays.hashCode and > ArraysSupport.vectorizedHashCode like that of Arrays.mismatch and > ArraysSupport.vectorizedMismatch. It's either all the null check but > sh

  1   2   3   4   >