From naoto at openjdk.java.net Mon Jan 3 19:37:03 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 3 Jan 2022 19:37:03 GMT
Subject: RFR: 8278434: timeouts in test
java/time/test/java/time/format/TestZoneTextPrinterParser.java [v2]
In-Reply-To:
References:
Message-ID: <8N71-gx_FGHCfV8aQmNh9HbSb4gAQJRMh9W9UdAFS-Y=.e5a2d32c-dd71-460c-b4fc-d10fb9666c2d@github.com>
> The proposed fix is to address the performance degradation caused by the fix to JDK-8275721. Some amount of the degradation cannot be avoided as the lookup now falls back up to the bundles at Locale.ROOT. However, by lowering the fallback priority of `regionFormatFallback` than `COMPAT`'s lookup, it can avoid the excess bundle lookups for regions.
> I also changed the test case `TestZoneTextPrinterParser.java`, which currently iterates over 3 nested loops, i.e., all-locales x all-timezones x 8, which is absolutely unnecessary. Made it to sample some locales.
> In addition, I added a microbenchmark for the DateFormatSymbols.getZoneStrings() method. Here is the result:
>
> Before the fix to JDK-8275721:
>
> Benchmark Mode Cnt Score Error Units
> ZoneStrings.testZoneStrings ss 5 6.865 ? 0.696 s/op
>
> Before the proposed fix:
>
> Benchmark Mode Cnt Score Error Units
> ZoneStrings.testZoneStrings ss 5 15.741 ? 4.300 s/op
>
> After the proposed fix:
>
> Benchmark Mode Cnt Score Error Units
> ZoneStrings.testZoneStrings ss 5 9.756 ? 3.685 s/op
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 commits since the last revision:
- Merge branch 'master' into JDK-8278434
- Copyright year update
- Added a microbenchmark for zone strings
- 8278434: timeouts in test java/time/test/java/time/format/TestZoneTextPrinterParser.java
-------------
Changes:
- all: https://git.openjdk.java.net/jdk/pull/6790/files
- new: https://git.openjdk.java.net/jdk/pull/6790/files/f14f5450..5f38bd13
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6790&range=01
- incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6790&range=00-01
Stats: 20434 lines in 643 files changed: 14380 ins; 3767 del; 2287 mod
Patch: https://git.openjdk.java.net/jdk/pull/6790.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/6790/head:pull/6790
PR: https://git.openjdk.java.net/jdk/pull/6790
From joehw at openjdk.java.net Mon Jan 3 23:48:19 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 3 Jan 2022 23:48:19 GMT
Subject: RFR: 8278434: timeouts in test
java/time/test/java/time/format/TestZoneTextPrinterParser.java [v2]
In-Reply-To: <8N71-gx_FGHCfV8aQmNh9HbSb4gAQJRMh9W9UdAFS-Y=.e5a2d32c-dd71-460c-b4fc-d10fb9666c2d@github.com>
References:
<8N71-gx_FGHCfV8aQmNh9HbSb4gAQJRMh9W9UdAFS-Y=.e5a2d32c-dd71-460c-b4fc-d10fb9666c2d@github.com>
Message-ID:
On Mon, 3 Jan 2022 19:37:03 GMT, Naoto Sato wrote:
>> The proposed fix is to address the performance degradation caused by the fix to JDK-8275721. Some amount of the degradation cannot be avoided as the lookup now falls back up to the bundles at Locale.ROOT. However, by lowering the fallback priority of `regionFormatFallback` than `COMPAT`'s lookup, it can avoid the excess bundle lookups for regions.
>> I also changed the test case `TestZoneTextPrinterParser.java`, which currently iterates over 3 nested loops, i.e., all-locales x all-timezones x 8, which is absolutely unnecessary. Made it to sample some locales.
>> In addition, I added a microbenchmark for the DateFormatSymbols.getZoneStrings() method. Here is the result:
>>
>> Before the fix to JDK-8275721:
>>
>> Benchmark Mode Cnt Score Error Units
>> ZoneStrings.testZoneStrings ss 5 6.865 ? 0.696 s/op
>>
>> Before the proposed fix:
>>
>> Benchmark Mode Cnt Score Error Units
>> ZoneStrings.testZoneStrings ss 5 15.741 ? 4.300 s/op
>>
>> After the proposed fix:
>>
>> Benchmark Mode Cnt Score Error Units
>> ZoneStrings.testZoneStrings ss 5 9.756 ? 3.685 s/op
>
> 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 commits since the last revision:
>
> - Merge branch 'master' into JDK-8278434
> - Copyright year update
> - Added a microbenchmark for zone strings
> - 8278434: timeouts in test java/time/test/java/time/format/TestZoneTextPrinterParser.java
Marked as reviewed by joehw (Reviewer).
It?s nice to see you?ve got most of the performance back. Hope looping through Zone strings isn't really necessary.
-------------
PR: https://git.openjdk.java.net/jdk/pull/6790
From naoto at openjdk.java.net Tue Jan 4 00:00:15 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 4 Jan 2022 00:00:15 GMT
Subject: RFR: 8278434: timeouts in test
java/time/test/java/time/format/TestZoneTextPrinterParser.java [v2]
In-Reply-To:
References:
<8N71-gx_FGHCfV8aQmNh9HbSb4gAQJRMh9W9UdAFS-Y=.e5a2d32c-dd71-460c-b4fc-d10fb9666c2d@github.com>
Message-ID:
On Mon, 3 Jan 2022 23:45:16 GMT, Joe Wang wrote:
> Hope looping through Zone strings isn't really necessary.
Thanks, Joe. IMHO, `DateFormatSymbols.getZoneStrings()` is badly designed. It just simply exposes the names in the underlying ResourceBundle, and I cannot think of any use cases for this method, rather than using `ZoneId` or `TimeZone`'s display names retrieval methods.
-------------
PR: https://git.openjdk.java.net/jdk/pull/6790
From naoto at openjdk.java.net Tue Jan 4 02:52:22 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 4 Jan 2022 02:52:22 GMT
Subject: Integrated: 8278434: timeouts in test
java/time/test/java/time/format/TestZoneTextPrinterParser.java
In-Reply-To:
References:
Message-ID:
On Fri, 10 Dec 2021 00:27:25 GMT, Naoto Sato wrote:
> The proposed fix is to address the performance degradation caused by the fix to JDK-8275721. Some amount of the degradation cannot be avoided as the lookup now falls back up to the bundles at Locale.ROOT. However, by lowering the fallback priority of `regionFormatFallback` than `COMPAT`'s lookup, it can avoid the excess bundle lookups for regions.
> I also changed the test case `TestZoneTextPrinterParser.java`, which currently iterates over 3 nested loops, i.e., all-locales x all-timezones x 8, which is absolutely unnecessary. Made it to sample some locales.
> In addition, I added a microbenchmark for the DateFormatSymbols.getZoneStrings() method. Here is the result:
>
> Before the fix to JDK-8275721:
>
> Benchmark Mode Cnt Score Error Units
> ZoneStrings.testZoneStrings ss 5 6.865 ? 0.696 s/op
>
> Before the proposed fix:
>
> Benchmark Mode Cnt Score Error Units
> ZoneStrings.testZoneStrings ss 5 15.741 ? 4.300 s/op
>
> After the proposed fix:
>
> Benchmark Mode Cnt Score Error Units
> ZoneStrings.testZoneStrings ss 5 9.756 ? 3.685 s/op
This pull request has now been integrated.
Changeset: 8dc4437d
Author: Naoto Sato
URL: https://git.openjdk.java.net/jdk/commit/8dc4437d002db5d025b47f48e7420e3bae55bdec
Stats: 73 lines in 3 files changed: 59 ins; 7 del; 7 mod
8278434: timeouts in test java/time/test/java/time/format/TestZoneTextPrinterParser.java
Reviewed-by: joehw
-------------
PR: https://git.openjdk.java.net/jdk/pull/6790
From naoto at openjdk.java.net Wed Jan 5 22:51:48 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 5 Jan 2022 22:51:48 GMT
Subject: RFR: 8268081: Support for Unicode 14
Message-ID:
Please review the changes for upgrading the Unicode support in the JDK, from version 13 to version 14. Corresponding CSR has also been drafted.
-------------
Commit messages:
- Amend unicode.md and icu.md files
- Minor fixup
- Merge branch 'master' into unicode
- Copyright year to 2022
- ICU4J 70.1
- 18 -> 19
- Merge branch 'master' into unicode
- Unicode 14.0.0 (final)
- UCD ver. 14.0 (beta) / Unicode Text Segmentation rev. 38 (draft)
- ICU4J 69.1
Changes: https://git.openjdk.java.net/jdk/pull/6974/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6974&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8268081
Stats: 3443 lines in 41 files changed: 2353 ins; 101 del; 989 mod
Patch: https://git.openjdk.java.net/jdk/pull/6974.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/6974/head:pull/6974
PR: https://git.openjdk.java.net/jdk/pull/6974
From joehw at openjdk.java.net Thu Jan 6 01:49:12 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 6 Jan 2022 01:49:12 GMT
Subject: RFR: 8268081: Upgrade Unicode Data Files to 14.0.0
In-Reply-To:
References:
Message-ID:
On Wed, 5 Jan 2022 22:42:38 GMT, Naoto Sato wrote:
> Please review the changes for upgrading the Unicode support in the JDK, from version 13 to version 14. Corresponding CSR has also been drafted.
Marked as reviewed by joehw (Reviewer).
-------------
PR: https://git.openjdk.java.net/jdk/pull/6974
From joehw at openjdk.java.net Thu Jan 6 01:52:12 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 6 Jan 2022 01:52:12 GMT
Subject: RFR: 8268081: Upgrade Unicode Data Files to 14.0.0
In-Reply-To:
References:
Message-ID:
On Wed, 5 Jan 2022 22:42:38 GMT, Naoto Sato wrote:
> Please review the changes for upgrading the Unicode support in the JDK, from version 13 to version 14. Corresponding CSR has also been drafted.
I like how they changed dizzy face to face with crossed-out eyes. Pistol to water pistol, that's even better, just to avoid any confusion ;-)
-------------
PR: https://git.openjdk.java.net/jdk/pull/6974
From iris at openjdk.java.net Thu Jan 6 05:24:14 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 6 Jan 2022 05:24:14 GMT
Subject: RFR: 8268081: Upgrade Unicode Data Files to 14.0.0
In-Reply-To:
References:
Message-ID:
On Wed, 5 Jan 2022 22:42:38 GMT, Naoto Sato wrote:
> Please review the changes for upgrading the Unicode support in the JDK, from version 13 to version 14. Corresponding CSR has also been drafted.
Marked as reviewed by iris (Reviewer).
-------------
PR: https://git.openjdk.java.net/jdk/pull/6974
From lancea at openjdk.java.net Thu Jan 6 17:58:16 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 6 Jan 2022 17:58:16 GMT
Subject: RFR: 8268081: Upgrade Unicode Data Files to 14.0.0
In-Reply-To:
References:
Message-ID:
On Wed, 5 Jan 2022 22:42:38 GMT, Naoto Sato wrote:
> Please review the changes for upgrading the Unicode support in the JDK, from version 13 to version 14. Corresponding CSR has also been drafted.
Marked as reviewed by lancea (Reviewer).
-------------
PR: https://git.openjdk.java.net/jdk/pull/6974
From psadhukhan at openjdk.java.net Mon Jan 10 05:33:01 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 10 Jan 2022 05:33:01 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop
module
Message-ID:
The changes done under JDK-8278175 suppress on a per-file basis various missing comments that would otherwise trigger doclint warnings. Fixed them so as to remove the doclint:missing warnings.
-------------
Commit messages:
- Fix
- 8278254: Cleanup doclint warnings in java.desktop module
Changes: https://git.openjdk.java.net/jdk/pull/7004/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7004&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8278254
Stats: 258 lines in 19 files changed: 192 ins; 19 del; 47 mod
Patch: https://git.openjdk.java.net/jdk/pull/7004.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7004/head:pull/7004
PR: https://git.openjdk.java.net/jdk/pull/7004
From serb at openjdk.java.net Tue Jan 11 05:44:26 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 11 Jan 2022 05:44:26 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in
java.desktop module
In-Reply-To:
References:
Message-ID:
On Mon, 10 Jan 2022 05:25:51 GMT, Prasanta Sadhukhan wrote:
> The changes done under JDK-8278175 suppress on a per-file basis various missing comments that would otherwise trigger doclint warnings. Fixed them so as to remove the doclint:missing warnings.
src/java.desktop/share/classes/java/awt/BufferCapabilities.java line 65:
> 63:
> 64: /**
> 65: * Returns the imaga capabilities of the front buffer
Please add a dot after the first sentence, it is used as a summary doc for the method.
Why the text about "displayed" buffer is removed? is it some special "term" like "intermediate" below?
src/java.desktop/share/classes/java/awt/BufferCapabilities.java line 134:
> 132:
> 133: /**
> 134: * Returns whether or not
I am not sure that preserving such a format style is a good thing.
src/java.desktop/share/classes/java/awt/Component.java line 4697:
> 4695:
> 4696: /**
> 4697: * Checks whether or not paint messages received from the operating system
In the change above the "Returns whether or not" text is used. It is better to use the same new text, or just use the old one.
src/java.desktop/share/classes/java/awt/event/KeyEvent.java line 653:
> 651: /* For European keyboards */
> 652: /**
> 653: * Constant for the DEAD_GRAVE function key.
I do not know, are all the keys here actually "function keys"?
src/java.desktop/share/classes/java/beans/beancontext/BeanContextServicesSupport.java line 150:
> 148: /************************************************************************/
> 149:
> 150: /**
This will add many statements to the specification which could be verified by the TCK. DO we really want to say all of that? Especially about serialization. Same question for other changes below.
src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 1686:
> 1684:
> 1685: /**
> 1686: * Returns HTMLDocument of given JEditorPane
.
Should we wrap the HTMLDocument by the ?
src/java.desktop/share/classes/javax/swing/text/html/parser/Parser.java line 213:
> 211:
> 212: /**
> 213: * Return the line number of the line currently being parsed.
In some other places above the "Returns xxx" was used.
src/java.desktop/share/classes/javax/swing/undo/UndoableEditSupport.java line 150:
> 148:
> 149: /**
> 150: * Start UndoableEdit.
What does it mean? Is it clear enough for the class which "managing UndoableEdit
listeners"?
-------------
PR: https://git.openjdk.java.net/jdk/pull/7004
From kcr at openjdk.java.net Wed Jan 12 19:05:29 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 12 Jan 2022 19:05:29 GMT
Subject: RFR: 8268081: Upgrade Unicode Data Files to 14.0.0
In-Reply-To:
References:
Message-ID:
On Wed, 5 Jan 2022 22:42:38 GMT, Naoto Sato wrote:
> Please review the changes for upgrading the Unicode support in the JDK, from version 13 to version 14. Corresponding CSR has also been drafted.
The CSR is now approved. This comment should be sufficient to wake up the bot.
-------------
PR: https://git.openjdk.java.net/jdk/pull/6974
From naoto at openjdk.java.net Wed Jan 12 19:21:32 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 12 Jan 2022 19:21:32 GMT
Subject: Integrated: 8268081: Upgrade Unicode Data Files to 14.0.0
In-Reply-To:
References:
Message-ID:
On Wed, 5 Jan 2022 22:42:38 GMT, Naoto Sato wrote:
> Please review the changes for upgrading the Unicode support in the JDK, from version 13 to version 14. Corresponding CSR has also been drafted.
This pull request has now been integrated.
Changeset: 0a094d7c
Author: Naoto Sato
URL: https://git.openjdk.java.net/jdk/commit/0a094d7c286ed0b5a35c517391e48c603cb43a68
Stats: 3443 lines in 41 files changed: 2353 ins; 101 del; 989 mod
8268081: Upgrade Unicode Data Files to 14.0.0
Reviewed-by: joehw, iris, lancea
-------------
PR: https://git.openjdk.java.net/jdk/pull/6974
From prappo at openjdk.java.net Thu Jan 13 10:35:39 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 10:35:39 GMT
Subject: RFR: 8279918: Fix various doc typos
Message-ID: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
- Most of the typos are of a trivial kind: missing whitespace.
- If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
- As I understand it, in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
- ' is an apostrophe, which does not require to be encoded.
-------------
Commit messages:
- Initial commit
Changes: https://git.openjdk.java.net/jdk/pull/7063/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7063&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8279918
Stats: 85 lines in 34 files changed: 0 ins; 0 del; 85 mod
Patch: https://git.openjdk.java.net/jdk/pull/7063.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7063/head:pull/7063
PR: https://git.openjdk.java.net/jdk/pull/7063
From kevinw at openjdk.java.net Thu Jan 13 10:49:28 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 13 Jan 2022 10:49:28 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID:
On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo wrote:
> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it, in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - ' is an apostrophe, which does not require to be encoded.
src/java.base/share/classes/sun/text/RuleBasedBreakIterator.java line 73:
> 71: * will be transparent to the BreakIterator. A sequence of characters will break the
> 72: * same way it would if any ignore characters it contains are taken out. Break
> 73: * positions never occur before ignore characters.
"before ignored characters"
-------------
PR: https://git.openjdk.java.net/jdk/pull/7063
From kevinw at openjdk.java.net Thu Jan 13 11:04:28 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 13 Jan 2022 11:04:28 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com>
On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo wrote:
> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it, in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - ' is an apostrophe, which does not require to be encoded.
src/java.sql/share/classes/java/sql/BatchUpdateException.java line 58:
> 56: * A JDBC driver implementation should use
> 57: * the constructor {@code BatchUpdateException(String reason, String SQLState,
> 58: * int vendorCode, long []updateCounts, Throwable cause) } instead of
While we are here, is it more normal to say "long[] updateCounts", not separating the [] from the type.
Similarly at line 81, 118, 151, 247, 277, 318, 354.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7063
From prappo at openjdk.java.net Thu Jan 13 11:04:28 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 11:04:28 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To:
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <4f89A8T4GDZajnNMg-tT5qWaN5OCrH04Vwh9HZ6uTvg=.f2af94ec-43b4-4521-8158-aef4137b400b@github.com>
On Thu, 13 Jan 2022 10:46:11 GMT, Kevin Walls wrote:
>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - ' is an apostrophe, which does not require to be encoded.
>
> src/java.base/share/classes/sun/text/RuleBasedBreakIterator.java line 73:
>
>> 71: * will be transparent to the BreakIterator. A sequence of characters will break the
>> 72: * same way it would if any ignore characters it contains are taken out. Break
>> 73: * positions never occur before ignore characters.
>
> "before ignored characters"
I believe it's the name of a concept, so I will leave it as is:
> There is one special substitution. If the description defines a substitution called "", the expression must be a [] expression, and the expression defines a set of characters (the "ignore characters") that will be transparent to the BreakIterator.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7063
From prappo at openjdk.java.net Thu Jan 13 11:07:28 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 11:07:28 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
<2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com>
Message-ID:
On Thu, 13 Jan 2022 11:00:55 GMT, Kevin Walls wrote:
>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - ' is an apostrophe, which does not require to be encoded.
>
> src/java.sql/share/classes/java/sql/BatchUpdateException.java line 58:
>
>> 56: * A JDBC driver implementation should use
>> 57: * the constructor {@code BatchUpdateException(String reason, String SQLState,
>> 58: * int vendorCode, long []updateCounts, Throwable cause) } instead of
>
> While we are here, is it more normal to say "long[] updateCounts", not separating the [] from the type.
> Similarly at line 81, 118, 151, 247, 277, 318, 354.
I thought about it too, but then noticed how the position of `[]` mimics that of the respective method signatures in code.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7063
From kevinw at openjdk.java.net Thu Jan 13 11:21:27 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 13 Jan 2022 11:21:27 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID:
On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo wrote:
> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - `'` is an apostrophe, which does not require to be encoded.
src/java.sql/share/classes/java/sql/Statement.java line 784:
> 782: * statement returns a {@code ResultSet} object, the second argument
> 783: * supplied to this method is not an
> 784: * {@code int} array whose elements are valid column indexes, the method is called on a
Should it be "or the method is called on...", i.e. add the "or", otherwise it's a list of problems but we don't know if they are all required, or are alternatives. It probably does not mean that all these have to be true to throw the exception, but it doesn't say that. We are nitpicking of course.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7063
From kevinw at openjdk.java.net Thu Jan 13 11:33:27 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 13 Jan 2022 11:33:27 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To:
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
<2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com>
Message-ID:
On Thu, 13 Jan 2022 11:04:43 GMT, Pavel Rappo wrote:
>> src/java.sql/share/classes/java/sql/BatchUpdateException.java line 58:
>>
>>> 56: * A JDBC driver implementation should use
>>> 57: * the constructor {@code BatchUpdateException(String reason, String SQLState,
>>> 58: * int vendorCode, long []updateCounts, Throwable cause) } instead of
>>
>> While we are here, is it more normal to say "long[] updateCounts", not separating the [] from the type.
>> Similarly at line 81, 118, 151, 247, 277, 318, 354.
>
> I thought about it too, but then noticed how the position of `[]` mimics that of the respective method signatures in code.
OK, so lines 264, 295, 329, 364, 431 are arguably wrong as well? Separating the [] completely looks quite rare.
I'll leave it up to you. 8-)
-------------
PR: https://git.openjdk.java.net/jdk/pull/7063
From kevinw at openjdk.java.net Thu Jan 13 11:33:27 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 13 Jan 2022 11:33:27 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID:
On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo wrote:
> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - `'` is an apostrophe, which does not require to be encoded.
Marked as reviewed by kevinw (Committer).
-------------
PR: https://git.openjdk.java.net/jdk/pull/7063
From prappo at openjdk.java.net Thu Jan 13 11:33:28 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 11:33:28 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To:
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com>
On Thu, 13 Jan 2022 11:18:42 GMT, Kevin Walls wrote:
>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `'` is an apostrophe, which does not require to be encoded.
>
> src/java.sql/share/classes/java/sql/Statement.java line 784:
>
>> 782: * statement returns a {@code ResultSet} object, the second argument
>> 783: * supplied to this method is not an
>> 784: * {@code int} array whose elements are valid column indexes, the method is called on a
>
> Should it be "or the method is called on...", i.e. add the "or", otherwise it's a list of problems but we don't know if they are all required, or are alternatives. It probably does not mean that all these have to be true to throw the exception, but it doesn't say that. We are nitpicking of course.
You are right in that this `@throws` description reads a bit weird in its current form. That said, I wouldn't touch it in this PR for two reasons. Firstly, this wording seems to be consistent with other locations in that file. Secondly, this is a spec territory.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7063
From lancea at openjdk.java.net Thu Jan 13 11:46:27 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 Jan 2022 11:46:27 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID:
On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo wrote:
> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - `'` is an apostrophe, which does not require to be encoded.
Overall this looks good, thanks for the clean up :-)
A few comments below
src/java.base/share/classes/java/io/DataInput.java line 496:
> 494: * ceases. If the character {@code '\r'}
> 495: * is encountered, it is discarded and, if
> 496: * the following byte converts to the
The above is a bit confusing as it reads(same in ImageInputStream.java). I think that that can be looked at later.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7063
From lancea at openjdk.java.net Thu Jan 13 11:46:27 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 Jan 2022 11:46:27 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To:
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
<2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com>
Message-ID:
On Thu, 13 Jan 2022 11:28:34 GMT, Kevin Walls wrote:
>> I thought about it too, but then noticed how the position of `[]` mimics that of the respective method signatures in code.
>
> OK, so lines 264, 295, 329, 364, 431 are arguably wrong as well? Separating the [] completely looks quite rare.
> I'll leave it up to you. 8-)
I think that can be a follow on clean up.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7063
From lancea at openjdk.java.net Thu Jan 13 11:46:28 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 Jan 2022 11:46:28 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
<90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com>
Message-ID:
On Thu, 13 Jan 2022 11:29:35 GMT, Pavel Rappo wrote:
>> src/java.sql/share/classes/java/sql/Statement.java line 784:
>>
>>> 782: * statement returns a {@code ResultSet} object, the second argument
>>> 783: * supplied to this method is not an
>>> 784: * {@code int} array whose elements are valid column indexes, the method is called on a
>>
>> Should it be "or the method is called on...", i.e. add the "or", otherwise it's a list of problems but we don't know if they are all required, or are alternatives. It probably does not mean that all these have to be true to throw the exception, but it doesn't say that. We are nitpicking of course.
>
> You are right in that this `@throws` description reads a bit weird in its current form. That said, I wouldn't touch it in this PR for two reasons. Firstly, this wording seems to be consistent with other locations in that file. Secondly, this is a spec territory.
Yes an "or" is probably worthwhile to add.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7063
From prappo at openjdk.java.net Thu Jan 13 12:40:45 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 12:40:45 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To:
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID:
On Thu, 13 Jan 2022 11:42:48 GMT, Lance Andersen wrote:
> The above is a bit confusing as it reads(same in ImageInputStream.java). I think that that can be looked at later.
Just to clarify: you are okay with removing the ` ` entity, right? As for ImageInputStream, some doc comments should probably use `@inheritDoc`. But this is a much bigger clean-up.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7063
From mullan at openjdk.java.net Thu Jan 13 13:45:30 2022
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 13 Jan 2022 13:45:30 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID:
On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo wrote:
> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - `'` is an apostrophe, which does not require to be encoded.
The change in the one security class (KeyStoreLoginModule) looks fine.
-------------
Marked as reviewed by mullan (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7063
From prappo at openjdk.java.net Thu Jan 13 13:51:34 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 13:51:34 GMT
Subject: RFR: 8279918: Fix various doc typos
In-Reply-To:
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
<90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com>
Message-ID: <9HH1T6jnf2bbBhD0h9sZZGoBWqEAoYen5Ymr52wVyDA=.7afbde78-363f-4e51-b0ad-a7e0cf2c0d6d@github.com>
On Thu, 13 Jan 2022 11:38:13 GMT, Lance Andersen wrote:
> Yes an "or" is probably worthwhile to add.
I would prefer to leave it for the follow-up cleanup if only because adding "or" here would make it inconsistent with other `@throws SQLException` descriptions in that file and perhaps elsewhere in java.sql:
* java/sql/Statement.java:59
* java/sql/Statement.java:85
* java/sql/Statement.java:346
* java/sql/Statement.java:524
* java/sql/Statement.java:745
* java/sql/Statement.java:814
* java/sql/Statement.java:860
* java/sql/Statement.java:913
* java/sql/Statement.java:962
* java/sql/Statement.java:1225
* java/sql/Statement.java:1269
* java/sql/Statement.java:1314
-------------
PR: https://git.openjdk.java.net/jdk/pull/7063
From prappo at openjdk.java.net Thu Jan 13 14:01:04 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 13 Jan 2022 14:01:04 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID:
> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - `'` is an apostrophe, which does not require to be encoded.
Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
Additional typos
-------------
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7063/files
- new: https://git.openjdk.java.net/jdk/pull/7063/files/fe81eeca..b256a13f
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7063&range=01
- incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7063&range=00-01
Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
Patch: https://git.openjdk.java.net/jdk/pull/7063.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7063/head:pull/7063
PR: https://git.openjdk.java.net/jdk/pull/7063
From sspitsyn at openjdk.java.net Thu Jan 13 16:53:27 2022
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Thu, 13 Jan 2022 16:53:27 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To:
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID:
On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo wrote:
>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `'` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>
> Additional typos
Hi Pavel,
Looks good.
Thanks,
Serguei
-------------
Marked as reviewed by sspitsyn (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7063
From lancea at openjdk.java.net Thu Jan 13 17:18:23 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 Jan 2022 17:18:23 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To:
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID:
On Thu, 13 Jan 2022 12:37:46 GMT, Pavel Rappo wrote:
> > The above is a bit confusing as it reads(same in ImageInputStream.java). I think that that can be looked at later.
>
> Just to clarify: you are okay with removing the ` ` entity, right? As for ImageInputStream, some doc comments should probably use `@inheritDoc`. But this is a much bigger clean-up.
Yes I am. It just does not flow as well as it could IMHO
-------------
PR: https://git.openjdk.java.net/jdk/pull/7063
From naoto at openjdk.java.net Thu Jan 13 17:25:30 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 13 Jan 2022 17:25:30 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To:
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID:
On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo wrote:
>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `'` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>
> Additional typos
Marked as reviewed by naoto (Reviewer).
-------------
PR: https://git.openjdk.java.net/jdk/pull/7063
From naoto at openjdk.java.net Thu Jan 13 17:25:31 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 13 Jan 2022 17:25:31 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <4f89A8T4GDZajnNMg-tT5qWaN5OCrH04Vwh9HZ6uTvg=.f2af94ec-43b4-4521-8158-aef4137b400b@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
<4f89A8T4GDZajnNMg-tT5qWaN5OCrH04Vwh9HZ6uTvg=.f2af94ec-43b4-4521-8158-aef4137b400b@github.com>
Message-ID: <4-d5YVHaRmPcyMlFYm2fxtIaRq6Z5PVooC8yd0OIbag=.cbd015b1-b2bd-43ba-b12f-8727087364b5@github.com>
On Thu, 13 Jan 2022 10:59:13 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/sun/text/RuleBasedBreakIterator.java line 73:
>>
>>> 71: * will be transparent to the BreakIterator. A sequence of characters will break the
>>> 72: * same way it would if any ignore characters it contains are taken out. Break
>>> 73: * positions never occur before ignore characters.
>>
>> "before ignored characters"
>
> I believe it's the name of a concept, so I will leave it as is:
>
>> There is one special substitution. If the description defines a substitution called "", the expression must be a [] expression, and the expression defines a set of characters (the "ignore characters") that will be transparent to the BreakIterator.
Yes, that is correct.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7063
From lancea at openjdk.java.net Thu Jan 13 17:25:31 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 Jan 2022 17:25:31 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To: <9HH1T6jnf2bbBhD0h9sZZGoBWqEAoYen5Ymr52wVyDA=.7afbde78-363f-4e51-b0ad-a7e0cf2c0d6d@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
<90v_XM2RzHUik7EfePw8m-79pscrcKUAb10T6FMJHYA=.3577ceee-012b-45f7-af57-64f0a8172dfa@github.com>
<9HH1T6jnf2bbBhD0h9sZZGoBWqEAoYen5Ymr52wVyDA=.7afbde78-363f-4e51-b0ad-a7e0cf2c0d6d@github.com>
Message-ID: <-4rLp_8_PwigKKpD1gGONCS8QMfDkNNNP4uZU1k9u9M=.9119e3bf-b879-42eb-a3a7-af6442a0551e@github.com>
On Thu, 13 Jan 2022 13:48:02 GMT, Pavel Rappo wrote:
> > Yes an "or" is probably worthwhile to add.
>
> I would prefer to leave it for the follow-up cleanup if only because adding "or" here would make it inconsistent with other `@throws SQLException` descriptions in that file and perhaps elsewhere in java.sql:
>
> * java/sql/Statement.java:59
> * java/sql/Statement.java:85
> * java/sql/Statement.java:346
> * java/sql/Statement.java:524
> * java/sql/Statement.java:745
> * java/sql/Statement.java:814
> * java/sql/Statement.java:860
> * java/sql/Statement.java:913
> * java/sql/Statement.java:962
> * java/sql/Statement.java:1225
> * java/sql/Statement.java:1269
> * java/sql/Statement.java:1314
I am fine with that. I guess a semi-colon could also be used vs. a comma to divide the Exception scenarios listed
-------------
PR: https://git.openjdk.java.net/jdk/pull/7063
From lancea at openjdk.java.net Thu Jan 13 17:35:25 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 13 Jan 2022 17:35:25 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To:
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID:
On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo wrote:
>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `'` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>
> Additional typos
Marked as reviewed by lancea (Reviewer).
-------------
PR: https://git.openjdk.java.net/jdk/pull/7063
From naoto at openjdk.java.net Thu Jan 13 22:03:01 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 13 Jan 2022 22:03:01 GMT
Subject: [jdk18] RFR: 8278434: timeouts in test
java/time/test/java/time/format/TestZoneTextPrinterParser.java
Message-ID:
8278434: timeouts in test java/time/test/java/time/format/TestZoneTextPrinterParser.java
-------------
Commit messages:
- Backport 8dc4437d002db5d025b47f48e7420e3bae55bdec
Changes: https://git.openjdk.java.net/jdk18/pull/100/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=100&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8278434
Stats: 73 lines in 3 files changed: 59 ins; 7 del; 7 mod
Patch: https://git.openjdk.java.net/jdk18/pull/100.diff
Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/100/head:pull/100
PR: https://git.openjdk.java.net/jdk18/pull/100
From naoto at openjdk.java.net Thu Jan 13 22:09:34 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 13 Jan 2022 22:09:34 GMT
Subject: [jdk18] Integrated: 8278434: timeouts in test
java/time/test/java/time/format/TestZoneTextPrinterParser.java
In-Reply-To:
References:
Message-ID:
On Thu, 13 Jan 2022 21:52:59 GMT, Naoto Sato wrote:
> 8278434: timeouts in test java/time/test/java/time/format/TestZoneTextPrinterParser.java
This pull request has now been integrated.
Changeset: 064ee6ae
Author: Naoto Sato
URL: https://git.openjdk.java.net/jdk18/commit/064ee6ae135366d59e9485b449a41d2b55811bbe
Stats: 73 lines in 3 files changed: 59 ins; 7 del; 7 mod
8278434: timeouts in test java/time/test/java/time/format/TestZoneTextPrinterParser.java
Backport-of: 8dc4437d002db5d025b47f48e7420e3bae55bdec
-------------
PR: https://git.openjdk.java.net/jdk18/pull/100
From jjg at openjdk.java.net Thu Jan 13 23:01:28 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 13 Jan 2022 23:01:28 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To:
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
<2bsQg-3igmY6_fAT_OD9jIuJ7ziQBgvB7oF1CiZN_Zo=.51e0dd63-d489-4996-8fb9-b2e8c385cbb8@github.com>
Message-ID:
On Thu, 13 Jan 2022 11:40:20 GMT, Lance Andersen wrote:
>> OK, so lines 264, 295, 329, 364, 431 are arguably wrong as well? Separating the [] completely looks quite rare.
>> I'll leave it up to you. 8-)
>
> I think that can be a follow on clean up.
The strange formatting of `long []updateCounts` looks very unusual and well worth a followup cleanup.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7063
From jlahoda at openjdk.java.net Fri Jan 14 11:22:36 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 14 Jan 2022 11:22:36 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To:
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID:
On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo wrote:
>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `'` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>
> Additional typos
javac changes look good to me.
-------------
Marked as reviewed by jlahoda (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7063
From azvegint at openjdk.java.net Fri Jan 14 12:19:28 2022
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 14 Jan 2022 12:19:28 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To:
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <2NHrJp-0YZuLsk1to7auM4-WbJ0BxxfUImHMBAYHxs8=.012a0e0c-a9e7-4bb9-b822-21334744d4ed@github.com>
On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo wrote:
>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `'` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>
> Additional typos
Client changes looks good to me.
-------------
Marked as reviewed by azvegint (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7063
From egahlin at openjdk.java.net Fri Jan 14 12:42:32 2022
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Fri, 14 Jan 2022 12:42:32 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To:
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID:
On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo wrote:
>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `'` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>
> Additional typos
Marked as reviewed by egahlin (Reviewer).
The JFR related changes looks OK.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7063
From jjg at openjdk.java.net Fri Jan 14 16:08:31 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 14 Jan 2022 16:08:31 GMT
Subject: RFR: 8279918: Fix various doc typos [v2]
In-Reply-To:
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID: <96bxwtnI-_Z67Udh4acEGwA2xzIy6dAV6CxOe9HLkRo=.dd8643aa-f3be-42e2-ad72-4a00d90363d9@github.com>
On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo wrote:
>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
>> - `'` is an apostrophe, which does not require to be encoded.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>
> Additional typos
jdk.compiler and jdk.javadoc look good
-------------
Marked as reviewed by jjg (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7063
From prappo at openjdk.java.net Fri Jan 14 16:13:34 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 14 Jan 2022 16:13:34 GMT
Subject: Integrated: 8279918: Fix various doc typos
In-Reply-To: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
References: <46YbMVL2FChSPfnSUQA9DT5-GV61UGS5WeBxaGsHGz8=.915d9070-8ee4-4703-bf34-1ae07085e550@github.com>
Message-ID:
On Thu, 13 Jan 2022 10:30:07 GMT, Pavel Rappo wrote:
> - Most of the typos are of a trivial kind: missing whitespace.
> - If any of the typos should be fixed in the upstream projects instead, please say so; I will drop those typos from the patch.
> - As I understand it, ` ` in ImageInputStream and DataInput is an irrelevant formatting artefact and thus can be removed.
> - `'` is an apostrophe, which does not require to be encoded.
This pull request has now been integrated.
Changeset: f1805309
Author: Pavel Rappo
URL: https://git.openjdk.java.net/jdk/commit/f1805309352a22119ae2edf8bfbb596f00936224
Stats: 88 lines in 35 files changed: 0 ins; 0 del; 88 mod
8279918: Fix various doc typos
Reviewed-by: kevinw, lancea, mullan, sspitsyn, naoto, jlahoda, azvegint, egahlin, jjg
-------------
PR: https://git.openjdk.java.net/jdk/pull/7063
From psadhukhan at openjdk.java.net Mon Jan 17 05:31:00 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 17 Jan 2022 05:31:00 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in
java.desktop module [v2]
In-Reply-To:
References:
Message-ID:
> The changes done under JDK-8278175 suppress on a per-file basis various missing comments that would otherwise trigger doclint warnings. Fixed them so as to remove the doclint:missing warnings.
Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
review fix
-------------
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7004/files
- new: https://git.openjdk.java.net/jdk/pull/7004/files/97d0232a..765c4147
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7004&range=01
- incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7004&range=00-01
Stats: 43 lines in 7 files changed: 12 ins; 0 del; 31 mod
Patch: https://git.openjdk.java.net/jdk/pull/7004.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7004/head:pull/7004
PR: https://git.openjdk.java.net/jdk/pull/7004
From psadhukhan at openjdk.java.net Mon Jan 17 05:31:08 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 17 Jan 2022 05:31:08 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in
java.desktop module [v2]
In-Reply-To:
References:
Message-ID: <5CkIUz9DUi5RJjOxhRAygCpX8KS4v6leUVf-wfz3qqA=.9700c7e8-ee9f-49a0-863f-7176b7046aaa@github.com>
On Tue, 11 Jan 2022 05:19:56 GMT, Sergey Bylokhov wrote:
>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>>
>> review fix
>
> src/java.desktop/share/classes/java/awt/BufferCapabilities.java line 65:
>
>> 63:
>> 64: /**
>> 65: * Returns the imaga capabilities of the front buffer
>
> Please add a dot after the first sentence, it is used as a summary doc for the method.
> Why the text about "displayed" buffer is removed? is it some special "term" like "intermediate" below?
Done
> src/java.desktop/share/classes/java/awt/Component.java line 4697:
>
>> 4695:
>> 4696: /**
>> 4697: * Checks whether or not paint messages received from the operating system
>
> In the change above the "Returns whether or not" text is used. It is better to use the same new text, or just use the old one.
Done
> src/java.desktop/share/classes/java/awt/event/KeyEvent.java line 653:
>
>> 651: /* For European keyboards */
>> 652: /**
>> 653: * Constant for the DEAD_GRAVE function key.
>
> I do not know, are all the keys here actually "function keys"?
Remove function keyword as it seems dead keys are combination of keys.
> src/java.desktop/share/classes/java/beans/beancontext/BeanContextServicesSupport.java line 150:
>
>> 148: /************************************************************************/
>> 149:
>> 150: /**
>
> This will add many statements to the specification which could be verified by the TCK. DO we really want to say all of that? Especially about serialization. Same question for other changes below.
ok. only added relevant info
> src/java.desktop/share/classes/javax/swing/undo/UndoableEditSupport.java line 150:
>
>> 148:
>> 149: /**
>> 150: * Start UndoableEdit.
>
> What does it mean? Is it clear enough for the class which "managing UndoableEdit
listeners"?
It seems it other places like CompoundEdit class, "assemble little UndoableEdits " statement is used so it seems ok to use UndoableEdit here. At least it's better than (to me)
"DEADLOCK WARNING: Calling this method may call
* undoableEditHappened
in all listeners."
used in endUpdate...
-------------
PR: https://git.openjdk.java.net/jdk/pull/7004
From aivanov at openjdk.java.net Tue Jan 18 16:58:39 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 18 Jan 2022 16:58:39 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in
java.desktop module [v2]
In-Reply-To:
References:
Message-ID:
On Mon, 17 Jan 2022 05:31:00 GMT, Prasanta Sadhukhan wrote:
>> The changes done under JDK-8278175 suppress on a per-file basis various missing comments that would otherwise trigger doclint warnings. Fixed them so as to remove the doclint:missing warnings.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>
> review fix
Changes requested by aivanov (Reviewer).
src/java.desktop/share/classes/java/awt/BufferCapabilities.java line 67:
> 65: * Returns the imaga capabilities of the front (displayed) buffer.
> 66: *
> 67: * @return the imaga capabilities of the front (displayed) buffer
Typo
Suggestion:
* Returns the image capabilities of the front (displayed) buffer.
*
* @return the image capabilities of the front (displayed) buffer
src/java.desktop/share/classes/java/awt/BufferCapabilities.java line 75:
> 73: /**
> 74: * Returns the image capabilities of all back buffers (intermediate buffers
> 75: * are considered back buffers)
Missing full stop.
Suggestion:
* Returns the image capabilities of all back buffers (intermediate buffers
* are considered back buffers).
src/java.desktop/share/classes/java/awt/BufferCapabilities.java line 85:
> 83:
> 84: /**
> 85: * Returns whether or not the buffer strategy uses page flipping; a set of
I am for simplified form which implies the same:
Suggestion:
* Returns whether the buffer strategy uses page flipping; a set of
Probably there should be full stop after ?flipping?. Javadoc uses the first sentence to provide a short summary of the method description. Without the full stop, the description is overly detailed. What do you think?
src/java.desktop/share/classes/java/awt/BufferCapabilities.java line 92:
> 90: * buffers uses blitting to copy the contents from one buffer to
> 91: * another; when this is the case, {@code getFlipContents} returns
> 92: * {@code null}
Suggestion:
* {@code null}.
Full stop to end the sentence.
src/java.desktop/share/classes/java/awt/BufferCapabilities.java line 136:
> 134: * Returns whether or not
> 135: * page flipping can be performed using more than two buffers (one or more
> 136: * intermediate buffers as well as the front and back buffer).
I'd rather re-flow both the description and `@return` tag description, the latter could omit the text in the parentheses.
src/java.desktop/share/classes/java/awt/Component.java line 4137:
> 4135: * Gets direct access to the back buffer, as an image.
> 4136: *
> 4137: * @return direct access to the back buffer, as an image.
Suggestion:
* Provides direct access to the back buffer as an image.
*
* @return direct access to the back buffer as an image.
The comma before ?as? makes the description confusing.
src/java.desktop/share/classes/java/awt/event/KeyEvent.java line 653:
> 651: /* For European keyboards */
> 652: /**
> 653: * Constant for the DEAD_GRAVE key.
A suggestion: use the key description rather than constant.
Suggestion:
* Constant for the Dead Grave key.
This is more human-friendly in my opinion. The names of the keys could be found at [KeyEvent line 1591](https://github.com/openjdk/jdk/blob/765c414752076cdf5d893364fb648b478d97523f/src/java.desktop/share/classes/java/awt/event/KeyEvent.java#L1591). They're really key name with first letters capitalised and spaces instead of underscores.
src/java.desktop/share/classes/java/awt/event/KeyEvent.java line 779:
> 777:
> 778: /**
> 779: * Constant for the BRACELEFT key.
Suggestion:
* Constant for the "{" key.
src/java.desktop/share/classes/java/awt/event/KeyEvent.java line 785:
> 783:
> 784: /**
> 785: * Constant for the BRACERIGHT key.
Suggestion:
* Constant for the "}" key.
src/java.desktop/share/classes/java/awt/event/KeyEvent.java line 1018:
> 1016: /* for Sun keyboards */
> 1017: /**
> 1018: * Constant for the "CUT" key.
I'd rather capitalise only the first letter of the key name.
src/java.desktop/share/classes/java/beans/beancontext/BeanContextServicesSupport.java line 161:
> 159: /**
> 160: * protected nested class containing per child information
> 161: * in the "children" hashtable.
Suggestion:
* A protected nested class containing per-child information
* in the {@code children} hashtable.
src/java.desktop/share/classes/java/beans/beancontext/BeanContextServicesSupport.java line 794:
> 792:
> 793: /**
> 794: * subclasses may subclass this nested class to represent proxy for
Suggestion:
* Subclasses may subclass this nested class to represent a proxy for
src/java.desktop/share/classes/java/beans/beancontext/BeanContextSupport.java line 309:
> 307: /**
> 308: * protected nested class containing per child information
> 309: * in the "children" hashtable.
Suggestion:
* A protected nested class containing per-child information
* in the {@code children} hashtable.
src/java.desktop/share/classes/javax/swing/JApplet.java line 109:
> 107: /**
> 108: * The JRootPane
instance that manages the
> 109: * contentPane
Suggestion:
* contentPane
.
src/java.desktop/share/classes/javax/swing/JDialog.java line 115:
> 113: /**
> 114: * The JRootPane
instance that manages the
> 115: * contentPane
Suggestion:
* contentPane
.
src/java.desktop/share/classes/javax/swing/JScrollBar.java line 111:
> 109:
> 110: /**
> 111: * Orientation for this scrollBar
Suggestion:
* Orientation of this scrollbar.
src/java.desktop/share/classes/javax/swing/JScrollBar.java line 120:
> 118: /**
> 119: * Amount to change the scrollbar's value by,
> 120: * given a unit up/down request.
Suggestion:
* The amount to change the value of the scrollbar by,
* given a unit up/down request.
However, this still looks cumbersome and is not as clear.
src/java.desktop/share/classes/javax/swing/JScrollBar.java line 129:
> 127: /**
> 128: * Amount to change the scrollbar's value by,
> 129: * given a block (usually "page") up/down request.
Suggestion:
* The amount to change the value of the scrollbar by,
* given a block (usually "page") up/down request.
src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 353:
> 351: * File(parent, fileName) except when parent and child are both
> 352: * special folders, in which case the File
is a wrapper containing
> 353: * a ShellFolder
object.
Suggestion:
* Returns a File
object which is normally constructed with new
* File(parent, fileName)
except when the parent and child are both
* special folders in which case the File
is a wrapper containing
* a ShellFolder
object.
Does it make sense to simplify the description of `@return` tag?
src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 928:
> 926:
> 927: /**
> 928: * The class represents the border of a {@code JTextField}.
Suggestion:
* Border for a {@code JTextField}.
Such a description is used for other classes which aren't public.
src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 1029:
> 1027:
> 1028: /**
> 1029: * The class represents the border of a {@code JToggleButton}.
Suggestion:
* Border for a {@code JToggleButton}.
src/java.desktop/share/classes/javax/swing/text/LayeredHighlighter.java line 32:
> 30: /**
> 31: * Highlighter interface to mark up the background of leaf views
> 32: * with colored areas.
Suggestion:
* Implementation of {@code Highlighter} interface to mark up the background of leaf views
* with colored areas.
src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 1686:
> 1684:
> 1685: /**
> 1686: * Returns HTMLDocument
of given JEditorPane
.
Suggestion:
* Returns HTMLDocument
of the given JEditorPane
.
src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 1700:
> 1698:
> 1699: /**
> 1700: * Returns HTMLEditorKit of given JEditorPane
.
Suggestion:
* Returns HTMLEditorKit of the given JEditorPane
.
src/java.desktop/share/classes/javax/swing/text/html/parser/AttributeList.java line 113:
> 111:
> 112: /**
> 113: * Return the attribute name.
Suggestion:
* Returns the attribute name.
src/java.desktop/share/classes/javax/swing/text/html/parser/AttributeList.java line 122:
> 120:
> 121: /**
> 122: * Return the attribute type.
Suggestion:
* Returns the attribute type.
src/java.desktop/share/classes/javax/swing/text/html/parser/AttributeList.java line 132:
> 130:
> 131: /**
> 132: * Return attribute modifier.
Suggestion:
* Returns the attribute modifier.
src/java.desktop/share/classes/javax/swing/text/html/parser/AttributeList.java line 142:
> 140:
> 141: /**
> 142: * Return possible attribute values.
Suggestion:
* Returns possible attribute values.
src/java.desktop/share/classes/javax/swing/text/html/parser/AttributeList.java line 151:
> 149:
> 150: /**
> 151: * Return default attribute value.
Suggestion:
* Returns the default attribute value.
src/java.desktop/share/classes/javax/swing/text/html/parser/AttributeList.java line 160:
> 158:
> 159: /**
> 160: * Return the next attribute in the list.
Suggestion:
* Returns the next attribute in the list.
src/java.desktop/share/classes/javax/swing/undo/UndoableEditSupport.java line 150:
> 148:
> 149: /**
> 150: * Start UndoableEdit.
Suggestion:
* Starts a compound update.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7004
From aivanov at openjdk.java.net Tue Jan 18 16:58:39 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 18 Jan 2022 16:58:39 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in
java.desktop module [v2]
In-Reply-To: <5CkIUz9DUi5RJjOxhRAygCpX8KS4v6leUVf-wfz3qqA=.9700c7e8-ee9f-49a0-863f-7176b7046aaa@github.com>
References:
<5CkIUz9DUi5RJjOxhRAygCpX8KS4v6leUVf-wfz3qqA=.9700c7e8-ee9f-49a0-863f-7176b7046aaa@github.com>
Message-ID:
On Mon, 17 Jan 2022 05:26:47 GMT, Prasanta Sadhukhan wrote:
>> src/java.desktop/share/classes/javax/swing/undo/UndoableEditSupport.java line 150:
>>
>>> 148:
>>> 149: /**
>>> 150: * Start UndoableEdit.
>>
>> What does it mean? Is it clear enough for the class which "managing UndoableEdit
listeners"?
>
> It seems it other places like CompoundEdit class, "assemble little UndoableEdits " statement is used so it seems ok to use UndoableEdit here. At least it's better than (to me)
>
> "DEADLOCK WARNING: Calling this method may call
> * undoableEditHappened
in all listeners."
>
>
> used in endUpdate...
Can we update the docs for those methods with a more meaningful description? In a separate issue.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7004
From aivanov at openjdk.java.net Wed Jan 19 20:20:57 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 19 Jan 2022 20:20:57 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in
java.desktop module [v2]
In-Reply-To:
References:
Message-ID:
On Tue, 18 Jan 2022 16:30:07 GMT, Alexey Ivanov wrote:
>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>>
>> review fix
>
> src/java.desktop/share/classes/javax/swing/JScrollBar.java line 120:
>
>> 118: /**
>> 119: * Amount to change the scrollbar's value by,
>> 120: * given a unit up/down request.
>
> Suggestion:
>
> * The amount to change the value of the scrollbar by,
> * given a unit up/down request.
>
> However, this still looks cumbersome and is not as clear.
What about _Stores the amount by which the value of the scrollbar is changed upon a unit up/down request_?
> src/java.desktop/share/classes/javax/swing/JScrollBar.java line 129:
>
>> 127: /**
>> 128: * Amount to change the scrollbar's value by,
>> 129: * given a block (usually "page") up/down request.
>
> Suggestion:
>
> * The amount to change the value of the scrollbar by,
> * given a block (usually "page") up/down request.
Similarly, _Stores the amount by which the value of the scrollbar is changed upon a block (usually "page") up/down request_.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7004
From psadhukhan at openjdk.java.net Thu Jan 20 06:08:22 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 20 Jan 2022 06:08:22 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in
java.desktop module [v3]
In-Reply-To:
References:
Message-ID:
> The changes done under JDK-8278175 suppress on a per-file basis various missing comments that would otherwise trigger doclint warnings. Fixed them so as to remove the doclint:missing warnings.
Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
Address review comments
-------------
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7004/files
- new: https://git.openjdk.java.net/jdk/pull/7004/files/765c4147..7c98aecf
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7004&range=02
- incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7004&range=01-02
Stats: 67 lines in 14 files changed: 0 ins; 4 del; 63 mod
Patch: https://git.openjdk.java.net/jdk/pull/7004.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7004/head:pull/7004
PR: https://git.openjdk.java.net/jdk/pull/7004
From psadhukhan at openjdk.java.net Thu Jan 20 06:12:29 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Thu, 20 Jan 2022 06:12:29 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in
java.desktop module [v4]
In-Reply-To:
References:
Message-ID:
> The changes done under JDK-8278175 suppress on a per-file basis various missing comments that would otherwise trigger doclint warnings. Fixed them so as to remove the doclint:missing warnings.
Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
Fix
-------------
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7004/files
- new: https://git.openjdk.java.net/jdk/pull/7004/files/7c98aecf..16d76ed3
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7004&range=03
- incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7004&range=02-03
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.java.net/jdk/pull/7004.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7004/head:pull/7004
PR: https://git.openjdk.java.net/jdk/pull/7004
From aivanov at openjdk.java.net Thu Jan 20 15:20:53 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 20 Jan 2022 15:20:53 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in
java.desktop module [v4]
In-Reply-To:
References:
Message-ID:
On Thu, 20 Jan 2022 06:12:29 GMT, Prasanta Sadhukhan wrote:
>> The changes done under JDK-8278175 suppress on a per-file basis various missing comments that would otherwise trigger doclint warnings. Fixed them so as to remove the doclint:missing warnings.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>
> Fix
src/java.desktop/share/classes/java/awt/Component.java line 4137:
> 4135: * Provides direct access to the back buffer as an image.
> 4136: *
> 4137: * @return direct access to the back buffer as an image.
Hm? This doesn't look right.
Suggestion:
* @return the back buffer as an image.
src/java.desktop/share/classes/java/beans/beancontext/BeanContextSupport.java line 312:
> 310: */
> 311: protected class BCSChild implements Serializable {
> 312:
Shall we indent `serialVersionUID`? It's for `BCSChild` but its indentation suggests it's for the surrounding class.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7004
From aivanov at openjdk.java.net Thu Jan 20 15:20:53 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 20 Jan 2022 15:20:53 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in
java.desktop module [v4]
In-Reply-To:
References:
Message-ID:
On Thu, 20 Jan 2022 15:11:37 GMT, Alexey Ivanov wrote:
> Shall we indent `serialVersionUID`? It's for `BCSChild` but its indentation suggests it's for the surrounding class.
It's right below the class declaration.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7004
From naoto.sato at oracle.com Thu Jan 20 21:46:49 2022
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 20 Jan 2022 13:46:49 -0800
Subject: Additional Date-Time Formats
Message-ID: <683f3d39-8109-5cb5-4792-1b33a4b1bd57@oracle.com>
Hello,
I am proposing a couple of new factory methods in
java.time.format.DateTimeFormatter that produce flexible localized
date/time formats, other than the existing pre-defined
(FULL/LONG/MEDIUM/SHORT) styles. For example, if the user wants a year
and month only string, such as the title for the calendar, currently
they would have to use DateTimeFormatter.ofPattern() with explicit
pattern argument, such as "MMM y". This is problematic because it is
correct in locales such as US, but not correct in other locales.
So, I propose methods that are parallel to ofPattern(), which take
pattern template. This is based on the CLDR's skeleton:
https://www.unicode.org/reports/tr35/tr35-dates.html#availableFormats_appendItems
Detailed design can be found in the draft CSR:
https://bugs.openjdk.java.net/browse/JDK-8243445
Comments are welcome.
Naoto
From huizhe.wang at oracle.com Fri Jan 21 05:52:57 2022
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 20 Jan 2022 21:52:57 -0800
Subject: Additional Date-Time Formats
In-Reply-To: <683f3d39-8109-5cb5-4792-1b33a4b1bd57@oracle.com>
References: <683f3d39-8109-5cb5-4792-1b33a4b1bd57@oracle.com>
Message-ID: <318fe2db-fead-f1d3-8b63-7d83137b789c@oracle.com>
Hi Naoto,
The javadoc points to LDML, it seems to me though it might be useful to
add more information similar to that for the ofPattern methods, what's
under the "Patterns for Formatting and Parsing" section, so that for at
least the common use cases we could rely on the javadoc without having
to consult the LDML specification. Some comparison with the ofPattern
methods might also be helpful.
Just my 2 cents.
Thanks,
Joe
On 1/20/22 1:46 PM, Naoto Sato wrote:
> Hello,
>
> I am proposing a couple of new factory methods in
> java.time.format.DateTimeFormatter that produce flexible localized
> date/time formats, other than the existing pre-defined
> (FULL/LONG/MEDIUM/SHORT) styles. For example, if the user wants a year
> and month only string, such as the title for the calendar, currently
> they would have to use DateTimeFormatter.ofPattern() with explicit
> pattern argument, such as "MMM y". This is problematic because it is
> correct in locales such as US, but not correct in other locales.
>
> So, I propose methods that are parallel to ofPattern(), which take
> pattern template. This is based on the CLDR's skeleton:
> https://www.unicode.org/reports/tr35/tr35-dates.html#availableFormats_appendItems
>
> Detailed design can be found in the draft CSR:
> https://bugs.openjdk.java.net/browse/JDK-8243445
>
> Comments are welcome.
>
> Naoto
>
From serb at openjdk.java.net Fri Jan 21 07:46:53 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 21 Jan 2022 07:46:53 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in
java.desktop module [v4]
In-Reply-To:
References:
Message-ID:
On Thu, 20 Jan 2022 06:12:29 GMT, Prasanta Sadhukhan wrote:
>> The changes done under JDK-8278175 suppress on a per-file basis various missing comments that would otherwise trigger doclint warnings. Fixed them so as to remove the doclint:missing warnings.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>
> Fix
src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 353:
> 351: * File(parent, fileName) except when the parent and child are both
> 352: * special folders, in which case the File
is a wrapper containing
> 353: * a ShellFolder
object.
Is a "ShellFolder" part of the public API? If not should we mention it in the spec?
-------------
PR: https://git.openjdk.java.net/jdk/pull/7004
From aturbanov at openjdk.java.net Fri Jan 21 17:04:58 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Fri, 21 Jan 2022 17:04:58 GMT
Subject: RFR: 8280470: Confusing instanceof check in
HijrahChronology.range
Message-ID:
Parameter `ChronoField field` is checked by `if (field instanceof ChronoField)`. Such check is confusing, because only one case, when this could be `false` is when `field == null`.
But if condition is not satisfied we will get immediate NullPointerException anyway in `return field.range();`.
-------------
Commit messages:
- [PATCH] Remove confusing instanceof check in HijrahChronology.range
- [PATCH] Remove confusing instanceof check in HijrahChronology.range
Changes: https://git.openjdk.java.net/jdk/pull/7118/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7118&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8280470
Stats: 13 lines in 1 file changed: 0 ins; 4 del; 9 mod
Patch: https://git.openjdk.java.net/jdk/pull/7118.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7118/head:pull/7118
PR: https://git.openjdk.java.net/jdk/pull/7118
From rriggs at openjdk.java.net Fri Jan 21 17:19:41 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 21 Jan 2022 17:19:41 GMT
Subject: RFR: 8280470: Confusing instanceof check in
HijrahChronology.range
In-Reply-To:
References:
Message-ID:
On Mon, 17 Jan 2022 21:02:35 GMT, Andrey Turbanov wrote:
> Parameter `ChronoField field` is checked by `if (field instanceof ChronoField)`. Such check is confusing, because only one case, when this could be `false` is when `field == null`.
> But if condition is not satisfied we will get immediate NullPointerException anyway in `return field.range();`.
Looks fine; I have no idea how that came to be; there was a lot of copy paste in the initial check-in of java.time.
-------------
Marked as reviewed by rriggs (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7118
From naoto at openjdk.java.net Fri Jan 21 17:29:43 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 21 Jan 2022 17:29:43 GMT
Subject: RFR: 8280470: Confusing instanceof check in
HijrahChronology.range
In-Reply-To:
References:
Message-ID:
On Mon, 17 Jan 2022 21:02:35 GMT, Andrey Turbanov wrote:
> Parameter `ChronoField field` is checked by `if (field instanceof ChronoField)`. Such check is confusing, because only one case, when this could be `false` is when `field == null`.
> But if condition is not satisfied we will get immediate NullPointerException anyway in `return field.range();`.
Marked as reviewed by naoto (Reviewer).
-------------
PR: https://git.openjdk.java.net/jdk/pull/7118
From dfuchs at openjdk.java.net Fri Jan 21 18:05:41 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 21 Jan 2022 18:05:41 GMT
Subject: RFR: 8280470: Confusing instanceof check in
HijrahChronology.range
In-Reply-To:
References:
Message-ID:
On Mon, 17 Jan 2022 21:02:35 GMT, Andrey Turbanov wrote:
> Parameter `ChronoField field` is checked by `if (field instanceof ChronoField)`. Such check is confusing, because only one case, when this could be `false` is when `field == null`.
> But if condition is not satisfied we will get immediate NullPointerException anyway in `return field.range();`.
Marked as reviewed by dfuchs (Reviewer).
-------------
PR: https://git.openjdk.java.net/jdk/pull/7118
From iris at openjdk.java.net Fri Jan 21 18:17:42 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 21 Jan 2022 18:17:42 GMT
Subject: RFR: 8280470: Confusing instanceof check in
HijrahChronology.range
In-Reply-To:
References:
Message-ID: <4cS4uzlig3bPC1NNM7jfbtldFeae_UJNKIAASc8RXAk=.b780126d-71e5-4192-afce-1195a00b327e@github.com>
On Mon, 17 Jan 2022 21:02:35 GMT, Andrey Turbanov wrote:
> Parameter `ChronoField field` is checked by `if (field instanceof ChronoField)`. Such check is confusing, because only one case, when this could be `false` is when `field == null`.
> But if condition is not satisfied we will get immediate NullPointerException anyway in `return field.range();`.
Marked as reviewed by iris (Reviewer).
-------------
PR: https://git.openjdk.java.net/jdk/pull/7118
From djelinski at openjdk.java.net Fri Jan 21 19:47:37 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 21 Jan 2022 19:47:37 GMT
Subject: RFR: 8280474: Garbage value passed to
getLocaleInfoWrapper in HostLocaleProviderAdapter_md
Message-ID:
Reported by clang-tidy. Verified manually by running
Calendar c = Calendar.getInstance();
System.out.println (c.getDisplayNames(Calendar.MONTH, Calendar.SHORT_STANDALONE, Locale.getDefault()));
with `-Djava.locale.providers=HOST`
Without the fix the WINAPI functions fail, and [this block](https://github.com/openjdk/jdk/blame/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/windows/native/libjava/HostLocaleProviderAdapter_md.c#L857) is never entered. With the fix this block is entered and sensible values are stored in the returned array.
No test because the observable effect with and without the fix was the same; apparently there's a fallback to another provider that works.
-------------
Commit messages:
- Update copyright year
- make sure isGenitive is initialized before use
Changes: https://git.openjdk.java.net/jdk/pull/7184/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7184&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8280474
Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
Patch: https://git.openjdk.java.net/jdk/pull/7184.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7184/head:pull/7184
PR: https://git.openjdk.java.net/jdk/pull/7184
From naoto at openjdk.java.net Fri Jan 21 21:12:10 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 21 Jan 2022 21:12:10 GMT
Subject: RFR: 8280474: Garbage value passed to
getLocaleInfoWrapper in HostLocaleProviderAdapter_md
In-Reply-To:
References:
Message-ID:
On Fri, 21 Jan 2022 19:28:21 GMT, Daniel Jeli?ski wrote:
> Reported by clang-tidy. Verified manually by running
>
> Calendar c = Calendar.getInstance();
> System.out.println (c.getDisplayNames(Calendar.MONTH, Calendar.SHORT_STANDALONE, Locale.getDefault()));
>
> with `-Djava.locale.providers=HOST`
>
> Without the fix the WINAPI functions fail, and [this block](https://github.com/openjdk/jdk/blame/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/windows/native/libjava/HostLocaleProviderAdapter_md.c#L857) is never entered. With the fix this block is entered and sensible values are stored in the returned array.
>
> No test because the observable effect with and without the fix was the same; apparently there's a fallback to another provider that works.
Looks good. The difference would be observable for locales that have different month names for standalone/format, such as Polish ??
I'd add `noreg-hard` label to the JBS issue, as it would require Windows to be set to those locales.
-------------
Marked as reviewed by naoto (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7184
From naoto.sato at oracle.com Fri Jan 21 22:39:21 2022
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 21 Jan 2022 14:39:21 -0800
Subject: Additional Date-Time Formats
In-Reply-To: <318fe2db-fead-f1d3-8b63-7d83137b789c@oracle.com>
References: <683f3d39-8109-5cb5-4792-1b33a4b1bd57@oracle.com>
<318fe2db-fead-f1d3-8b63-7d83137b789c@oracle.com>
Message-ID:
Thanks, Joe.
Good point. I will elaborate the pattern template part more, less
depending on the LDML spec. Would have been better if we could introduce
our own, such as ofLocalizedPattern(Set template), but not
exactly suffices the need.
Naoto
On 1/20/22 9:52 PM, Joe Wang wrote:
> Hi Naoto,
>
> The javadoc points to LDML, it seems to me though it might be useful to
> add more information similar to that for the ofPattern methods, what's
> under the "Patterns for Formatting and Parsing" section, so that for at
> least the common use cases we could rely on the javadoc without having
> to consult the LDML specification. Some comparison with the ofPattern
> methods might also be helpful.
>
> Just my 2 cents.
>
> Thanks,
> Joe
>
> On 1/20/22 1:46 PM, Naoto Sato wrote:
>> Hello,
>>
>> I am proposing a couple of new factory methods in
>> java.time.format.DateTimeFormatter that produce flexible localized
>> date/time formats, other than the existing pre-defined
>> (FULL/LONG/MEDIUM/SHORT) styles. For example, if the user wants a year
>> and month only string, such as the title for the calendar, currently
>> they would have to use DateTimeFormatter.ofPattern() with explicit
>> pattern argument, such as "MMM y". This is problematic because it is
>> correct in locales such as US, but not correct in other locales.
>>
>> So, I propose methods that are parallel to ofPattern(), which take
>> pattern template. This is based on the CLDR's skeleton:
>> https://www.unicode.org/reports/tr35/tr35-dates.html#availableFormats_appendItems
>>
>>
>> Detailed design can be found in the draft CSR:
>> https://bugs.openjdk.java.net/browse/JDK-8243445
>>
>> Comments are welcome.
>>
>> Naoto
>>
>
From alanb at openjdk.java.net Sat Jan 22 12:17:07 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 22 Jan 2022 12:17:07 GMT
Subject: RFR: 8280474: Garbage value passed to
getLocaleInfoWrapper in HostLocaleProviderAdapter_md
In-Reply-To:
References:
Message-ID:
On Fri, 21 Jan 2022 19:28:21 GMT, Daniel Jeli?ski wrote:
> Reported by clang-tidy. Verified manually by running
>
> Calendar c = Calendar.getInstance();
> System.out.println (c.getDisplayNames(Calendar.MONTH, Calendar.SHORT_STANDALONE, Locale.getDefault()));
>
> with `-Djava.locale.providers=HOST`
>
> Without the fix the WINAPI functions fail, and [this block](https://github.com/openjdk/jdk/blame/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/windows/native/libjava/HostLocaleProviderAdapter_md.c#L857) is never entered. With the fix this block is entered and sensible values are stored in the returned array.
>
> No test because the observable effect with and without the fix was the same; apparently there's a fallback to another provider that works.
Good find.
-------------
Marked as reviewed by alanb (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7184
From darcy at openjdk.java.net Sat Jan 22 21:15:29 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 22 Jan 2022 21:15:29 GMT
Subject: RFR: JDK-8280492: Address remaining doclint issues in
JDK build
Message-ID:
Use presumed syntax that will be introduced by JDK-8280488.
-------------
Commit messages:
- JDK-8280492: Address remaining doclint issues in JDK build
Changes: https://git.openjdk.java.net/jdk/pull/7189/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7189&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8280492
Stats: 57 lines in 17 files changed: 0 ins; 0 del; 57 mod
Patch: https://git.openjdk.java.net/jdk/pull/7189.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7189/head:pull/7189
PR: https://git.openjdk.java.net/jdk/pull/7189
From darcy at openjdk.java.net Sat Jan 22 21:38:04 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 22 Jan 2022 21:38:04 GMT
Subject: RFR: JDK-8280492: Address remaining doclint issues
in JDK build
In-Reply-To:
References:
Message-ID:
On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote:
> Use presumed syntax that will be introduced by JDK-8280488.
This should be the (near) final step to fully enable all doclint checks during the javac portion of the build. The "reference" doclint check is currently disabled in the build command for several modules. The problematic references are cross-module @see and @link tags. This PR changes those tags to use a to a new proposed syntax for cross-module references.
Before this PR is pushed, the javadoc changes need to be made and I'll update the make files to enable the "reference" warning category.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7189
From iris at openjdk.java.net Sun Jan 23 04:20:09 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Sun, 23 Jan 2022 04:20:09 GMT
Subject: RFR: JDK-8280492: Address remaining doclint issues
in JDK build
In-Reply-To:
References:
Message-ID:
On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote:
> Use presumed syntax that will be introduced by JDK-8280488.
Marked as reviewed by iris (Reviewer).
-------------
PR: https://git.openjdk.java.net/jdk/pull/7189
From serb at openjdk.java.net Sun Jan 23 08:09:08 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 23 Jan 2022 08:09:08 GMT
Subject: RFR: JDK-8280492: Address remaining doclint issues
in JDK build
In-Reply-To:
References:
Message-ID:
On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote:
> Use presumed syntax that will be introduced by JDK-8280488.
Marked as reviewed by serb (Reviewer).
-------------
PR: https://git.openjdk.java.net/jdk/pull/7189
From lancea at openjdk.java.net Sun Jan 23 11:48:06 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sun, 23 Jan 2022 11:48:06 GMT
Subject: RFR: JDK-8280492: Address remaining doclint issues
in JDK build
In-Reply-To:
References:
Message-ID: <2G0jVnCjP0i0VZhKN-fy0jDFtkT3BbBVcBiOJdxT56c=.870ed070-ad3c-4c88-bced-9ccb6155867b@github.com>
On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote:
> Use presumed syntax that will be introduced by JDK-8280488.
Marked as reviewed by lancea (Reviewer).
-------------
PR: https://git.openjdk.java.net/jdk/pull/7189
From psadhukhan at openjdk.java.net Mon Jan 24 06:03:42 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 24 Jan 2022 06:03:42 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in
java.desktop module [v5]
In-Reply-To:
References:
Message-ID:
> The changes done under JDK-8278175 suppress on a per-file basis various missing comments that would otherwise trigger doclint warnings. Fixed them so as to remove the doclint:missing warnings.
Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
Address review comment
-------------
Changes:
- all: https://git.openjdk.java.net/jdk/pull/7004/files
- new: https://git.openjdk.java.net/jdk/pull/7004/files/16d76ed3..752b7a09
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7004&range=04
- incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7004&range=03-04
Stats: 7 lines in 3 files changed: 0 ins; 0 del; 7 mod
Patch: https://git.openjdk.java.net/jdk/pull/7004.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/7004/head:pull/7004
PR: https://git.openjdk.java.net/jdk/pull/7004
From psadhukhan at openjdk.java.net Mon Jan 24 06:03:45 2022
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Mon, 24 Jan 2022 06:03:45 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in
java.desktop module [v4]
In-Reply-To:
References:
Message-ID:
On Fri, 21 Jan 2022 07:43:17 GMT, Sergey Bylokhov wrote:
>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Fix
>
> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 353:
>
>> 351: * File(parent, fileName) except when the parent and child are both
>> 352: * special folders, in which case the File
is a wrapper containing
>> 353: * a ShellFolder
object.
>
> Is a "ShellFolder" part of the public API? If not should we mention it in the spec?
It is already mentioned in getSystemDisplayName, getSystemTypeDescription, getSystemIcon, isRoot. Anyways, I have removed the linkage for the new addition as it will not be able to resolve.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7004
From djelinski at openjdk.java.net Mon Jan 24 08:09:04 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 24 Jan 2022 08:09:04 GMT
Subject: RFR: 8280474: Garbage value passed to
getLocaleInfoWrapper in HostLocaleProviderAdapter_md
In-Reply-To:
References:
Message-ID: <6H7ByIE0exrvC76VNJncAIeXIno7GvxJeztKwFw-dFM=.0b40544c-ea07-4bd7-a67b-6af9799ab4e8@github.com>
On Fri, 21 Jan 2022 19:28:21 GMT, Daniel Jeli?ski wrote:
> Reported by clang-tidy. Verified manually by running
>
> Calendar c = Calendar.getInstance();
> System.out.println (c.getDisplayNames(Calendar.MONTH, Calendar.SHORT_STANDALONE, Locale.getDefault()));
>
> with `-Djava.locale.providers=HOST`
>
> Without the fix the WINAPI functions fail, and [this block](https://github.com/openjdk/jdk/blame/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/windows/native/libjava/HostLocaleProviderAdapter_md.c#L857) is never entered. With the fix this block is entered and sensible values are stored in the returned array.
>
> No test because the observable effect with and without the fix was the same; apparently there's a fallback to another provider that works.
Thanks!
-------------
PR: https://git.openjdk.java.net/jdk/pull/7184
From aivanov at openjdk.java.net Mon Jan 24 10:54:18 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 24 Jan 2022 10:54:18 GMT
Subject: RFR: 8278254: Cleanup doclint warnings in
java.desktop module [v4]
In-Reply-To:
References:
Message-ID: