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: On Mon, 24 Jan 2022 06:00:02 GMT, Prasanta Sadhukhan wrote: >> 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. If `ShellFolder` remains mentioned, I'd rather use `ShellFolder` as it was done originally. I guess Sergey challenged the fact of referencing `ShellFolder`. The fact that it could be `ShellFolder` rather than `File` is an implementation detail. Can we drop that from the spec? On the other hand, `ShellFolder` class, even though it's not a public API, is mentioned in quite a few methods in `FileSystemView`. I don't have a strong opinion here. Perhaps, we should scrap all the references to `ShellFolder`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7004 From dfuchs at openjdk.java.net Mon Jan 24 11:04:04 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 24 Jan 2022 11:04:04 GMT Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build In-Reply-To: References: Message-ID: <_88lIvfjpVm1vQZK5-cmAGaqPJ5iUTCEn6p-oF5Hf0Y=.c64be2a1-a932-4ac3-90c2-838f890ab56f@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 dfuchs (Reviewer). LGTM. I hope in the future IDEs will pick that rule up and offer some help when writing `{@link }` `@see`... ------------- PR: https://git.openjdk.java.net/jdk/pull/7189 From prappo at openjdk.java.net Mon Jan 24 11:21:08 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 24 Jan 2022 11:21:08 GMT Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build In-Reply-To: <_88lIvfjpVm1vQZK5-cmAGaqPJ5iUTCEn6p-oF5Hf0Y=.c64be2a1-a932-4ac3-90c2-838f890ab56f@github.com> References: <_88lIvfjpVm1vQZK5-cmAGaqPJ5iUTCEn6p-oF5Hf0Y=.c64be2a1-a932-4ac3-90c2-838f890ab56f@github.com> Message-ID: On Mon, 24 Jan 2022 11:00:37 GMT, Daniel Fuchs wrote: > LGTM. I hope in the future IDEs will pick that rule up and offer some help when writing `{@link }` `@see`... They will do it quicker, if you create new or support existing bugs in their bug trackers. ------------- PR: https://git.openjdk.java.net/jdk/pull/7189 From psadhukhan at openjdk.java.net Mon Jan 24 11:31:11 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 24 Jan 2022 11:31:11 GMT Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v4] In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 10:51:00 GMT, Alexey Ivanov wrote: >> 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. > > If `ShellFolder` remains mentioned, I'd rather use `ShellFolder` as it was done originally. > > I guess Sergey challenged the fact of referencing `ShellFolder`. The fact that it could be `ShellFolder` rather than `File` is an implementation detail. Can we drop that from the spec? > > On the other hand, `ShellFolder` class, even though it's not a public API, is mentioned in quite a few methods in `FileSystemView`. > > I don't have a strong opinion here. Perhaps, we should scrap all the references to `ShellFolder`. Since it is mentioned in other places, I would rather not scrap it. Also, since in most places it is mentioned as a non-link value, I chose to modify it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7004 From prappo at openjdk.java.net Mon Jan 24 11:36:04 2022 From: prappo at openjdk.java.net (Pavel Rappo) Date: Mon, 24 Jan 2022 11:36: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. Is that a wrong bug? If you are talking about module-prefix syntax for links, then it was introduced in JDK 15; JDK-8164408: Add module support for @see, @link and @linkplain javadoc tags. ------------- PR: https://git.openjdk.java.net/jdk/pull/7189 From aivanov at openjdk.java.net Mon Jan 24 11:39:12 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 24 Jan 2022 11:39:12 GMT Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v4] In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 11:28:06 GMT, Prasanta Sadhukhan wrote: >> If `ShellFolder` remains mentioned, I'd rather use `ShellFolder` as it was done originally. >> >> I guess Sergey challenged the fact of referencing `ShellFolder`. The fact that it could be `ShellFolder` rather than `File` is an implementation detail. Can we drop that from the spec? >> >> On the other hand, `ShellFolder` class, even though it's not a public API, is mentioned in quite a few methods in `FileSystemView`. >> >> I don't have a strong opinion here. Perhaps, we should scrap all the references to `ShellFolder`. > > Since it is mentioned in other places, I would rather not scrap it. Also, since in most places it is mentioned as a non-link value, I chose to modify it. The `` element does not create a link, it uses monospace font to render its contents which implies it's part of computer code. Class names usually marked up with `` HTML element or with `{@code }` javadoc element. These aren't used consistently. Often classes aren't marked up. So you're right: in the majority of cases, `ShellFolder` isn't marked up. The `` markup is used in two methods only: `isRoot` and `getChild`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7004 From aivanov at openjdk.java.net Mon Jan 24 11:39:12 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 24 Jan 2022 11:39:12 GMT Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v4] In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 11:34:04 GMT, Alexey Ivanov wrote: >> Since it is mentioned in other places, I would rather not scrap it. Also, since in most places it is mentioned as a non-link value, I chose to modify it. > > The `` element does not create a link, it uses monospace font to render its contents which implies it's part of computer code. Class names usually marked up with `` HTML element or with `{@code }` javadoc element. > > These aren't used consistently. Often classes aren't marked up. So you're right: in the majority of cases, `ShellFolder` isn't marked up. The `` markup is used in two methods only: `isRoot` and `getChild`. I was referring to removing all the references to `ShellFolder` from public API, under another bugid, if it's to be done. ------------- PR: https://git.openjdk.java.net/jdk/pull/7004 From darcy at openjdk.java.net Mon Jan 24 18:25:08 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 24 Jan 2022 18:25:08 GMT Subject: RFR: JDK-8280492: Address remaining doclint issues in JDK build In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 11:33:18 GMT, Pavel Rappo wrote: > > Use presumed syntax that will be introduced by JDK-8280488. > > Is that a wrong bug? If you are talking about module-prefix syntax for links, then it was introduced in JDK 15; JDK-8164408: Add module support for @see, @link and @linkplain javadoc tags. Ah; thanks Pavel for the additional context. Bug JDK-8280488 will allow (i.e. ignore) cross-module @see/@link references during javac compilation. So while the syntax in this PR is already valid per JDK-8164408, I cannot (yet) enable the "reference" doctlint check in the javac build due to the cross-module situation. I'll double-check the syntax in this PR generates the expected links in the result of the docs builds, give the bug a more descriptive title, and get these changes pushed. Enabling the reference warning can be done under another bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/7189 From aivanov at openjdk.java.net Mon Jan 24 18:57:10 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 24 Jan 2022 18:57:10 GMT Subject: RFR: JDK-8280492: Use cross-module syntax for cross-module links 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 aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7189 From aivanov at openjdk.java.net Mon Jan 24 19:09:11 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 24 Jan 2022 19:09:11 GMT Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v5] In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 06:03:42 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: > > Address review comment Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7004 From djelinski at openjdk.java.net Mon Jan 24 19:35:14 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 24 Jan 2022 19:35:14 GMT Subject: Integrated: 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. This pull request has now been integrated. Changeset: a5416669 Author: Daniel Jeli?ski Committer: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/a5416669a57a7739af13efc32ec084560527862b Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8280474: Garbage value passed to getLocaleInfoWrapper in HostLocaleProviderAdapter_md Reviewed-by: naoto, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7184 From darcy at openjdk.java.net Mon Jan 24 20:10:40 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 24 Jan 2022 20:10:40 GMT Subject: RFR: JDK-8280492: Use cross-module syntax for cross-module links [v2] In-Reply-To: References: Message-ID: <8CLBwHk3ls8ijDaN-6poNrhGMxCulNGrjFvImPGQ-sY=.e8629cdc-b51d-4614-a5af-923f848d0703@github.com> > Use presumed syntax that will be introduced by JDK-8280488. Joe Darcy 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 three additional commits since the last revision: - Update copyrigths. - Merge branch 'master' into JDK-8280492 - JDK-8280492: Address remaining doclint issues in JDK build ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7189/files - new: https://git.openjdk.java.net/jdk/pull/7189/files/b74e7d85..6f3bd429 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7189&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7189&range=00-01 Stats: 664 lines in 55 files changed: 433 ins; 128 del; 103 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 Mon Jan 24 20:20:12 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 24 Jan 2022 20:20:12 GMT Subject: Integrated: JDK-8280492: Use cross-module syntax for cross-module links In-Reply-To: References: Message-ID: <2oUpK1s5mNt-fWdUF5YZP3MlqzjXypdqMMz8QG-3Q5U=.f971fd74-655b-400d-9718-11299edcb7c8@github.com> On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote: > Use presumed syntax that will be introduced by JDK-8280488. This pull request has now been integrated. Changeset: 8e82d002 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/8e82d0021c119b7793870811fad37d7659c1174d Stats: 72 lines in 17 files changed: 0 ins; 0 del; 72 mod 8280492: Use cross-module syntax for cross-module links Reviewed-by: iris, serb, lancea, dfuchs, aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/7189 From naoto.sato at oracle.com Tue Jan 25 00:13:57 2022 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 24 Jan 2022 16:13:57 -0800 Subject: Additional Date-Time Formats In-Reply-To: References: <683f3d39-8109-5cb5-4792-1b33a4b1bd57@oracle.com> <318fe2db-fead-f1d3-8b63-7d83137b789c@oracle.com> Message-ID: <2474cef3-abb6-f2fd-458b-9a9a0e947608@oracle.com> Updated the CSR (https://bugs.openjdk.java.net/browse/JDK-8243445), by adding a regular expression for the requested template. This way, it is less depending on the LDML specification. Naoto On 1/21/22 2:39 PM, Naoto Sato wrote: > 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 huizhe.wang at oracle.com Tue Jan 25 01:50:16 2022 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 24 Jan 2022 17:50:16 -0800 Subject: Additional Date-Time Formats In-Reply-To: <2474cef3-abb6-f2fd-458b-9a9a0e947608@oracle.com> References: <683f3d39-8109-5cb5-4792-1b33a4b1bd57@oracle.com> <318fe2db-fead-f1d3-8b63-7d83137b789c@oracle.com> <2474cef3-abb6-f2fd-458b-9a9a0e947608@oracle.com> Message-ID: <2d6af6a5-57ae-482a-b566-19c7cf32985a@oracle.com> Hi Naoto, Nice use of regular expression! Saves a lot of description if I would just follow the regex pattern. Question: ?????? The 2nd and 3rd statements defined the requestedTemplate, does it imply the characters listed in the snippet are the only ones that are valid, in other words, can other characters under the Patterns section be used? It may be helpful to elaborate on the snippet a bit more. ?????? Also, the range implies a valid range for a particular symbol, if that's the case, y and w feel like they are unbound. If I do that with ofPettern, I get ArrayIndexOutOfBoundsException. For the sample code, it might be helpful to put them in a code snippet and with the actual java code. If "yMMM" formats to 'Jun 2020', that might require some explanation too since that would be the same as ofPattern("MMM y") for the default(US) locale, or was it a typo?. (I'm not familiar with the use of DTF, just printed out date.format(DTF.ofPattern("yMMM" and "MMM y") :-)) Joe On 1/24/22 4:13 PM, Naoto Sato wrote: > Updated the CSR (https://bugs.openjdk.java.net/browse/JDK-8243445), by > adding a regular expression for the requested template. This way, it > is less depending on the LDML specification. > > Naoto > > On 1/21/22 2:39 PM, Naoto Sato wrote: >> 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 serb at openjdk.java.net Tue Jan 25 03:08:37 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 25 Jan 2022 03:08:37 GMT Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v5] In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 06:03:42 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: > > Address review comment Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7004 From aturbanov at openjdk.java.net Tue Jan 25 08:12:40 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Tue, 25 Jan 2022 08:12:40 GMT Subject: Integrated: 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();`. This pull request has now been integrated. Changeset: 53804720 Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/53804720a04b5b314701de82eddf1a55798eba00 Stats: 13 lines in 1 file changed: 0 ins; 4 del; 9 mod 8280470: Confusing instanceof check in HijrahChronology.range Reviewed-by: rriggs, naoto, dfuchs, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/7118 From serb at openjdk.java.net Tue Jan 25 18:24:44 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 25 Jan 2022 18:24:44 GMT Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v5] In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 06:03:42 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: > > Address review comment I think we need to file a CSR to document all that new specifications. ------------- PR: https://git.openjdk.java.net/jdk/pull/7004 From naoto.sato at oracle.com Tue Jan 25 22:30:25 2022 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 25 Jan 2022 14:30:25 -0800 Subject: Additional Date-Time Formats In-Reply-To: <2d6af6a5-57ae-482a-b566-19c7cf32985a@oracle.com> References: <683f3d39-8109-5cb5-4792-1b33a4b1bd57@oracle.com> <318fe2db-fead-f1d3-8b63-7d83137b789c@oracle.com> <2474cef3-abb6-f2fd-458b-9a9a0e947608@oracle.com> <2d6af6a5-57ae-482a-b566-19c7cf32985a@oracle.com> Message-ID: Hi Joe, On 1/24/22 5:50 PM, Joe Wang wrote: > ?????? The 2nd and 3rd statements defined the requestedTemplate, does > it imply the characters listed in the snippet are the only ones that are > valid, in other words, can other characters under the Patterns section > be used? It may be helpful to elaborate on the snippet a bit more. Those symbols represent each field, so other symbols are considered illegal as a template symbol. Added some explanation there. > ?????? Also, the range implies a valid range for a particular symbol, > if that's the case, y and w feel like they are unbound. If I do that > with ofPettern, I get ArrayIndexOutOfBoundsException. The spec of 'year' and 'number' presentations do not have any upper limit number of letters, thus I added the '*' quantifier. Not exactly sure why AIOOBE is thrown with ofPattern(), could be a separate bug? It should be zero-padded or sign-padded. > > For the sample code, it might be helpful to put them in a code snippet > and with the actual java code. If "yMMM" formats to 'Jun 2020', that > might require some explanation too since that would be the same as > ofPattern("MMM y") for the default(US) locale, or was it a typo?. (I'm > not familiar with the use of DTF, just printed out > date.format(DTF.ofPattern("yMMM" and "MMM y") :-)) Well, it is not a typo and `ofLocalizedPattern("yMMM", Locale.US)` and `ofPattern("MMM y", Locale.US)` both generating the same result is exactly what this API is aiming at. Users don't need to pay attention to locale specific format pattern with this API. HTH, Naoto From huizhe.wang at oracle.com Tue Jan 25 23:49:11 2022 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 25 Jan 2022 15:49:11 -0800 Subject: Additional Date-Time Formats In-Reply-To: References: <683f3d39-8109-5cb5-4792-1b33a4b1bd57@oracle.com> <318fe2db-fead-f1d3-8b63-7d83137b789c@oracle.com> <2474cef3-abb6-f2fd-458b-9a9a0e947608@oracle.com> <2d6af6a5-57ae-482a-b566-19c7cf32985a@oracle.com> Message-ID: Hi Naoto, Looks good to me, and thanks for the explanation. I agree, AIOOBE would be a separate bug with ofPattern. Thanks, Joe On 1/25/22 2:30 PM, Naoto Sato wrote: > Hi Joe, > > On 1/24/22 5:50 PM, Joe Wang wrote: >> ??????? The 2nd and 3rd statements defined the requestedTemplate, >> does it imply the characters listed in the snippet are the only ones >> that are valid, in other words, can other characters under the >> Patterns section be used? It may be helpful to elaborate on the >> snippet a bit more. > > Those symbols represent each field, so other symbols are considered > illegal as a template symbol. Added some explanation there. > >> ??????? Also, the range implies a valid range for a particular >> symbol, if that's the case, y and w feel like they are unbound. If I >> do that with ofPettern, I get ArrayIndexOutOfBoundsException. > > The spec of 'year' and 'number' presentations do not have any upper > limit number of letters, thus I added the '*' quantifier. Not exactly > sure why AIOOBE is thrown with ofPattern(), could be a separate bug? > It should be zero-padded or sign-padded. > >> >> For the sample code, it might be helpful to put them in a code >> snippet and with the actual java code. If "yMMM" formats to 'Jun >> 2020', that might require some explanation too since that would be >> the same as ofPattern("MMM y") for the default(US) locale, or was it >> a typo?. (I'm not familiar with the use of DTF, just printed out >> date.format(DTF.ofPattern("yMMM" and "MMM y") :-)) > > Well, it is not a typo and `ofLocalizedPattern("yMMM", Locale.US)` and > `ofPattern("MMM y", Locale.US)` both generating the same result is > exactly what this API is aiming at. Users don't need to pay attention > to locale specific format pattern with this API. > > HTH, > Naoto From psadhukhan at openjdk.java.net Thu Jan 27 05:15:34 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 27 Jan 2022 05:15:34 GMT Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v5] In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 06:03:42 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: > > Address review comment CSR JDK-8280765 added. please review.. ------------- PR: https://git.openjdk.java.net/jdk/pull/7004 From aivanov at openjdk.java.net Fri Jan 28 21:13:14 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 28 Jan 2022 21:13:14 GMT Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v5] In-Reply-To: References: Message-ID: <1taSqWg7RU0PdROACiBsbkNkGwu1QUaob7y03mC2gM4=.c64aca26-6333-4491-b852-0373c219d514@github.com> On Mon, 24 Jan 2022 06:03:42 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: > > Address review comment Marked as reviewed by aivanov (Reviewer). src/java.desktop/share/classes/java/awt/Component.java line 4701: > 4699: * > 4700: * @return whether or not paint messages received from the operating system > 4701: * should be ignored. Shall we remove the ending punctuation from `@return` tag for consistency? ------------- PR: https://git.openjdk.java.net/jdk/pull/7004 From psadhukhan at openjdk.java.net Mon Jan 31 07:39:45 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 31 Jan 2022 07:39:45 GMT Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v6] 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: Remove . to be consistent ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7004/files - new: https://git.openjdk.java.net/jdk/pull/7004/files/752b7a09..aebc9d70 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7004&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7004&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 31 07:39:49 2022 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 31 Jan 2022 07:39:49 GMT Subject: RFR: 8278254: Cleanup doclint warnings in java.desktop module [v5] In-Reply-To: <1taSqWg7RU0PdROACiBsbkNkGwu1QUaob7y03mC2gM4=.c64aca26-6333-4491-b852-0373c219d514@github.com> References: <1taSqWg7RU0PdROACiBsbkNkGwu1QUaob7y03mC2gM4=.c64aca26-6333-4491-b852-0373c219d514@github.com> Message-ID: On Fri, 28 Jan 2022 19:29:14 GMT, Alexey Ivanov wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comment > > src/java.desktop/share/classes/java/awt/Component.java line 4701: > >> 4699: * >> 4700: * @return whether or not paint messages received from the operating system >> 4701: * should be ignored. > > Shall we remove the ending punctuation from `@return` tag for consistency? There are few places in this file too where it still have "." but those are not touched by this PR but I agree in most places we don't have so I removed from the places where we are touching in this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/7004