NormalizedCustomID:

> 108:  * NormalizedCustomID:
> 109:  *         {@code GMT} Sign TwoDigitHours {@code :} Minutes [Seconds]

Hello Naoto,

Should this instead be: `... Minutes [{@code :} Seconds]` - i.e. should it have the `:` literal if seconds are present in the custom timezone id?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8606

From jpai at openjdk.java.net  Tue May 10 14:24:00 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 10 May 2022 14:24:00 GMT
Subject:  RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does
 not work for all ZoneOffsets and returns GMT unexpected
In-Reply-To: 
References: 
Message-ID: 

On Mon, 9 May 2022 18:59:43 GMT, Naoto Sato  wrote:

> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support second-level resolution, enabling round trips with `java.time.ZoneOffset`s. Corresponding CSR is also being drafted.

src/java.base/share/classes/java/util/TimeZone.java line 543:

> 541:             return new ZoneInfo(totalSecs == 0 ? "UTC" : GMT_ID + tzid, totalSecs);
> 542:         } else {
> 543:             return getTimeZone(tzid, true);

Before the change in this PR, we used to prefix `GMT` to (non-custom timezone ids) if the timezone id returned by `ZoneId#getId()` started with the `+` or `-` sign, before calling `getTimeZone(modifiedTzid, true)`. 
With this change, for `ZoneId`s that aren't `ZoneOffset` instance, we now call `getTimeZone(originalTzid, true)`, without first checking/prefixing the id with `GMT`. Is that an intentional change and would that potentially cause `getTimeZone(String, boolean)` to return a different result?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8606

From naoto at openjdk.java.net  Tue May 10 17:38:44 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 10 May 2022 17:38:44 GMT
Subject:  RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does
 not work for all ZoneOffsets and returns GMT unexpected [v2]
In-Reply-To: 
References: 
Message-ID: 

> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support second-level resolution, enabling round trips with `java.time.ZoneOffset`s. Corresponding CSR is also being drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Fixed offsets in milliseconds, added test variations, refined Custom ID definitions

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8606/files
  - new: https://git.openjdk.java.net/jdk/pull/8606/files/843e86be..81a806e5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8606&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8606&range=00-01

  Stats: 13 lines in 2 files changed: 3 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8606.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8606/head:pull/8606

PR: https://git.openjdk.java.net/jdk/pull/8606

From naoto at openjdk.java.net  Tue May 10 17:46:55 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 10 May 2022 17:46:55 GMT
Subject:  RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does
 not work for all ZoneOffsets and returns GMT unexpected [v2]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 10 May 2022 13:12:10 GMT, Jaikiran Pai  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed offsets in milliseconds, added test variations, refined Custom ID definitions
>
> src/java.base/share/classes/java/util/TimeZone.java line 109:
> 
>> 107:  * >> 108:  * NormalizedCustomID:
>> 109:  *         {@code GMT} Sign TwoDigitHours {@code :} Minutes [Seconds]
> 
> Hello Naoto,
> 
> Should this instead be: `... Minutes [{@code :} Seconds]` - i.e. should it have the `:` literal if seconds are present in the custom timezone id?

The colon is included in `Seconds` part below. I changed the part name to `ColonSeconds` to make it clearer.

> src/java.base/share/classes/java/util/TimeZone.java line 543:
> 
>> 541:             return new ZoneInfo(totalSecs == 0 ? "UTC" : GMT_ID + tzid, totalSecs);
>> 542:         } else {
>> 543:             return getTimeZone(tzid, true);
> 
> Before the change in this PR, we used to prefix `GMT` to (non-custom timezone ids) if the timezone id returned by `ZoneId#getId()` started with the `+` or `-` sign, before calling `getTimeZone(modifiedTzid, true)`. 
> With this change, for `ZoneId`s that aren't `ZoneOffset` instance, we now call `getTimeZone(originalTzid, true)`, without first checking/prefixing the id with `GMT`. Is that an intentional change and would that potentially cause `getTimeZone(String, boolean)` to return a different result?

Yes, it is intentional. The `Time-zone IDs` section in the `ZoneId` class description is clear that zone id starting with "+/-" is a `ZoneOffset` instance. Other ZoneIds should have offsets with prefix or region-based ids.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8606

From naoto at openjdk.java.net  Tue May 10 17:46:58 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 10 May 2022 17:46:58 GMT
Subject:  RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does
 not work for all ZoneOffsets and returns GMT unexpected [v2]
In-Reply-To: 
References: 

Message-ID: 

On Mon, 9 May 2022 22:29:50 GMT, Uwe Schindler  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed offsets in milliseconds, added test variations, refined Custom ID definitions
>
> src/java.base/share/classes/java/util/TimeZone.java line 539:
> 
>> 537:     public static TimeZone getTimeZone(ZoneId zoneId) {
>> 538:         String tzid = zoneId.getId(); // throws an NPE if null
>> 539:         if (zoneId instanceof ZoneOffset zo) {
> 
> I like this because it is much faster than the conversion to ZoneId and parsing it back! It is similar to use of SimpleTimeZone, but this is better as the returned timezone is unmodifiable, correct?

Yes, and it aligns with the other call site (line 588).

> test/jdk/java/util/TimeZone/ZoneOffsetRoundTripTest.java line 43:
> 
>> 41:     private Object[][] testZoneOffsets() {
>> 42:         return new Object[][] {
>> 43:                 {ZoneId.of("Z"), 0},
> 
> I know, `ZoneId.of()` should parse this as a `ZoneOffset` and return a `ZoneOffset` instance, but maybe add also the other string variants with prefix (`ZoneId.of("UTC+00:00:01")` or `ZoneId.of("GMT+00:00:01")` as data items. Maybe also use `ZoneOffset.of()` for the plain zones to be explicit.

Added them except "UTC+...", as it is not recognizable as a Custom ID.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8606

From rriggs at openjdk.java.net  Tue May 10 21:38:19 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 10 May 2022 21:38:19 GMT
Subject:  RFR: 8286378: Address possibly lossy conversions in
 java.base
Message-ID: 

PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
>From the CSR:

"If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."

This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
Since these casts are truncating the value, there might be a different refactoring that avoids the cast
but a direct replacement was chosen here.

(Advise and suggestions will inform similar updates to other OpenJDK modules).

-------------

Commit messages:
 - 8286378: Address possibly lossy conversions in java.base

Changes: https://git.openjdk.java.net/jdk/pull/8642/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8642&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286378
  Stats: 57 lines in 33 files changed: 1 ins; 3 del; 53 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8642.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8642/head:pull/8642

PR: https://git.openjdk.java.net/jdk/pull/8642

From naoto at openjdk.java.net  Tue May 10 22:02:49 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 10 May 2022 22:02:49 GMT
Subject:  RFR: 8286378: Address possibly lossy conversions in
 java.base
In-Reply-To: 
References: 
Message-ID: 

On Tue, 10 May 2022 21:32:10 GMT, Roger Riggs  wrote:

> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
> From the CSR:
> 
> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
> 
> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
> but a direct replacement was chosen here.
> 
> (Advise and suggestions will inform similar updates to other OpenJDK modules).

Looks good. Assuming copyright years will be updated.

src/java.base/share/classes/java/time/es line 1:

> 1: X

Looks like a random file was added by accident?

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8642

From xuelei at openjdk.java.net  Tue May 10 22:16:47 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 10 May 2022 22:16:47 GMT
Subject:  RFR: 8286378: Address possibly lossy conversions in
 java.base
In-Reply-To: 
References: 
Message-ID: <7lDCcjqL3nlin4_E8rebEkaoQ96_Tz2jbarFVJVF3PY=.88a6da8e-6f79-4889-88f3-4248037609e1@github.com>

On Tue, 10 May 2022 21:32:10 GMT, Roger Riggs  wrote:

> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
> From the CSR:
> 
> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
> 
> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
> but a direct replacement was chosen here.
> 
> (Advise and suggestions will inform similar updates to other OpenJDK modules).

The update in security area looks good to me.

-------------

Marked as reviewed by xuelei (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8642

From bpb at openjdk.java.net  Tue May 10 22:57:49 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 10 May 2022 22:57:49 GMT
Subject:  RFR: 8286378: Address possibly lossy conversions in
 java.base
In-Reply-To: 
References: 
Message-ID: <7I3Y3hwAO8Sirtab0JkW7SPyjqZlDAhGciKVD47qXOE=.22ddd9bd-1491-4b39-94ed-de1977181c1f@github.com>

On Tue, 10 May 2022 21:32:10 GMT, Roger Riggs  wrote:

> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
> From the CSR:
> 
> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
> 
> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
> but a direct replacement was chosen here.
> 
> (Advise and suggestions will inform similar updates to other OpenJDK modules).

IO, math, and NIO changes look fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8642

From rriggs at openjdk.java.net  Tue May 10 23:01:33 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 10 May 2022 23:01:33 GMT
Subject:  RFR: 8286378: Address possibly lossy conversions in
 java.base [v2]
In-Reply-To: 
References: 
Message-ID: 

> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
> From the CSR:
> 
> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
> 
> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
> but a direct replacement was chosen here.
> 
> (Advise and suggestions will inform similar updates to other OpenJDK modules).

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  remove stray file

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8642/files
  - new: https://git.openjdk.java.net/jdk/pull/8642/files/e72ce85c..7ff806a5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8642&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8642&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8642.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8642/head:pull/8642

PR: https://git.openjdk.java.net/jdk/pull/8642

From alanb at openjdk.java.net  Wed May 11 05:26:39 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 11 May 2022 05:26:39 GMT
Subject:  RFR: 8286378: Address possibly lossy conversions in
 java.base [v2]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 10 May 2022 23:01:33 GMT, Roger Riggs  wrote:

>> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
>> From the CSR:
>> 
>> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
>> 
>> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
>> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
>> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
>> but a direct replacement was chosen here.
>> 
>> (Advise and suggestions will inform similar updates to other OpenJDK modules).
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove stray file

src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 128:

> 126:                     // timed poll interrupted so need to adjust timeout
> 127:                     long adjust = System.nanoTime() - startTime;
> 128:                     to -= (int)TimeUnit.MILLISECONDS.convert(adjust, TimeUnit.NANOSECONDS);

Can we change this `to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);` while we here?

src/java.base/share/classes/jdk/internal/org/objectweb/asm/Frame.java line 615:

> 613:         if (outputStackTop >= elements) {
> 614:             outputStackTop -= (short)elements;
> 615:         } else {

I think we usually try to avoid changing the ASM code if possible but maybe you have to do this because the compiler option is used for compiling java.base?

src/java.base/unix/classes/sun/nio/ch/PollSelectorImpl.java line 123:

> 121:                     // timed poll interrupted so need to adjust timeout
> 122:                     long adjust = System.nanoTime() - startTime;
> 123:                     to -= (int)TimeUnit.MILLISECONDS.convert(adjust, TimeUnit.NANOSECONDS);

This one can also be changed to:

`to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);`

-------------

PR: https://git.openjdk.java.net/jdk/pull/8642

From uschindler at openjdk.java.net  Wed May 11 07:56:37 2022
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Wed, 11 May 2022 07:56:37 GMT
Subject:  RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does
 not work for all ZoneOffsets and returns GMT unexpected [v2]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 10 May 2022 17:43:24 GMT, Naoto Sato  wrote:

>> src/java.base/share/classes/java/util/TimeZone.java line 543:
>> 
>>> 541:             return new ZoneInfo(totalSecs == 0 ? "UTC" : GMT_ID + tzid, totalSecs);
>>> 542:         } else {
>>> 543:             return getTimeZone(tzid, true);
>> 
>> Before the change in this PR, we used to prefix `GMT` to (non-custom timezone ids) if the timezone id returned by `ZoneId#getId()` started with the `+` or `-` sign, before calling `getTimeZone(modifiedTzid, true)`. 
>> With this change, for `ZoneId`s that aren't `ZoneOffset` instance, we now call `getTimeZone(originalTzid, true)`, without first checking/prefixing the id with `GMT`. Is that an intentional change and would that potentially cause `getTimeZone(String, boolean)` to return a different result?
>
> Yes, it is intentional. The `Time-zone IDs` section in the `ZoneId` class description is clear that zone id starting with "+/-" is a `ZoneOffset` instance. Other ZoneIds should have offsets with prefix or region-based ids.

I was stumbling on this, too, but it is only ZoneOffset isntances that have those strange names without GMT/UTC prefix. Default ZoneId instances created from text strings always have a prefix. If you call ZoneId.of() with an offset only and no prefix it returns a ZoneOffset instance (see the test).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8606

From asotona at openjdk.java.net  Wed May 11 08:06:39 2022
From: asotona at openjdk.java.net (Adam Sotona)
Date: Wed, 11 May 2022 08:06:39 GMT
Subject:  RFR: 8286378: Address possibly lossy conversions in
 java.base [v2]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 10 May 2022 23:01:33 GMT, Roger Riggs  wrote:

>> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
>> From the CSR:
>> 
>> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
>> 
>> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
>> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
>> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
>> but a direct replacement was chosen here.
>> 
>> (Advise and suggestions will inform similar updates to other OpenJDK modules).
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove stray file

I can confirm this patch clears all warnings from java.base.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8642

From scolebourne at openjdk.java.net  Wed May 11 08:16:40 2022
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Wed, 11 May 2022 08:16:40 GMT
Subject:  RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does
 not work for all ZoneOffsets and returns GMT unexpected [v2]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 10 May 2022 17:43:07 GMT, Naoto Sato  wrote:

>> test/jdk/java/util/TimeZone/ZoneOffsetRoundTripTest.java line 43:
>> 
>>> 41:     private Object[][] testZoneOffsets() {
>>> 42:         return new Object[][] {
>>> 43:                 {ZoneId.of("Z"), 0},
>> 
>> I know, `ZoneId.of()` should parse this as a `ZoneOffset` and return a `ZoneOffset` instance, but maybe add also the other string variants with prefix (`ZoneId.of("UTC+00:00:01")` or `ZoneId.of("GMT+00:00:01")` as data items. Maybe also use `ZoneOffset.of()` for the plain zones to be explicit.
>
> Added them except "UTC+...", as it is not recognizable as a Custom ID.

Can the test cover `UT` prefix as well? (This is another valid prefix in `ZoneId`)

If this PR isn't meant to work with UTC prefix, can a test be added that proves it does *not* work.

ie. all these are valid in `ZoneId` - "Z", "UTC", "GMT", "UT", "UTC+01:00", "GMT+01:00", "UT+01:00" - and all should have some form of associated test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8606

From uschindler at openjdk.java.net  Wed May 11 08:36:35 2022
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Wed, 11 May 2022 08:36:35 GMT
Subject:  RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does
 not work for all ZoneOffsets and returns GMT unexpected [v2]
In-Reply-To: 
References: 

Message-ID: <0w73_YddkD3sWCUqC6EsEue-oOCZyxvPqWJA2QSZgCY=.8700718e-64b2-4781-8e54-f5e5a838291d@github.com>

On Wed, 11 May 2022 08:10:56 GMT, Stephen Colebourne  wrote:

>> Added them except "UTC+...", as it is not recognizable as a Custom ID.
>
> Can the test cover `UT` prefix as well? (This is another valid prefix in `ZoneId`)
> 
> If this PR isn't meant to work with UTC prefix, can a test be added that proves it does *not* work.
> 
> ie. all these are valid in `ZoneId` - "Z", "UTC", "GMT", "UT", "UTC+01:00", "GMT+01:00", "UT+01:00" - and all should have some form of associated test.

I tried it out: If you create a ZoneId with prefixes "UT" and "UTC", they fail to convert to TimeZone. Same happens if you use this as String name in `TimeZone#getTimeZone(String)`. This is another bug / missing feature! It does not work with or without this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8606

From uschindler at openjdk.java.net  Wed May 11 09:04:46 2022
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Wed, 11 May 2022 09:04:46 GMT
Subject:  RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does
 not work for all ZoneOffsets and returns GMT unexpected [v2]
In-Reply-To: <0w73_YddkD3sWCUqC6EsEue-oOCZyxvPqWJA2QSZgCY=.8700718e-64b2-4781-8e54-f5e5a838291d@github.com>
References: 

 <0w73_YddkD3sWCUqC6EsEue-oOCZyxvPqWJA2QSZgCY=.8700718e-64b2-4781-8e54-f5e5a838291d@github.com>
Message-ID: 

On Wed, 11 May 2022 08:32:48 GMT, Uwe Schindler  wrote:

>> Can the test cover `UT` prefix as well? (This is another valid prefix in `ZoneId`)
>> 
>> If this PR isn't meant to work with UTC prefix, can a test be added that proves it does *not* work.
>> 
>> ie. all these are valid in `ZoneId` - "Z", "UTC", "GMT", "UT", "UTC+01:00", "GMT+01:00", "UT+01:00" - and all should have some form of associated test.
>
> I tried it out: If you create a ZoneId with prefixes "UT" and "UTC", they fail to convert to TimeZone. Same happens if you use this as String name in `TimeZone#getTimeZone(String)`. This is another bug / missing feature! It does not work with or without this PR.

In short, we can only test what works. The test was mainly added to allow roundtrips of `ZoneOffset` instances.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8606

From rriggs at openjdk.java.net  Wed May 11 16:30:41 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 11 May 2022 16:30:41 GMT
Subject:  RFR: 8286378: Address possibly lossy conversions in
 java.base [v3]
In-Reply-To: 
References: 
Message-ID: 

> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
> From the CSR:
> 
> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
> 
> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
> but a direct replacement was chosen here.
> 
> (Advise and suggestions will inform similar updates to other OpenJDK modules).

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Updated copyrights
  Fixed cast style to add a space after cast, (where consistent with file style)
  Improved code per review comments in PollSelectors.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8642/files
  - new: https://git.openjdk.java.net/jdk/pull/8642/files/7ff806a5..a6679ce7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8642&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8642&range=01-02

  Stats: 41 lines in 24 files changed: 0 ins; 0 del; 41 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8642.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8642/head:pull/8642

PR: https://git.openjdk.java.net/jdk/pull/8642

From naoto at openjdk.java.net  Wed May 11 16:37:34 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 11 May 2022 16:37:34 GMT
Subject:  RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does
 not work for all ZoneOffsets and returns GMT unexpected [v3]
In-Reply-To: 
References: 
Message-ID: 

> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support second-level resolution, enabling round trips with `java.time.ZoneOffset`s. Corresponding CSR is also being drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Allowed round-trips for offset-style ZoneIds.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8606/files
  - new: https://git.openjdk.java.net/jdk/pull/8606/files/81a806e5..fcdaf512

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8606&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8606&range=01-02

  Stats: 133 lines in 3 files changed: 70 ins; 61 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8606.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8606/head:pull/8606

PR: https://git.openjdk.java.net/jdk/pull/8606

From naoto at openjdk.java.net  Wed May 11 16:40:48 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 11 May 2022 16:40:48 GMT
Subject:  RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does
 not work for all ZoneOffsets and returns GMT unexpected [v3]
In-Reply-To: 
References: 

 <0w73_YddkD3sWCUqC6EsEue-oOCZyxvPqWJA2QSZgCY=.8700718e-64b2-4781-8e54-f5e5a838291d@github.com>

Message-ID: 

On Wed, 11 May 2022 09:00:45 GMT, Uwe Schindler  wrote:

>> I tried it out: If you create a ZoneId with prefixes "UT" and "UTC", they fail to convert to TimeZone. Same happens if you use this as String name in `TimeZone#getTimeZone(String)`. This is another bug / missing feature! It does not work with or without this PR.
>
> In short, we can only test what works. The test was mainly added to allow roundtrips of `ZoneOffset` instances.

The code intended to allow only offset-style ids that start with `GMT` (which is compatible with TimeZone's CustomID). Now I made changes to allow all offset-style zone ids.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8606

From naoto at openjdk.java.net  Wed May 11 17:04:41 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 11 May 2022 17:04:41 GMT
Subject:  RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does
 not work for all ZoneOffsets and returns GMT unexpected [v4]
In-Reply-To: 
References: 
Message-ID: <1zSZc32pEuDhOtIfc1t1svegXZ_Ty3cUVSBnQkWpIDA=.ef77de25-0da2-4ca0-85a3-4449c46ad870@github.com>

> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support second-level resolution, enabling round trips with `java.time.ZoneOffset`s. Corresponding CSR is also being drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Minor fixup

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8606/files
  - new: https://git.openjdk.java.net/jdk/pull/8606/files/fcdaf512..9722decd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8606&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8606&range=02-03

  Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8606.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8606/head:pull/8606

PR: https://git.openjdk.java.net/jdk/pull/8606

From bpb at openjdk.java.net  Wed May 11 17:11:46 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 11 May 2022 17:11:46 GMT
Subject:  RFR: 8286378: Address possibly lossy conversions in
 java.base [v3]
In-Reply-To: 
References: 

Message-ID: 

On Wed, 11 May 2022 16:30:41 GMT, Roger Riggs  wrote:

>> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
>> From the CSR:
>> 
>> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
>> 
>> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
>> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
>> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
>> but a direct replacement was chosen here.
>> 
>> (Advise and suggestions will inform similar updates to other OpenJDK modules).
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyrights
>   Fixed cast style to add a space after cast, (where consistent with file style)
>   Improved code per review comments in PollSelectors.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8642

From alanb at openjdk.java.net  Wed May 11 19:10:45 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 11 May 2022 19:10:45 GMT
Subject:  RFR: 8286378: Address possibly lossy conversions in
 java.base [v3]
In-Reply-To: 
References: 

Message-ID: 

On Wed, 11 May 2022 16:30:41 GMT, Roger Riggs  wrote:

>> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
>> From the CSR:
>> 
>> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
>> 
>> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
>> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
>> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
>> but a direct replacement was chosen here.
>> 
>> (Advise and suggestions will inform similar updates to other OpenJDK modules).
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyrights
>   Fixed cast style to add a space after cast, (where consistent with file style)
>   Improved code per review comments in PollSelectors.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8642

From joehw at openjdk.java.net  Wed May 11 19:20:55 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 11 May 2022 19:20:55 GMT
Subject:  RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does
 not work for all ZoneOffsets and returns GMT unexpected [v4]
In-Reply-To: <1zSZc32pEuDhOtIfc1t1svegXZ_Ty3cUVSBnQkWpIDA=.ef77de25-0da2-4ca0-85a3-4449c46ad870@github.com>
References: 
 <1zSZc32pEuDhOtIfc1t1svegXZ_Ty3cUVSBnQkWpIDA=.ef77de25-0da2-4ca0-85a3-4449c46ad870@github.com>
Message-ID: 

On Wed, 11 May 2022 17:04:41 GMT, Naoto Sato  wrote:

>> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support second-level resolution, enabling round trips with `java.time.ZoneOffset`s. Corresponding CSR is also being drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor fixup

src/java.base/share/classes/java/util/TimeZone.java line 80:

> 78:  *         {@code GMT} Sign Hours {@code :} Minutes {@code :} Seconds
> 79:  *         {@code GMT} Sign Hours {@code :} Minutes
> 80:  *         {@code GMT} Sign Hours Minutes

For hours and minutes, the format can be hh:mm or hhmm. Is it worth it to support hhmmss as well?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8606

From naoto at openjdk.java.net  Wed May 11 20:04:39 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 11 May 2022 20:04:39 GMT
Subject:  RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does
 not work for all ZoneOffsets and returns GMT unexpected [v5]
In-Reply-To: 
References: 
Message-ID: 

> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support second-level resolution, enabling round trips with `java.time.ZoneOffset`s. Corresponding CSR is also being 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 six additional commits since the last revision:

 - Disallow `UTC` -> `GMT`
 - Merge branch 'master' into JDK-8285844
 - Minor fixup
 - Allowed round-trips for offset-style ZoneIds.
 - Fixed offsets in milliseconds, added test variations, refined Custom ID definitions
 - 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8606/files
  - new: https://git.openjdk.java.net/jdk/pull/8606/files/9722decd..11150ac5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8606&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8606&range=03-04

  Stats: 8626 lines in 248 files changed: 4866 ins; 2323 del; 1437 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8606.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8606/head:pull/8606

PR: https://git.openjdk.java.net/jdk/pull/8606

From naoto at openjdk.java.net  Wed May 11 20:04:40 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 11 May 2022 20:04:40 GMT
Subject:  RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does
 not work for all ZoneOffsets and returns GMT unexpected [v4]
In-Reply-To: 
References: 
 <1zSZc32pEuDhOtIfc1t1svegXZ_Ty3cUVSBnQkWpIDA=.ef77de25-0da2-4ca0-85a3-4449c46ad870@github.com>

Message-ID: 

On Wed, 11 May 2022 18:30:32 GMT, Joe Wang  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor fixup
>
> src/java.base/share/classes/java/util/TimeZone.java line 80:
> 
>> 78:  *         {@code GMT} Sign Hours {@code :} Minutes {@code :} Seconds
>> 79:  *         {@code GMT} Sign Hours {@code :} Minutes
>> 80:  *         {@code GMT} Sign Hours Minutes
> 
> For hours and minutes, the format can be hh:mm or hhmm. Is it worth it to support hhmmss as well?

It would be consistent, but I don't see much requirement for it. I'll consider if someone needs it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8606

From scolebourne at openjdk.java.net  Wed May 11 20:21:43 2022
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Wed, 11 May 2022 20:21:43 GMT
Subject:  RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does
 not work for all ZoneOffsets and returns GMT unexpected [v5]
In-Reply-To: 
References: 

Message-ID: 

On Wed, 11 May 2022 20:04:39 GMT, Naoto Sato  wrote:

>> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support second-level resolution, enabling round trips with `java.time.ZoneOffset`s. Corresponding CSR is also being 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 six additional commits since the last revision:
> 
>  - Disallow `UTC` -> `GMT`
>  - Merge branch 'master' into JDK-8285844
>  - Minor fixup
>  - Allowed round-trips for offset-style ZoneIds.
>  - Fixed offsets in milliseconds, added test variations, refined Custom ID definitions
>  - 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected

Marked as reviewed by scolebourne (Author).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8606

From joehw at openjdk.java.net  Wed May 11 20:42:52 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 11 May 2022 20:42:52 GMT
Subject:  RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does
 not work for all ZoneOffsets and returns GMT unexpected [v5]
In-Reply-To: 
References: 

Message-ID: 

On Wed, 11 May 2022 20:04:39 GMT, Naoto Sato  wrote:

>> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support second-level resolution, enabling round trips with `java.time.ZoneOffset`s. Corresponding CSR is also being 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 six additional commits since the last revision:
> 
>  - Disallow `UTC` -> `GMT`
>  - Merge branch 'master' into JDK-8285844
>  - Minor fixup
>  - Allowed round-trips for offset-style ZoneIds.
>  - Fixed offsets in milliseconds, added test variations, refined Custom ID definitions
>  - 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8606

From uschindler at openjdk.java.net  Wed May 11 20:48:55 2022
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Wed, 11 May 2022 20:48:55 GMT
Subject:  RFR: 8285844: TimeZone.getTimeZone(ZoneOffset) does
 not work for all ZoneOffsets and returns GMT unexpected [v5]
In-Reply-To: 
References: 

Message-ID: 

On Wed, 11 May 2022 20:04:39 GMT, Naoto Sato  wrote:

>> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support second-level resolution, enabling round trips with `java.time.ZoneOffset`s. Corresponding CSR is also being 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 six additional commits since the last revision:
> 
>  - Disallow `UTC` -> `GMT`
>  - Merge branch 'master' into JDK-8285844
>  - Minor fixup
>  - Allowed round-trips for offset-style ZoneIds.
>  - Fixed offsets in milliseconds, added test variations, refined Custom ID definitions
>  - 8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected

Marked as reviewed by uschindler (Author).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8606

From rriggs at openjdk.java.net  Thu May 12 16:54:48 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 12 May 2022 16:54:48 GMT
Subject:  Integrated: 8286378: Address possibly lossy conversions
 in java.base
In-Reply-To: 
References: 
Message-ID: 

On Tue, 10 May 2022 21:32:10 GMT, Roger Riggs  wrote:

> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
> From the CSR:
> 
> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
> 
> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
> but a direct replacement was chosen here.
> 
> (Advise and suggestions will inform similar updates to other OpenJDK modules).

This pull request has now been integrated.

Changeset: 17c52789
Author:    Roger Riggs 
URL:       https://git.openjdk.java.net/jdk/commit/17c52789b79a4ccd65308f90c4e02c1732b206be
Stats:     71 lines in 32 files changed: 0 ins; 3 del; 68 mod

8286378: Address possibly lossy conversions in java.base

Reviewed-by: naoto, xuelei, bpb, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/8642

From duke at openjdk.java.net  Fri May 13 04:44:38 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Fri, 13 May 2022 04:44:38 GMT
Subject:  RFR: 8286378: Address possibly lossy conversions in
 java.base [v3]
In-Reply-To: 
References: 

Message-ID: 

On Wed, 11 May 2022 16:30:41 GMT, Roger Riggs  wrote:

>> PR#8599 8244681: proposes to add compiler warnings for possible lossy conversions
>> From the CSR:
>> 
>> "If the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable, a cast is implied and possible lossy conversion may silently occur. While similar situations are resolved as compilation errors for primitive assignments, there are no similar rules defined for compound assignments."
>> 
>> This PR anticipates the warnings and adds explicit casts to replace the implicit casts.
>> In most cases, the cast matches the type of the right-hand side to type of the compound assignment.
>> Since these casts are truncating the value, there might be a different refactoring that avoids the cast
>> but a direct replacement was chosen here.
>> 
>> (Advise and suggestions will inform similar updates to other OpenJDK modules).
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyrights
>   Fixed cast style to add a space after cast, (where consistent with file style)
>   Improved code per review comments in PollSelectors.

src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 128:

> 126:                     // timed poll interrupted so need to adjust timeout
> 127:                     long adjust = System.nanoTime() - startTime;
> 128:                     to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);

This?will?now always?assign a?negative?number to?`to`.

--------------------------------------------------------------------------------

`=-`?is?not a?compound?assignment, it?s?negation followed?by a?normal?assignment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8642

From alanb at openjdk.java.net  Fri May 13 05:56:40 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 13 May 2022 05:56:40 GMT
Subject:  RFR: 8286378: Address possibly lossy conversions in
 java.base [v3]
In-Reply-To: 
References: 

Message-ID: 

On Fri, 13 May 2022 04:41:03 GMT, ExE Boss  wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated copyrights
>>   Fixed cast style to add a space after cast, (where consistent with file style)
>>   Improved code per review comments in PollSelectors.
>
> src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 128:
> 
>> 126:                     // timed poll interrupted so need to adjust timeout
>> 127:                     long adjust = System.nanoTime() - startTime;
>> 128:                     to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);
> 
> This?will?now always?assign a?negative?number to?`to`.
> 
> --------------------------------------------------------------------------------
> 
> `=-`?is?not a?compound?assignment, it?s?negation followed?by a?normal?assignment.

Well spotted, I don't think that change was intentionally.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8642

From rriggs at openjdk.java.net  Fri May 13 14:22:01 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 13 May 2022 14:22:01 GMT
Subject:  RFR: 8286378: Address possibly lossy conversions in
 java.base [v3]
In-Reply-To: 
References: 

Message-ID: 

On Fri, 13 May 2022 05:54:15 GMT, Alan Bateman  wrote:

>> src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 128:
>> 
>>> 126:                     // timed poll interrupted so need to adjust timeout
>>> 127:                     long adjust = System.nanoTime() - startTime;
>>> 128:                     to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);
>> 
>> This?will?now always?assign a?negative?number to?`to`.
>> 
>> --------------------------------------------------------------------------------
>> 
>> `=-`?is?not a?compound?assignment, it?s?negation followed?by a?normal?assignment.
>
> Well spotted, I don't think that change was intentionally.

Ouch; Will fix:

I took Alan's earlier comment literally:

"This one can also be changed to:

to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);"

-------------

PR: https://git.openjdk.java.net/jdk/pull/8642

From duke at openjdk.java.net  Fri May 13 14:27:02 2022
From: duke at openjdk.java.net (ExE Boss)
Date: Fri, 13 May 2022 14:27:02 GMT
Subject:  RFR: 8286378: Address possibly lossy conversions in
 java.base [v3]
In-Reply-To: 
References: 

Message-ID: 

On Fri, 13 May 2022 14:18:04 GMT, Roger Riggs  wrote:

>> Well spotted, I don't think that change was intentionally.
>
> Ouch; Will fix:
> 
> I took Alan's earlier comment literally:
> 
> "This one can also be changed to:
> 
> to =- (int) TimeUnit.NANOSECONDS.toMillis(adjust);"

@RogerRiggs
This?already got?fixed by?@jaikiran in?[GH?8693].

[GH?8693]: https://github.com/openjdk/jdk/pull/8693

-------------

PR: https://git.openjdk.java.net/jdk/pull/8642

From ihse at openjdk.java.net  Fri May 13 16:11:04 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 13 May 2022 16:11:04 GMT
Subject:  RFR: 8285306: Fix typos in java.desktop [v2]
In-Reply-To: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
Message-ID: 

> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
> 
> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Magnus Ihse Bursie has updated the pull request incrementally with 14 additional commits since the last revision:

 - Update src/java.desktop/share/classes/javax/swing/ActionPropertyChangeListener.java

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/windows/native/libawt/windows/awt_PrintDialog.cpp

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/windows/native/libawt/windows/awt_Label.h

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLVertexCache.m

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLVertexCache.m

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLGraphicsConfig.m

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzSurfaceData.m

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/e5c0e79d...d11ef860

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8328/files
  - new: https://git.openjdk.java.net/jdk/pull/8328/files/e5c0e79d..d11ef860

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8328&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8328&range=00-01

  Stats: 18 lines in 14 files changed: 0 ins; 0 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8328.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8328/head:pull/8328

PR: https://git.openjdk.java.net/jdk/pull/8328

From ihse at openjdk.java.net  Fri May 13 16:17:56 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 13 May 2022 16:17:56 GMT
Subject:  RFR: 8285306: Fix typos in java.desktop [v3]
In-Reply-To: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
Message-ID: 

> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
> 
> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Magnus Ihse Bursie has updated the pull request incrementally with four additional commits since the last revision:

 - Update src/java.desktop/share/classes/javax/swing/JLayeredPane.java

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/share/classes/javax/swing/JLayeredPane.java

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/share/classes/javax/swing/JCheckBox.java

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/share/classes/javax/swing/DefaultRowSorter.java

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8328/files
  - new: https://git.openjdk.java.net/jdk/pull/8328/files/d11ef860..42656f52

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8328&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8328&range=01-02

  Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8328.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8328/head:pull/8328

PR: https://git.openjdk.java.net/jdk/pull/8328

From ihse at openjdk.java.net  Fri May 13 16:17:59 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 13 May 2022 16:17:59 GMT
Subject:  RFR: 8285306: Fix typos in java.desktop [v3]
In-Reply-To: <1x04_BXzoS9x2Uh3iaA-wo08JPGM6xUli_YbFbyOkFY=.248133c8-2be5-4a68-89bc-9b6f62e33fb9@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <1x04_BXzoS9x2Uh3iaA-wo08JPGM6xUli_YbFbyOkFY=.248133c8-2be5-4a68-89bc-9b6f62e33fb9@github.com>
Message-ID: 

On Thu, 28 Apr 2022 16:48:04 GMT, Alexey Ivanov  wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Update src/java.desktop/share/classes/javax/swing/JLayeredPane.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/javax/swing/JLayeredPane.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/javax/swing/JCheckBox.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/javax/swing/DefaultRowSorter.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>
> src/java.desktop/share/classes/javax/swing/GroupLayout.java line 1654:
> 
>> 1652:         /**
>> 1653:          * Used to compute how the two values representing two springs
>> 1654:          * will be combined.  For example, a group that laid things out
> 
> Suggestion:
> 
>          * will be combined.  For example, a group that laid out things
> 
> Not sure which one is correct. Usually the particle in a phrasal verb follows the verb is the object is a noun.

If you're not sure, I prefer to leave it as it is.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8328

From ihse at openjdk.java.net  Fri May 13 16:20:11 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 13 May 2022 16:20:11 GMT
Subject:  RFR: 8285306: Fix typos in java.desktop [v4]
In-Reply-To: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
Message-ID: <6Hmf5mjZoahwM1ZkGvSOp7dOYsVlDme8M2FKh96JdmM=.afe9dd13-b975-4fc8-a75b-0884d2c9927b@github.com>

> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
> 
> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/java.desktop/share/classes/javax/swing/JPopupMenu.java

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/share/classes/javax/swing/JMenu.java

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8328/files
  - new: https://git.openjdk.java.net/jdk/pull/8328/files/42656f52..b6025570

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8328&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8328&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8328.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8328/head:pull/8328

PR: https://git.openjdk.java.net/jdk/pull/8328

From ihse at openjdk.java.net  Fri May 13 16:32:48 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 13 May 2022 16:32:48 GMT
Subject:  RFR: 8285306: Fix typos in java.desktop [v5]
In-Reply-To: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
Message-ID: <3SlpqjTO1Y6zx6N-uF9RuZSZFqX7oqZXnjczEUgCQ3Y=.6c5e356f-848e-426d-a3c0-bd9548cf6ac8@github.com>

> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
> 
> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Magnus Ihse Bursie has updated the pull request incrementally with four additional commits since the last revision:

 - Update src/java.desktop/share/classes/javax/swing/plaf/metal/MetalTheme.java

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/share/classes/javax/swing/plaf/metal/MetalRootPaneUI.java

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/share/classes/javax/swing/SwingWorker.java

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/share/classes/javax/swing/JSpinner.java

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8328/files
  - new: https://git.openjdk.java.net/jdk/pull/8328/files/b6025570..40c585cd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8328&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8328&range=03-04

  Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8328.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8328/head:pull/8328

PR: https://git.openjdk.java.net/jdk/pull/8328

From ihse at openjdk.java.net  Fri May 13 16:53:00 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 13 May 2022 16:53:00 GMT
Subject:  RFR: 8285306: Fix typos in java.desktop [v6]
In-Reply-To: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
Message-ID: <6VLaunLW3FJYLzJKcXYYvCX2ShaBucrjDGJjf0M9GMA=.5abbc53d-8980-4697-af0c-6f15fdf3c153@github.com>

> I ran `codespell` on the `src/java.desktop` directory, and accepted those changes where it indeed discovered real typos.
> 
> I ignored typos in public methods and variables. Maybe they can be fixed later on without much fanfare, if they are in internal classes. Typos in exposed APIs are likely here to stay.
> 
> I will update copyright years using a script before pushing (otherwise like every second change would be a copyright update, making reviewing much harder).
> 
> The long term goal here is to make tooling support for running `codespell`. The trouble with automating this is of course all false positives. But before even trying to solve that issue, all true positives must be fixed. Hence this PR.

Magnus Ihse Bursie has updated the pull request incrementally with 17 additional commits since the last revision:

 - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/share/classes/javax/swing/tree/FixedHeightLayoutCache.java

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/share/classes/javax/swing/text/html/parser/TagStack.java

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Update src/java.desktop/share/classes/javax/swing/text/html/CSS.java

   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/40c585cd...98e635a5

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8328/files
  - new: https://git.openjdk.java.net/jdk/pull/8328/files/40c585cd..98e635a5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8328&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8328&range=04-05

  Stats: 21 lines in 14 files changed: 0 ins; 0 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8328.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8328/head:pull/8328

PR: https://git.openjdk.java.net/jdk/pull/8328

From ihse at openjdk.java.net  Fri May 13 16:53:02 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 13 May 2022 16:53:02 GMT
Subject:  RFR: 8285306: Fix typos in java.desktop [v6]
In-Reply-To: <1x04_BXzoS9x2Uh3iaA-wo08JPGM6xUli_YbFbyOkFY=.248133c8-2be5-4a68-89bc-9b6f62e33fb9@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <1x04_BXzoS9x2Uh3iaA-wo08JPGM6xUli_YbFbyOkFY=.248133c8-2be5-4a68-89bc-9b6f62e33fb9@github.com>
Message-ID: 

On Thu, 28 Apr 2022 20:37:22 GMT, Alexey Ivanov  wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with 17 additional commits since the last revision:
>> 
>>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/javax/swing/tree/FixedHeightLayoutCache.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/javax/swing/text/html/parser/TagStack.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/javax/swing/text/html/CSS.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - ... and 7 more: https://git.openjdk.java.net/jdk/compare/40c585cd...98e635a5
>
> src/java.desktop/share/classes/sun/swing/text/TextComponentPrintable.java line 772:
> 
>> 770:                         /*
>> 771:                          * we do not store the same value as previous. in our
>> 772:                          * documents it is often for consequent positions to have
> 
> Looks this actually means _consecutive_ positions?

Possibly. I suggest you file a follow up PR to address additional documentation errors.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8328

From ihse at openjdk.java.net  Fri May 13 16:56:54 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 13 May 2022 16:56:54 GMT
Subject:  RFR: 8285306: Fix typos in java.desktop [v6]
In-Reply-To: <1x04_BXzoS9x2Uh3iaA-wo08JPGM6xUli_YbFbyOkFY=.248133c8-2be5-4a68-89bc-9b6f62e33fb9@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <1x04_BXzoS9x2Uh3iaA-wo08JPGM6xUli_YbFbyOkFY=.248133c8-2be5-4a68-89bc-9b6f62e33fb9@github.com>
Message-ID: 

On Thu, 28 Apr 2022 21:25:02 GMT, Alexey Ivanov  wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with 17 additional commits since the last revision:
>> 
>>  - Update src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/sun/awt/image/ImagingLib.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/javax/swing/tree/FixedHeightLayoutCache.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/javax/swing/text/html/parser/TagStack.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - Update src/java.desktop/share/classes/javax/swing/text/html/CSS.java
>>    
>>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>>  - ... and 7 more: https://git.openjdk.java.net/jdk/compare/40c585cd...98e635a5
>
> Nearly 500 files are too many. Smaller chunks would be easier to review.
> 
> Some of the native code files could come from upstream libraries.

@aivanov-jdk While I approve of finding and fixing spelling mistakes, grammatical or semantic errors, the mistakes you posted suggestions for was not at all associated with the mechanical changes made by codespell that this PR included, and I assume you noticed them just because you read the text around the typo my PR fixed. 

In hindsight, it would have been better if you've made these changes yourself, in a separate PR. 

But since you had spent the effort of looking for these problems, and suggesting fixes, I have now accepted all of them. Due to how the Github UI works, this was quite tedious, so please refrain from submitting more than a handful suggestions next time you review a PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8328

From aivanov at openjdk.java.net  Fri May 13 18:34:01 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 13 May 2022 18:34:01 GMT
Subject:  RFR: 8285306: Fix typos in java.desktop [v6]
In-Reply-To: 
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <1x04_BXzoS9x2Uh3iaA-wo08JPGM6xUli_YbFbyOkFY=.248133c8-2be5-4a68-89bc-9b6f62e33fb9@github.com>

Message-ID: 

On Fri, 13 May 2022 16:53:31 GMT, Magnus Ihse Bursie  wrote:

>> Nearly 500 files are too many. Smaller chunks would be easier to review.
>> 
>> Some of the native code files could come from upstream libraries.
>
> @aivanov-jdk While I approve of finding and fixing spelling mistakes, grammatical or semantic errors, the mistakes you posted suggestions for was not at all associated with the mechanical changes made by codespell that this PR included, and I assume you noticed them just because you read the text around the typo my PR fixed. 
> 
> In hindsight, it would have been better if you've made these changes yourself, in a separate PR. 
> 
> But since you had spent the effort of looking for these problems, and suggesting fixes, I have now accepted all of them. Due to how the Github UI works, this was quite tedious, so please refrain from submitting more than a handful suggestions next time you review a PR.

Thank you, @magicus,  I should've noted the changes and created a branch on top yours.

That's right. Even looking through all the changes in this PR was tedious, more than hundred files doesn't work well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8328

From aivanov at openjdk.java.net  Fri May 13 18:42:01 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 13 May 2022 18:42:01 GMT
Subject:  RFR: 8285306: Fix typos in java.desktop [v6]
In-Reply-To: 
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <1x04_BXzoS9x2Uh3iaA-wo08JPGM6xUli_YbFbyOkFY=.248133c8-2be5-4a68-89bc-9b6f62e33fb9@github.com>

Message-ID: 

On Fri, 13 May 2022 16:48:35 GMT, Magnus Ihse Bursie  wrote:

>> src/java.desktop/share/classes/sun/swing/text/TextComponentPrintable.java line 772:
>> 
>>> 770:                         /*
>>> 771:                          * we do not store the same value as previous. in our
>>> 772:                          * documents it is often for consequent positions to have
>> 
>> Looks this actually means _consecutive_ positions?
>
> Possibly. I suggest you file a follow up PR to address additional documentation errors.

I've submitted [JDK-8286759](https://bugs.openjdk.java.net/browse/JDK-8286759): TextComponentPrintable: consequent -> consecutive positions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8328

From aivanov at openjdk.java.net  Fri May 13 19:22:52 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 13 May 2022 19:22:52 GMT
Subject:  RFR: 8285306: Fix typos in java.desktop
In-Reply-To: <4QVTblMgjEo2KBoDGn1G67qqvHtOkdmqeU4e88o2eHU=.faf55412-6b4a-4fe4-ac84-82ee0cea2f8d@github.com>
References: <5gAPAoRiIJr6BEko1UEaMd3QeUte-snqvfc9eNU2Jgk=.a6d39dcd-0d89-4444-a890-a6c53f41245b@github.com>
 <4QVTblMgjEo2KBoDGn1G67qqvHtOkdmqeU4e88o2eHU=.faf55412-6b4a-4fe4-ac84-82ee0cea2f8d@github.com>
Message-ID: <-jePZ8ESH0oSeqb03Bpr7kJUSkAOEsme4nNWfR4JuKU=.1ad19f01-d116-4e82-b530-4c5f13fe7e43@github.com>

On Wed, 27 Apr 2022 03:38:09 GMT, Phil Race  wrote:

> Please exclude ALL 3rd party libraries from this PR.

Are these the only files to be excluded?

src/java.desktop/share/native/libfreetype/src/autofit/afcjk.c
src/java.desktop/share/native/libfreetype/src/autofit/aflatin.c
src/java.desktop/share/native/libfreetype/src/base/ftsynth.c
src/java.desktop/share/native/libfreetype/src/raster/ftraster.c

-------------

PR: https://git.openjdk.java.net/jdk/pull/8328

From naoto at openjdk.java.net  Mon May 16 15:48:59 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 16 May 2022 15:48:59 GMT
Subject:  Integrated: 8285844: TimeZone.getTimeZone(ZoneOffset)
 does not work for all ZoneOffsets and returns GMT unexpected
In-Reply-To: 
References: 
Message-ID: 

On Mon, 9 May 2022 18:59:43 GMT, Naoto Sato  wrote:

> This is to extend the `Custom ID`s in `java.util.TimeZone` class to support second-level resolution, enabling round trips with `java.time.ZoneOffset`s. Corresponding CSR is also being drafted.

This pull request has now been integrated.

Changeset: b884db8f
Author:    Naoto Sato 
URL:       https://git.openjdk.java.net/jdk/commit/b884db8f7c03fd300becaeb9d572f3b2c18351ae
Stats:     155 lines in 4 files changed: 110 ins; 0 del; 45 mod

8285844: TimeZone.getTimeZone(ZoneOffset) does not work for all ZoneOffsets and returns GMT unexpected

Reviewed-by: uschindler, scolebourne, joehw

-------------

PR: https://git.openjdk.java.net/jdk/pull/8606

From duke at openjdk.java.net  Tue May 17 14:20:20 2022
From: duke at openjdk.java.net (Gaurav Chaudhari)
Date: Tue, 17 May 2022 14:20:20 GMT
Subject:  RFR: 8285838: DST not applying properly with zone id
 offset set with TZ env variable
Message-ID: 

This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.

-------------

Commit messages:
 - 8285838: Fix for TZ environment variable DST rules

Changes: https://git.openjdk.java.net/jdk/pull/8661/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8661&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285838
  Stats: 139 lines in 3 files changed: 138 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8661.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8661/head:pull/8661

PR: https://git.openjdk.java.net/jdk/pull/8661

From robilad at openjdk.java.net  Tue May 17 14:20:20 2022
From: robilad at openjdk.java.net (Dalibor Topic)
Date: Tue, 17 May 2022 14:20:20 GMT
Subject:  RFR: 8285838: DST not applying properly with zone id
 offset set with TZ env variable
In-Reply-To: 
References: 
Message-ID: 

On Wed, 11 May 2022 18:00:31 GMT, Gaurav Chaudhari  wrote:

> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.

Hi, please send me an e-mail at Dalibor.topic at oracle.com, so that I can mark your account as verified.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8661

From duke at openjdk.java.net  Tue May 17 14:20:21 2022
From: duke at openjdk.java.net (Gaurav Chaudhari)
Date: Tue, 17 May 2022 14:20:21 GMT
Subject:  RFR: 8285838: DST not applying properly with zone id
 offset set with TZ env variable
In-Reply-To: 
References: 

Message-ID: <0TgrauJHrnHHGSmvbOl-FtaQONNQcCME-9_4qw-o2fc=.01f2211e-87ab-43fe-93eb-c280f7431e1f@github.com>

On Wed, 11 May 2022 21:20:52 GMT, Dalibor Topic  wrote:

>> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.
>
> Hi, please send me an e-mail at Dalibor.topic at oracle.com, so that I can mark your account as verified.

I've sent an email yesterday @robilad

-------------

PR: https://git.openjdk.java.net/jdk/pull/8661

From naoto at openjdk.java.net  Tue May 17 20:48:55 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 17 May 2022 20:48:55 GMT
Subject:  RFR: 8285838: DST not applying properly with zone id
 offset set with TZ env variable
In-Reply-To: 
References: 
Message-ID: 

On Wed, 11 May 2022 18:00:31 GMT, Gaurav Chaudhari  wrote:

> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.

Thanks for contributing the fix. This issue has been reported in the past, but closed as will not fix (https://bugs.openjdk.java.net/browse/JDK-6992725), as implementing POSIX TZ fully requires a sizable amount of work for a rare situation. Returning a fixed offset ID with the `TZ` set to observing DST is thus a compromised solution. Even if the fix would return a custom zone observing the DST does not mean the zone is correct in winter. Having said that I agree that the derived fixed offset zone should reflect the *current* offset, as well as macOS's implementation.

src/java.base/unix/native/libjava/TimeZone_md.c line 609:

> 607:     }
> 608: 
> 609:     offset = (gmt.tm_hour - localtm.tm_hour)*3600 + (gmt.tm_min - localtm.tm_min)*60;

Since it is not using `timezone` anymore, we can reverse the subtraction, i.e., `localtime` - `gmtime` so that the weird sign switch below can be eliminated.

test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java line 2:

> 1: /*
> 2:  * Copyright (c) 2001, 2022, Oracle and/or its affiliates. All rights reserved.

This is a new test case, the year should be only 2022.

test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java line 27:

> 25:  * Specifically called by runCustomTzIDCheckDST.sh to check if Daylight savings is
> 26:  * properly followed with a custom TZ code set through environment variables.
> 27:  * */

Nit: Need a new line.

test/jdk/java/util/TimeZone/runCustomTzIDCheckDST.sh line 1:

> 1: #

I'd change this script into a java test case (using `.sh` is not recommended). In fact, this causes a failure invoking `javac` with `-Xmx768m` (from TESTVMOPTS)
There are libraries under `jdk/test/lib/` for building test jvm process and tools.

test/jdk/java/util/TimeZone/runCustomTzIDCheckDST.sh line 40:

> 38: 
> 39: OS=`uname -s`
> 40: case "$OS" in 

In case other than Linux/AIX, it would be helpful to emit some message that the test is ignored.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8661

From naoto at openjdk.java.net  Tue May 17 23:40:04 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 17 May 2022 23:40:04 GMT
Subject:  RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v10]
In-Reply-To: 
References: 
Message-ID: 

> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding 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 13 additional commits since the last revision:

 - Merge branch 'master' into JDK-8279185
 - Addressing review comments
 - Revert to use the default method
 - Removed unnecessary package names
 - Modified class desc of `IsoFields`
 - abstract class -> top level interface
 - interface -> abstract class
 - Removed the method
 - Changed to use a type to determine ISO based or not
 - Renamed the new method
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/d7dfd3a6...3f69909f

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7683/files
  - new: https://git.openjdk.java.net/jdk/pull/7683/files/45edbc3b..3f69909f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=08-09

  Stats: 243466 lines in 3650 files changed: 182993 ins; 40828 del; 19645 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7683.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7683/head:pull/7683

PR: https://git.openjdk.java.net/jdk/pull/7683

From aivanov at openjdk.java.net  Wed May 18 13:34:24 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 18 May 2022 13:34:24 GMT
Subject:  RFR: 8284191: Replace usages of 'a the' in hotspot and
 java.base
Message-ID: 

Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?

Also, I fixed a couple of spelling mistakes.

-------------

Commit messages:
 - 8284191: Replace usages of 'the an' in hotspot and java.base
 - 8284191: Replace usages of 'the an' in hotspot and java.base
 - 8284191: Replace usages of 'the an' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - 8284191: Replace usages of 'the the' in hotspot and java.base
 - ... and 13 more: https://git.openjdk.java.net/jdk/compare/69ff86a3...c7e73658

Changes: https://git.openjdk.java.net/jdk/pull/8768/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284191
  Stats: 202 lines in 162 files changed: 0 ins; 11 del; 191 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8768/head:pull/8768

PR: https://git.openjdk.java.net/jdk/pull/8768

From lancea at openjdk.java.net  Wed May 18 14:42:53 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 18 May 2022 14:42:53 GMT
Subject:  RFR: 8284191: Replace usages of 'a the' in hotspot
 and java.base
In-Reply-To: 
References: 
Message-ID: 

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov  wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8768

From aivanov at openjdk.java.net  Wed May 18 14:53:28 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 18 May 2022 14:53:28 GMT
Subject:  RFR: 8284209: Replace remaining usages of 'a the' in
 source code
Message-ID: 

Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?

It's the last issue in the series, and it still touches different areas of the code.

-------------

Commit messages:
 - 8284209: Replace remaining usages of 'the a' in source code
 - 8284209: Replace remaining usages of 'the a' in source code
 - 8284209: Replace remaining usages of 'the a' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'an? an?' in source code
 - 8284209: Replace remaining usages of 'a the' in source code
 - 8284209: Replace remaining usages of 'an the' in source code
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/69ff86a3...8290c07e

Changes: https://git.openjdk.java.net/jdk/pull/8771/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8771&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8284209
  Stats: 51 lines in 41 files changed: 0 ins; 2 del; 49 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8771.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8771/head:pull/8771

PR: https://git.openjdk.java.net/jdk/pull/8771

From lancea at openjdk.java.net  Wed May 18 14:59:56 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 18 May 2022 14:59:56 GMT
Subject:  RFR: 8284209: Replace remaining usages of 'a the' in
 source code
In-Reply-To: 
References: 
Message-ID: 

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov  wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8771

From wetmore at openjdk.java.net  Wed May 18 15:15:56 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 18 May 2022 15:15:56 GMT
Subject:  RFR: 8284191: Replace usages of 'a the' in hotspot
 and java.base
In-Reply-To: 
References: 
Message-ID: 

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov  wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Looked at 

- java.base/.../sun/security
- jdk.crypto.*
- test/*/com/sun/crypto/provider
- test/*/java/lang/SecurityManager
- test/*/java/security
- test/*/krb5
- test/*/jarsigner

and those look fine.

-------------

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8768

From wetmore at openjdk.java.net  Wed May 18 15:19:55 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 18 May 2022 15:19:55 GMT
Subject:  RFR: 8284209: Replace remaining usages of 'a the' in
 source code
In-Reply-To: 
References: 
Message-ID: 

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov  wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Looked at 

-java.security.jgss.

LGTM

-------------

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8771

From dfuchs at openjdk.java.net  Wed May 18 16:07:52 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 18 May 2022 16:07:52 GMT
Subject:  RFR: 8284209: Replace remaining usages of 'a the' in
 source code
In-Reply-To: 
References: 
Message-ID: 

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov  wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Logging/JNDI OK

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8771

From naoto at openjdk.java.net  Wed May 18 16:18:58 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 18 May 2022 16:18:58 GMT
Subject:  RFR: 8284191: Replace usages of 'a the' in hotspot
 and java.base
In-Reply-To: 
References: 
Message-ID: <4eXpe5pmBsvw8u6fJlzd9BWsnY74LiyjTqQhQ88uxoc=.6182985a-f751-4d55-b9d0-bc605d7636da@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov  wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

LGTM for i18n changes.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8768

From naoto at openjdk.java.net  Wed May 18 16:35:28 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 18 May 2022 16:35:28 GMT
Subject:  RFR: 8267038: Update IANA Language Subtag Registry to
 Version 2022-03-02
Message-ID: 

This is to incorporate the latest language subtag registry definition (version 2022-03-02) into JDK19.

-------------

Commit messages:
 - LSR 2022-03-02
 - LSR 2021-12-29
 - LSR 2021-08-06
 - LSR 2021-07-21

Changes: https://git.openjdk.java.net/jdk/pull/8776/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8776&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267038
  Stats: 281 lines in 2 files changed: 271 ins; 2 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8776.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8776/head:pull/8776

PR: https://git.openjdk.java.net/jdk/pull/8776

From iris at openjdk.java.net  Wed May 18 16:59:50 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 18 May 2022 16:59:50 GMT
Subject:  RFR: 8284191: Replace usages of 'a the' in hotspot
 and java.base
In-Reply-To: 
References: 
Message-ID: 

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov  wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8768

From iris at openjdk.java.net  Wed May 18 17:04:50 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 18 May 2022 17:04:50 GMT
Subject:  RFR: 8284209: Replace remaining usages of 'a the' in
 source code
In-Reply-To: 
References: 
Message-ID: 

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov  wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8771

From jjg at openjdk.java.net  Wed May 18 22:06:44 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 18 May 2022 22:06:44 GMT
Subject:  RFR: 8284209: Replace remaining usages of 'a the' in
 source code
In-Reply-To: 
References: 
Message-ID: 

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov  wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

javac and javadoc changes look OK

test/langtools/tools/javac/modules/T8168854/module-info.java line 4:

> 2:  * @test
> 3:  * @bug 8168854
> 4:  * @summary javac erroneously reject a service interface inner class in a provides clause

FYI, this duplication was in the JBS issue summary; now fixed there.

-------------

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8771

From kevinw at openjdk.java.net  Thu May 19 08:43:45 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 08:43:45 GMT
Subject:  RFR: 8284191: Replace usages of 'a the' in hotspot
 and java.base
In-Reply-To: 
References: 
Message-ID: 

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov  wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/jdk.sctp/share/classes/com/sun/nio/sctp/ShutdownNotification.java line 28:

> 26: 
> 27: /**
> 28:  * Notification emitted when a peers shutdowns the association.

Maybe: "...when a peer shuts down an association."
(could be "shuts down the association" if there is only ever one, but using "an" looks safe)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8768

From kevinw at openjdk.java.net  Thu May 19 08:50:49 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 08:50:49 GMT
Subject:  RFR: 8284191: Replace usages of 'a the' in hotspot
 and java.base
In-Reply-To: 
References: 
Message-ID: 

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov  wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/jdk.jdi/share/classes/com/sun/jdi/ClassType.java line 348:

> 346: 
> 347:     /**
> 348:      * Returns the single non-abstract {@link Method} visible from

I would think "Returns a single ..." because the implementation returns the first match it finds, from possibly many.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8768

From kevinw at openjdk.java.net  Thu May 19 09:02:49 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:02:49 GMT
Subject:  RFR: 8284191: Replace usages of 'a the' in hotspot
 and java.base
In-Reply-To: 
References: 
Message-ID: 

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov  wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/hotspot/share/opto/graphKit.cpp line 3626:

> 3624: // The optional arguments are for specialized use by intrinsics:
> 3625: //  - If 'extra_slow_test' if not null is an extra condition for the slow-path.
> 3626: //  - If 'return_size_val', report the total object size to the caller.

"reports the total"

-------------

PR: https://git.openjdk.java.net/jdk/pull/8768

From kevinw at openjdk.java.net  Thu May 19 09:09:50 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:09:50 GMT
Subject:  RFR: 8284191: Replace usages of 'a the' in hotspot
 and java.base
In-Reply-To: 
References: 
Message-ID: 

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov  wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/hotspot/share/interpreter/bytecodeUtils.cpp line 186:

> 184:   static const int _max_cause_detail = 5;
> 185: 
> 186:   // Merges the stack the given bci with the given stack. If there

"...the stack at the given bci..."

-------------

PR: https://git.openjdk.java.net/jdk/pull/8768

From kevinw at openjdk.java.net  Thu May 19 09:27:55 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:27:55 GMT
Subject:  RFR: 8284191: Replace usages of 'a the' in hotspot
 and java.base
In-Reply-To: 
References: 
Message-ID: <02e6mwqZ3ihNyJb4lBK-5WeIGMfiLMj3I8LpJPv4i8o=.3c56077b-54f0-4c4e-b031-5a000b9ea887@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov  wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

src/hotspot/share/cds/filemap.cpp line 1914:

> 1912: 
> 1913:     // the current value of the pointers to be patched must be within this
> 1914:     // range (i.e., must be between the requested base address, and the of the current archive).

"the of the" ? 
Maybe "..and the address of the current archive",  or maybe it was a typo for "and that of the current archive".

-------------

PR: https://git.openjdk.java.net/jdk/pull/8768

From kevinw at openjdk.java.net  Thu May 19 09:35:42 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:35:42 GMT
Subject:  RFR: 8284191: Replace usages of 'a the' in hotspot
 and java.base
In-Reply-To: 
References: 
Message-ID: <4JpasHDyu9n0P6aT7kW33MaTrwaEmYsOFBjmo6N6vso=.03ee31f3-a611-496b-ad09-387ec3a3175c@github.com>

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov  wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java line 84:

> 82: 
> 83:     /**
> 84:      * Create a Zip file that will result in an Zip64 Extra (EXT) header

"result in a Zip64..."

test/jdk/sun/security/tools/jarsigner/OldSig.java line 32:

> 30: /*
> 31:  * See also PreserveRawManifestEntryAndDigest.java for tests with arbitrarily
> 32:  * formatted individual sections in addition the main attributes tested

"in addition to the..."

-------------

PR: https://git.openjdk.java.net/jdk/pull/8768

From kevinw at openjdk.java.net  Thu May 19 09:41:57 2022
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Thu, 19 May 2022 09:41:57 GMT
Subject:  RFR: 8284191: Replace usages of 'a the' in hotspot
 and java.base
In-Reply-To: 
References: 
Message-ID: 

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov  wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

OK.  I started with serviceability but then went through everything as it's hard to record what you have/haven't seen in these long reviews.

test/jdk/java/net/InterfaceAddress/Equals.java line 81:

> 79:     /**
> 80:      * Returns an InterfaceAddress instance with its fields set the values
> 81:      * specificed.

probably a typo for "set to the values specified."

-------------

Marked as reviewed by kevinw (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8768

From rriggs at openjdk.java.net  Thu May 19 14:36:43 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 19 May 2022 14:36:43 GMT
Subject:  RFR: 8267038: Update IANA Language Subtag Registry
 to Version 2022-03-02
In-Reply-To: 
References: 
Message-ID: 

On Wed, 18 May 2022 16:28:02 GMT, Naoto Sato  wrote:

> This is to incorporate the latest language subtag registry definition (version 2022-03-02) into JDK19.

Looks fine.

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8776

From xuelei at openjdk.java.net  Thu May 19 14:58:49 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 19 May 2022 14:58:49 GMT
Subject:  RFR: 8284191: Replace usages of 'a the' in hotspot
 and java.base
In-Reply-To: <4JpasHDyu9n0P6aT7kW33MaTrwaEmYsOFBjmo6N6vso=.03ee31f3-a611-496b-ad09-387ec3a3175c@github.com>
References: 
 <4JpasHDyu9n0P6aT7kW33MaTrwaEmYsOFBjmo6N6vso=.03ee31f3-a611-496b-ad09-387ec3a3175c@github.com>
Message-ID: 

On Thu, 19 May 2022 09:31:07 GMT, Kevin Walls  wrote:

>> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
>> 
>> Also, I fixed a couple of spelling mistakes.
>
> test/jdk/sun/security/tools/jarsigner/OldSig.java line 32:
> 
>> 30: /*
>> 31:  * See also PreserveRawManifestEntryAndDigest.java for tests with arbitrarily
>> 32:  * formatted individual sections in addition the main attributes tested
> 
> "in addition to the..."

+1.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8768

From xuelei at openjdk.java.net  Thu May 19 14:58:48 2022
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 19 May 2022 14:58:48 GMT
Subject:  RFR: 8284191: Replace usages of 'a the' in hotspot
 and java.base
In-Reply-To: 
References: 
Message-ID: 

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov  wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

The security/crypto parts look good to me.

-------------

Marked as reviewed by xuelei (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8768

From naoto at openjdk.java.net  Thu May 19 18:53:53 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 19 May 2022 18:53:53 GMT
Subject:  Integrated: 8267038: Update IANA Language Subtag
 Registry to Version 2022-03-02
In-Reply-To: 
References: 
Message-ID: <2GtR8PtSUO2KoohdPPb-jv8JDbbnD2IYVo_VEdR-BJs=.64dfaf2d-d04f-4e96-8ca5-08940b8ac4ee@github.com>

On Wed, 18 May 2022 16:28:02 GMT, Naoto Sato  wrote:

> This is to incorporate the latest language subtag registry definition (version 2022-03-02) into JDK19.

This pull request has now been integrated.

Changeset: 7b19226b
Author:    Naoto Sato 
URL:       https://git.openjdk.java.net/jdk/commit/7b19226be24356572df493446e3b0a9380b3d217
Stats:     281 lines in 2 files changed: 271 ins; 2 del; 8 mod

8267038: Update IANA Language Subtag Registry to Version 2022-03-02

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/8776

From aivanov at openjdk.java.net  Thu May 19 18:54:04 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 19 May 2022 18:54:04 GMT
Subject:  RFR: 8284191: Replace usages of 'a the' in hotspot
 and java.base [v2]
In-Reply-To: 
References: 
Message-ID: 

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Alexey Ivanov has updated the pull request incrementally with seven additional commits since the last revision:

 - ...set to the values...
 - ...will result in a Zip64 Extra (EXT) header
 - ...in addition to the main attributes...
 - ...and the address of the current archive
 - Merges the stack at the given bci...
 - Returns a single ...
 - ...when a peer shuts down an association.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8768/files
  - new: https://git.openjdk.java.net/jdk/pull/8768/files/c7e73658..0669cdc1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=00-01

  Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8768/head:pull/8768

PR: https://git.openjdk.java.net/jdk/pull/8768

From aivanov at openjdk.java.net  Thu May 19 18:59:57 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 19 May 2022 18:59:57 GMT
Subject:  RFR: 8284191: Replace usages of 'a the' in hotspot
 and java.base [v2]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 19 May 2022 08:47:47 GMT, Kevin Walls  wrote:

>> Alexey Ivanov has updated the pull request incrementally with seven additional commits since the last revision:
>> 
>>  - ...set to the values...
>>  - ...will result in a Zip64 Extra (EXT) header
>>  - ...in addition to the main attributes...
>>  - ...and the address of the current archive
>>  - Merges the stack at the given bci...
>>  - Returns a single ...
>>  - ...when a peer shuts down an association.
>
> src/jdk.jdi/share/classes/com/sun/jdi/ClassType.java line 348:
> 
>> 346: 
>> 347:     /**
>> 348:      * Returns the single non-abstract {@link Method} visible from
> 
> I would think "Returns a single ..." because the implementation returns the first match it finds, from possibly many.

I've accepted it, yet I'm still unsure whether ?a? or ?the??

-------------

PR: https://git.openjdk.java.net/jdk/pull/8768

From aivanov at openjdk.java.net  Thu May 19 19:06:56 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Thu, 19 May 2022 19:06:56 GMT
Subject:  RFR: 8284191: Replace usages of 'a the' in hotspot
 and java.base [v2]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 19 May 2022 09:38:40 GMT, Kevin Walls  wrote:

>> Alexey Ivanov has updated the pull request incrementally with seven additional commits since the last revision:
>> 
>>  - ...set to the values...
>>  - ...will result in a Zip64 Extra (EXT) header
>>  - ...in addition to the main attributes...
>>  - ...and the address of the current archive
>>  - Merges the stack at the given bci...
>>  - Returns a single ...
>>  - ...when a peer shuts down an association.
>
> OK.  I started with serviceability but then went through everything as it's hard to record what you have/haven't seen in these long reviews.

Thank you @kevinjwalls for your suggestions. I've incorporated them.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8768

From aturbanov at openjdk.java.net  Thu May 19 21:24:20 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Thu, 19 May 2022 21:24:20 GMT
Subject:  RFR: 8287053: Avoid redundant HashMap.containsKey calls
 in ZoneInfoFile.getZoneInfo0
Message-ID: 

Instead of pair `HashMap.containsKey`/`HashMap.get` method calls, we can use single call `HashMap.getOrDefault`.
It's faster and clearer.

-------------

Commit messages:
 - [PATCH] Avoid redundant HashMap.containsKey calls in ZoneInfoFile

Changes: https://git.openjdk.java.net/jdk/pull/8487/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8487&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287053
  Stats: 6 lines in 1 file changed: 0 ins; 3 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8487.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8487/head:pull/8487

PR: https://git.openjdk.java.net/jdk/pull/8487

From redestad at openjdk.java.net  Fri May 20 08:19:03 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 20 May 2022 08:19:03 GMT
Subject:  RFR: 8287053: Avoid redundant HashMap.containsKey
 calls in ZoneInfoFile.getZoneInfo0
In-Reply-To: 
References: 
Message-ID: 

On Sat, 30 Apr 2022 17:00:03 GMT, Andrey Turbanov  wrote:

> Instead of pair `HashMap.containsKey`/`HashMap.get` method calls, we can use single call `HashMap.getOrDefault`.
> It's faster and clearer.

Marked as reviewed by redestad (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8487

From ihse at openjdk.java.net  Fri May 20 08:42:44 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 20 May 2022 08:42:44 GMT
Subject:  RFR: 8284209: Replace remaining usages of 'a the' in
 source code
In-Reply-To: 
References: 
Message-ID: 

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov  wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Build changes look good. Thanks for the cleanup!

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8771

From naoto at openjdk.java.net  Fri May 20 15:52:50 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 20 May 2022 15:52:50 GMT
Subject:  RFR: 8287053: Avoid redundant HashMap.containsKey
 calls in ZoneInfoFile.getZoneInfo0
In-Reply-To: 
References: 
Message-ID: 

On Sat, 30 Apr 2022 17:00:03 GMT, Andrey Turbanov  wrote:

> Instead of pair `HashMap.containsKey`/`HashMap.get` method calls, we can use single call `HashMap.getOrDefault`.
> It's faster and clearer.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8487

From rriggs at openjdk.java.net  Fri May 20 15:52:51 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 20 May 2022 15:52:51 GMT
Subject:  RFR: 8287053: Avoid redundant HashMap.containsKey
 calls in ZoneInfoFile.getZoneInfo0
In-Reply-To: 
References: 
Message-ID: 

On Sat, 30 Apr 2022 17:00:03 GMT, Andrey Turbanov  wrote:

> Instead of pair `HashMap.containsKey`/`HashMap.get` method calls, we can use single call `HashMap.getOrDefault`.
> It's faster and clearer.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8487

From rriggs at openjdk.java.net  Fri May 20 18:49:04 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 20 May 2022 18:49:04 GMT
Subject:  RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v10]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 17 May 2022 23:40:04 GMT, Naoto Sato  wrote:

>> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding 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 13 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8279185
>  - Addressing review comments
>  - Revert to use the default method
>  - Removed unnecessary package names
>  - Modified class desc of `IsoFields`
>  - abstract class -> top level interface
>  - interface -> abstract class
>  - Removed the method
>  - Changed to use a type to determine ISO based or not
>  - Renamed the new method
>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/2761b08b...3f69909f

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7683

From joehw at openjdk.java.net  Fri May 20 19:32:57 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 20 May 2022 19:32:57 GMT
Subject:  RFR: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate [v10]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 17 May 2022 23:40:04 GMT, Naoto Sato  wrote:

>> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding 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 13 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8279185
>  - Addressing review comments
>  - Revert to use the default method
>  - Removed unnecessary package names
>  - Modified class desc of `IsoFields`
>  - abstract class -> top level interface
>  - interface -> abstract class
>  - Removed the method
>  - Changed to use a type to determine ISO based or not
>  - Renamed the new method
>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/3b1d6d84...3f69909f

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7683

From aturbanov at openjdk.java.net  Mon May 23 08:32:02 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Mon, 23 May 2022 08:32:02 GMT
Subject:  Integrated: 8287053: Avoid redundant HashMap.containsKey
 calls in ZoneInfoFile.getZoneInfo0
In-Reply-To: 
References: 
Message-ID: 

On Sat, 30 Apr 2022 17:00:03 GMT, Andrey Turbanov  wrote:

> Instead of pair `HashMap.containsKey`/`HashMap.get` method calls, we can use single call `HashMap.getOrDefault`.
> It's faster and clearer.

This pull request has now been integrated.

Changeset: 01916e19
Author:    Andrey Turbanov 
URL:       https://git.openjdk.java.net/jdk/commit/01916e192039bebbb93f5a09eb3ca9ec31ee707f
Stats:     5 lines in 1 file changed: 0 ins; 3 del; 2 mod

8287053: Avoid redundant HashMap.containsKey calls in ZoneInfoFile.getZoneInfo0

Reviewed-by: redestad, naoto, rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/8487

From naoto at openjdk.java.net  Mon May 23 16:25:03 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 23 May 2022 16:25:03 GMT
Subject:  Integrated: 8279185: Support for IsoFields in
 JapaneseDate/MinguoDate/ThaiBuddhistDate
In-Reply-To: 
References: 
Message-ID: 

On Thu, 3 Mar 2022 19:33:31 GMT, Naoto Sato  wrote:

> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted.

This pull request has now been integrated.

Changeset: ef7a9f81
Author:    Naoto Sato 
URL:       https://git.openjdk.java.net/jdk/commit/ef7a9f817096d5fac8ed624cadb087fcbe5eb98a
Stats:     282 lines in 13 files changed: 244 ins; 10 del; 28 mod

8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate

Reviewed-by: joehw, rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/7683

From aivanov at openjdk.java.net  Mon May 23 20:06:57 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 23 May 2022 20:06:57 GMT
Subject:  RFR: 8284191: Replace usages of 'a the' in hotspot
 and java.base [v3]
In-Reply-To: 
References: 
Message-ID: <3E93xe0v68L9AHsT3c5D58_5OdaSDEGtdg5ih7TTkfk=.45bed80f-be56-49e8-9dfb-a7fa70b9ea23@github.com>

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright to 2022

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8768/files
  - new: https://git.openjdk.java.net/jdk/pull/8768/files/0669cdc1..fa2caaec

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8768&range=01-02

  Stats: 102 lines in 102 files changed: 0 ins; 0 del; 102 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8768/head:pull/8768

PR: https://git.openjdk.java.net/jdk/pull/8768

From aivanov at openjdk.java.net  Mon May 23 20:46:23 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Mon, 23 May 2022 20:46:23 GMT
Subject:  RFR: 8284209: Replace remaining usages of 'a the' in
 source code [v2]
In-Reply-To: 
References: 
Message-ID: <6pmdug3Hpy1LPgcb-OIdMP6XuOWpWYngOju7mFPdDV4=.a68d1c15-58a3-4ffa-b94d-a1a14666f9eb@github.com>

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Alexey Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge master
 - 8284209: Replace remaining usages of 'the a' in source code
 - 8284209: Replace remaining usages of 'the a' in source code
 - 8284209: Replace remaining usages of 'the a' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'the the' in source code
 - 8284209: Replace remaining usages of 'an? an?' in source code
 - 8284209: Replace remaining usages of 'a the' in source code
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/5b7d066c...fab0a4bb

-------------

Changes: https://git.openjdk.java.net/jdk/pull/8771/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8771&range=01
  Stats: 50 lines in 40 files changed: 0 ins; 2 del; 48 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8771.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8771/head:pull/8771

PR: https://git.openjdk.java.net/jdk/pull/8771

From aturbanov at openjdk.java.net  Mon May 23 20:51:16 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Mon, 23 May 2022 20:51:16 GMT
Subject:  RFR: 8287181: Avoid redundant HashMap.containsKey calls
 in InternalLocaleBuilder.setExtension
Message-ID: 

No need to separately perform `HashMap.containsKey` before `HashMap.remove` call. If key is present - it will be removed anyway. If it's not present, nothing will be deleted.

-------------

Commit messages:
 - [PATCH] Avoid redundant HashMap.containsKey calls in InternalLocaleBuilder

Changes: https://git.openjdk.java.net/jdk/pull/8488/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8488&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287181
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8488.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8488/head:pull/8488

PR: https://git.openjdk.java.net/jdk/pull/8488

From aivanov at openjdk.java.net  Tue May 24 09:52:29 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 24 May 2022 09:52:29 GMT
Subject:  RFR: 8284209: Replace remaining usages of 'a the' in
 source code [v3]
In-Reply-To: 
References: 
Message-ID: 

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright to 2022

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8771/files
  - new: https://git.openjdk.java.net/jdk/pull/8771/files/fab0a4bb..4d529f79

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8771&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8771&range=01-02

  Stats: 24 lines in 24 files changed: 0 ins; 0 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8771.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8771/head:pull/8771

PR: https://git.openjdk.java.net/jdk/pull/8771

From lancea at openjdk.java.net  Tue May 24 09:58:42 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 24 May 2022 09:58:42 GMT
Subject:  RFR: 8284209: Replace remaining usages of 'a the' in
 source code [v3]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 24 May 2022 09:52:29 GMT, Alexey Ivanov  wrote:

>> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
>> 
>> It's the last issue in the series, and it still touches different areas of the code.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright to 2022

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8771

From aivanov at openjdk.java.net  Tue May 24 11:28:50 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 24 May 2022 11:28:50 GMT
Subject:  Integrated: 8284191: Replace usages of 'a the' in
 hotspot and java.base
In-Reply-To: 
References: 
Message-ID: 

On Wed, 18 May 2022 13:27:24 GMT, Alexey Ivanov  wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> Also, I fixed a couple of spelling mistakes.

This pull request has now been integrated.

Changeset: e0d361ce
Author:    Alexey Ivanov 
URL:       https://git.openjdk.java.net/jdk/commit/e0d361cea91d3dd1450aece73f660b4abb7ce5fa
Stats:     303 lines in 162 files changed: 0 ins; 11 del; 292 mod

8284191: Replace usages of 'a the' in hotspot and java.base

Reviewed-by: lancea, wetmore, naoto, iris, kevinw, xuelei

-------------

PR: https://git.openjdk.java.net/jdk/pull/8768

From naoto at openjdk.java.net  Tue May 24 13:11:40 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 24 May 2022 13:11:40 GMT
Subject:  RFR: 8287181: Avoid redundant HashMap.containsKey
 calls in InternalLocaleBuilder.setExtension
In-Reply-To: 
References: 
Message-ID: <0y1YxpBNBcJbdc6T5LsNvbdyl4hyeR0jZopfZ-OelK0=.18563cd8-5ec1-467e-ad60-5984c09c915a@github.com>

On Sat, 30 Apr 2022 17:10:55 GMT, Andrey Turbanov  wrote:

> No need to separately perform `HashMap.containsKey` before `HashMap.remove` call. If key is present - it will be removed anyway. If it's not present, nothing will be deleted.

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8488

From rriggs at openjdk.java.net  Tue May 24 15:16:04 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 24 May 2022 15:16:04 GMT
Subject:  RFR: 8287181: Avoid redundant HashMap.containsKey
 calls in InternalLocaleBuilder.setExtension
In-Reply-To: 
References: 
Message-ID: 

On Sat, 30 Apr 2022 17:10:55 GMT, Andrey Turbanov  wrote:

> No need to separately perform `HashMap.containsKey` before `HashMap.remove` call. If key is present - it will be removed anyway. If it's not present, nothing will be deleted.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8488

From aivanov at openjdk.java.net  Tue May 24 20:12:09 2022
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Tue, 24 May 2022 20:12:09 GMT
Subject:  Integrated: 8284209: Replace remaining usages of 'a the'
 in source code
In-Reply-To: 
References: 
Message-ID: 

On Wed, 18 May 2022 14:46:42 GMT, Alexey Ivanov  wrote:

> Replaces usages of articles that follow each other in all combinations: a/the, an?/an?, the/the?
> 
> It's the last issue in the series, and it still touches different areas of the code.

This pull request has now been integrated.

Changeset: 9b7e42c0
Author:    Alexey Ivanov 
URL:       https://git.openjdk.java.net/jdk/commit/9b7e42c0f078db778dda1011d85cd92e3e4eb979
Stats:     74 lines in 40 files changed: 0 ins; 2 del; 72 mod

8284209: Replace remaining usages of 'a the' in source code

Reviewed-by: lancea, wetmore, dfuchs, iris, jjg, ihse

-------------

PR: https://git.openjdk.java.net/jdk/pull/8771

From aturbanov at openjdk.java.net  Wed May 25 07:28:00 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Wed, 25 May 2022 07:28:00 GMT
Subject:  Integrated: 8287181: Avoid redundant HashMap.containsKey
 calls in InternalLocaleBuilder.setExtension
In-Reply-To: 
References: 
Message-ID: 

On Sat, 30 Apr 2022 17:10:55 GMT, Andrey Turbanov  wrote:

> No need to separately perform `HashMap.containsKey` before `HashMap.remove` call. If key is present - it will be removed anyway. If it's not present, nothing will be deleted.

This pull request has now been integrated.

Changeset: 65850431
Author:    Andrey Turbanov 
URL:       https://git.openjdk.java.net/jdk/commit/65850431edd321c4cf49875f756ae28449c9f710
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8287181: Avoid redundant HashMap.containsKey calls in InternalLocaleBuilder.setExtension

Reviewed-by: naoto, rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/8488

From naoto at openjdk.java.net  Wed May 25 16:50:32 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 25 May 2022 16:50:32 GMT
Subject:  RFR: 8287187: Utilize HashMap.newHashMap() in
 CLDRConverter
Message-ID: 

Refactoring the leftover self-calculations of the optimized `HashMap` initial value with `newHashMap()` method. Also replaced some string literals using text blocks for better readability. Confirmed that the output resource bundle sources are effectively (sans indentation) the same as the original ones.

-------------

Commit messages:
 - 8287187: Utilize HashMap.newHashMap() in CLDRConverter

Changes: https://git.openjdk.java.net/jdk/pull/8887/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8887&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287187
  Stats: 65 lines in 1 file changed: 8 ins; 1 del; 56 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8887.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8887/head:pull/8887

PR: https://git.openjdk.java.net/jdk/pull/8887

From naoto at openjdk.java.net  Wed May 25 17:15:18 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 25 May 2022 17:15:18 GMT
Subject:  RFR: 8287187: Utilize HashMap.newHashMap() in
 CLDRConverter [v2]
In-Reply-To: 
References: 
Message-ID: 

> Refactoring the leftover self-calculations of the optimized `HashMap` initial value with `newHashMap()` method. Also replaced some string literals using text blocks for better readability. Confirmed that the output resource bundle sources are effectively (sans indentation) the same as the original ones.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  minor fixup

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8887/files
  - new: https://git.openjdk.java.net/jdk/pull/8887/files/faab3ea1..c2cc3391

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8887&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8887&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8887.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8887/head:pull/8887

PR: https://git.openjdk.java.net/jdk/pull/8887

From joehw at openjdk.java.net  Wed May 25 20:47:42 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 25 May 2022 20:47:42 GMT
Subject:  RFR: 8287187: Utilize HashMap.newHashMap() in
 CLDRConverter [v2]
In-Reply-To: 
References: 

Message-ID: 

On Wed, 25 May 2022 17:15:18 GMT, Naoto Sato  wrote:

>> Refactoring the leftover self-calculations of the optimized `HashMap` initial value with `newHashMap()` method. Also replaced some string literals using text blocks for better readability. Confirmed that the output resource bundle sources are effectively (sans indentation) the same as the original ones.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor fixup

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8887

From naoto at openjdk.java.net  Thu May 26 15:55:41 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 26 May 2022 15:55:41 GMT
Subject:  Integrated: 8287187: Utilize HashMap.newHashMap() in
 CLDRConverter
In-Reply-To: 
References: 
Message-ID: 

On Wed, 25 May 2022 16:43:59 GMT, Naoto Sato  wrote:

> Refactoring the leftover self-calculations of the optimized `HashMap` initial value with `newHashMap()` method. Also replaced some string literals using text blocks for better readability. Confirmed that the output resource bundle sources are effectively (sans indentation) the same as the original ones.

This pull request has now been integrated.

Changeset: c10749a6
Author:    Naoto Sato 
URL:       https://git.openjdk.java.net/jdk/commit/c10749a6a70977fbd6cd33b298410d212276fcf1
Stats:     65 lines in 1 file changed: 8 ins; 1 del; 56 mod

8287187: Utilize HashMap.newHashMap() in CLDRConverter

Reviewed-by: joehw

-------------

PR: https://git.openjdk.java.net/jdk/pull/8887

From duke at openjdk.java.net  Mon May 30 15:21:29 2022
From: duke at openjdk.java.net (Gaurav Chaudhari)
Date: Mon, 30 May 2022 15:21:29 GMT
Subject:  RFR: 8285838: DST not applying properly with zone id
 offset set with TZ env variable [v2]
In-Reply-To: 
References: 
Message-ID: <3Aj7iQ9CH4wSg_1bf_8gX7MPMrIhzHi92SQED8UInnQ=.6ea9fc33-1d8c-4bd1-9399-c07330326fa4@github.com>

> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.

Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision:

  8285838: Revised changes for Custom TZ DST test fixes.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8661/files
  - new: https://git.openjdk.java.net/jdk/pull/8661/files/dcf762a5..41e75494

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8661&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8661&range=00-01

  Stats: 94 lines in 3 files changed: 20 ins; 62 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8661.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8661/head:pull/8661

PR: https://git.openjdk.java.net/jdk/pull/8661

From duke at openjdk.java.net  Mon May 30 15:21:30 2022
From: duke at openjdk.java.net (Gaurav Chaudhari)
Date: Mon, 30 May 2022 15:21:30 GMT
Subject:  RFR: 8285838: DST not applying properly with zone id
 offset set with TZ env variable [v2]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 17 May 2022 20:19:28 GMT, Naoto Sato  wrote:

>> Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8285838: Revised changes for Custom TZ DST test fixes.
>
> src/java.base/unix/native/libjava/TimeZone_md.c line 609:
> 
>> 607:     }
>> 608: 
>> 609:     offset = (gmt.tm_hour - localtm.tm_hour)*3600 + (gmt.tm_min - localtm.tm_min)*60;
> 
> Since it is not using `timezone` anymore, we can reverse the subtraction, i.e., `localtime` - `gmtime` so that the weird sign switch below can be eliminated.

I've reversed it and reverted the weird sign switching below this code snippet.

> test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2001, 2022, Oracle and/or its affiliates. All rights reserved.
> 
> This is a new test case, the year should be only 2022.

Thanks, corrected this in the following commit

> test/jdk/java/util/TimeZone/runCustomTzIDCheckDST.sh line 1:
> 
>> 1: #
> 
> I'd change this script into a java test case (using `.sh` is not recommended). In fact, this causes a failure invoking `javac` with `-Xmx768m` (from TESTVMOPTS)
> There are libraries under `jdk/test/lib/` for building test jvm process and tools.

I did away with this .sh script and combined the shell script and java test into one. Initially the only purpose of this shell script was in order to set up the environment variable for the proceeding test. However, I learnt that all this could be done within java, and I consolidated both the files into one test now.

> test/jdk/java/util/TimeZone/runCustomTzIDCheckDST.sh line 40:
> 
>> 38: 
>> 39: OS=`uname -s`
>> 40: case "$OS" in 
> 
> In case other than Linux/AIX, it would be helpful to emit some message that the test is ignored.

All moved to one java test now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8661

From duke at openjdk.java.net  Mon May 30 15:32:36 2022
From: duke at openjdk.java.net (Gaurav Chaudhari)
Date: Mon, 30 May 2022 15:32:36 GMT
Subject:  RFR: 8285838: DST not applying properly with zone id
 offset set with TZ env variable [v3]
In-Reply-To: 
References: 
Message-ID: 

> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.

Gaurav Chaudhari has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch '8285838' of github.com:Deigue/jdk into 8285838
 - 8285838: Revised changes for Custom TZ DST test fixes.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8661/files
  - new: https://git.openjdk.java.net/jdk/pull/8661/files/41e75494..b80af8bf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8661&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8661&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8661.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8661/head:pull/8661

PR: https://git.openjdk.java.net/jdk/pull/8661

From duke at openjdk.java.net  Mon May 30 15:40:37 2022
From: duke at openjdk.java.net (Gaurav Chaudhari)
Date: Mon, 30 May 2022 15:40:37 GMT
Subject:  RFR: 8285838: DST not applying properly with zone id
 offset set with TZ env variable [v4]
In-Reply-To: 
References: 
Message-ID: 

> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.

Gaurav Chaudhari has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch '8285838' of github.com:Deigue/jdk into 8285838
 - Merge branch '8285838' of github.com:Deigue/jdk into 8285838

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8661/files
  - new: https://git.openjdk.java.net/jdk/pull/8661/files/b80af8bf..d7831659

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8661&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8661&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8661.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8661/head:pull/8661

PR: https://git.openjdk.java.net/jdk/pull/8661

From naoto at openjdk.java.net  Tue May 31 17:25:42 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 31 May 2022 17:25:42 GMT
Subject:  RFR: 8285838: DST not applying properly with zone id
 offset set with TZ env variable [v4]
In-Reply-To: 
References: 

Message-ID: 

On Mon, 30 May 2022 15:40:37 GMT, Gaurav Chaudhari  wrote:

>> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.
>
> Gaurav Chaudhari has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch '8285838' of github.com:Deigue/jdk into 8285838
>  - Merge branch '8285838' of github.com:Deigue/jdk into 8285838

test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java line 67:

> 65:         if ((month > Month.MARCH.getValue() && month < Month.OCTOBER.getValue()) ||
> 66:                 (month == Month.MARCH.getValue() && date.isAfter(getLastSundayOfMonth(date))) ||
> 67:                 (month == Month.OCTOBER.getValue() && date.isBefore(getLastSundayOfMonth(date)))) {

I don't think these conditions are correct, as `month` is zero-based, and comparing it with `Month.MARCH` will be incorrect. The same holds for October.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8661

From naoto at openjdk.java.net  Tue May 31 17:53:10 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 31 May 2022 17:53:10 GMT
Subject:  RFR: 8287340: Refactor old code using StringTokenizer in
 locale related code
Message-ID: 

Refactoring some old code in locale providers. The test case data have also been modified due to:
- There's a bug in `LocaleProviderAdapter.toLocaleArray()` where it did not handle the case for `no-NO-NY`.
- `Locale.toLanguageTag()` won't handle legacy Java locales, e.g., `ja_JP_JP` and falls back, so comparing locales using language tags does not work for those locales. Changed to compare with `Locale.toString()` instead.

-------------

Commit messages:
 - 8287340: Refactor old code using StringTokenizer in locale related code

Changes: https://git.openjdk.java.net/jdk/pull/8960/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8960&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287340
  Stats: 175 lines in 4 files changed: 6 ins; 61 del; 108 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8960.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8960/head:pull/8960

PR: https://git.openjdk.java.net/jdk/pull/8960

From duke at openjdk.java.net  Tue May 31 19:46:26 2022
From: duke at openjdk.java.net (Gaurav Chaudhari)
Date: Tue, 31 May 2022 19:46:26 GMT
Subject:  RFR: 8285838: DST not applying properly with zone id
 offset set with TZ env variable [v4]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 31 May 2022 17:21:50 GMT, Naoto Sato  wrote:

>> Gaurav Chaudhari has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch '8285838' of github.com:Deigue/jdk into 8285838
>>  - Merge branch '8285838' of github.com:Deigue/jdk into 8285838
>
> test/jdk/java/util/TimeZone/CustomTzIDCheckDST.java line 67:
> 
>> 65:         if ((month > Month.MARCH.getValue() && month < Month.OCTOBER.getValue()) ||
>> 66:                 (month == Month.MARCH.getValue() && date.isAfter(getLastSundayOfMonth(date))) ||
>> 67:                 (month == Month.OCTOBER.getValue() && date.isBefore(getLastSundayOfMonth(date)))) {
> 
> I don't think these conditions are correct, as `month` is zero-based, and comparing it with `Month.MARCH` will be incorrect. The same holds for October.

Oh thats true, just verified this by printing out the values. Will fix by adding 1 to the month for sensible direct comparison against the singleton instances.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8661

From iris at openjdk.java.net  Tue May 31 20:09:33 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 31 May 2022 20:09:33 GMT
Subject:  RFR: 8287340: Refactor old code using
 StringTokenizer in locale related code
In-Reply-To: 
References: 
Message-ID: 

On Tue, 31 May 2022 17:46:18 GMT, Naoto Sato  wrote:

> Refactoring some old code in locale providers. The test case data have also been modified due to:
> - There's a bug in `LocaleProviderAdapter.toLocaleArray()` where it did not handle the case for `no-NO-NY`.
> - `Locale.toLanguageTag()` won't handle legacy Java locales, e.g., `ja_JP_JP` and falls back, so comparing locales using language tags does not work for those locales. Changed to compare with `Locale.toString()` instead.

Very nice code moderization.

-------------

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8960

From duke at openjdk.java.net  Tue May 31 20:10:44 2022
From: duke at openjdk.java.net (Gaurav Chaudhari)
Date: Tue, 31 May 2022 20:10:44 GMT
Subject:  RFR: 8285838: DST not applying properly with zone id
 offset set with TZ env variable [v5]
In-Reply-To: 
References: 
Message-ID: <7SpDwS0sWsYuaiBdJqhhqUPEyc7gcBcL4mExUW3RE_4=.a62ad8f9-7fe9-4d45-92b9-74222698e845@github.com>

> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.

Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision:

  8285838: Corrected month comparison check for TZ DST

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8661/files
  - new: https://git.openjdk.java.net/jdk/pull/8661/files/d7831659..9e3b1bb4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8661&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8661&range=03-04

  Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8661.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8661/head:pull/8661

PR: https://git.openjdk.java.net/jdk/pull/8661

From joehw at openjdk.java.net  Tue May 31 20:44:36 2022
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 31 May 2022 20:44:36 GMT
Subject:  RFR: 8287340: Refactor old code using
 StringTokenizer in locale related code
In-Reply-To: 
References: 
Message-ID: 

On Tue, 31 May 2022 17:46:18 GMT, Naoto Sato  wrote:

> Refactoring some old code in locale providers. The test case data have also been modified due to:
> - There's a bug in `LocaleProviderAdapter.toLocaleArray()` where it did not handle the case for `no-NO-NY`.
> - `Locale.toLanguageTag()` won't handle legacy Java locales, e.g., `ja_JP_JP` and falls back, so comparing locales using language tags does not work for those locales. Changed to compare with `Locale.toString()` instead.

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8960

From naoto at openjdk.java.net  Tue May 31 22:37:52 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 31 May 2022 22:37:52 GMT
Subject:  RFR: 8285838: DST not applying properly with zone id
 offset set with TZ env variable [v5]
In-Reply-To: <7SpDwS0sWsYuaiBdJqhhqUPEyc7gcBcL4mExUW3RE_4=.a62ad8f9-7fe9-4d45-92b9-74222698e845@github.com>
References: 
 <7SpDwS0sWsYuaiBdJqhhqUPEyc7gcBcL4mExUW3RE_4=.a62ad8f9-7fe9-4d45-92b9-74222698e845@github.com>
Message-ID: 

On Tue, 31 May 2022 20:10:44 GMT, Gaurav Chaudhari  wrote:

>> This fix ensures that when a lookup for a custom TZ code fails, and an attempt is made to find the GMT offset in order to get the current time, Daylight savings rules are applied correctly.
>
> Gaurav Chaudhari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8285838: Corrected month comparison check for TZ DST

I tried out your patch on my local Linux machine, but the new test failed with the following exception:

ACTION: main -- Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Expected to get exit value of [0]
REASON: User specified action: run main/othervm CustomTzIDCheckDST 
TIME:   1.564 seconds
messages:
command: main CustomTzIDCheckDST
reason: User specified action: run main/othervm CustomTzIDCheckDST 
Mode: othervm [/othervm specified]
elapsed time (seconds): 1.564
configuration:
STDOUT:
Command line: [/home/nsato/projects/jdk/git/jdk/build/linux-x64/images/jdk/bin/java -cp /home/nsato/projects/jdk/git/jdk/build/linux-x64/test-support/jtreg_open_test_jdk_java_util_TimeZone/classes/0/java/util/TimeZone/CustomTzIDCheckDST.d:/home/nsato/projects/jdk/git/jdk/open/test/jdk/java/util/TimeZone:/home/nsato/projects/jdk/git/jdk/build/linux-x64/test-support/jtreg_open_test_jdk_java_util_TimeZone/classes/0/test/lib:/home/nsato/projects/jdk/git/jdk/open/test/lib:/var/tmp/jib-nsato/install/jtreg/6.1/1/bundles/jtreg-6.1+1.zip/jtreg/lib/javatest.jar:/var/tmp/jib-nsato/install/jtreg/6.1/1/bundles/jtreg-6.1+1.zip/jtreg/lib/jtreg.jar CustomTzIDCheckDST runTZTest ]
[2022-05-31T22:27:05.958567816Z] Gathering output for process 14771
[2022-05-31T22:27:06.635595481Z] Waiting for completion for process 14771
[2022-05-31T22:27:06.635976964Z] Waiting for completion finished for process 14771
Output and diagnostic info for process 14771 was saved into 'pid-14771-output.log'
[2022-05-31T22:27:06.663087767Z] Waiting for completion for process 14771
[2022-05-31T22:27:06.663360403Z] Waiting for completion finished for process 14771
[2022-05-31T22:27:06.663754609Z] Waiting for completion for process 14771
[2022-05-31T22:27:06.663869034Z] Waiting for completion finished for process 14771
STDERR:
 stdout: [];
 stderr: [Exception in thread "main" java.time.DateTimeException: Invalid ID for offset-based ZoneId: GMT-22:00
	at java.base/java.time.ZoneId.ofWithPrefix(ZoneId.java:436)
	at java.base/java.time.ZoneId.of(ZoneId.java:406)
	at java.base/java.time.ZoneId.of(ZoneId.java:358)
	at java.base/java.time.ZoneId.of(ZoneId.java:314)
	at java.base/java.util.TimeZone.toZoneId0(TimeZone.java:581)
	at java.base/java.util.TimeZone.toZoneId(TimeZone.java:558)
	at java.base/java.util.TimeZone.toZoneId0(TimeZone.java:570)
	at java.base/java.util.TimeZone.toZoneId(TimeZone.java:558)
	at java.base/java.time.ZoneId.systemDefault(ZoneId.java:274)
	at CustomTzIDCheckDST.runTZTest(CustomTzIDCheckDST.java:64)
	at CustomTzIDCheckDST.main(CustomTzIDCheckDST.java:51)
Caused by: java.time.DateTimeException: Zone offset hours not in valid range: value -22 is not in the range -18 to 18
	at java.base/java.time.ZoneOffset.validate(ZoneOffset.java:373)
	at java.base/java.time.ZoneOffset.ofHoursMinutesSeconds(ZoneOffset.java:326)
	at java.base/java.time.ZoneOffset.of(ZoneOffset.java:257)
	at java.base/java.time.ZoneId.ofWithPrefix(ZoneId.java:430)
	... 10 more
]
 exitValue = 1

java.lang.RuntimeException: Expected to get exit value of [0]

	at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:489)
	at CustomTzIDCheckDST.main(CustomTzIDCheckDST.java:49)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:1585)

JavaTest Message: Test threw exception: java.lang.RuntimeException: Expected to get exit value of [0]

JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.RuntimeException: Expected to get exit value of [0]

-------------

PR: https://git.openjdk.java.net/jdk/pull/8661