Ping.
Naoto
On 6/10/22 2:05 PM, Naoto Sato wrote:
As the name suggests, `COMPAT` locale provider keeps compatibility with JDK8's
locale data (before CLDR). This is useful for legacy applications, but some of
its data got obsolete for later locale data updates, such as the country
On Fri, 10 Jun 2022 20:58:03 GMT, Naoto Sato wrote:
> As the name suggests, `COMPAT` locale provider keeps compatibility with
> JDK8's locale data (before CLDR). This is useful for legacy applications,
> but some of its data got obsolete for later locale data updates, such as
On Wed, 22 Jun 2022 17:27:11 GMT, Roger Riggs wrote:
>> True. Which raises the question: do we need any arbitrary order? The
>> original code used a hashmap too. It preserved the original order only when
>> no duplicates were detected.
>
> A stable order is useful when comparing between builds
On Wed, 22 Jun 2022 17:30:48 GMT, Daniel Jeliński wrote:
>> This PR improves the performance of deduplication done by
>> ResourceBundleGenerator.
>>
>> The original implementation compared every pair of values, requiring O(n^2)
>> time. The new implementation uses a HashMap to find duplicates,
On Wed, 22 Jun 2022 17:57:44 GMT, Naoto Sato wrote:
>> A stable order is useful when comparing between builds (by a human).
>> It also supports the goal of reproducible builds.
>> @naotoj What do you think?
>
> IIUC, once this fix makes it to the repository, the build
On Thu, 23 Jun 2022 08:53:37 GMT, Daniel Jeliński wrote:
>> This PR improves the performance of deduplication done by
>> ResourceBundleGenerator.
>>
>> The original implementation compared every pair of values, requiring O(n^2)
>> time. The new implementation uses a HashMap to find duplicates,
This is a leftover documentation fix to the deprecation of `Locale`
constructors. `Locale.Builder` class had some texts that suggested using one of
those constructors, which need to be replaced with a `Locale.of()` method. A
corresponding CSR has also been drafted.
-
Commit message
On Tue, 28 Jun 2022 19:45:30 GMT, Roger Riggs wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> added `lang` attribute to the snippet
>
> src/java.base/share/classes/java/util/Loc
> This is a leftover documentation fix to the deprecation of `Locale`
> constructors. `Locale.Builder` class had some texts that suggested using one
> of those constructors, which need to be replaced with a `Locale.of()` method.
> A corresponding CSR has also been drafted.
Na
On Tue, 28 Jun 2022 18:52:32 GMT, Gaurav Chaudhari wrote:
> This is a REDO of the Fix that was incompletely implemented earlier:
> [8285838: Fix for TZ environment variable DST
> rules](https://github.com/openjdk/jdk/pull/8660)
>
> Offset calculation now accounts all the way upto year in order
On Tue, 28 Jun 2022 17:11:31 GMT, Naoto Sato wrote:
> This is a leftover documentation fix to the deprecation of `Locale`
> constructors. `Locale.Builder` class had some texts that suggested using one
> of those constructors, which need to be replaced with a `Locale.of()` met
On Tue, 28 Jun 2022 18:52:32 GMT, Gaurav Chaudhari wrote:
> This is a REDO of the Fix that was incompletely implemented earlier:
> [8285838: Fix for TZ environment variable DST
> rules](https://github.com/openjdk/jdk/pull/8660)
>
> Offset calculation now accounts all the way upto year in order
On Thu, 30 Jun 2022 18:29:42 GMT, Gaurav Chaudhari wrote:
> One more thing to note/I'd like to make sure is what the output looks like
> when TZ is GMT. Want to ensure that the final string being passed down is
> just "GMT" and that `strftime` invocation returns an empty result. If the
> resul
On Thu, 30 Jun 2022 18:32:56 GMT, Gaurav Chaudhari wrote:
>> This is a REDO of the Fix that was incompletely implemented earlier:
>> [8285838: Fix for TZ environment variable DST
>> rules](https://github.com/openjdk/jdk/pull/8660)
>>
>> Offset calculation now accounts all the way upto year in o
Trivial fix to currency data files. The change was only made to its amendment
number, as the new Sierra Leone currency has already been active with amendment
171.
-
Commit messages:
- 8289549: ISO 4217 Amendment 172 Update
Changes: https://git.openjdk.org/jdk19/pull/96/files
Webr
On Thu, 30 Jun 2022 22:05:38 GMT, Naoto Sato wrote:
> Trivial fix to currency data files. The change was only made to its amendment
> number, as the new Sierra Leone currency has already been active with
> amendment 171.
This pull request has now been integrated.
Changeset: 604ea9
On Sat, 30 Apr 2022 09:45:07 GMT, Andrey Turbanov wrote:
> The method `sun.nio.cs.ext.AbstractCharsetProvider#put` is effectively
> equivalent of `Map.putIfAbsent` call.
>
> https://github.com/openjdk/jdk/blob/df063f7db18a40ea7325fe608b3206a6dff812c1/src/jdk.charsets/share/classes/sun/nio/cs/ex
On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeliński wrote:
>> This patch removes many unused variables and one unused label reported by
>> the compilers when relevant warnings are enabled.
>>
>> The unused code was found by compiling after removing `unused` from the list
>> of disabled warnings
On Wed, 6 Jul 2022 14:05:39 GMT, Ichiroh Takiguchi
wrote:
> OpenJDK supports "Japanese EBCDIC - Katakana" and "Korean EBCDIC" SBCS and
> DBCS Only charsets.
> |Charset|Mix|SBCS|DBCS|
> | -- | -- | -- | -- |
> | Japanese EBCDIC - Katakana | Cp930 | Cp290 | Cp300 |
> | Korean | Cp933 | Cp833 | Cp
On Wed, 13 Jul 2022 04:30:39 GMT, Yoshiki Sato wrote:
> Please review this PR. The PR open sources the closed timezone tests.
Please modify the PR title to match the JBS.
-
PR: https://git.openjdk.org/jdk/pull/9476
On Wed, 13 Jul 2022 04:30:39 GMT, Yoshiki Sato wrote:
> Please review this PR. The PR open sources the closed timezone tests.
Marked as reviewed by naoto (Reviewer).
-
PR: https://git.openjdk.org/jdk/pull/9476
On Fri, 15 Jul 2022 12:40:50 GMT, Сергей Цыпанов wrote:
>> Simplify code with `String.join()`
>
> Сергей Цыпанов has updated the pull request incrementally with two additional
> commits since the last revision:
>
> - 8290300: Revert jops
> - 8290300: Revert jops
Changes to `Locale` look good
On Mon, 18 Jul 2022 11:08:24 GMT, Сергей Цыпанов wrote:
> For `Locale` all the call sites of `formatList()` never pass null, so the
> code in `if` block is never executed. I think we can delete this unused parts
> of the code in `Locale`,
Are you sure about this? `pattern` is derived from
`Lo
On Mon, 18 Jul 2022 18:40:51 GMT, Сергей Цыпанов wrote:
>> Simplify code with `String.join()`
>
> Сергей Цыпанов has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8290300: Revert erroneous changes
Marked as reviewed by naoto (Reviewer).
---
This PR is to propose supporting the `T` extension to the BCP 47 to which
`java.util.Locale` class conforms. There are two extensions to the BCP 47, one
is `Unicode Locale Extension` which has been supported since JDK7, the other is
this `Transformed Content` extension. A CSR has also been draft
CSR has also been drafted.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Removed unnecessary `contains()` check
-
Changes:
- all: https://git.openjdk.org/jdk/pull/9620/files
- new: https://git.openjdk.org/jdk/pul
On Sat, 23 Jul 2022 03:03:25 GMT, Alisen Chung wrote:
> open l10n msg drop
> All tests passed.
Changes requested by naoto (Reviewer).
src/java.base/share/classes/sun/util/resources/CurrencyNames_de.properties line
63:
> 61: # written authorization of the copyright holder.
> 62:
> 63: ADP=ADP
CSR has also been drafted.
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 12 additional commits since the
last revision:
- Modified ja
On Tue, 26 Jul 2022 01:07:29 GMT, Joe Wang wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed unnecessary `contains()` check
>
> src/java.base/share/classes/java/util/L
On Tue, 26 Jul 2022 19:03:24 GMT, Joe Wang wrote:
>> Naoto Sato has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 12 additional
CSR has also been drafted.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Removed convenient APIs for now
-
Changes:
- all: https://git.openjdk.org/jdk/pull/9620/files
- new: https://git.openjdk.org/jdk/pull/9620/fi
On Tue, 26 Jul 2022 18:41:57 GMT, Roger Riggs wrote:
> I would suggest deferring the APIs for `getTransformedContentFields()` and
> `getTransformedContentSource()`.
OK, removed those two convenient APIs.
-
PR: https://git.openjdk.org/jdk/pull/9620
Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy
came from the mapping difference between MS and IBM.
-
Commit messages:
- Fix 0x25 c2b in IBM864
Changes: https://git.openjdk.org/jdk/pull/9661/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9661&
On Wed, 27 Jul 2022 20:18:16 GMT, Gaurav Chaudhari wrote:
>> This is a REDO of the Fix that was incompletely implemented earlier:
>> [8285838: Fix for TZ environment variable DST
>> rules](https://github.com/openjdk/jdk/pull/8660)
>>
>> Offset calculation now accounts all the way upto year in o
On Thu, 28 Jul 2022 00:58:59 GMT, Ichiroh Takiguchi
wrote:
>> Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy
>> came from the mapping difference between MS and IBM.
>
> Hello @naotoj .
> I'm not reviewer, but I'd like to test this change.
> Could you wait for a mom
On Thu, 28 Jul 2022 10:29:07 GMT, Ichiroh Takiguchi
wrote:
>> @takiguc Sure. Appreciate it.
>
> Many thanks @naotoj .
>
> I checked the latest IBM-864 mapping table.
> (I assume current OpenJDK's IBM864 may refer older mapping table)
> https://raw.githubusercontent.com/unicode-org/icu/main/icu4
On Tue, 26 Jul 2022 20:31:44 GMT, Alisen Chung wrote:
>> open l10n msg drop
>> All tests passed.
>
> Alisen Chung has updated the pull request incrementally with one additional
> commit since the last revision:
>
> removed localized files from base
-
src/jdk.localedata/share/classes/sun/uti
On Wed, 27 Jul 2022 17:47:36 GMT, Naoto Sato wrote:
> Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy
> came from the mapping difference between MS and IBM.
Sorry, but I don't have any intention to change the current roundtrip behavior
of 0x25 <-
On Thu, 28 Jul 2022 19:43:04 GMT, Gaurav Chaudhari wrote:
>> This is a REDO of the Fix that was incompletely implemented earlier:
>> [8285838: Fix for TZ environment variable DST
>> rules](https://github.com/openjdk/jdk/pull/8660)
>>
>> Offset calculation now accounts all the way upto year in o
CSR has also been drafted.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Parse invalid fields correctly
-
Changes:
- all: https://git.openjdk.org/jdk/pull/9620/files
- new: https://git.openjdk.org/jdk/pull/9620/fi
CSR has also been drafted.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Use `assertThrows`
-
Changes:
- all: https://git.openjdk.org/jdk/pull/9620/files
- new: https://git.openjdk.org/jdk/pull/9620/files/d3242b
On Sat, 30 Jul 2022 01:39:54 GMT, Joe Wang wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Parse invalid fields correctly
>
> test/jdk/java/util/Locale/bcp47/TExtensionTests.java line 1
On Fri, 29 Jul 2022 18:13:25 GMT, Alisen Chung wrote:
>> open l10n msg drop
>> All tests passed.
>
> Alisen Chung has updated the pull request incrementally with one additional
> commit since the last revision:
>
> added comments in CurrencyNames root in base, moved US CurrencyNames back
> t
On Sat, 30 Jul 2022 20:52:49 GMT, Naoto Sato wrote:
>> This PR is to propose supporting the `T` extension to the BCP 47 to which
>> `java.util.Locale` class conforms. There are two extensions to the BCP 47,
>> one is `Unicode Locale Extension` which has been supported since J
On Tue, 2 Aug 2022 08:35:51 GMT, Alan Bateman wrote:
>> Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy
>> came from the mapping difference between MS and IBM.
>
> test/jdk/java/beans/XMLEncoder/Test4625418.java line 26:
>
>> 24: /*
>> 25: * @test
>> 26: * @bug 46
On Wed, 27 Jul 2022 17:47:36 GMT, Naoto Sato wrote:
> Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy
> came from the mapping difference between MS and IBM.
This pull request has now been integrated.
Changeset: e52a340d
Author: Naoto Sato
URL:
On Wed, 3 Aug 2022 14:08:26 GMT, Ichiroh Takiguchi
wrote:
> I'm not sure if this change will solve the reporter's issue...
It does solve the submitter's issue. With this fix:
jshell> HexFormat.ofDelimiter(" ").formatHex("<%adc".getBytes("IBM864"))
$181 ==> "3c 25 61 64 63"
which is exactly th
On Wed, 3 Aug 2022 13:55:04 GMT, Daniel Jeliński wrote:
> This patch fixes the test to use the same locale as the tested code
LGTM. Thanks for the fix!
-
Marked as reviewed by naoto (Reviewer).
PR: https://git.openjdk.org/jdk/pull/9729
On Fri, 5 Aug 2022 02:15:21 GMT, Ichiroh Takiguchi
wrote:
> To support Windows command prompt's codepage, following charsets should be
> moved from jdk.charsets module to java.base module.
>
> - IBM860
> - IBM861
> - IBM863
> - IBM864
> - IBM865
> - IBM869
Hi @takiguc,
I am not quite sure wha
On Fri, 5 Aug 2022 02:15:21 GMT, Ichiroh Takiguchi
wrote:
> To support Windows command prompt's codepage, following charsets should be
> moved from jdk.charsets module to java.base module.
>
> - IBM860
> - IBM861
> - IBM863
> - IBM864
> - IBM865
> - IBM869
I looked at this issue a bit more. I
This is to enhance the character break analysis in `java.text.BreakIterator` to
conform to the extended grapheme cluster boundaries defined in
https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A
corresponding CSR has also been drafted, as there will be behavioral changes
with t
On Tue, 23 Aug 2022 22:44:13 GMT, Naoto Sato wrote:
> This is to enhance the character break analysis in `java.text.BreakIterator`
> to conform to the extended grapheme cluster boundaries defined in
> https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A
> correspon
On Thu, 25 Aug 2022 03:52:48 GMT, Stuart Marks wrote:
>> This is to enhance the character break analysis in `java.text.BreakIterator`
>> to conform to the extended grapheme cluster boundaries defined in
>> https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A
>> corresponding CS
e behavioral changes
> with this modification.
Naoto Sato has updated the pull request incrementally with two additional
commits since the last revision:
- Fixing JCK failures
- Addressing review comments
-
Changes:
- all: https://git.openjdk.org/jdk/pull/9991/files
e behavioral changes
> with this modification.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Reverting the fix to BreakIterator.isBoundary()
-
Changes:
- all: https://git.openjdk.org/jdk/pull/9991/files
- new: https://
On Fri, 26 Aug 2022 18:12:04 GMT, Naoto Sato wrote:
>> This is to enhance the character break analysis in `java.text.BreakIterator`
>> to conform to the extended grapheme cluster boundaries defined in
>> https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A
&g
e behavioral changes
> with this modification.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Changed the paragraph to @implSpec
-
Changes:
- all: https://git.openjdk.org/jdk/pull/9991/files
- new: https://git.openjdk.or
On Fri, 26 Aug 2022 20:57:05 GMT, Stuart Marks wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reverting the fix to BreakIterator.isBoundary()
>
> src/java.base/share/classes/java/te
On Wed, 24 Aug 2022 19:31:23 GMT, Andrey Turbanov wrote:
> Couple of package-private classes in `java.text` package still use
> `StringBuffer`: `MergeCollation` and `PatternEntry`.
> StringBuffer is a legacy synchronized class. StringBuilder is a direct
> replacement to StringBuffer which gener
On Wed, 24 Aug 2022 19:22:51 GMT, Andrey Turbanov wrote:
> Field `java.text.DateFormatSymbols#millisPerHour` is unused. It was unused in
> initial OpenJDK sources.
This looks good too.
-
Marked as reviewed by naoto (Reviewer).
PR: https://git.openjdk.org/jdk/pull/10005
On Fri, 22 Jul 2022 21:53:35 GMT, Naoto Sato wrote:
> This PR is to propose supporting the `T` extension to the BCP 47 to which
> `java.util.Locale` class conforms. There are two extensions to the BCP 47,
> one is `Unicode Locale Extension` which has been supported since JDK7, the
&
Simple doc fix.
-
Commit messages:
- 8293154: TemporalQueries java doc error
Changes: https://git.openjdk.org/jdk/pull/10103/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10103&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8293154
Stats: 3 lines in 1 file changed
On Wed, 31 Aug 2022 17:08:28 GMT, Naoto Sato wrote:
> Simple doc fix.
This pull request has now been integrated.
Changeset: 6a1b0b56
Author: Naoto Sato
URL:
https://git.openjdk.org/jdk/commit/6a1b0b5649dd4f2a970df0839bf77bdb899fbd6f
Stats: 3 lines in 1 file changed: 0 ins; 0
On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato wrote:
> Please review this PR. The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.
LGTM
-
Marked as reviewed by naoto (Rev
Fixed the max week number on parsing the week of week-based year field in
strict mode. It used to be always returning the largest maximum, which should
be adjusted by the actual week-based year.
-
Commit messages:
- 8293146: Strict DateTimeFormatter fails to report an invalid week
> Fixed the max week number on parsing the week of week-based year field in
> strict mode. It used to be always returning the largest maximum, which should
> be adjusted by the actual week-based year.
Naoto Sato has updated the pull request with a new target base due to a merge
or
On Tue, 6 Sep 2022 17:30:27 GMT, Naoto Sato wrote:
> Fixed the max week number on parsing the week of week-based year field in
> strict mode. It used to be always returning the largest maximum, which should
> be adjusted by the actual week-based year.
This pull request has now been i
e behavioral changes
> with this modification.
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 ten additional commits since the
last revision:
On Wed, 7 Sep 2022 21:27:10 GMT, Stuart Marks wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Changed the paragraph to @implSpec
>
> src/java.base/share/classes/jdk/internal/ut
e behavioral changes
> with this modification.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Removed unnecessary comments
-
Changes:
- all: https://git.openjdk.org/jdk/pull/9991/files
- new: https://git.openjdk.org/jdk/
On Tue, 23 Aug 2022 22:44:13 GMT, Naoto Sato wrote:
> This is to enhance the character break analysis in `java.text.BreakIterator`
> to conform to the extended grapheme cluster boundaries defined in
> https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A
> correspon
On Fri, 5 Aug 2022 02:15:21 GMT, Ichiroh Takiguchi
wrote:
> To support Windows command prompt's codepage, following charsets should be
> moved from jdk.charsets module to java.base module.
>
> - IBM860
> - IBM861
> - IBM863
> - IBM864
> - IBM865
> - IBM869
Considering those code page encoding
On Thu, 25 Aug 2022 02:26:19 GMT, Yoshiki Sato wrote:
> Please review this PR. The PR adopts the official tzdata2022c as it is.
> It means the pre-1970s data merged in tzdata2022c doesn't exist.
> All tests have been passed with no failures.
Names are retrieved through aliases, so I think there
Fixing JCK failures caused by the new grapheme implementation. The length of a
CharSequence should return the `endIndex`, not `endIndex - beginIndex`.
-
Commit messages:
- 8294008: Graphme implementation of setText() throws IndexOutOfBoundsException
Changes: https://git.openjdk.org
On Mon, 19 Sep 2022 20:46:08 GMT, Joe Wang wrote:
>> Fixing JCK failures caused by the new grapheme implementation. The length of
>> a CharSequence should return the `endIndex`, not `endIndex - beginIndex`.
>
> src/java.base/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java
>
> Fixing JCK failures caused by the new grapheme implementation. The length of
> a CharSequence should return the `endIndex`, not `endIndex - beginIndex`.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Added comments to
On Mon, 19 Sep 2022 22:07:13 GMT, Joe Wang wrote:
>> It's somewhat confusing as this class adapts `CharacterIterator` into
>> `CharSequence` which are similar to each other (thus the bug). Those
>> `beginIndex`/`endIndex` designate the range in the source
>> `CharacterIterator`, and this `leng
> Fixing JCK failures caused by the new grapheme implementation. The length of
> a CharSequence should return the `endIndex`, not `endIndex - beginIndex`.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Refine the comments by
On Mon, 19 Sep 2022 23:04:12 GMT, Stuart Marks wrote:
>> Thanks, Joe. Added comment to the method.
>
> OK yeah this is really confusing. One might ask a similar question in
> `charAt` about why it doesn't call
>
> src.setIndex(index + src.getBeginIndex());
>
> The answer is that this is a
On Mon, 19 Sep 2022 19:01:57 GMT, Naoto Sato wrote:
> Fixing JCK failures caused by the new grapheme implementation. The length of
> a CharSequence should return the `endIndex`, not `endIndex - beginIndex`.
This pull request has now been integrated.
Changeset: e3358e77
Author: Naot
On Mon, 26 Sep 2022 18:25:34 GMT, Justin Lu wrote:
> Problem: Unnecessary instances of StringBuffer + .toString()
>
> Fix: StringBuffer Replaced with StringBuilder, and .toString() removed when
> possible
>
> Other: Line 698 in RuleBasedCollator.java also uses a .toString() conversion,
> but
On Mon, 26 Sep 2022 19:12:16 GMT, Andrey Turbanov wrote:
> Found this redundant suppressions by IntelliJ IDEA inspection.
> Seems initially `Chronology` was generic class?
+1
-
Marked as reviewed by naoto (Reviewer).
PR: https://git.openjdk.org/jdk/pull/10433
On Wed, 28 Sep 2022 22:54:33 GMT, Justin Lu wrote:
> Problem: Unnecessary instances of StringBuffer within java.text (internal
> only)
>
> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method
> names
AFAICT, the reason is described in the test class description, i.e., t
On Thu, 29 Sep 2022 22:19:26 GMT, Lance Andersen wrote:
> Understand, I guess I don't see the difference from moving the tags to the
> actual test but there could be a subtlety I am missing (wouldn't be the first
> time ;-) )
The runner has a @library/@build tag to build the test case as a lib
On Wed, 28 Sep 2022 03:40:06 GMT, Yoshiki Sato wrote:
> Please review this PR. The change include some code changes in
> ZoneInfoFile.java and TestZoneInfo310.java since tzdata2022d breaks
> TestZoneInfo310.java.
Some minor comments
src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.
On Fri, 30 Sep 2022 00:25:24 GMT, Lance Andersen wrote:
> > > Understand, I guess I don't see the difference from moving the tags to
> > > the actual test but there could be a subtlety I am missing (wouldn't be
> > > the first time ;-) )
> >
> >
> > The runner has a @library/@build tag to bui
On Wed, 28 Sep 2022 03:40:06 GMT, Yoshiki Sato wrote:
> Please review this PR. The change include some code changes in
> ZoneInfoFile.java and TestZoneInfo310.java since tzdata2022d breaks
> TestZoneInfo310.java.
test/jdk/java/util/TimeZone/TimeZoneData/displaynames.txt line 170:
> 168: Euro
On Wed, 28 Sep 2022 03:40:06 GMT, Yoshiki Sato wrote:
> Please review this PR. The change include some code changes in
> ZoneInfoFile.java and TestZoneInfo310.java since tzdata2022d breaks
> TestZoneInfo310.java.
Marked as reviewed by naoto (Reviewer).
-
PR: https://git.openjdk.
On Fri, 30 Sep 2022 04:54:27 GMT, Yoshiki Sato wrote:
>> test/jdk/java/util/TimeZone/TimeZoneData/displaynames.txt line 170:
>>
>>> 168: Europe/Vilnius EET EEST
>>> 169: Europe/Warsaw CET CEST
>>> 170: Europe/Zaporozhye EET EEST
>>
>> Do we need to remove those newly linked zone ids from testin
On Thu, 29 Sep 2022 23:19:16 GMT, Justin Lu wrote:
> Problem: Amendment number outdated
>
> Fix: Update amendment number + date in properties file and test case data file
LGTM
-
Marked as reviewed by naoto (Reviewer).
PR: https://git.openjdk.org/jdk/pull/10499
On Fri, 30 Sep 2022 20:08:10 GMT, Justin Lu wrote:
>> Problem: Unnecessary instances of StringBuffer within java.text (internal
>> only)
>>
>> Fix: StringBuffer Replaced with StringBuilder, and adjusted variable/method
>> names
>
> Justin Lu has updated the pull request incrementally with two
On Tue, 4 Oct 2022 18:42:52 GMT, Justin Lu wrote:
>> src/java.base/share/classes/java/text/DigitList.java line 161:
>>
>>> 159: public final double getDouble() {
>>> 160: if (count == 0) {
>>> 161: return 0.0;
>>
>> The doc for this method is incorrect:
>>
>> * If (coun
On Wed, 5 Oct 2022 22:17:26 GMT, Justin Lu wrote:
> Problem: Unused variables in GregorianCalendar, JapaneseImperialCalendar, and
> Base Calendar.
>
> Fix: Removed all unused variables in bug description except normalizedYear in
> JapaneseImpericalCalendar.getActualMaximum.() as there was no m
Fixed to utilize `StaticProperty` so that the system property value for
`java.locale.useOldISOCodes` set on the command line is honored even with lazy
`Locale` initialization.
-
Commit messages:
- 8295232: "java.locale.useOldISOCodes" property is read lazily
Changes: https://git.o
On Thu, 13 Oct 2022 10:33:32 GMT, Sean Coffey wrote:
>> Fixed to utilize `StaticProperty` so that the system property value for
>> `java.locale.useOldISOCodes` set on the command line is honored even with
>> lazy `Locale` initialization.
>
> src/java.base/share/classes/sun/util/locale/BaseLocal
> Fixed to utilize `StaticProperty` so that the system property value for
> `java.locale.useOldISOCodes` set on the command line is honored even with
> lazy `Locale` initialization.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last
On Wed, 12 Oct 2022 20:03:05 GMT, Naoto Sato wrote:
> Fixed to utilize `StaticProperty` so that the system property value for
> `java.locale.useOldISOCodes` set on the command line is honored even with
> lazy `Locale` initialization.
This pull request has now been integrated.
On Wed, 12 Oct 2022 04:35:08 GMT, David Alvarez wrote:
>> Please, review this PR for an update of timezone data. No changes besides
>> the import were needed.
>
> David Alvarez has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update display
On Fri, 14 Oct 2022 20:38:32 GMT, Justin Lu wrote:
> Issue: Formatter unit tests are launched via basic.sh
>
> Fix: Replace basic.sh with a Java test launcher
>
> Note: Java.internal.math was included in the original configuration of Basic,
> but I removed it as it was not used within the Basi
Plurals were determined only by looking at the integer part of the compact
number. Changed to consider the fraction digits as well.
-
Commit messages:
- 8295372: CompactNumberFormat handling of number one with decimal part
Changes: https://git.openjdk.org/jdk/pull/10748/files
Webr
1 - 100 of 1164 matches
Mail list logo
