From zgu at redhat.com  Tue Nov  2 17:45:06 2021
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 2 Nov 2021 13:45:06 -0400
Subject: [8u] RFR 8274779: HttpURLConnection: HttpClient and HttpsClient
 incorrectly check request method when set to POST
Message-ID: <8166d717-68e6-384a-ce9d-d1d69907db78@redhat.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8274779
Patch: 
https://github.com/openjdk/jdk/commit/45ce06c9f3e9bee7d4bda313c38f0f0e8786a4db

I would like to backport this patch to openjdk8u for parity with Oracle 
8u331.

The original patch applies cleanly, but new test needs to be modified 
for 8u.

1) Adjust test library path and name
2) Removed modules
3) Use ClassFileInstaller to build injection class into inject.jar and 
append it to bootclasspath

8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8274779-8u/webrev.00/

Test:
   jdk_net (including the new test)


Thanks,

-Zhengyu


From zgu at redhat.com  Tue Nov  2 18:57:32 2021
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 2 Nov 2021 14:57:32 -0400
Subject: [8u] RFR 8274779: HttpURLConnection: HttpClient and HttpsClient
 incorrectly check request method when set to POST
In-Reply-To: <8166d717-68e6-384a-ce9d-d1d69907db78@redhat.com>
References: <8166d717-68e6-384a-ce9d-d1d69907db78@redhat.com>
Message-ID: <92bd2e9b-ecaa-25dc-1276-2789185e6409@redhat.com>

Forgot to mention:

8u URIBuilder.host() does not take InetAddress as parameter, so changed 
RequestMethodEquality.java#80

.host(server.getAddress().getAddress())  ==> 
.host(server.getAddress().getHostString())


-Zhengyu

On 11/2/21 13:45, Zhengyu Gu wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8274779
> Patch: 
> https://github.com/openjdk/jdk/commit/45ce06c9f3e9bee7d4bda313c38f0f0e8786a4db 
> 
> 
> I would like to backport this patch to openjdk8u for parity with Oracle 
> 8u331.
> 
> The original patch applies cleanly, but new test needs to be modified 
> for 8u.
> 
> 1) Adjust test library path and name
> 2) Removed modules
> 3) Use ClassFileInstaller to build injection class into inject.jar and 
> append it to bootclasspath
> 
> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8274779-8u/webrev.00/
> 
> Test:
>  ? jdk_net (including the new test)
> 
> 
> Thanks,
> 
> -Zhengyu


From hohensee at amazon.com  Tue Nov  2 19:16:17 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 2 Nov 2021 19:16:17 +0000
Subject: [8u] RFR 8274779: HttpURLConnection: HttpClient and HttpsClient
 incorrectly check request method when set to POST
Message-ID: <56832C87-F457-4FB4-B283-7EEA4E81171F@amazon.com>

Looks good, except I'd use "@library /lib/testlibrary" instead of "@library ../../../../../lib/testlibrary" so that the test is independent of its file system location. I know there are a lot of tests that use the latter, but we don't need to make things worse than they are. :)

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Zhengyu Gu <zgu at redhat.com>
Date: Tuesday, November 2, 2021 at 10:46 AM
To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject: [8u] RFR 8274779: HttpURLConnection: HttpClient and HttpsClient incorrectly check request method when set to POST

Bug: https://bugs.openjdk.java.net/browse/JDK-8274779
Patch:
https://github.com/openjdk/jdk/commit/45ce06c9f3e9bee7d4bda313c38f0f0e8786a4db

I would like to backport this patch to openjdk8u for parity with Oracle
8u331.

The original patch applies cleanly, but new test needs to be modified
for 8u.

1) Adjust test library path and name
2) Removed modules
3) Use ClassFileInstaller to build injection class into inject.jar and
append it to bootclasspath

8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8274779-8u/webrev.00/

Test:
   jdk_net (including the new test)


Thanks,

-Zhengyu



From zgu at redhat.com  Tue Nov  2 19:21:48 2021
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 2 Nov 2021 15:21:48 -0400
Subject: [8u] RFR 8274779: HttpURLConnection: HttpClient and HttpsClient
 incorrectly check request method when set to POST
In-Reply-To: <56832C87-F457-4FB4-B283-7EEA4E81171F@amazon.com>
References: <56832C87-F457-4FB4-B283-7EEA4E81171F@amazon.com>
Message-ID: <dc2763e2-d6ec-e248-1e5e-b2c810fc5bbe@redhat.com>

Thanks, Paul.

Updated: http://cr.openjdk.java.net/~zgu/JDK-8274779-8u/webrev.01/

-Zhengyu

On 11/2/21 15:16, Hohensee, Paul wrote:
> Looks good, except I'd use "@library /lib/testlibrary" instead of "@library ../../../../../lib/testlibrary" so that the test is independent of its file system location. I know there are a lot of tests that use the latter, but we don't need to make things worse than they are. :)
> 
> Thanks,
> Paul
> 
> ?-----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Zhengyu Gu <zgu at redhat.com>
> Date: Tuesday, November 2, 2021 at 10:46 AM
> To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
> Subject: [8u] RFR 8274779: HttpURLConnection: HttpClient and HttpsClient incorrectly check request method when set to POST
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8274779
> Patch:
> https://github.com/openjdk/jdk/commit/45ce06c9f3e9bee7d4bda313c38f0f0e8786a4db
> 
> I would like to backport this patch to openjdk8u for parity with Oracle
> 8u331.
> 
> The original patch applies cleanly, but new test needs to be modified
> for 8u.
> 
> 1) Adjust test library path and name
> 2) Removed modules
> 3) Use ClassFileInstaller to build injection class into inject.jar and
> append it to bootclasspath
> 
> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8274779-8u/webrev.00/
> 
> Test:
>     jdk_net (including the new test)
> 
> 
> Thanks,
> 
> -Zhengyu
> 
> 


From hohensee at amazon.com  Tue Nov  2 22:49:25 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 2 Nov 2021 22:49:25 +0000
Subject: [8u] RFR 8274779: HttpURLConnection: HttpClient and HttpsClient
 incorrectly check request method when set to POST
Message-ID: <63A243D4-345F-4F9F-9689-49CDF57FD0FB@amazon.com>

Lgtm.

?-----Original Message-----
From: Zhengyu Gu <zgu at redhat.com>
Date: Tuesday, November 2, 2021 at 12:22 PM
To: "Hohensee, Paul" <hohensee at amazon.com>, jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject: RE: [8u] RFR 8274779: HttpURLConnection: HttpClient and HttpsClient incorrectly check request method when set to POST

Thanks, Paul.

Updated: http://cr.openjdk.java.net/~zgu/JDK-8274779-8u/webrev.01/

-Zhengyu

On 11/2/21 15:16, Hohensee, Paul wrote:
> Looks good, except I'd use "@library /lib/testlibrary" instead of "@library ../../../../../lib/testlibrary" so that the test is independent of its file system location. I know there are a lot of tests that use the latter, but we don't need to make things worse than they are. :)
>
> Thanks,
> Paul
>
> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Zhengyu Gu <zgu at redhat.com>
> Date: Tuesday, November 2, 2021 at 10:46 AM
> To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
> Subject: [8u] RFR 8274779: HttpURLConnection: HttpClient and HttpsClient incorrectly check request method when set to POST
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8274779
> Patch:
> https://github.com/openjdk/jdk/commit/45ce06c9f3e9bee7d4bda313c38f0f0e8786a4db
>
> I would like to backport this patch to openjdk8u for parity with Oracle
> 8u331.
>
> The original patch applies cleanly, but new test needs to be modified
> for 8u.
>
> 1) Adjust test library path and name
> 2) Removed modules
> 3) Use ClassFileInstaller to build injection class into inject.jar and
> append it to bootclasspath
>
> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8274779-8u/webrev.00/
>
> Test:
>     jdk_net (including the new test)
>
>
> Thanks,
>
> -Zhengyu
>
>



From akashche at redhat.com  Wed Nov  3 13:38:51 2021
From: akashche at redhat.com (Alex Kashchenko)
Date: Wed, 3 Nov 2021 13:38:51 +0000
Subject: [8u] RFR: 8198406: Test TestAATMorxFont is unstable
Message-ID: <CABUxsJ15bo2v3GZf2PcOUxi-Z9Lq07XVEW4XcWN2DFt=x04tPQ@mail.gmail.com>

Hi,

Please review a backport of 8198406 to 8u:

Bug: https://bugs.openjdk.java.net/browse/JDK-8198406

Original change: https://hg.openjdk.java.net/jdk/jdk/rev/7f82666c916b

8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8198406/webrev.00/

Patch is test-only, it does not apply cleanly because it depends on
8198333 [1]. It is not clear whether it is a good idea to backport
such large-scale test cleanups (another example is 8185500 [2][3]) so
the patch is modified slightly removing @headful tag. Testing: checked
that updated test passes on Mac, was unable to reproduce the failure
without the patch.

[1] https://bugs.openjdk.java.net/browse/JDK-8198333
[2] https://bugs.openjdk.java.net/browse/JDK-8185500
[3] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-October/014327.html

-- 
-Alex


From jvanek at redhat.com  Thu Nov  4 19:27:30 2021
From: jvanek at redhat.com (Jiri Vanek)
Date: Thu, 4 Nov 2021 20:27:30 +0100
Subject: [8u] RFR bad source/target in Makefile of J2DBench
In-Reply-To: <8d950e2d-22ee-3115-5618-c467edc3ba4a@redhat.com>
References: <0dae8811-f1c1-0371-5283-4c2374f2fbbe@redhat.com>
 <YXazABvztP5wPn2M@hex.discworld.ac.uk>
 <8d950e2d-22ee-3115-5618-c467edc3ba4a@redhat.com>
Message-ID: <e829978a-f72d-0ad8-561d-6fbbf942c39c@redhat.com>

ping please!

On 10/25/21 20:14, Jiri Vanek wrote:
> Thanx!
> 
> webrev adapted: http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/webrev/
> 
> Compared to original, I had dropepd the build.xml change, as it was not relevant.
> 
> The https://bugs.openjdk.java.net/browse/JDK-8042199 is already closed.? Should it be reopened, or new bug will be created?
> 
> Thanx!
>  ?J.
> 
> 
> 
> On 10/25/21 15:37, Andrew Hughes wrote:
>> On 18:56 Thu 21 Oct???? , Jiri Vanek wrote:
>>> http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/
>>>
>>> Hello! the build.xml (https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/d2bbff5b7006/src/share/demo/java2d/J2DBench/build.xml#l52) is corerect,
>>> and have -source/target correctly on 1.5
>>>
>>> However Mkaefile was left behind, and is on 1.2, which jdk8 itself can not play.
>>>
>>>
>>> Am looking forward for kind soul to create a bug a commit on my behalf.
>>>
>>> Happy hacking,
>>> ???? J.
>>> -- 
>>> Jiri Vanek Mgr.
>>> Principal QA Software Engineer
>>> Red Hat Inc.
>>> +420 775 39 01 09
>>>
>>
>> This looks like a subset of:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8042199
>>
>> I think it would be preferable to backport this to keep this code aligned
>> across JDKs. It fixes some other differences between the Makefile &
>> build.xml, as well as actually making it buildable with 1.4, as the
>> README claims.
>>
>> The -g:none addition seemed strange to me, but it seems debug=false
>> has been in build.xml since the start of the OpenJDK project [0].
>> If we want to remove that, we should probably do so in HEAD and
>> backport for consistency across releases.
>>
>> [0] https://mail.openjdk.java.net/pipermail/2d-dev/2014-August/004736.html
>>
> 

-- 
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09


From hohensee at amazon.com  Thu Nov  4 20:47:13 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 4 Nov 2021 20:47:13 +0000
Subject: [8u] RFR bad source/target in Makefile of J2DBench
Message-ID: <EB43B7D9-3DA7-4115-A5B3-4CBB71E9F290@amazon.com>

The use of -source 1.5 -target 1.5 in J2DBench/Makefile doesn't correspond to the comment in the README, which says that 1.6 is the minimum due to jdk9's javac. The original jdk9 patch used -source 1.6 and -target 1.6, so I'd do the same and also leave the README comment alone.  A reference to a later JDK is fine in a backport.

The patch to CMMTests.java is missing the spelling update to the definition and use of usePlatfromProfiles and usePlatfrom. To be sure, it's a nop, but should be done to keep any future backport(s) consistent.

Otherwise lgtm.

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Jiri Vanek <jvanek at redhat.com>
Date: Thursday, November 4, 2021 at 12:29 PM
To: Andrew Hughes <gnu.andrew at redhat.com>
Cc: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: Re: [8u] RFR bad source/target in Makefile of J2DBench

ping please!

On 10/25/21 20:14, Jiri Vanek wrote:
> Thanx!
>
> webrev adapted: http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/webrev/
>
> Compared to original, I had dropepd the build.xml change, as it was not relevant.
>
> The https://bugs.openjdk.java.net/browse/JDK-8042199 is already closed.  Should it be reopened, or new bug will be created?
>
> Thanx!
>   J.
>
>
>
> On 10/25/21 15:37, Andrew Hughes wrote:
>> On 18:56 Thu 21 Oct     , Jiri Vanek wrote:
>>> http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/
>>>
>>> Hello! the build.xml (https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/d2bbff5b7006/src/share/demo/java2d/J2DBench/build.xml#l52) is corerect,
>>> and have -source/target correctly on 1.5
>>>
>>> However Mkaefile was left behind, and is on 1.2, which jdk8 itself can not play.
>>>
>>>
>>> Am looking forward for kind soul to create a bug a commit on my behalf.
>>>
>>> Happy hacking,
>>>      J.
>>> --
>>> Jiri Vanek Mgr.
>>> Principal QA Software Engineer
>>> Red Hat Inc.
>>> +420 775 39 01 09
>>>
>>
>> This looks like a subset of:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8042199
>>
>> I think it would be preferable to backport this to keep this code aligned
>> across JDKs. It fixes some other differences between the Makefile &
>> build.xml, as well as actually making it buildable with 1.4, as the
>> README claims.
>>
>> The -g:none addition seemed strange to me, but it seems debug=false
>> has been in build.xml since the start of the OpenJDK project [0].
>> If we want to remove that, we should probably do so in HEAD and
>> backport for consistency across releases.
>>
>> [0] https://mail.openjdk.java.net/pipermail/2d-dev/2014-August/004736.html
>>
>

--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09



From mbalao at redhat.com  Thu Nov  4 23:28:46 2021
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 4 Nov 2021 19:28:46 -0400
Subject: [8u] RFR 8273826: Correct Manifest file name and NPE checks
Message-ID: <ef90e32b-b271-8e44-6ac3-3e7503364db3@redhat.com>

Hi,

I'd like to request a review for the 8u backport of JDK-8273826 [1].

Webrev.00:

 *
http://cr.openjdk.java.net/~mbalao/webrevs/8273826/8273826.webrev.8u.jdk.00/

The 11u patch does not apply cleanly because:

 * ManifestEntryVerifier.java
  * 8078468 is not in 8u
   * This affects the context only, not the actual code modified. I
don't see it as a blocking dependency. Manually applied the change.

 * LowerCaseManifest.java
  * JarUtils imports and lib path adjusted to 8u location
  * Path.of -> Paths.get replacement

The new 'LowerCaseManifest.java' test passes. No tests regressions in
jdk/sun/security/tools/jarsigner.

Thanks,
Martin.-

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8273826


From sgehwolf at redhat.com  Fri Nov  5 10:13:32 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 05 Nov 2021 11:13:32 +0100
Subject: [8u] RFR 8273826: Correct Manifest file name and NPE checks
In-Reply-To: <ef90e32b-b271-8e44-6ac3-3e7503364db3@redhat.com>
References: <ef90e32b-b271-8e44-6ac3-3e7503364db3@redhat.com>
Message-ID: <1997b119830b50f7219a30030e56e765bf534082.camel@redhat.com>

On Thu, 2021-11-04 at 19:28 -0400, Martin Balao wrote:
> Hi,
> 
> I'd like to request a review for the 8u backport of JDK-8273826 [1].
> 
> Webrev.00:
> 
> ?*
> http://cr.openjdk.java.net/~mbalao/webrevs/8273826/8273826.webrev.8u.jdk.00/
> 
> The 11u patch does not apply cleanly because:
> 
> ?* ManifestEntryVerifier.java
> ? * 8078468 is not in 8u
> ?? * This affects the context only, not the actual code modified. I
> don't see it as a blocking dependency. Manually applied the change.
> 
> ?* LowerCaseManifest.java
> ? * JarUtils imports and lib path adjusted to 8u location
> ? * Path.of -> Paths.get replacement
> 
> The new 'LowerCaseManifest.java' test passes. No tests regressions in
> jdk/sun/security/tools/jarsigner.

This looks good to me.

Thanks,
Severin


From jvanek at redhat.com  Fri Nov  5 14:46:01 2021
From: jvanek at redhat.com (Jiri Vanek)
Date: Fri, 5 Nov 2021 15:46:01 +0100
Subject: [8u] RFR bad source/target in Makefile of J2DBench
In-Reply-To: <EB43B7D9-3DA7-4115-A5B3-4CBB71E9F290@amazon.com>
References: <EB43B7D9-3DA7-4115-A5B3-4CBB71E9F290@amazon.com>
Message-ID: <0f3bbdad-70d0-c3a5-f22a-cab27ac6cd6a@redhat.com>


On 11/4/21 21:47, Hohensee, Paul wrote:
> The use of -source 1.5 -target 1.5 in J2DBench/Makefile doesn't correspond to the comment in the README, which says that 1.6 is the minimum due to jdk9's javac. The original jdk9 patch used -source 1.6 and -target 1.6, so I'd do the same and also leave the README comment alone.  A reference to a later JDK is fine in a backport.

Ok. Will do.

> 
> The patch to CMMTests.java is missing the spelling update to the definition and use of usePlatfromProfiles and usePlatfrom. To be sure, it's a nop, but should be done to keep any future backport(s) consistent.

How that happened. Will double check.


> 
> Otherwise lgtm.
> 
> Thanks,
> Paul
> 
> ?-----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Jiri Vanek <jvanek at redhat.com>
> Date: Thursday, November 4, 2021 at 12:29 PM
> To: Andrew Hughes <gnu.andrew at redhat.com>
> Cc: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
> Subject: Re: [8u] RFR bad source/target in Makefile of J2DBench
> 
> ping please!
> 
> On 10/25/21 20:14, Jiri Vanek wrote:
>> Thanx!
>>
>> webrev adapted: http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/webrev/
>>
>> Compared to original, I had dropepd the build.xml change, as it was not relevant.
>>
>> The https://bugs.openjdk.java.net/browse/JDK-8042199 is already closed.  Should it be reopened, or new bug will be created?
>>
>> Thanx!
>>    J.
>>
>>
>>
>> On 10/25/21 15:37, Andrew Hughes wrote:
>>> On 18:56 Thu 21 Oct     , Jiri Vanek wrote:
>>>> http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/
>>>>
>>>> Hello! the build.xml (https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/d2bbff5b7006/src/share/demo/java2d/J2DBench/build.xml#l52) is corerect,
>>>> and have -source/target correctly on 1.5
>>>>
>>>> However Mkaefile was left behind, and is on 1.2, which jdk8 itself can not play.
>>>>
>>>>
>>>> Am looking forward for kind soul to create a bug a commit on my behalf.
>>>>
>>>> Happy hacking,
>>>>       J.
>>>> --
>>>> Jiri Vanek Mgr.
>>>> Principal QA Software Engineer
>>>> Red Hat Inc.
>>>> +420 775 39 01 09
>>>>
>>>
>>> This looks like a subset of:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8042199
>>>
>>> I think it would be preferable to backport this to keep this code aligned
>>> across JDKs. It fixes some other differences between the Makefile &
>>> build.xml, as well as actually making it buildable with 1.4, as the
>>> README claims.
>>>
>>> The -g:none addition seemed strange to me, but it seems debug=false
>>> has been in build.xml since the start of the OpenJDK project [0].
>>> If we want to remove that, we should probably do so in HEAD and
>>> backport for consistency across releases.
>>>
>>> [0] https://mail.openjdk.java.net/pipermail/2d-dev/2014-August/004736.html
>>>
>>
> 
> --
> Jiri Vanek Mgr.
> Principal QA Software Engineer
> Red Hat Inc.
> +420 775 39 01 09
> 
> 

-- 
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09


From jvanek at redhat.com  Fri Nov  5 15:14:44 2021
From: jvanek at redhat.com (Jiri Vanek)
Date: Fri, 5 Nov 2021 16:14:44 +0100
Subject: [8u] RFR bad source/target in Makefile of J2DBench
In-Reply-To: <0f3bbdad-70d0-c3a5-f22a-cab27ac6cd6a@redhat.com>
References: <EB43B7D9-3DA7-4115-A5B3-4CBB71E9F290@amazon.com>
 <0f3bbdad-70d0-c3a5-f22a-cab27ac6cd6a@redhat.com>
Message-ID: <2ba61562-084b-d9b9-bfab-23bec9caf964@redhat.com>

http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/webrev/

updated. Now is 1:1 with original.

TY!

On 11/5/21 15:46, Jiri Vanek wrote:
> 
> On 11/4/21 21:47, Hohensee, Paul wrote:
>> The use of -source 1.5 -target 1.5 in J2DBench/Makefile doesn't correspond to the comment in the README, which says that 1.6 is the minimum due to jdk9's javac. The original jdk9 patch used -source 1.6 and -target 1.6, so I'd do the same 
>> and also leave the README comment alone.? A reference to a later JDK is fine in a backport.
> 
> Ok. Will do.
> 
>>
>> The patch to CMMTests.java is missing the spelling update to the definition and use of usePlatfromProfiles and usePlatfrom. To be sure, it's a nop, but should be done to keep any future backport(s) consistent.
> 
> How that happened. Will double check.
> 
> 
>>
>> Otherwise lgtm.
>>
>> Thanks,
>> Paul
>>
>> ?-----Original Message-----
>> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Jiri Vanek <jvanek at redhat.com>
>> Date: Thursday, November 4, 2021 at 12:29 PM
>> To: Andrew Hughes <gnu.andrew at redhat.com>
>> Cc: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
>> Subject: Re: [8u] RFR bad source/target in Makefile of J2DBench
>>
>> ping please!
>>
>> On 10/25/21 20:14, Jiri Vanek wrote:
>>> Thanx!
>>>
>>> webrev adapted: http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/webrev/
>>>
>>> Compared to original, I had dropepd the build.xml change, as it was not relevant.
>>>
>>> The https://bugs.openjdk.java.net/browse/JDK-8042199 is already closed.? Should it be reopened, or new bug will be created?
>>>
>>> Thanx!
>>> ?? J.
>>>
>>>
>>>
>>> On 10/25/21 15:37, Andrew Hughes wrote:
>>>> On 18:56 Thu 21 Oct???? , Jiri Vanek wrote:
>>>>> http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/
>>>>>
>>>>> Hello! the build.xml (https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/d2bbff5b7006/src/share/demo/java2d/J2DBench/build.xml#l52) is corerect,
>>>>> and have -source/target correctly on 1.5
>>>>>
>>>>> However Mkaefile was left behind, and is on 1.2, which jdk8 itself can not play.
>>>>>
>>>>>
>>>>> Am looking forward for kind soul to create a bug a commit on my behalf.
>>>>>
>>>>> Happy hacking,
>>>>> ????? J.
>>>>> -- 
>>>>> Jiri Vanek Mgr.
>>>>> Principal QA Software Engineer
>>>>> Red Hat Inc.
>>>>> +420 775 39 01 09
>>>>>
>>>>
>>>> This looks like a subset of:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8042199
>>>>
>>>> I think it would be preferable to backport this to keep this code aligned
>>>> across JDKs. It fixes some other differences between the Makefile &
>>>> build.xml, as well as actually making it buildable with 1.4, as the
>>>> README claims.
>>>>
>>>> The -g:none addition seemed strange to me, but it seems debug=false
>>>> has been in build.xml since the start of the OpenJDK project [0].
>>>> If we want to remove that, we should probably do so in HEAD and
>>>> backport for consistency across releases.
>>>>
>>>> [0] https://mail.openjdk.java.net/pipermail/2d-dev/2014-August/004736.html
>>>>
>>>
>>
>> -- 
>> Jiri Vanek Mgr.
>> Principal QA Software Engineer
>> Red Hat Inc.
>> +420 775 39 01 09
>>
>>
> 

-- 
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09


From hohensee at amazon.com  Fri Nov  5 20:38:14 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 5 Nov 2021 20:38:14 +0000
Subject: [8u] RFR bad source/target in Makefile of J2DBench
Message-ID: <B3776B4C-48F6-4EFF-A132-539A7F5582E7@amazon.com>

Still has the CMMTests.java issue. I can see the change in the new version of the file but not the webrev, so try "webrev -b". The actual patch will need to include the original commit metadata. You can get that using "hg export --git -r <commit-id>".

The hg-updater daemon will create the backport issue when the backport is pushed, so you don't have to do it yourself.

?-----Original Message-----
From: Jiri Vanek <jvanek at redhat.com>
Date: Friday, November 5, 2021 at 8:15 AM
To: "Hohensee, Paul" <hohensee at amazon.com>, Andrew Hughes <gnu.andrew at redhat.com>
Cc: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: RE: [8u] RFR bad source/target in Makefile of J2DBench

http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/webrev/

updated. Now is 1:1 with original.

TY!

On 11/5/21 15:46, Jiri Vanek wrote:
>
> On 11/4/21 21:47, Hohensee, Paul wrote:
>> The use of -source 1.5 -target 1.5 in J2DBench/Makefile doesn't correspond to the comment in the README, which says that 1.6 is the minimum due to jdk9's javac. The original jdk9 patch used -source 1.6 and -target 1.6, so I'd do the same
>> and also leave the README comment alone.  A reference to a later JDK is fine in a backport.
>
> Ok. Will do.
>
>>
>> The patch to CMMTests.java is missing the spelling update to the definition and use of usePlatfromProfiles and usePlatfrom. To be sure, it's a nop, but should be done to keep any future backport(s) consistent.
>
> How that happened. Will double check.
>
>
>>
>> Otherwise lgtm.
>>
>> Thanks,
>> Paul
>>
>> -----Original Message-----
>> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Jiri Vanek <jvanek at redhat.com>
>> Date: Thursday, November 4, 2021 at 12:29 PM
>> To: Andrew Hughes <gnu.andrew at redhat.com>
>> Cc: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
>> Subject: Re: [8u] RFR bad source/target in Makefile of J2DBench
>>
>> ping please!
>>
>> On 10/25/21 20:14, Jiri Vanek wrote:
>>> Thanx!
>>>
>>> webrev adapted: http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/webrev/
>>>
>>> Compared to original, I had dropepd the build.xml change, as it was not relevant.
>>>
>>> The https://bugs.openjdk.java.net/browse/JDK-8042199 is already closed.  Should it be reopened, or new bug will be created?
>>>
>>> Thanx!
>>>    J.
>>>
>>>
>>>
>>> On 10/25/21 15:37, Andrew Hughes wrote:
>>>> On 18:56 Thu 21 Oct     , Jiri Vanek wrote:
>>>>> http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/
>>>>>
>>>>> Hello! the build.xml (https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/d2bbff5b7006/src/share/demo/java2d/J2DBench/build.xml#l52) is corerect,
>>>>> and have -source/target correctly on 1.5
>>>>>
>>>>> However Mkaefile was left behind, and is on 1.2, which jdk8 itself can not play.
>>>>>
>>>>>
>>>>> Am looking forward for kind soul to create a bug a commit on my behalf.
>>>>>
>>>>> Happy hacking,
>>>>>       J.
>>>>> --
>>>>> Jiri Vanek Mgr.
>>>>> Principal QA Software Engineer
>>>>> Red Hat Inc.
>>>>> +420 775 39 01 09
>>>>>
>>>>
>>>> This looks like a subset of:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8042199
>>>>
>>>> I think it would be preferable to backport this to keep this code aligned
>>>> across JDKs. It fixes some other differences between the Makefile &
>>>> build.xml, as well as actually making it buildable with 1.4, as the
>>>> README claims.
>>>>
>>>> The -g:none addition seemed strange to me, but it seems debug=false
>>>> has been in build.xml since the start of the OpenJDK project [0].
>>>> If we want to remove that, we should probably do so in HEAD and
>>>> backport for consistency across releases.
>>>>
>>>> [0] https://mail.openjdk.java.net/pipermail/2d-dev/2014-August/004736.html
>>>>
>>>
>>
>> --
>> Jiri Vanek Mgr.
>> Principal QA Software Engineer
>> Red Hat Inc.
>> +420 775 39 01 09
>>
>>
>

--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09



From jvanek at redhat.com  Mon Nov  8 17:07:52 2021
From: jvanek at redhat.com (Jiri Vanek)
Date: Mon, 8 Nov 2021 18:07:52 +0100
Subject: [8u] RFR bad source/target in Makefile of J2DBench
In-Reply-To: <B3776B4C-48F6-4EFF-A132-539A7F5582E7@amazon.com>
References: <B3776B4C-48F6-4EFF-A132-539A7F5582E7@amazon.com>
Message-ID: <a98f2d1b-c8b5-9bf0-58b5-b6fee74bee91@redhat.com>

Hello!

Metadata updated
http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/webrev/


I'mnot a commiter, so you aor Andrew will need commit on my behalf. TY!

J.

On 11/5/21 21:38, Hohensee, Paul wrote:
> Still has the CMMTests.java issue. I can see the change in the new version of the file but not the webrev, so try "webrev -b". The actual patch will need to include the original commit metadata. You can get that using "hg export --git -r <commit-id>".

^ cleared.
> 
> The hg-updater daemon will create the backport issue when the backport is pushed, so you don't have to do it yourself.
> 
> ?-----Original Message-----
> From: Jiri Vanek <jvanek at redhat.com>
> Date: Friday, November 5, 2021 at 8:15 AM
> To: "Hohensee, Paul" <hohensee at amazon.com>, Andrew Hughes <gnu.andrew at redhat.com>
> Cc: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
> Subject: RE: [8u] RFR bad source/target in Makefile of J2DBench
> 
> http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/webrev/
> 
> updated. Now is 1:1 with original.
> 
> TY!
> 
> On 11/5/21 15:46, Jiri Vanek wrote:
>>
>> On 11/4/21 21:47, Hohensee, Paul wrote:
>>> The use of -source 1.5 -target 1.5 in J2DBench/Makefile doesn't correspond to the comment in the README, which says that 1.6 is the minimum due to jdk9's javac. The original jdk9 patch used -source 1.6 and -target 1.6, so I'd do the same
>>> and also leave the README comment alone.  A reference to a later JDK is fine in a backport.
>>
>> Ok. Will do.
>>
>>>
>>> The patch to CMMTests.java is missing the spelling update to the definition and use of usePlatfromProfiles and usePlatfrom. To be sure, it's a nop, but should be done to keep any future backport(s) consistent.
>>
>> How that happened. Will double check.
>>
>>
>>>
>>> Otherwise lgtm.
>>>
>>> Thanks,
>>> Paul
>>>
>>> -----Original Message-----
>>> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Jiri Vanek <jvanek at redhat.com>
>>> Date: Thursday, November 4, 2021 at 12:29 PM
>>> To: Andrew Hughes <gnu.andrew at redhat.com>
>>> Cc: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
>>> Subject: Re: [8u] RFR bad source/target in Makefile of J2DBench
>>>
>>> ping please!
>>>
>>> On 10/25/21 20:14, Jiri Vanek wrote:
>>>> Thanx!
>>>>
>>>> webrev adapted: http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/webrev/
>>>>
>>>> Compared to original, I had dropepd the build.xml change, as it was not relevant.
>>>>
>>>> The https://bugs.openjdk.java.net/browse/JDK-8042199 is already closed.  Should it be reopened, or new bug will be created?
>>>>
>>>> Thanx!
>>>>     J.
>>>>
>>>>
>>>>
>>>> On 10/25/21 15:37, Andrew Hughes wrote:
>>>>> On 18:56 Thu 21 Oct     , Jiri Vanek wrote:
>>>>>> http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/
>>>>>>
>>>>>> Hello! the build.xml (https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/d2bbff5b7006/src/share/demo/java2d/J2DBench/build.xml#l52) is corerect,
>>>>>> and have -source/target correctly on 1.5
>>>>>>
>>>>>> However Mkaefile was left behind, and is on 1.2, which jdk8 itself can not play.
>>>>>>
>>>>>>
>>>>>> Am looking forward for kind soul to create a bug a commit on my behalf.
>>>>>>
>>>>>> Happy hacking,
>>>>>>        J.
>>>>>> --
>>>>>> Jiri Vanek Mgr.
>>>>>> Principal QA Software Engineer
>>>>>> Red Hat Inc.
>>>>>> +420 775 39 01 09
>>>>>>
>>>>>
>>>>> This looks like a subset of:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8042199
>>>>>
>>>>> I think it would be preferable to backport this to keep this code aligned
>>>>> across JDKs. It fixes some other differences between the Makefile &
>>>>> build.xml, as well as actually making it buildable with 1.4, as the
>>>>> README claims.
>>>>>
>>>>> The -g:none addition seemed strange to me, but it seems debug=false
>>>>> has been in build.xml since the start of the OpenJDK project [0].
>>>>> If we want to remove that, we should probably do so in HEAD and
>>>>> backport for consistency across releases.
>>>>>
>>>>> [0] https://mail.openjdk.java.net/pipermail/2d-dev/2014-August/004736.html
>>>>>
>>>>
>>>
>>> --
>>> Jiri Vanek Mgr.
>>> Principal QA Software Engineer
>>> Red Hat Inc.
>>> +420 775 39 01 09
>>>
>>>
>>
> 
> --
> Jiri Vanek Mgr.
> Principal QA Software Engineer
> Red Hat Inc.
> +420 775 39 01 09
> 
> 

-- 
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09


From jvanek at redhat.com  Tue Nov  9 09:41:48 2021
From: jvanek at redhat.com (Jiri Vanek)
Date: Tue, 9 Nov 2021 10:41:48 +0100
Subject: [8u] RFR bad source/target in Makefile of J2DBench
In-Reply-To: <a98f2d1b-c8b5-9bf0-58b5-b6fee74bee91@redhat.com>
References: <B3776B4C-48F6-4EFF-A132-539A7F5582E7@amazon.com>
 <a98f2d1b-c8b5-9bf0-58b5-b6fee74bee91@redhat.com>
Message-ID: <45a96d0b-d255-f275-2414-18413c5bc9a0@redhat.com>

hmm. Webrev messed up.
Now am using the one from https://hg.openjdk.java.net/code-tools/webrev/raw-file/tip/webrev.ksh

And output is better - the  patch itself is same, but the whole history of files is correctly omitted.
updated:  http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/webrev/

The  J2DBench  is not included in the main build cycle. You have to:

$ pushd  jdk/src/share/demo/java2d/J2DBench/
$ make
$ java -jar dist/J2DBench.jar

It starts the starter gui.
 From that you can load options/default.opt and press start
Without gui,  you can do:
$ java -jar dist/J2DBench.jar -loadopts options/default.opt  -batch -title review -description review  -saveres review.raw

which runs 1 hour.

https://bugs.openjdk.java.net/browse/JDK-8042199 amended as you sugested


Thanx for patience!
   J.


On 11/8/21 18:07, Jiri Vanek wrote:
> Hello!
> 
> Metadata updated
> http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/webrev/
> 
> 
> I'mnot a commiter, so you aor Andrew will need commit on my behalf. TY!
> 
> J.
> 
> On 11/5/21 21:38, Hohensee, Paul wrote:
>> Still has the CMMTests.java issue. I can see the change in the new version of the file but not the webrev, so try "webrev -b". The actual patch will need to include the original commit metadata. You can get that using "hg export --git -r 
>> <commit-id>".
> 
> ^ cleared.
>>
>> The hg-updater daemon will create the backport issue when the backport is pushed, so you don't have to do it yourself.
>>
>> ?-----Original Message-----
>> From: Jiri Vanek <jvanek at redhat.com>
>> Date: Friday, November 5, 2021 at 8:15 AM
>> To: "Hohensee, Paul" <hohensee at amazon.com>, Andrew Hughes <gnu.andrew at redhat.com>
>> Cc: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
>> Subject: RE: [8u] RFR bad source/target in Makefile of J2DBench
>>
>> http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/webrev/
>>
>> updated. Now is 1:1 with original.
>>
>> TY!
>>
>> On 11/5/21 15:46, Jiri Vanek wrote:
>>>
>>> On 11/4/21 21:47, Hohensee, Paul wrote:
>>>> The use of -source 1.5 -target 1.5 in J2DBench/Makefile doesn't correspond to the comment in the README, which says that 1.6 is the minimum due to jdk9's javac. The original jdk9 patch used -source 1.6 and -target 1.6, so I'd do the same
>>>> and also leave the README comment alone.? A reference to a later JDK is fine in a backport.
>>>
>>> Ok. Will do.
>>>
>>>>
>>>> The patch to CMMTests.java is missing the spelling update to the definition and use of usePlatfromProfiles and usePlatfrom. To be sure, it's a nop, but should be done to keep any future backport(s) consistent.
>>>
>>> How that happened. Will double check.
>>>
>>>
>>>>
>>>> Otherwise lgtm.
>>>>
>>>> Thanks,
>>>> Paul
>>>>
>>>> -----Original Message-----
>>>> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Jiri Vanek <jvanek at redhat.com>
>>>> Date: Thursday, November 4, 2021 at 12:29 PM
>>>> To: Andrew Hughes <gnu.andrew at redhat.com>
>>>> Cc: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
>>>> Subject: Re: [8u] RFR bad source/target in Makefile of J2DBench
>>>>
>>>> ping please!
>>>>
>>>> On 10/25/21 20:14, Jiri Vanek wrote:
>>>>> Thanx!
>>>>>
>>>>> webrev adapted: http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/webrev/
>>>>>
>>>>> Compared to original, I had dropepd the build.xml change, as it was not relevant.
>>>>>
>>>>> The https://bugs.openjdk.java.net/browse/JDK-8042199 is already closed.? Should it be reopened, or new bug will be created?
>>>>>
>>>>> Thanx!
>>>>> ??? J.
>>>>>
>>>>>
>>>>>
>>>>> On 10/25/21 15:37, Andrew Hughes wrote:
>>>>>> On 18:56 Thu 21 Oct???? , Jiri Vanek wrote:
>>>>>>> http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/
>>>>>>>
>>>>>>> Hello! the build.xml (https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/d2bbff5b7006/src/share/demo/java2d/J2DBench/build.xml#l52) is corerect,
>>>>>>> and have -source/target correctly on 1.5
>>>>>>>
>>>>>>> However Mkaefile was left behind, and is on 1.2, which jdk8 itself can not play.
>>>>>>>
>>>>>>>
>>>>>>> Am looking forward for kind soul to create a bug a commit on my behalf.
>>>>>>>
>>>>>>> Happy hacking,
>>>>>>> ?????? J.
>>>>>>> -- 
>>>>>>> Jiri Vanek Mgr.
>>>>>>> Principal QA Software Engineer
>>>>>>> Red Hat Inc.
>>>>>>> +420 775 39 01 09
>>>>>>>
>>>>>>
>>>>>> This looks like a subset of:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8042199
>>>>>>
>>>>>> I think it would be preferable to backport this to keep this code aligned
>>>>>> across JDKs. It fixes some other differences between the Makefile &
>>>>>> build.xml, as well as actually making it buildable with 1.4, as the
>>>>>> README claims.
>>>>>>
>>>>>> The -g:none addition seemed strange to me, but it seems debug=false
>>>>>> has been in build.xml since the start of the OpenJDK project [0].
>>>>>> If we want to remove that, we should probably do so in HEAD and
>>>>>> backport for consistency across releases.
>>>>>>
>>>>>> [0] https://mail.openjdk.java.net/pipermail/2d-dev/2014-August/004736.html
>>>>>>
>>>>>
>>>>
>>>> -- 
>>>> Jiri Vanek Mgr.
>>>> Principal QA Software Engineer
>>>> Red Hat Inc.
>>>> +420 775 39 01 09
>>>>
>>>>
>>>
>>
>> -- 
>> Jiri Vanek Mgr.
>> Principal QA Software Engineer
>> Red Hat Inc.
>> +420 775 39 01 09
>>
>>
> 

-- 
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09


From qingfeng.yy at alibaba-inc.com  Tue Nov  9 09:46:45 2021
From: qingfeng.yy at alibaba-inc.com (Yi Yang)
Date: Tue, 09 Nov 2021 17:46:45 +0800
Subject: =?UTF-8?B?UmU6IFs4dV0gUkZSOiA4MjI1NjkwOiBNdWx0aXBsZSBBdHRhY2hMaXN0ZW5lciB0aHJlYWRz?=
 =?UTF-8?B?IGNhbiBiZSBjcmVhdGVk?=
In-Reply-To: <bc568328-a9a4-4ee4-be2b-8cd184ac52da.qingfeng.yy@alibaba-inc.com>
References: <967A142B-ED73-4F79-9506-8E7DAAC4AF0C@amazon.com>,
 <bc568328-a9a4-4ee4-be2b-8cd184ac52da.qingfeng.yy@alibaba-inc.com>
Message-ID: <7cd421e4-9919-4d91-8714-972c8141f1db.qingfeng.yy@alibaba-inc.com>

Gentle PING :-

Thanks!


------------------------------------------------------------------
From:YANG, Yi <qingfeng.yy at alibaba-inc.com>
Send Time:2021 Oct. 21 (Thu.) 16:08
To:"Hohensee, Paul" <hohensee at amazon.com>; jdk8u-dev at openjdk.java.net <jdk8u-dev at openjdk.java.net>
Subject:Re: [8u] RFR: 8225690: Multiple AttachListener threads can be created

Hi Paul,

Currently, Atomic::load only accepts jlong as a parameter, so I use some macros to define AL_XX values and change type of _state to `volatile jlong`, what do you think?

Introduction LingeredApp has a relatively large effort and may also be relatively risky. There are already similar examples of removing @test tag when using LingeredApp(ClhsdbJstackXcompStress, LingeredAppWithRecComputation), so this may be a feasible solution. These tests are all passed(w/ some modifications to allow it working on JDK8u). Nevertheless, I could investigate if it's possible to backport LingeredApp to  after these patches.

I have prepared all related changeset. Please help review it, thank you.

-yyang

1. 8225690: Multiple AttachListener threads can be created
Original Issue: https://bugs.openjdk.java.net/browse/JDK-8225690
Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/70fab3a8ff02
Backport Issue: https://bugs.openjdk.java.net/browse/JDK-8274953
Backport Changeset: http://cr.openjdk.java.net/~yyang/8274953/webrev.00/
Review Effort: M

2. 8227815: Minimal VM: set_state is not a member of AttachListener
Original Issue: https://bugs.openjdk.java.net/browse/JDK-8227815
Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/2660d47140da
Backport Issue: https://bugs.openjdk.java.net/browse/JDK-8275694
Backport Changeset: https://cr.openjdk.java.net/~yyang/8275694/webrev/
Review Effort: XS

3. 8227738: jvmti/DataDumpRequest/datadumpreq001 failed due to "exit code is 134"
Original Issue: https://bugs.openjdk.java.net/browse/JDK-8227738
Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/4888ccfc234e
Backport Issue: https://bugs.openjdk.java.net/browse/JDK-8275695
Backport Changeset: https://cr.openjdk.java.net/~yyang/8275695/webrev/Review Effort: XS


------------------------------------------------------------------
From:Hohensee, Paul <hohensee at amazon.com>
Send Time:2021 Oct. 16 (Sat.) 04:39
To:"YANG, Yi" <qingfeng.yy at alibaba-inc.com>; jdk8u-dev at openjdk.java.net <jdk8u-dev at openjdk.java.net>
Subject:Re: [8u] RFR: 8225690: Multiple AttachListener threads can be created

In attachListener.hpp, the AttachListenerState enum's underlying type will be int, so casting to jlong for the atomic operations will clobber whatever is beyond _state, and won't work at all on big-endian machines. C++11 adds enum base type specification, but we can't use C++11 features in 8u. I would define const int AL_* values and declare _state to be an int.

I'm leery of disabling the test. Please see if you can backport 8165500, which introduced LingeredApp.

You have code from 8237499 in the patch which has already been backported. Please remove it. Also, please post review requests for 8227815 and 8227738 backports, with the intent to push all three at once.

Thanks,
Paul

 -----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Yi Yang <qingfeng.yy at alibaba-inc.com>
Reply-To: Yi Yang <qingfeng.yy at alibaba-inc.com>
Date: Friday, October 8, 2021 at 4:21 AM
To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: [8u] RFR: 8225690: Multiple AttachListener threads can be created

Hi,

Can I have a review for this backport of JDK-8225690?
Original Issue: https://bugs.openjdk.java.net/browse/JDK-8225690
Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/70fab3a8ff02
Backport Issue: https://bugs.openjdk.java.net/browse/JDK-8274953
Backport Changeset: http://cr.openjdk.java.net/~yyang/8274953/

VM can't be attached If someone cleans up the /tmp directory. This patch
addresses the problem. It can not apply cleanly, some minor conflicts are as follows:

1. Atomic::store(new_state, &_state)
jdk8u does not have templated Atomic function family, use explicitly type
conversion `Atomic::store((jlong)new_state, (volatile jlong*)&_state)`.

2. IsRegisteredEnum<AttachListenerState>
jdk8u does not have metaprogramming type traits,
`template<> struct IsRegisteredEnum<AttachListenerState> : public TrueType {};`
simply omit it.

3. os::naked_yield
os::naked_yield is missing due to https://bugs.openjdk.java.net/browse/JDK-8047714,
use os::yield instead.

4. log_debug(attach)("...")
jdk8u does not have unified logging system. Use the following code:
`debug_only(warning("..."))`

5. Test
They can not work because of the usages of LingeredApp. Remove @test tag to
disable them while keeping their source code.

Test cases have been passed manually. The original issue has related bugs:
https://bugs.openjdk.java.net/browse/JDK-8227815
https://bugs.openjdk.java.net/browse/JDK-8235211
https://bugs.openjdk.java.net/browse/JDK-8227738
I'd like to create follow-up backports(JDK-8227815 and JDK-8227738) once this
merged. JDK-8235211 is not necessary since RemovingUnixDomainSocketTest.java
will be ignored as I said before.

Thanks!


From hohensee at amazon.com  Tue Nov  9 12:09:21 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 9 Nov 2021 12:09:21 +0000
Subject: [8u] RFR bad source/target in Makefile of J2DBench
Message-ID: <1D401238-D77D-4101-BD99-4B34F6D94351@amazon.com>

No problem. Looks good now.

Thanks,
Paul

?-----Original Message-----
From: Jiri Vanek <jvanek at redhat.com>
Date: Tuesday, November 9, 2021 at 1:42 AM
To: "Hohensee, Paul" <hohensee at amazon.com>, Andrew Hughes <gnu.andrew at redhat.com>
Cc: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: RE: [8u] RFR bad source/target in Makefile of J2DBench

hmm. Webrev messed up.
Now am using the one from https://hg.openjdk.java.net/code-tools/webrev/raw-file/tip/webrev.ksh

And output is better - the  patch itself is same, but the whole history of files is correctly omitted.
updated:  http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/webrev/

The  J2DBench  is not included in the main build cycle. You have to:

$ pushd  jdk/src/share/demo/java2d/J2DBench/
$ make
$ java -jar dist/J2DBench.jar

It starts the starter gui.
 From that you can load options/default.opt and press start
Without gui,  you can do:
$ java -jar dist/J2DBench.jar -loadopts options/default.opt  -batch -title review -description review  -saveres review.raw

which runs 1 hour.

https://bugs.openjdk.java.net/browse/JDK-8042199 amended as you sugested


Thanx for patience!
   J.


On 11/8/21 18:07, Jiri Vanek wrote:
> Hello!
>
> Metadata updated
> http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/webrev/
>
>
> I'mnot a commiter, so you aor Andrew will need commit on my behalf. TY!
>
> J.
>
> On 11/5/21 21:38, Hohensee, Paul wrote:
>> Still has the CMMTests.java issue. I can see the change in the new version of the file but not the webrev, so try "webrev -b". The actual patch will need to include the original commit metadata. You can get that using "hg export --git -r
>> <commit-id>".
>
> ^ cleared.
>>
>> The hg-updater daemon will create the backport issue when the backport is pushed, so you don't have to do it yourself.
>>
>> -----Original Message-----
>> From: Jiri Vanek <jvanek at redhat.com>
>> Date: Friday, November 5, 2021 at 8:15 AM
>> To: "Hohensee, Paul" <hohensee at amazon.com>, Andrew Hughes <gnu.andrew at redhat.com>
>> Cc: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
>> Subject: RE: [8u] RFR bad source/target in Makefile of J2DBench
>>
>> http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/webrev/
>>
>> updated. Now is 1:1 with original.
>>
>> TY!
>>
>> On 11/5/21 15:46, Jiri Vanek wrote:
>>>
>>> On 11/4/21 21:47, Hohensee, Paul wrote:
>>>> The use of -source 1.5 -target 1.5 in J2DBench/Makefile doesn't correspond to the comment in the README, which says that 1.6 is the minimum due to jdk9's javac. The original jdk9 patch used -source 1.6 and -target 1.6, so I'd do the same
>>>> and also leave the README comment alone.  A reference to a later JDK is fine in a backport.
>>>
>>> Ok. Will do.
>>>
>>>>
>>>> The patch to CMMTests.java is missing the spelling update to the definition and use of usePlatfromProfiles and usePlatfrom. To be sure, it's a nop, but should be done to keep any future backport(s) consistent.
>>>
>>> How that happened. Will double check.
>>>
>>>
>>>>
>>>> Otherwise lgtm.
>>>>
>>>> Thanks,
>>>> Paul
>>>>
>>>> -----Original Message-----
>>>> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Jiri Vanek <jvanek at redhat.com>
>>>> Date: Thursday, November 4, 2021 at 12:29 PM
>>>> To: Andrew Hughes <gnu.andrew at redhat.com>
>>>> Cc: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
>>>> Subject: Re: [8u] RFR bad source/target in Makefile of J2DBench
>>>>
>>>> ping please!
>>>>
>>>> On 10/25/21 20:14, Jiri Vanek wrote:
>>>>> Thanx!
>>>>>
>>>>> webrev adapted: http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/webrev/
>>>>>
>>>>> Compared to original, I had dropepd the build.xml change, as it was not relevant.
>>>>>
>>>>> The https://bugs.openjdk.java.net/browse/JDK-8042199 is already closed.  Should it be reopened, or new bug will be created?
>>>>>
>>>>> Thanx!
>>>>>     J.
>>>>>
>>>>>
>>>>>
>>>>> On 10/25/21 15:37, Andrew Hughes wrote:
>>>>>> On 18:56 Thu 21 Oct     , Jiri Vanek wrote:
>>>>>>> http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/
>>>>>>>
>>>>>>> Hello! the build.xml (https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/d2bbff5b7006/src/share/demo/java2d/J2DBench/build.xml#l52) is corerect,
>>>>>>> and have -source/target correctly on 1.5
>>>>>>>
>>>>>>> However Mkaefile was left behind, and is on 1.2, which jdk8 itself can not play.
>>>>>>>
>>>>>>>
>>>>>>> Am looking forward for kind soul to create a bug a commit on my behalf.
>>>>>>>
>>>>>>> Happy hacking,
>>>>>>>        J.
>>>>>>> --
>>>>>>> Jiri Vanek Mgr.
>>>>>>> Principal QA Software Engineer
>>>>>>> Red Hat Inc.
>>>>>>> +420 775 39 01 09
>>>>>>>
>>>>>>
>>>>>> This looks like a subset of:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8042199
>>>>>>
>>>>>> I think it would be preferable to backport this to keep this code aligned
>>>>>> across JDKs. It fixes some other differences between the Makefile &
>>>>>> build.xml, as well as actually making it buildable with 1.4, as the
>>>>>> README claims.
>>>>>>
>>>>>> The -g:none addition seemed strange to me, but it seems debug=false
>>>>>> has been in build.xml since the start of the OpenJDK project [0].
>>>>>> If we want to remove that, we should probably do so in HEAD and
>>>>>> backport for consistency across releases.
>>>>>>
>>>>>> [0] https://mail.openjdk.java.net/pipermail/2d-dev/2014-August/004736.html
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Jiri Vanek Mgr.
>>>> Principal QA Software Engineer
>>>> Red Hat Inc.
>>>> +420 775 39 01 09
>>>>
>>>>
>>>
>>
>> --
>> Jiri Vanek Mgr.
>> Principal QA Software Engineer
>> Red Hat Inc.
>> +420 775 39 01 09
>>
>>
>

--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09



From gnu.andrew at redhat.com  Wed Nov 10 01:45:28 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 10 Nov 2021 01:45:28 +0000
Subject: [8u] RFR bad source/target in Makefile of J2DBench
In-Reply-To: <45a96d0b-d255-f275-2414-18413c5bc9a0@redhat.com>
References: <B3776B4C-48F6-4EFF-A132-539A7F5582E7@amazon.com>
 <a98f2d1b-c8b5-9bf0-58b5-b6fee74bee91@redhat.com>
 <45a96d0b-d255-f275-2414-18413c5bc9a0@redhat.com>
Message-ID: <YYskOJOKjsshkiFP@hex.discworld.ac.uk>

On 10:41 Tue 09 Nov     , Jiri Vanek wrote:
> hmm. Webrev messed up.
> Now am using the one from https://hg.openjdk.java.net/code-tools/webrev/raw-file/tip/webrev.ksh
> 
> And output is better - the  patch itself is same, but the whole history of files is correctly omitted.
> updated:  http://cr.openjdk.java.net/~jvanek/bad_j2d_bytecodeversion/webrev/
> 
> The  J2DBench  is not included in the main build cycle. You have to:
> 
> $ pushd  jdk/src/share/demo/java2d/J2DBench/
> $ make
> $ java -jar dist/J2DBench.jar
> 
> It starts the starter gui.
>  From that you can load options/default.opt and press start
> Without gui,  you can do:
> $ java -jar dist/J2DBench.jar -loadopts options/default.opt  -batch -title review -description review  -saveres review.raw
> 
> which runs 1 hour.
> 
> https://bugs.openjdk.java.net/browse/JDK-8042199 amended as you sugested
> 
> 
> Thanx for patience!
>    J.
>

As far as I can see, this didn't need a review; the patch is a clean backport
from the 11u version. I get the same patch if I apply the 11u patch to
8u-dev/jdk.

Please add the jdk8u-fix-request label to the bug and I'll approve & push.

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From gnu.andrew at redhat.com  Wed Nov 10 16:02:30 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 10 Nov 2021 16:02:30 +0000
Subject: [8u] RFR: 8048021: Remove @version tag in jaxp repo
In-Reply-To: <CABUxsJ3OHsN5xLUAK60yXYQOhXsxcJ5Bu8J4t83XZEak3Y1L_A@mail.gmail.com>
References: <CABUxsJ3OHsN5xLUAK60yXYQOhXsxcJ5Bu8J4t83XZEak3Y1L_A@mail.gmail.com>
Message-ID: <YYvtFuDPMZsa5dYp@hex.discworld.ac.uk>

On 14:08 Tue 19 Oct     , Alex Kashchenko wrote:
> Hi,
> 
> Please review the backport of JDK-8048021 to 8u:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8048021
> 
> Original commit: https://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/01c25780f33f
> 
> 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8048021/webrev.00/
> 
> This change can make it easier to backport subsequent JAXP parity
> issues to 8u. There are no code changes, all changes are to comments.
> The following files were resolved manually:
> 
> src/com/sun/org/apache/xerces/internal/impl/XML11EntityScanner.java
> src/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java
> src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java
> src/com/sun/org/apache/xerces/internal/impl/dtd/DTDGrammar.java
> src/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaValidator.java
> src/com/sun/org/apache/xerces/internal/util/EncodingMap.java
> src/com/sun/org/apache/xerces/internal/xpointer/ElementSchemePointer.java
> src/javax/xml/parsers/DocumentBuilderFactory.java
> src/javax/xml/parsers/FactoryConfigurationError.java
> src/javax/xml/parsers/SAXParserFactory.java
> 
> -- 
> -Alex
> 

Looks good. Approved.

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From akashche at redhat.com  Wed Nov 10 16:30:11 2021
From: akashche at redhat.com (Alex Kashchenko)
Date: Wed, 10 Nov 2021 16:30:11 +0000
Subject: [8u] RFR: 8048021: Remove @version tag in jaxp repo
In-Reply-To: <YYvtFuDPMZsa5dYp@hex.discworld.ac.uk>
References: <CABUxsJ3OHsN5xLUAK60yXYQOhXsxcJ5Bu8J4t83XZEak3Y1L_A@mail.gmail.com>
 <YYvtFuDPMZsa5dYp@hex.discworld.ac.uk>
Message-ID: <CABUxsJ3r0J+P=LUBd7F1OM3w9UJb5WvoHBO1mbhquPN5F1+MUA@mail.gmail.com>

On 11/10/21, Andrew Hughes <gnu.andrew at redhat.com> wrote:
> On 14:08 Tue 19 Oct     , Alex Kashchenko wrote:
>> Hi,
>>
>> Please review the backport of JDK-8048021 to 8u:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8048021
>>
>> Original commit:
>> https://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/01c25780f33f
>>
>> 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8048021/webrev.00/
>>
>> This change can make it easier to backport subsequent JAXP parity
>> issues to 8u. There are no code changes, all changes are to comments.
>> The following files were resolved manually:
>>
>> src/com/sun/org/apache/xerces/internal/impl/XML11EntityScanner.java
>> src/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java
>> src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java
>> src/com/sun/org/apache/xerces/internal/impl/dtd/DTDGrammar.java
>> src/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaValidator.java
>> src/com/sun/org/apache/xerces/internal/util/EncodingMap.java
>> src/com/sun/org/apache/xerces/internal/xpointer/ElementSchemePointer.java
>> src/javax/xml/parsers/DocumentBuilderFactory.java
>> src/javax/xml/parsers/FactoryConfigurationError.java
>> src/javax/xml/parsers/SAXParserFactory.java
>>
>> --
>> -Alex
>>
>
> Looks good. Approved.

Thanks for the approval! I've pushed it.

Note, there is another similar JAXP comments-only patch submitted approval:

https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-October/014355.html


-- 
-Alex


From hohensee at amazon.com  Wed Nov 10 18:44:17 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 10 Nov 2021 18:44:17 +0000
Subject: [8u] RFR: 8225690: Multiple AttachListener threads can be created
Message-ID: <9BE29070-4242-4925-97BC-7BFAA5041A26@amazon.com>

Apologies for the delay.

Lgtm for 8274953, except that I?d use the original AttachListenerState enum type definition in attachListener.hpp rather than #defines. The enums will be converted properly to jlongs, and #defines of constants aren?t typed so shouldn?t be used unless absolutely necessary.

Lgtm for 8227815 and 8227738.

Thanks,
Paul

From: Yi Yang <qingfeng.yy at alibaba-inc.com>
Reply-To: Yi Yang <qingfeng.yy at alibaba-inc.com>
Date: Tuesday, November 9, 2021 at 1:47 AM
To: "YANG, Yi" <qingfeng.yy at alibaba-inc.com>, "Hohensee, Paul" <hohensee at amazon.com>, "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: RE: [8u] RFR: 8225690: Multiple AttachListener threads can be created

Gentle PING :-

Thanks!

------------------------------------------------------------------
From:YANG, Yi <qingfeng.yy at alibaba-inc.com>
Send Time:2021 Oct. 21 (Thu.) 16:08
To:"Hohensee, Paul" <hohensee at amazon.com>; jdk8u-dev at openjdk.java.net <jdk8u-dev at openjdk.java.net>
Subject:Re: [8u] RFR: 8225690: Multiple AttachListener threads can be created

Hi Paul,
Currently, Atomic::load only accepts jlong as a parameter, so I use some macros to define AL_XX values and change type of _state to `volatile jlong`, what do you think?

Introduction LingeredApp has a relatively large effort and may also be relatively risky. There are already similar examples of removing @test tag when using LingeredApp(ClhsdbJstackXcompStress, LingeredAppWithRecComputation), so this may be a feasible solution. These tests are all passed(w/ some modifications to allow it working on JDK8u). Nevertheless, I could investigate if it's possible to backport LingeredApp to  after these patches.

I have prepared all related changeset. Please help review it, thank you.

-yyang

1. 8225690: Multiple AttachListener threads can be created
Original Issue: https://bugs.openjdk.java.net/browse/JDK-8225690
Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/70fab3a8ff02
Backport Issue: https://bugs.openjdk.java.net/browse/JDK-8274953
Backport Changeset: http://cr.openjdk.java.net/~yyang/8274953/webrev.00/
Review Effort: M

2. 8227815: Minimal VM: set_state is not a member of AttachListener
Original Issue: https://bugs.openjdk.java.net/browse/JDK-8227815
Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/2660d47140da
Backport Issue: https://bugs.openjdk.java.net/browse/JDK-8275694
Backport Changeset: https://cr.openjdk.java.net/~yyang/8275694/webrev/
Review Effort: XS

3. 8227738: jvmti/DataDumpRequest/datadumpreq001 failed due to "exit code is 134"
Original Issue: https://bugs.openjdk.java.net/browse/JDK-8227738
Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/4888ccfc234e
Backport Issue: https://bugs.openjdk.java.net/browse/JDK-8275695
Backport Changeset: https://cr.openjdk.java.net/~yyang/8275695/webrev/
Review Effort: XS

------------------------------------------------------------------
From:Hohensee, Paul <hohensee at amazon.com>
Send Time:2021 Oct. 16 (Sat.) 04:39
To:"YANG, Yi" <qingfeng.yy at alibaba-inc.com>; jdk8u-dev at openjdk.java.net <jdk8u-dev at openjdk.java.net>
Subject:Re: [8u] RFR: 8225690: Multiple AttachListener threads can be created

In attachListener.hpp, the AttachListenerState enum's underlying type will be int, so casting to jlong for the atomic operations will clobber whatever is beyond _state, and won't work at all on big-endian machines. C++11 adds enum base type specification, but we can't use C++11 features in 8u. I would define const int AL_* values and declare _state to be an int.

I'm leery of disabling the test. Please see if you can backport 8165500, which introduced LingeredApp.

You have code from 8237499 in the patch which has already been backported. Please remove it. Also, please post review requests for 8227815 and 8227738 backports, with the intent to push all three at once.

Thanks,
Paul

-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Yi Yang <qingfeng.yy at alibaba-inc.com>
Reply-To: Yi Yang <qingfeng.yy at alibaba-inc.com>
Date: Friday, October 8, 2021 at 4:21 AM
To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: [8u] RFR: 8225690: Multiple AttachListener threads can be created

Hi,

Can I have a review for this backport of JDK-8225690?
Original Issue: https://bugs.openjdk.java.net/browse/JDK-8225690
Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/70fab3a8ff02
Backport Issue: https://bugs.openjdk.java.net/browse/JDK-8274953
Backport Changeset: http://cr.openjdk.java.net/~yyang/8274953/

VM can't be attached If someone cleans up the /tmp directory. This patch
addresses the problem. It can not apply cleanly, some minor conflicts are as follows:

1. Atomic::store(new_state, &_state)
jdk8u does not have templated Atomic function family, use explicitly type
conversion `Atomic::store((jlong)new_state, (volatile jlong*)&_state)`.

2. IsRegisteredEnum<AttachListenerState>
jdk8u does not have metaprogramming type traits,
`template<> struct IsRegisteredEnum<AttachListenerState> : public TrueType {};`
simply omit it.

3. os::naked_yield
os::naked_yield is missing due to https://bugs.openjdk.java.net/browse/JDK-8047714,
use os::yield instead.

4. log_debug(attach)("...")
jdk8u does not have unified logging system. Use the following code:
`debug_only(warning("..."))`

5. Test
They can not work because of the usages of LingeredApp. Remove @test tag to
disable them while keeping their source code.

Test cases have been passed manually. The original issue has related bugs:
https://bugs.openjdk.java.net/browse/JDK-8227815
https://bugs.openjdk.java.net/browse/JDK-8235211
https://bugs.openjdk.java.net/browse/JDK-8227738
I'd like to create follow-up backports(JDK-8227815 and JDK-8227738) once this
merged. JDK-8235211 is not necessary since RemovingUnixDomainSocketTest.java
will be ignored as I said before.

Thanks!

From qingfeng.yy at alibaba-inc.com  Thu Nov 11 02:42:13 2021
From: qingfeng.yy at alibaba-inc.com (Yi Yang)
Date: Thu, 11 Nov 2021 10:42:13 +0800
Subject: =?UTF-8?B?UmU6IFs4dV0gUkZSOiA4MjI1NjkwOiBNdWx0aXBsZSBBdHRhY2hMaXN0ZW5lciB0aHJlYWRz?=
 =?UTF-8?B?IGNhbiBiZSBjcmVhdGVk?=
In-Reply-To: <9BE29070-4242-4925-97BC-7BFAA5041A26@amazon.com>
References: <9BE29070-4242-4925-97BC-7BFAA5041A26@amazon.com>
Message-ID: <e5e234bd-14f4-4c1a-9733-114297f51abe.qingfeng.yy@alibaba-inc.com>

Hi Paul,

In my initial changes, I used enum AttachListenerState. Enum cannot be automatically converted to jlong, the compiler complains about this, so forced type casting is required. At that time you were worried that forced type conversion might cause problems:

> the AttachListenerState enum's underlying type will be int, so casting to jlong for the atomic operations will clobber whatever is beyond _state, and won't work at all on big-endian machines. C++11 adds enum base type specification, but we can't use C++11 features in 8u. I would define const int AL_* values and declare _state to be an int.

It is always correct to use constants, so I am using constant(macro definition) now.

Thanks!


------------------------------------------------------------------
From:Hohensee, Paul <hohensee at amazon.com>
Send Time:2021 Nov. 11 (Thu.) 02:44
To:"YANG, Yi" <qingfeng.yy at alibaba-inc.com>; jdk8u-dev at openjdk.java.net <jdk8u-dev at openjdk.java.net>
Subject:Re: [8u] RFR: 8225690: Multiple AttachListener threads can be created

  
Apologies for the delay.
Lgtm for 8274953, except that I?d use the original AttachListenerState enum type definition in attachListener.hpp rather than #defines. The enums will be converted properly to jlongs, and #defines of constants aren?t typed so shouldn?t be used unless absolutely necessary.
Lgtm for  8227815 and 8227738.
Thanks,
Paul
From: Yi Yang <qingfeng.yy at alibaba-inc.com>
Reply-To: Yi Yang <qingfeng.yy at alibaba-inc.com>
Date: Tuesday, November 9, 2021 at 1:47 AM
To: "YANG, Yi" <qingfeng.yy at alibaba-inc.com>, "Hohensee, Paul" <hohensee at amazon.com>, "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: RE:  [8u] RFR: 8225690: Multiple AttachListener threads can be created 
Gentle PING :-

 Thanks! 
   
------------------------------------------------------------------ 
From:YANG, Yi <qingfeng.yy at alibaba-inc.com> 
Send Time:2021 Oct. 21 (Thu.) 16:08 
To:"Hohensee, Paul" <hohensee at amazon.com>; jdk8u-dev at openjdk.java.net <jdk8u-dev at openjdk.java.net> 
Subject:Re: [8u] RFR: 8225690: Multiple AttachListener threads can be created 
  
Hi Paul,
Currently, Atomic::load only accepts jlong as a parameter, so I use some macros to define AL_XX values and change type of _state to `volatile jlong`, what do you think? 

 Introduction LingeredApp has a relatively large effort and may also be relatively risky. There are already similar examples of removing @test tag when using LingeredApp(ClhsdbJstackXcompStress, LingeredAppWithRecComputation), so this may be a feasible solution. These tests are all passed(w/ some modifications to allow it working on JDK8u). Nevertheless, I could investigate if it's possible to backport LingeredApp to  after these patches. 

 I have prepared all related changeset. Please help review it, thank you. 

 -yyang 

 1. 8225690: Multiple AttachListener threads can be created 
Original Issue: https://bugs.openjdk.java.net/browse/JDK-8225690 
Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/70fab3a8ff02 
Backport Issue: https://bugs.openjdk.java.net/browse/JDK-8274953 
Backport Changeset: http://cr.openjdk.java.net/~yyang/8274953/webrev.00/ 
Review Effort: M 

 2. 8227815: Minimal VM: set_state is not a member of AttachListener 
Original Issue: https://bugs.openjdk.java.net/browse/JDK-8227815 
Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/2660d47140da 
Backport Issue: https://bugs.openjdk.java.net/browse/JDK-8275694 
Backport Changeset: https://cr.openjdk.java.net/~yyang/8275694/webrev/ 
Review Effort: XS 

 3. 8227738: jvmti/DataDumpRequest/datadumpreq001 failed due to "exit code is 134" 
Original Issue: https://bugs.openjdk.java.net/browse/JDK-8227738 
Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/4888ccfc234e 
Backport Issue: https://bugs.openjdk.java.net/browse/JDK-8275695 
Backport Changeset: https://cr.openjdk.java.net/~yyang/8275695/webrev/ 
Review Effort: XS 
  
------------------------------------------------------------------ 
From:Hohensee, Paul <hohensee at amazon.com> 
Send Time:2021 Oct. 16 (Sat.) 04:39 
To:"YANG, Yi" <qingfeng.yy at alibaba-inc.com>; jdk8u-dev at openjdk.java.net <jdk8u-dev at openjdk.java.net> 
Subject:Re: [8u] RFR: 8225690: Multiple AttachListener threads can be created 
  
In attachListener.hpp, the AttachListenerState enum's underlying type will be int, so casting to jlong for the atomic operations will clobber whatever is beyond _state, and won't work at all on big-endian machines. C++11 adds enum base type specification, but we can't use C++11 features in 8u. I would define const int AL_* values and declare _state to be an int.

 I'm leery of disabling the test. Please see if you can backport 8165500, which introduced LingeredApp.

 You have code from 8237499 in the patch which has already been backported. Please remove it. Also, please post review requests for 8227815 and 8227738 backports, with the intent to push all three at once.

 Thanks,
 Paul

 -----Original Message-----
 From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Yi Yang <qingfeng.yy at alibaba-inc.com>
 Reply-To: Yi Yang <qingfeng.yy at alibaba-inc.com>
 Date: Friday, October 8, 2021 at 4:21 AM
 To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
 Subject: [8u] RFR: 8225690: Multiple AttachListener threads can be created

 Hi,

 Can I have a review for this backport of JDK-8225690?
 Original Issue: https://bugs.openjdk.java.net/browse/JDK-8225690
 Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/70fab3a8ff02
 Backport Issue: https://bugs.openjdk.java.net/browse/JDK-8274953
 Backport Changeset: http://cr.openjdk.java.net/~yyang/8274953/

 VM can't be attached If someone cleans up the /tmp directory. This patch
 addresses the problem. It can not apply cleanly, some minor conflicts are as follows:

 1. Atomic::store(new_state, &_state)
 jdk8u does not have templated Atomic function family, use explicitly type
 conversion `Atomic::store((jlong)new_state, (volatile jlong*)&_state)`.

 2. IsRegisteredEnum<AttachListenerState>
 jdk8u does not have metaprogramming type traits,
 `template<> struct IsRegisteredEnum<AttachListenerState> : public TrueType {};`
 simply omit it.

 3. os::naked_yield
 os::naked_yield is missing due to https://bugs.openjdk.java.net/browse/JDK-8047714,
 use os::yield instead.

 4. log_debug(attach)("...")
 jdk8u does not have unified logging system. Use the following code:
 `debug_only(warning("..."))`

 5. Test
 They can not work because of the usages of LingeredApp. Remove @test tag to
 disable them while keeping their source code.

 Test cases have been passed manually. The original issue has related bugs:
https://bugs.openjdk.java.net/browse/JDK-8227815
https://bugs.openjdk.java.net/browse/JDK-8235211
https://bugs.openjdk.java.net/browse/JDK-8227738
 I'd like to create follow-up backports(JDK-8227815 and JDK-8227738) once this
 merged. JDK-8235211 is not necessary since RemovingUnixDomainSocketTest.java
 will be ignored as I said before.

 Thanks!       

From hohensee at amazon.com  Thu Nov 11 14:17:55 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Thu, 11 Nov 2021 14:17:55 +0000
Subject: [8u] RFR: 8225690: Multiple AttachListener threads can be created
Message-ID: <57CD738C-D783-4A41-9F8B-629E33B8E02B@amazon.com>

Forced type conversion of the base type of a pointer was the problem, not forced type conversion of a constant. But, if you?re getting warnings from your compiler (I didn?t from gcc 7.3.1, but that?s pretty old), then I?m ok with leaving it as is.

Lgtm.

Paul

From: Yi Yang <qingfeng.yy at alibaba-inc.com>
Reply-To: Yi Yang <qingfeng.yy at alibaba-inc.com>
Date: Wednesday, November 10, 2021 at 6:42 PM
To: "Hohensee, Paul" <hohensee at amazon.com>, "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: RE: [8u] RFR: 8225690: Multiple AttachListener threads can be created

Hi Paul,

In my initial changes, I used enum AttachListenerState. Enum cannot be automatically converted to jlong, the compiler complains about this, so forced type casting is required. At that time you were worried that forced type conversion might cause problems:

> the AttachListenerState enum's underlying type will be int, so casting to jlong for the atomic operations will clobber whatever is beyond _state, and won't work at all on big-endian machines. C++11 adds enum base type specification, but we can't use C++11 features in 8u. I would define const int AL_* values and declare _state to be an int.


It is always correct to use constants, so I am using constant(macro definition) now.
Thanks!

------------------------------------------------------------------
From:Hohensee, Paul <hohensee at amazon.com>
Send Time:2021 Nov. 11 (Thu.) 02:44
To:"YANG, Yi" <qingfeng.yy at alibaba-inc.com>; jdk8u-dev at openjdk.java.net <jdk8u-dev at openjdk.java.net>
Subject:Re: [8u] RFR: 8225690: Multiple AttachListener threads can be created

Apologies for the delay.

Lgtm for 8274953, except that I?d use the original AttachListenerState enum type definition in attachListener.hpp rather than #defines. The enums will be converted properly to jlongs, and #defines of constants aren?t typed so shouldn?t be used unless absolutely necessary.

Lgtm for 8227815 and 8227738.

Thanks,
Paul

From: Yi Yang <qingfeng.yy at alibaba-inc.com>
Reply-To: Yi Yang <qingfeng.yy at alibaba-inc.com>
Date: Tuesday, November 9, 2021 at 1:47 AM
To: "YANG, Yi" <qingfeng.yy at alibaba-inc.com>, "Hohensee, Paul" <hohensee at amazon.com>, "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: RE: [8u] RFR: 8225690: Multiple AttachListener threads can be created

Gentle PING :-

Thanks!

------------------------------------------------------------------
From:YANG, Yi <qingfeng.yy at alibaba-inc.com>
Send Time:2021 Oct. 21 (Thu.) 16:08
To:"Hohensee, Paul" <hohensee at amazon.com>; jdk8u-dev at openjdk.java.net <jdk8u-dev at openjdk.java.net>
Subject:Re: [8u] RFR: 8225690: Multiple AttachListener threads can be created

Hi Paul,
Currently, Atomic::load only accepts jlong as a parameter, so I use some macros to define AL_XX values and change type of _state to `volatile jlong`, what do you think?

Introduction LingeredApp has a relatively large effort and may also be relatively risky. There are already similar examples of removing @test tag when using LingeredApp(ClhsdbJstackXcompStress, LingeredAppWithRecComputation), so this may be a feasible solution. These tests are all passed(w/ some modifications to allow it working on JDK8u). Nevertheless, I could investigate if it's possible to backport LingeredApp to  after these patches.

I have prepared all related changeset. Please help review it, thank you.

-yyang

1. 8225690: Multiple AttachListener threads can be created
Original Issue: https://bugs.openjdk.java.net/browse/JDK-8225690
Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/70fab3a8ff02
Backport Issue: https://bugs.openjdk.java.net/browse/JDK-8274953
Backport Changeset: http://cr.openjdk.java.net/~yyang/8274953/webrev.00/
Review Effort: M

2. 8227815: Minimal VM: set_state is not a member of AttachListener
Original Issue: https://bugs.openjdk.java.net/browse/JDK-8227815
Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/2660d47140da
Backport Issue: https://bugs.openjdk.java.net/browse/JDK-8275694
Backport Changeset: https://cr.openjdk.java.net/~yyang/8275694/webrev/
Review Effort: XS

3. 8227738: jvmti/DataDumpRequest/datadumpreq001 failed due to "exit code is 134"
Original Issue: https://bugs.openjdk.java.net/browse/JDK-8227738
Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/4888ccfc234e
Backport Issue: https://bugs.openjdk.java.net/browse/JDK-8275695
Backport Changeset: https://cr.openjdk.java.net/~yyang/8275695/webrev/
Review Effort: XS

------------------------------------------------------------------
From:Hohensee, Paul <hohensee at amazon.com>
Send Time:2021 Oct. 16 (Sat.) 04:39
To:"YANG, Yi" <qingfeng.yy at alibaba-inc.com>; jdk8u-dev at openjdk.java.net <jdk8u-dev at openjdk.java.net>
Subject:Re: [8u] RFR: 8225690: Multiple AttachListener threads can be created

In attachListener.hpp, the AttachListenerState enum's underlying type will be int, so casting to jlong for the atomic operations will clobber whatever is beyond _state, and won't work at all on big-endian machines. C++11 adds enum base type specification, but we can't use C++11 features in 8u. I would define const int AL_* values and declare _state to be an int.

I'm leery of disabling the test. Please see if you can backport 8165500, which introduced LingeredApp.

You have code from 8237499 in the patch which has already been backported. Please remove it. Also, please post review requests for 8227815 and 8227738 backports, with the intent to push all three at once.

Thanks,
Paul

-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Yi Yang <qingfeng.yy at alibaba-inc.com>
Reply-To: Yi Yang <qingfeng.yy at alibaba-inc.com>
Date: Friday, October 8, 2021 at 4:21 AM
To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: [8u] RFR: 8225690: Multiple AttachListener threads can be created

Hi,

Can I have a review for this backport of JDK-8225690?
Original Issue: https://bugs.openjdk.java.net/browse/JDK-8225690
Original Changeset: https://hg.openjdk.java.net/jdk/jdk/rev/70fab3a8ff02
Backport Issue: https://bugs.openjdk.java.net/browse/JDK-8274953
Backport Changeset: http://cr.openjdk.java.net/~yyang/8274953/

VM can't be attached If someone cleans up the /tmp directory. This patch
addresses the problem. It can not apply cleanly, some minor conflicts are as follows:

1. Atomic::store(new_state, &_state)
jdk8u does not have templated Atomic function family, use explicitly type
conversion `Atomic::store((jlong)new_state, (volatile jlong*)&_state)`.

2. IsRegisteredEnum<AttachListenerState>
jdk8u does not have metaprogramming type traits,
`template<> struct IsRegisteredEnum<AttachListenerState> : public TrueType {};`
simply omit it.

3. os::naked_yield
os::naked_yield is missing due to https://bugs.openjdk.java.net/browse/JDK-8047714,
use os::yield instead.

4. log_debug(attach)("...")
jdk8u does not have unified logging system. Use the following code:
`debug_only(warning("..."))`

5. Test
They can not work because of the usages of LingeredApp. Remove @test tag to
disable them while keeping their source code.

Test cases have been passed manually. The original issue has related bugs:
https://bugs.openjdk.java.net/browse/JDK-8227815
https://bugs.openjdk.java.net/browse/JDK-8235211
https://bugs.openjdk.java.net/browse/JDK-8227738
I'd like to create follow-up backports(JDK-8227815 and JDK-8227738) once this
merged. JDK-8235211 is not necessary since RemovingUnixDomainSocketTest.java
will be ignored as I said before.

Thanks!

From hedongbo at huawei.com  Sat Nov 13 02:29:42 2021
From: hedongbo at huawei.com (hedongbo)
Date: Sat, 13 Nov 2021 02:29:42 +0000
Subject: [8u] PRF:8167014 :jdeps: Missing message: warn.skipped.entry
Message-ID: <1ae62a88acb34e3388eb614cb1407b7e@huawei.com>

Hi,

    Please review the backport of JDK-8167014 to 8u.
    Bug: https://bugs.openjdk.java.net/browse/JDK-8167014
    Original commit: http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/d7c3ad383ed5
    8u webrev: http://cr.openjdk.java.net/~dongbohe/8167014/webrev.00/

    This patch doesn't apply cleanly but is trivial. For JepsTask.java, the lambda expression is used in JDK9,
    and the for loop is used in JDK8. For jdeps.properties, it is only a different context

    Before patch:
    jdeps: tomcat-embed-websocket-10.0.8.jar (https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/10.0.8/tomcat-embed-websocket-10.0.8.jar)
    ````java
    Exception in thread "main" java.lang.InternalError: Missing message: warn.skipped.entry
        at com.sun.tools.jdeps.JdepsTask.getMessage(JdepsTask.java:709)
        at com.sun.tools.jdeps.JdepsTask.warning(JdepsTask.java:673)
        at com.sun.tools.jdeps.JdepsTask.findDependencies(JdepsTask.java:563)
        at com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:324)
        at com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:306)
        at com.sun.tools.jdeps.Main.main(Main.java:48)
    ````

    After Patch:
    worked correctly.

    Tested with tier1. No regression in tests.


Thanks,
hedongbo

From hohensee at amazon.com  Sat Nov 13 22:26:40 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Sat, 13 Nov 2021 22:26:40 +0000
Subject: [8u] PRF:8167014 :jdeps: Missing message: warn.skipped.entry
Message-ID: <3D85D948-4812-4D11-AA57-42CAB40BAEB7@amazon.com>

Lgtm.

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of hedongbo <hedongbo at huawei.com>
Date: Friday, November 12, 2021 at 6:31 PM
To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject: [8u] PRF:8167014 :jdeps: Missing message: warn.skipped.entry

Hi,

    Please review the backport of JDK-8167014 to 8u.
    Bug: https://bugs.openjdk.java.net/browse/JDK-8167014
    Original commit: http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/d7c3ad383ed5
    8u webrev: http://cr.openjdk.java.net/~dongbohe/8167014/webrev.00/

    This patch doesn't apply cleanly but is trivial. For JepsTask.java, the lambda expression is used in JDK9,
    and the for loop is used in JDK8. For jdeps.properties, it is only a different context

    Before patch:
    jdeps: tomcat-embed-websocket-10.0.8.jar (https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/10.0.8/tomcat-embed-websocket-10.0.8.jar)
    ````java
    Exception in thread "main" java.lang.InternalError: Missing message: warn.skipped.entry
        at com.sun.tools.jdeps.JdepsTask.getMessage(JdepsTask.java:709)
        at com.sun.tools.jdeps.JdepsTask.warning(JdepsTask.java:673)
        at com.sun.tools.jdeps.JdepsTask.findDependencies(JdepsTask.java:563)
        at com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:324)
        at com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:306)
        at com.sun.tools.jdeps.Main.main(Main.java:48)
    ````

    After Patch:
    worked correctly.

    Tested with tier1. No regression in tests.


Thanks,
hedongbo


From hedongbo at huawei.com  Mon Nov 15 01:34:42 2021
From: hedongbo at huawei.com (hedongbo)
Date: Mon, 15 Nov 2021 01:34:42 +0000
Subject: [8u] PRF:8167014 :jdeps: Missing message: warn.skipped.entry
In-Reply-To: <3D85D948-4812-4D11-AA57-42CAB40BAEB7@amazon.com>
References: <3D85D948-4812-4D11-AA57-42CAB40BAEB7@amazon.com>
Message-ID: <8a5a39f3bee44834a65401f7f5d5c8d8@huawei.com>

Thank you for your review, Paul.  Tagged.

Thanks,
hedongbo

-----Original Message-----
From: Hohensee, Paul <hohensee at amazon.com> 
Sent: Sunday, November 14, 2021 6:27 AM
To: hedongbo <hedongbo at huawei.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject: Re: [8u] PRF:8167014 :jdeps: Missing message: warn.skipped.entry

Lgtm.

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of hedongbo <hedongbo at huawei.com>
Date: Friday, November 12, 2021 at 6:31 PM
To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject: [8u] PRF:8167014 :jdeps: Missing message: warn.skipped.entry

Hi,

    Please review the backport of JDK-8167014 to 8u.
    Bug: https://bugs.openjdk.java.net/browse/JDK-8167014
    Original commit: http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/d7c3ad383ed5
    8u webrev: http://cr.openjdk.java.net/~dongbohe/8167014/webrev.00/

    This patch doesn't apply cleanly but is trivial. For JepsTask.java, the lambda expression is used in JDK9,
    and the for loop is used in JDK8. For jdeps.properties, it is only a different context

    Before patch:
    jdeps: tomcat-embed-websocket-10.0.8.jar (https://repo1.maven.org/maven2/org/apache/tomcat/embed/tomcat-embed-websocket/10.0.8/tomcat-embed-websocket-10.0.8.jar)
    ````java
    Exception in thread "main" java.lang.InternalError: Missing message: warn.skipped.entry
        at com.sun.tools.jdeps.JdepsTask.getMessage(JdepsTask.java:709)
        at com.sun.tools.jdeps.JdepsTask.warning(JdepsTask.java:673)
        at com.sun.tools.jdeps.JdepsTask.findDependencies(JdepsTask.java:563)
        at com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:324)
        at com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:306)
        at com.sun.tools.jdeps.Main.main(Main.java:48)
    ````

    After Patch:
    worked correctly.

    Tested with tier1. No regression in tests.


Thanks,
hedongbo


From akashche at redhat.com  Mon Nov 15 11:37:36 2021
From: akashche at redhat.com (Alex Kashchenko)
Date: Mon, 15 Nov 2021 11:37:36 +0000
Subject: [8u] RFR: 8240633: Memory leaks in the implementations of
 FileChooserUI
Message-ID: <CABUxsJ3q_cFzf361oWnEj3SvvLfX3VfhM+q_FJLGpqh9nS_Mdw@mail.gmail.com>

Hi,

Please review a backport of a Mac-specific fix:

Bug: https://bugs.openjdk.java.net/browse/JDK-8240633

Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/45273ef93e6f

8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8240633/webrev/

Only changes are to paths and copyright years. Testing: checked that
added test fails without the patch and passes with the patch.

-- 
-Alex


From akashche at redhat.com  Mon Nov 15 18:24:59 2021
From: akashche at redhat.com (Alex Kashchenko)
Date: Mon, 15 Nov 2021 18:24:59 +0000
Subject: [8u] RFR: 8198411: [TEST_BUG] Two java2d tests are unstable in
 mach5
In-Reply-To: <AB103E69-074E-4D38-A6B1-CF2CE203509E@amazon.com>
References: <AB103E69-074E-4D38-A6B1-CF2CE203509E@amazon.com>
Message-ID: <CABUxsJ3Kzusen+KCm6jptJPwT2N0ARvsF64OpkuB_SnZJOhg3Q@mail.gmail.com>

On 4/27/21, Hohensee, Paul <hohensee at amazon.com> wrote:
> Lgtm.

Apologies, I've only discovered this email today. Thanks for the
review! I've re-checked these tests on Linux and Windows and marked
the bug for approval.

>
> Thanks,
> Paul
>
> ?-----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Alex
> Kashchenko <akashche at redhat.com>
> Date: Tuesday, December 1, 2020 at 5:01 AM
> To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
> Subject: [8u] RFR: 8198411: [TEST_BUG] Two java2d tests are unstable in
> mach5
>
> Hi,
>
> Please review the backport of JDK-8198411 to 8u:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198411
>
> Original change: https://hg.openjdk.java.net/jdk/jdk/raw-rev/af2ed7605f8c
>
> 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8198411/webrev.00/
>
> For 8u changes to ProblemList are excluded and paths are changed.
> Testing: checked that changed tests pass on Linux and Windows.
>
> --
> -Alex
>
>
>


-- 
-Alex


From hohensee at amazon.com  Mon Nov 15 19:02:55 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 15 Nov 2021 19:02:55 +0000
Subject: [8u] RFR: 8240633: Memory leaks in the implementations of
 FileChooserUI
Message-ID: <DE0D8A1D-7F94-4704-A715-101E486E3312@amazon.com>

Lgtm.

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Alex Kashchenko <akashche at redhat.com>
Date: Monday, November 15, 2021 at 3:39 AM
To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject: [8u] RFR: 8240633: Memory leaks in the implementations of FileChooserUI

Hi,

Please review a backport of a Mac-specific fix:

Bug: https://bugs.openjdk.java.net/browse/JDK-8240633

Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/45273ef93e6f

8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8240633/webrev/

Only changes are to paths and copyright years. Testing: checked that
added test fails without the patch and passes with the patch.

--
-Alex



From akashche at redhat.com  Mon Nov 15 19:11:06 2021
From: akashche at redhat.com (Alex Kashchenko)
Date: Mon, 15 Nov 2021 19:11:06 +0000
Subject: [8u] RFR: 8240633: Memory leaks in the implementations of
 FileChooserUI
In-Reply-To: <DE0D8A1D-7F94-4704-A715-101E486E3312@amazon.com>
References: <DE0D8A1D-7F94-4704-A715-101E486E3312@amazon.com>
Message-ID: <CABUxsJ3im0=4hYFbHG58sAcYNKUxAmiy78tdZV9g_j0kJOsjgw@mail.gmail.com>

On 11/15/21, Hohensee, Paul <hohensee at amazon.com> wrote:
> Lgtm.

Thanks for the review! I've marked the bug for approval.

>
> Thanks,
> Paul
>
> ?-----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Alex
> Kashchenko <akashche at redhat.com>
> Date: Monday, November 15, 2021 at 3:39 AM
> To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
> Subject: [8u] RFR: 8240633: Memory leaks in the implementations of
> FileChooserUI
>
> Hi,
>
> Please review a backport of a Mac-specific fix:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8240633
>
> Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/45273ef93e6f
>
> 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8240633/webrev/
>
> Only changes are to paths and copyright years. Testing: checked that
> added test fails without the patch and passes with the patch.
>
> --
> -Alex
>
>
>


-- 
-Alex


From dcherepanov at azul.com  Tue Nov 16 16:08:47 2021
From: dcherepanov at azul.com (Dmitry Cherepanov)
Date: Tue, 16 Nov 2021 19:08:47 +0300
Subject: [8u] RFR: JDK-8274407: (tz) Update Timezone Data to 2021c
Message-ID: <a47837ed-1a67-3a64-a4fe-77754d5c94a3@azul.com>

JBS: https://bugs.openjdk.java.net/browse/JDK-8274407
Webrev: http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8274407/webrev.01/

Please review the update to tzdata2021c
 ?* updated manually from the rearguard version (tzdata2021c-rearguard.tar.gz generated by `cd tzdb-2021c && make rearguard_tarballs`)
 ?* backported the diff for ZoneInfoFile.java and TimeZoneTest.java (applied cleanly except the bug id in the test)
 ?* updated the copy of the timezone data that is in the test folder

Testing: tests for sun.util.calendar and java.time.test passed.

Thanks

Dmitry


From zgu at redhat.com  Wed Nov 17 13:05:38 2021
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 17 Nov 2021 08:05:38 -0500
Subject: [8u] RFR 8253147: The javax/swing/JPopupMenu/7154841/bug7154841.java
 fail on big screens
Message-ID: <02a19e0b-9f4b-2601-c140-044260448ffe@redhat.com>

I would like to backport this patch to openjdk8u for parity with Oracle 
8u331.

Bug: https://bugs.openjdk.java.net/browse/JDK-8253147
Patch: https://github.com/openjdk/jdk/commit/65bfe092

The original patch does not apply cleanly.

- AlphaColorTest.java is not in 8u, stripped out corresponding changes.
- bug7154841.java has conflicts on copyright year.

8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8253147-8u/webrev.00/

Test:
   bug7154841.java passed.


Thanks,

-Zhengyu


From hohensee at amazon.com  Wed Nov 17 18:03:24 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 17 Nov 2021 18:03:24 +0000
Subject: [8u] RFR 8253147: The
 javax/swing/JPopupMenu/7154841/bug7154841.java fail on big screens
Message-ID: <D0181616-FD93-4858-AFA7-10762F768130@amazon.com>

Lgtm.

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Zhengyu Gu <zgu at redhat.com>
Date: Wednesday, November 17, 2021 at 5:06 AM
To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject: [8u] RFR 8253147: The javax/swing/JPopupMenu/7154841/bug7154841.java fail on big screens

I would like to backport this patch to openjdk8u for parity with Oracle
8u331.

Bug: https://bugs.openjdk.java.net/browse/JDK-8253147
Patch: https://github.com/openjdk/jdk/commit/65bfe092

The original patch does not apply cleanly.

- AlphaColorTest.java is not in 8u, stripped out corresponding changes.
- bug7154841.java has conflicts on copyright year.

8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8253147-8u/webrev.00/

Test:
   bug7154841.java passed.


Thanks,

-Zhengyu



From zgu at redhat.com  Wed Nov 17 18:39:24 2021
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 17 Nov 2021 13:39:24 -0500
Subject: [8u] RFR 8253147: The
 javax/swing/JPopupMenu/7154841/bug7154841.java fail on big screens
In-Reply-To: <D0181616-FD93-4858-AFA7-10762F768130@amazon.com>
References: <D0181616-FD93-4858-AFA7-10762F768130@amazon.com>
Message-ID: <59f5c736-1b12-53c5-e2ee-3ea656659bed@redhat.com>

Thanks, Paul.

-Zhengyu

On 11/17/21 13:03, Hohensee, Paul wrote:
> Lgtm.
> 
> Thanks,
> Paul
> 
> ?-----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Zhengyu Gu <zgu at redhat.com>
> Date: Wednesday, November 17, 2021 at 5:06 AM
> To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
> Subject: [8u] RFR 8253147: The javax/swing/JPopupMenu/7154841/bug7154841.java fail on big screens
> 
> I would like to backport this patch to openjdk8u for parity with Oracle
> 8u331.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8253147
> Patch: https://github.com/openjdk/jdk/commit/65bfe092
> 
> The original patch does not apply cleanly.
> 
> - AlphaColorTest.java is not in 8u, stripped out corresponding changes.
> - bug7154841.java has conflicts on copyright year.
> 
> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8253147-8u/webrev.00/
> 
> Test:
>     bug7154841.java passed.
> 
> 
> Thanks,
> 
> -Zhengyu
> 
> 


From hohensee at amazon.com  Wed Nov 17 20:30:56 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 17 Nov 2021 20:30:56 +0000
Subject: [8u] RFR: JDK-8274407: (tz) Update Timezone Data to 2021c
Message-ID: <270A2C46-4B26-49AF-981E-3D4474146BB0@amazon.com>

Lgtm.

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Dmitry Cherepanov <dcherepanov at azul.com>
Date: Tuesday, November 16, 2021 at 8:10 AM
To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: [8u] RFR: JDK-8274407: (tz) Update Timezone Data to 2021c

JBS: https://bugs.openjdk.java.net/browse/JDK-8274407
Webrev: http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8274407/webrev.01/

Please review the update to tzdata2021c
  * updated manually from the rearguard version (tzdata2021c-rearguard.tar.gz generated by `cd tzdb-2021c && make rearguard_tarballs`)
  * backported the diff for ZoneInfoFile.java and TimeZoneTest.java (applied cleanly except the bug id in the test)
  * updated the copy of the timezone data that is in the test folder

Testing: tests for sun.util.calendar and java.time.test passed.

Thanks

Dmitry



From dcherepanov at azul.com  Thu Nov 18 08:45:59 2021
From: dcherepanov at azul.com (Dmitry Cherepanov)
Date: Thu, 18 Nov 2021 11:45:59 +0300
Subject: [8u] RFR: JDK-8274407: (tz) Update Timezone Data to 2021c
In-Reply-To: <270A2C46-4B26-49AF-981E-3D4474146BB0@amazon.com>
References: <270A2C46-4B26-49AF-981E-3D4474146BB0@amazon.com>
Message-ID: <f6a3d7ee-0590-42fa-c817-a170196239ca@azul.com>

Thanks Paul.

Tagged for approval.

Dmitry

On 17.11.2021 23:30, Hohensee, Paul wrote:
> Lgtm.
>
> Thanks,
> Paul
>
> ?-----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Dmitry Cherepanov <dcherepanov at azul.com>
> Date: Tuesday, November 16, 2021 at 8:10 AM
> To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
> Subject: [8u] RFR: JDK-8274407: (tz) Update Timezone Data to 2021c
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8274407
> Webrev: http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8274407/webrev.01/
>
> Please review the update to tzdata2021c
>    * updated manually from the rearguard version (tzdata2021c-rearguard.tar.gz generated by `cd tzdb-2021c && make rearguard_tarballs`)
>    * backported the diff for ZoneInfoFile.java and TimeZoneTest.java (applied cleanly except the bug id in the test)
>    * updated the copy of the timezone data that is in the test folder
>
> Testing: tests for sun.util.calendar and java.time.test passed.
>
> Thanks
>
> Dmitry
>
>

From ebaron at redhat.com  Fri Nov 19 20:00:42 2021
From: ebaron at redhat.com (Elliott Baron)
Date: Fri, 19 Nov 2021 15:00:42 -0500
Subject: [8u] RFR: 8033980: Xerces Update: datatype XMLGregorianCalendarImpl
 and DurationImpl
Message-ID: <7ab49225-ca04-5db4-1586-913330b66277@redhat.com>

Hi,

I'm requesting a backport of 8033980 to 8u, as part of an update of 
Xerces to 2.12.0. Xerces should be updated for parity with Oracle JDK.

The JDK 9 fix applies cleanly except for one hunk, which was already 
patched by "8028363: XmlGregorianCalendarImpl.getTimeZone() bug when 
offset is less than 10 minutes".

Bug: https://bugs.openjdk.java.net/browse/JDK-8033980
8u Webrev: https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8033980/webrev.00/

Testing: x86_64 build, jdk_tier1, jdk_other (includes javax/xml) tests

Thanks,
Elliott


From ebaron at redhat.com  Fri Nov 19 22:03:35 2021
From: ebaron at redhat.com (Elliott Baron)
Date: Fri, 19 Nov 2021 17:03:35 -0500
Subject: [8u] RFR: 8035437: Xerces Update: xml/serialize/DOMSerializerImpl
Message-ID: <92168065-bd31-0c4a-d9e4-4fa7b4af4ea8@redhat.com>

Hi,

I'm requesting a backport of 8035437 to 8u, as part of an update of 
Xerces to 2.12.0. Xerces should be updated for parity with Oracle JDK [1].

The JDK 9 patch requires some cosmetic changes to apply to 8u. These 
changes are outlined below categorized by file:
- com/sun/org/apache/xerces/internal/impl/XMLEntityManager
-- Copyright header differences
-- Import differences
- com/sun/org/apache/xml/internal/serialize/XMLSerializer
-- Copyright header differences
-- Import differences
-- Changed context due to previous backport of "8068842: Better JAXP 
data handling".
- com/sun/org/apache/xml/internal/serialize/BaseMarkupSerializer
-- Copyright header differences
-- Import differences
- com/sun/org/apache/xml/internal/serialize/DOMSerializerImpl
-- Context changes due to "8146961: Fix PermGen memory leaks caused by 
static final Exceptions" and "8011795: DOM Serializer prints stack 
traces to System.err"

Bug: https://bugs.openjdk.java.net/browse/JDK-8035437
8u Webrev: https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8035437/webrev.00/

Testing: x86_64 build, jdk_tier1, jdk_other (includes javax/xml) tests

Thanks,
Elliott

[1] https://bugs.openjdk.java.net/browse/JDK-8238164


From ebaron at redhat.com  Fri Nov 19 22:25:40 2021
From: ebaron at redhat.com (Elliott Baron)
Date: Fri, 19 Nov 2021 17:25:40 -0500
Subject: [8u] RFR: 8035437: Xerces Update: xml/serialize/DOMSerializerImpl
In-Reply-To: <92168065-bd31-0c4a-d9e4-4fa7b4af4ea8@redhat.com>
References: <92168065-bd31-0c4a-d9e4-4fa7b4af4ea8@redhat.com>
Message-ID: <0769dd25-0455-45f7-1d5a-c3855fa949ee@redhat.com>

Hi,

On 2021-11-19 5:03 p.m., Elliott Baron wrote:
> I'm requesting a backport of 8035437 to 8u, as part of an update of 
> Xerces to 2.12.0. Xerces should be updated for parity with Oracle JDK [1].
> 
> The JDK 9 patch requires some cosmetic changes to apply to 8u. These 
> changes are outlined below categorized by file:
> - com/sun/org/apache/xerces/internal/impl/XMLEntityManager
> -- Copyright header differences
> -- Import differences
> - com/sun/org/apache/xml/internal/serialize/XMLSerializer
> -- Copyright header differences
> -- Import differences
> -- Changed context due to previous backport of "8068842: Better JAXP 
> data handling".
> - com/sun/org/apache/xml/internal/serialize/BaseMarkupSerializer
> -- Copyright header differences
> -- Import differences
> - com/sun/org/apache/xml/internal/serialize/DOMSerializerImpl
> -- Context changes due to "8146961: Fix PermGen memory leaks caused by 
> static final Exceptions" and "8011795: DOM Serializer prints stack 
> traces to System.err"
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8035437
> 8u Webrev: https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8035437/webrev.00/

Please see this revised 8u webrev, which includes tests in the jdk repo:
https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8035437/webrev.01/

> 
> Testing: x86_64 build, jdk_tier1, jdk_other (includes javax/xml) tests
> 

Thanks,
Elliott

> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8238164


From ebaron at redhat.com  Fri Nov 19 22:58:21 2021
From: ebaron at redhat.com (Elliott Baron)
Date: Fri, 19 Nov 2021 17:58:21 -0500
Subject: [8u] RFR: 8033980: Xerces Update: datatype
 XMLGregorianCalendarImpl and DurationImpl
In-Reply-To: <7ab49225-ca04-5db4-1586-913330b66277@redhat.com>
References: <7ab49225-ca04-5db4-1586-913330b66277@redhat.com>
Message-ID: <3d09cbdf-dc41-a430-f845-fb6aef8009a4@redhat.com>

Hi,

On 2021-11-19 3:00 p.m., Elliott Baron wrote:
> I'm requesting a backport of 8033980 to 8u, as part of an update of 
> Xerces to 2.12.0. Xerces should be updated for parity with Oracle JDK.
> 
> The JDK 9 fix applies cleanly except for one hunk, which was already 
> patched by "8028363: XmlGregorianCalendarImpl.getTimeZone() bug when 
> offset is less than 10 minutes".
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8033980
> 8u Webrev: https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8033980/webrev.00/

Sorry, I forgot to include the JDK repo tests. Here is a revised webrev:
https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8033980/webrev.01/

> 
> Testing: x86_64 build, jdk_tier1, jdk_other (includes javax/xml) tests
> 

Thanks,
Elliott


From akashche at redhat.com  Wed Nov 24 16:07:16 2021
From: akashche at redhat.com (Alex Kashchenko)
Date: Wed, 24 Nov 2021 16:07:16 +0000
Subject: [8u] RFA: 8162572: Update License Header for all JAXP sources
In-Reply-To: <CABUxsJ1YGFqAvEKxi+G8JTY0KS6CD6VuKexYF0yE=_n8KjDVfA@mail.gmail.com>
References: <CABUxsJ1YGFqAvEKxi+G8JTY0KS6CD6VuKexYF0yE=_n8KjDVfA@mail.gmail.com>
Message-ID: <CABUxsJ3G4R8M_Pn9bGW8Mm_0cQEymweEB6o=VkR3Zxt+AATPwA@mail.gmail.com>

On 10/15/21, Alex Kashchenko <akashche at redhat.com> wrote:
> Hi,
>
> JDK-8162572 is not public, so requesting the approval here:
>
> Fix request (8u)
>
> Backport is requested because it can make it easier to backport
> subsequent JAXP parity
> issues to 8u (don't have a comprehensive list, intend to proceed with
> JDK-8163121 first).
>
> Review approval:
>
> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-October/014353.html

Gentle reminder just to increase the visibility of this request, that
is not visible in Jira approval queue because the issue is not public.


-- 
-Alex


From gnu.andrew at redhat.com  Thu Nov 25 01:13:34 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 25 Nov 2021 01:13:34 +0000
Subject: [8u] RFR: JDK-8274407: (tz) Update Timezone Data to 2021c
In-Reply-To: <270A2C46-4B26-49AF-981E-3D4474146BB0@amazon.com>
References: <270A2C46-4B26-49AF-981E-3D4474146BB0@amazon.com>
Message-ID: <YZ7jPoAKxBsyo4aQ@hex.discworld.ac.uk>

On 20:30 Wed 17 Nov     , Hohensee, Paul wrote:
> Lgtm.
> 
> Thanks,
> Paul
> 
> ?-----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Dmitry Cherepanov <dcherepanov at azul.com>
> Date: Tuesday, November 16, 2021 at 8:10 AM
> To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
> Subject: [8u] RFR: JDK-8274407: (tz) Update Timezone Data to 2021c
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8274407
> Webrev: http://cr.openjdk.java.net/~dcherepanov/openjdk8u/8274407/webrev.01/
> 
> Please review the update to tzdata2021c
>   * updated manually from the rearguard version (tzdata2021c-rearguard.tar.gz generated by `cd tzdb-2021c && make rearguard_tarballs`)
>   * backported the diff for ZoneInfoFile.java and TimeZoneTest.java (applied cleanly except the bug id in the test)
>   * updated the copy of the timezone data that is in the test folder
> 
> Testing: tests for sun.util.calendar and java.time.test passed.
> 
> Thanks
> 
> Dmitry
> 
> 

Looks fine to me too, assuming the test files are all the same
as the main data. Approved.

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From dcherepanov at azul.com  Thu Nov 25 10:03:50 2021
From: dcherepanov at azul.com (Dmitry Cherepanov)
Date: Thu, 25 Nov 2021 13:03:50 +0300
Subject: [8u] RFR: JDK-8274407: (tz) Update Timezone Data to 2021c
In-Reply-To: <YZ7jPoAKxBsyo4aQ@hex.discworld.ac.uk>
References: <270A2C46-4B26-49AF-981E-3D4474146BB0@amazon.com>
 <YZ7jPoAKxBsyo4aQ@hex.discworld.ac.uk>
Message-ID: <4a0bc90b-bfc2-6e6e-e173-9a4c1128f7bf@azul.com>

Thanks Andrew. Correct, the test files are all the same as the main data. Pushed.

Dmitry

On 25.11.2021 04:13, Andrew Hughes wrote:
> Looks fine to me too, assuming the test files are all the same
> as the main data. Approved.
>
> Thanks,

From apavlyutkin at azul.com  Thu Nov 25 12:23:17 2021
From: apavlyutkin at azul.com (Alexey Pavlyutkin)
Date: Thu, 25 Nov 2021 12:23:17 +0000
Subject: [8u] RFR 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream
Message-ID: <CH0PR11MB552330D2B65F5A08B0AA68D5C9629@CH0PR11MB5523.namprd11.prod.outlook.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8190753

Patch: https://github.com/openjdk/jdk/commit/c3d8e9228d0558a2ce3e093c105c61ea7af2e1d1

I would like to backport this patch to openjdk8u (the issue was initially raised exactly against 8)

The following changes done to the original patch for 8u


  1.  eliminated using of unsupported instanceof pattern match feature
  2.  changes to absent DeflatingEntryOutputStream class were skipped (in 8 EntryOutputStream handles both RAW and deflating streaming)
  3.  tests were updated to not use unsupported APIs like Path.of(), Map.of(), etc.

8u webrev: http://cr.openjdk.java.net/~yan/8190753/webrev.00/


Verified with with accompanying

./jdk/test/demo/zipfs/LargeCompressedEntrySizeTest.java
./jdk/test/demo/zipfs/ZipFSOutputStreamTest.java
Regression: jdk:tier2

Thank you,
Alex

From dcherepanov at azul.com  Thu Nov 25 12:54:49 2021
From: dcherepanov at azul.com (Dmitry Cherepanov)
Date: Thu, 25 Nov 2021 15:54:49 +0300
Subject: [8u] RFR: JDK-8275766: (tz) Update Timezone Data to 2021e
Message-ID: <f8979470-00dc-563e-cd10-9f441dd56460@azul.com>

JBS: https://bugs.openjdk.java.net/browse/JDK-8275766
Webrev: https://cr.openjdk.java.net/~dcherepanov/openjdk8u/8275766/webrev.01

Please review the update to tzdata2021e
 ?* updated manually from the rearguard version (tzdata2021e-rearguard.tar.gz generated by `cd tzdb-2021e && make rearguard_tarballs`)
 ?* the diff for ZoneInfoFile.java applied cleanly
 ?* updated the copy of the timezone data in the test folder

Will submit a separate request for https://bugs.openjdk.java.net/browse/JDK-8276536

Testing: tests for sun.util.calendar and java.time.test passed

Thanks

Dmitry



From dcherepanov at azul.com  Thu Nov 25 12:58:32 2021
From: dcherepanov at azul.com (Dmitry Cherepanov)
Date: Thu, 25 Nov 2021 15:58:32 +0300
Subject: [8u] RFR: JDK-8276536: Update TimeZoneNames files to follow the
 changes made by JDK-8275766
Message-ID: <940f5999-326d-de28-a2a4-690623a7b51e@azul.com>

JBS: https://bugs.openjdk.java.net/browse/JDK-8276536
Webrev: https://cr.openjdk.java.net/~dcherepanov/openjdk8u/8276536/webrev.01/

The original patch applies cleanly after path shuffling. Backported on top of JDK-8275766.

Testing: tests for sun.util.calendar and java.time.test passed

Thanks

Dmitry


From hohensee at amazon.com  Fri Nov 26 22:30:19 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 26 Nov 2021 22:30:19 +0000
Subject: [8u] RFR: 8035437: Xerces Update: xml/serialize/DOMSerializerImpl
Message-ID: <D96ED7E4-D45E-410B-99F6-9AB0D116ADF2@amazon.com>

Lgtm.

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Elliott Baron <ebaron at redhat.com>
Date: Friday, November 19, 2021 at 2:26 PM
To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject: Re: [8u] RFR: 8035437: Xerces Update: xml/serialize/DOMSerializerImpl

Hi,

On 2021-11-19 5:03 p.m., Elliott Baron wrote:
> I'm requesting a backport of 8035437 to 8u, as part of an update of
> Xerces to 2.12.0. Xerces should be updated for parity with Oracle JDK [1].
>
> The JDK 9 patch requires some cosmetic changes to apply to 8u. These
> changes are outlined below categorized by file:
> - com/sun/org/apache/xerces/internal/impl/XMLEntityManager
> -- Copyright header differences
> -- Import differences
> - com/sun/org/apache/xml/internal/serialize/XMLSerializer
> -- Copyright header differences
> -- Import differences
> -- Changed context due to previous backport of "8068842: Better JAXP
> data handling".
> - com/sun/org/apache/xml/internal/serialize/BaseMarkupSerializer
> -- Copyright header differences
> -- Import differences
> - com/sun/org/apache/xml/internal/serialize/DOMSerializerImpl
> -- Context changes due to "8146961: Fix PermGen memory leaks caused by
> static final Exceptions" and "8011795: DOM Serializer prints stack
> traces to System.err"
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8035437
> 8u Webrev: https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8035437/webrev.00/

Please see this revised 8u webrev, which includes tests in the jdk repo:
https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8035437/webrev.01/

>
> Testing: x86_64 build, jdk_tier1, jdk_other (includes javax/xml) tests
>

Thanks,
Elliott

>
> [1] https://bugs.openjdk.java.net/browse/JDK-8238164



From sgehwolf at redhat.com  Mon Nov 29 11:18:25 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 29 Nov 2021 12:18:25 +0100
Subject: [8u] RFR: JDK-8275766: (tz) Update Timezone Data to 2021e
In-Reply-To: <f8979470-00dc-563e-cd10-9f441dd56460@azul.com>
References: <f8979470-00dc-563e-cd10-9f441dd56460@azul.com>
Message-ID: <03e3e2c4aacae2b85bbde8b078a93700a6e7712f.camel@redhat.com>

On Thu, 2021-11-25 at 15:54 +0300, Dmitry Cherepanov wrote:
> JBS: https://bugs.openjdk.java.net/browse/JDK-8275766
> Webrev: https://cr.openjdk.java.net/~dcherepanov/openjdk8u/8275766/webrev.01
> 
> Please review the update to tzdata2021e
> ??* updated manually from the rearguard version (tzdata2021e-rearguard.tar.gz generated by `cd tzdb-2021e && make rearguard_tarballs`)
> ??* the diff for ZoneInfoFile.java applied cleanly
> ??* updated the copy of the timezone data in the test folder
> 
> Will submit a separate request for https://bugs.openjdk.java.net/browse/JDK-8276536
> 
> Testing: tests for sun.util.calendar and java.time.test passed

This looks fine to me.

Thanks,
Severin


From sgehwolf at redhat.com  Mon Nov 29 11:22:04 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 29 Nov 2021 12:22:04 +0100
Subject: [8u] RFR: JDK-8276536: Update TimeZoneNames files to follow the
 changes made by JDK-8275766
In-Reply-To: <940f5999-326d-de28-a2a4-690623a7b51e@azul.com>
References: <940f5999-326d-de28-a2a4-690623a7b51e@azul.com>
Message-ID: <b22bc4f9b2dc6ca78aaa89dc7ab2bfe3802a7def.camel@redhat.com>

On Thu, 2021-11-25 at 15:58 +0300, Dmitry Cherepanov wrote:
> JBS: https://bugs.openjdk.java.net/browse/JDK-8276536
> Webrev: https://cr.openjdk.java.net/~dcherepanov/openjdk8u/8276536/webrev.01/
> 
> The original patch applies cleanly after path shuffling. Backported on top of JDK-8275766.
> 
> Testing: tests for sun.util.calendar and java.time.test passed

OK. Clean patches don't need a review, though. Please mention this info
in the Fix Request comment (applies clean after JDK-8275766; testing
that you've done).

Thanks,
Severin


From dcherepanov at azul.com  Mon Nov 29 11:40:14 2021
From: dcherepanov at azul.com (Dmitry Cherepanov)
Date: Mon, 29 Nov 2021 14:40:14 +0300
Subject: [8u] RFR: JDK-8275766: (tz) Update Timezone Data to 2021e
In-Reply-To: <03e3e2c4aacae2b85bbde8b078a93700a6e7712f.camel@redhat.com>
References: <f8979470-00dc-563e-cd10-9f441dd56460@azul.com>
 <03e3e2c4aacae2b85bbde8b078a93700a6e7712f.camel@redhat.com>
Message-ID: <65ba0eed-bbc5-22be-9f38-3beddefd711e@azul.com>

Thanks Severin. Tagged for approval (this bug and JDK-8276536).

Dmitry

On 29.11.2021 14:18, Severin Gehwolf wrote:
> On Thu, 2021-11-25 at 15:54 +0300, Dmitry Cherepanov wrote:
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8275766
>> Webrev: https://cr.openjdk.java.net/~dcherepanov/openjdk8u/8275766/webrev.01
>>
>> Please review the update to tzdata2021e
>>  ??* updated manually from the rearguard version (tzdata2021e-rearguard.tar.gz generated by `cd tzdb-2021e && make rearguard_tarballs`)
>>  ??* the diff for ZoneInfoFile.java applied cleanly
>>  ??* updated the copy of the timezone data in the test folder
>>
>> Will submit a separate request for https://bugs.openjdk.java.net/browse/JDK-8276536
>>
>> Testing: tests for sun.util.calendar and java.time.test passed
> This looks fine to me.
>
> Thanks,
> Severin
>

From hohensee at amazon.com  Mon Nov 29 20:25:25 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 29 Nov 2021 20:25:25 +0000
Subject: [8u] RFR: 8033980: Xerces Update: datatype
 XMLGregorianCalendarImpl and DurationImpl
Message-ID: <1EC6BDA5-A1BF-4C6E-AC52-FD64F69E0CC8@amazon.com>

Lgtm.

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Elliott Baron <ebaron at redhat.com>
Date: Friday, November 19, 2021 at 2:59 PM
To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject: Re: [8u] RFR: 8033980: Xerces Update: datatype XMLGregorianCalendarImpl and DurationImpl

Hi,

On 2021-11-19 3:00 p.m., Elliott Baron wrote:
> I'm requesting a backport of 8033980 to 8u, as part of an update of
> Xerces to 2.12.0. Xerces should be updated for parity with Oracle JDK.
>
> The JDK 9 fix applies cleanly except for one hunk, which was already
> patched by "8028363: XmlGregorianCalendarImpl.getTimeZone() bug when
> offset is less than 10 minutes".
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8033980
> 8u Webrev: https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8033980/webrev.00/

Sorry, I forgot to include the JDK repo tests. Here is a revised webrev:
https://cr.openjdk.java.net/~ebaron/jdk8u/JDK-8033980/webrev.01/

>
> Testing: x86_64 build, jdk_tier1, jdk_other (includes javax/xml) tests
>

Thanks,
Elliott



From hohensee at amazon.com  Mon Nov 29 21:18:32 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 29 Nov 2021 21:18:32 +0000
Subject: [8u] RFR 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream
Message-ID: <A1704A93-080E-4B8F-8389-65BE918E4EB2@amazon.com>

Lgtm.

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Alexey Pavlyutkin <apavlyutkin at azul.com>
Date: Thursday, November 25, 2021 at 4:24 AM
To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: [8u] RFR 8190753: (zipfs): Accessing a large entry (> 2^31 bytes) leads to a negative initial size for ByteArrayOutputStream

Bug: https://bugs.openjdk.java.net/browse/JDK-8190753

Patch: https://github.com/openjdk/jdk/commit/c3d8e9228d0558a2ce3e093c105c61ea7af2e1d1

I would like to backport this patch to openjdk8u (the issue was initially raised exactly against 8)

The following changes done to the original patch for 8u


  1.  eliminated using of unsupported instanceof pattern match feature
  2.  changes to absent DeflatingEntryOutputStream class were skipped (in 8 EntryOutputStream handles both RAW and deflating streaming)
  3.  tests were updated to not use unsupported APIs like Path.of(), Map.of(), etc.

8u webrev: http://cr.openjdk.java.net/~yan/8190753/webrev.00/


Verified with with accompanying

./jdk/test/demo/zipfs/LargeCompressedEntrySizeTest.java
./jdk/test/demo/zipfs/ZipFSOutputStreamTest.java
Regression: jdk:tier2

Thank you,
Alex


From gnu.andrew at redhat.com  Tue Nov 30 02:44:36 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 30 Nov 2021 02:44:36 +0000
Subject: OpenJDK 8u322-b01 EA Released
Message-ID: <YaWQFNttNXoUcPyq@hex.discworld.ac.uk>

I've made available an early access source bundle for 8u322, based on
the tag jdk8u322-b01:

https://openjdk-sources.osci.io/openjdk8/openjdk8u322-b01-ea.tar.xz

The tarball is accompanied by a digital signature available at:

https://openjdk-sources.osci.io/openjdk8/openjdk8u322-b01-ea.tar.xz.sig

This is signed by our Red Hat OpenJDK key (openjdk at redhat.com):

PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net)
Fingerprint =3D CA5F 11C6 CE22 644D 42C6  AC44 92EF 8D39 DC13 168F

SHA256 checksums:

87cd94d3b2afc9032f3ecc25c198a380e4ca93f53bb96da81cd28ed7cd39123a  openjdk8u322-b01-ea.tar.xz
f5b7847e0a05ed795b374f05f7dbb88bca228a583d2d635bdfdf474d17d06f3c  openjdk8u322-b01-ea.tar.xz.sig

They are listed at
https://openjdk-sources.osci.io/openjdk8/openjdk8u322-b01-ea.sha256

The tarball was built on RHEL 6 (x86, x86_64) and RHEL 7 (aarch64,
ppc, ppc64, ppc64le, s390x, x86, x86_64)

Changes in 8u322-b01:
  - JDK-6801613: Cross-platform pageDialog and printDialog top margin entry broken
  - JDK-8049348: compiler/intrinsics/bmi/verifycode tests on lzcnt and tzcnt use incorrect assumption about REXB prefix usage
  - JDK-8066588: javax/management/remote/mandatory/connection/RMIConnector_NPETest.java fails to compile
  - JDK-8069034: gc/g1/TestEagerReclaimHumongousRegionsClearMarkBits.java nightly failure
  - JDK-8077590: windows_i586_6.2-product-c2-runThese8_Xcomp_vm failing after win compiler upgrade
  - JDK-8080287: The image of BufferedImage.TYPE_INT_ARGB and BufferedImage.TYPE_INT_ARGB_PRE is blank
  - JDK-8140472: java/net/ipv6tests/TcpTest.java failed intermittently with java.net.BindException: Address already in use: NET_Bind
  - JDK-8176837: SunPKCS11 provider needs to check more details on PKCS11 Mechanism
  - JDK-8177393: Result of RescaleOp for 4BYTE_ABGR images may be 25% black
  - JDK-8177536: Avoid Apple Peer-to-Peer interfaces in networking tests
  - JDK-8182036: Load from initializing arraycopy uses wrong memory state
  - JDK-8183369: RFC unconformity of HttpURLConnection with proxy
  - JDK-8183543: Aarch64: C2 compilation often fails with "failed spill-split-recycle sanity check"
  - JDK-8187450: JNI local refs exceeds capacity warning in NetworkInterface::getAll
  - JDK-8187649: ArrayIndexOutOfBoundsException in java.util.JapaneseImperialCalendar
  - JDK-8190793: Httpserver does not detect truncated request body
  - JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit
  - JDK-8210058: Algorithmic Italic font leans opposite angle in Printing
  - JDK-8225082: Remove IdenTrust certificate that is expiring in September 2021
  - JDK-8225083: Remove Google certificate that is expiring in December 2021
  - JDK-8226806: [macOS 10.14] Methods of Java Robot should be called from appropriate thread
  - JDK-8231438: [macOS] Dark mode for the desktop is not supported
  - JDK-8232226: [macos 10.15] test/jdk/java/awt/color/EqualityTest/EqualityTest.java may fail
  - JDK-8237499: JFR: Include stack trace in the ThreadStart event
  - JDK-8239886: Minimal VM build fails after JDK-8237499
  - JDK-8261397: Try Catch Method Failing to Work When Dividing An Integer By 0
  - JDK-8262731: [macOS] Exception from "Printable.print" is swallowed during "PrinterJob.print"
  - JDK-8272342: [TEST_BUG] java/awt/print/PrinterJob/PageDialogMarginTest.java catches all exceptions
  - JDK-8273342: Null pointer dereference in classFileParser.cpp:2817

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From gnu.andrew at redhat.com  Tue Nov 30 02:47:03 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 30 Nov 2021 02:47:03 +0000
Subject: OpenJDK 8u322-b02 EA Released
Message-ID: <YaWQpz4Ow52bf6iz@hex.discworld.ac.uk>

I've made available an early access source bundle for 8u322, based on
the tag jdk8u322-b02:

https://openjdk-sources.osci.io/openjdk8/openjdk8u322-b02-ea.tar.xz

The tarball is accompanied by a digital signature available at:

https://openjdk-sources.osci.io/openjdk8/openjdk8u322-b02-ea.tar.xz.sig

This is signed by our Red Hat OpenJDK key (openjdk at redhat.com):

PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net)
Fingerprint =3D CA5F 11C6 CE22 644D 42C6  AC44 92EF 8D39 DC13 168F

SHA256 checksums:

b1c43671a9ef0399bfd3443e29a5173e322d5fed6505cefb9ee66458655fafaa  openjdk8u322-b02-ea.tar.xz
23992cb3921fd3cec12d4f785cee706c21346a1b23dc241e1bf9ef993fa545ed  openjdk8u322-b02-ea.tar.xz.sig

They are listed at
https://openjdk-sources.osci.io/openjdk8/openjdk8u322-b02-ea.sha256

The tarball was built on RHEL 6 (x86, x86_64) and RHEL 7 (aarch64,
ppc, ppc64, ppc64le, s390x, x86, x86_64)

Changes in 8u322-b02:
  - JDK-8011541: [TEST_BUG] closed/javax/swing/plaf/metal/MetalUtils/bug6190373.java fails NPE since 7u25b03
  - JDK-8025430: [TEST_BUG] javax/swing/JEditorPane/5076514/bug5076514.java failed since jdk8b108
  - JDK-8041928: MouseEvent.getModifiersEx gives wrong result
  - JDK-8042199: The build of J2DBench via makefile is broken after the JDK-8005402
  - JDK-8044365: (dc) MulticastSendReceiveTests.java failing with ENOMEM when joining group (OS X 10.9)
  - JDK-8060027: Tests java/beans/XMLEncoder/Test4903007.java and java/beans/XMLEncoder/java_awt_GridBagLayout.java
  - JDK-8066652: Default TimeZone is GMT not local if user.timezone is invalid on Mac OS
  - JDK-8140329: [TEST_BUG] test FullScreenAfterSplash.java failed because image was not generated
  - JDK-8147051: StaxEntityResolverWrapper should create StaxXMLInputSource with a resolver indicator
  - JDK-8148915: Intermittent failures of bug6400879.java
  - JDK-8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride
  - JDK-8196572: Tests ColConvCCMTest.java and MTColConvTest.java fail
  - JDK-8220150: macos10.14 Mojave returns anti-aliased glyphs instead of aliased B&W glyphs
  - JDK-8231254: (fs) Add test for macOS Catalina changes to protect system software
  - JDK-8232178: MacVolumesTest failed after upgrade to MacOS Catalina
  - JDK-8235153: [TESTBUG] [macos 10.15] java/awt/Graphics/DrawImageBG/SystemBgColorTest.java fails
  - JDK-8273826: Correct Manifest file name and NPE checks
  - JDK-8274595: DisableRMIOverHTTPTest failed: connection refused
  - JDK-8274779: HttpURLConnection: HttpClient and HttpsClient incorrectly check request method when set to POST

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From gnu.andrew at redhat.com  Tue Nov 30 02:51:07 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 30 Nov 2021 02:51:07 +0000
Subject: OpenJDK 8u322-b03 EA Released
Message-ID: <YaWRmxoBAjaWMBH+@hex.discworld.ac.uk>

I've made available an early access source bundle for 8u322, based on
the tag jdk8u322-b03:

https://openjdk-sources.osci.io/openjdk8/openjdk8u322-b03-ea.tar.xz

The tarball is accompanied by a digital signature available at:

https://openjdk-sources.osci.io/openjdk8/openjdk8u322-b03-ea.tar.xz.sig

This is signed by our Red Hat OpenJDK key (openjdk at redhat.com):

PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net)
Fingerprint =3D CA5F 11C6 CE22 644D 42C6  AC44 92EF 8D39 DC13 168F

SHA256 checksums:

3b26a73c8159d91be30da12bd8cf0336068c731ce9c176b66c779ff0b578f4c2  openjdk8u322-b03-ea.tar.xz
c8296efca2815b5c5014c9ac847d9712bc7041c3b77bc1e537e9e516fa44957d  openjdk8u322-b03-ea.tar.xz.sig

They are listed at
https://openjdk-sources.osci.io/openjdk8/openjdk8u322-b03-ea.sha256

The tarball was built on RHEL 6 (x86, x86_64) and RHEL 7 (aarch64,
ppc, ppc64, ppc64le, s390x, x86, x86_64)

Changes in 8u322-b03:
  - JDK-8048021: Remove @version tag in jaxp repo
  - JDK-8236897: Fix the copyright header for pkcs11gcm2.h

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From gnu.andrew at redhat.com  Tue Nov 30 02:57:51 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 30 Nov 2021 02:57:51 +0000
Subject: [IMPORTANT] 8u & 8u-dev now CLOSED FOR PUSHES for rampdown of 8u322
 and monorepo transition
Message-ID: <YaWTLxaKvO5tc3/P@hex.discworld.ac.uk>

Hi all,

We are now ramping down for the release of OpenJDK 8u322 in January
2022.

jdk8u/jdk8u and jdk8u/jdk8u-dev will be closed until the monorepo
transition is complete [0] and then hgupdater is switched over to use
openjdk8u332 for 8u-dev.  Please await further e-mail before pushing
changes.

Once the monorepo transition is complete, it will be necessary to
perform a fresh checkout of the new 8u-dev repository and rebase
any existing patches on this repository.

Downstream users will be able to take advantage of live git
repositories once the transition is complete. The Mercurial
mono repositories only need to be used by those needing
write access for 8u322 & 8u332 development.

[0] https://bugs.openjdk.java.net/browse/SKARA-1214

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From gnu.andrew at redhat.com  Tue Nov 30 02:52:58 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 30 Nov 2021 02:52:58 +0000
Subject: OpenJDK 8u322-b04 EA Released
Message-ID: <YaWSCprzOSi9RNCV@hex.discworld.ac.uk>

I've made available an early access source bundle for 8u322, based on
the tag jdk8u322-b04:

https://openjdk-sources.osci.io/openjdk8/openjdk8u322-b04-ea.tar.xz

The tarball is accompanied by a digital signature available at:

https://openjdk-sources.osci.io/openjdk8/openjdk8u322-b04-ea.tar.xz.sig

This is signed by our Red Hat OpenJDK key (openjdk at redhat.com):

PGP Key: rsa4096/0x92EF8D39DC13168F (hkp://keys.gnupg.net)
Fingerprint =3D CA5F 11C6 CE22 644D 42C6  AC44 92EF 8D39 DC13 168F

SHA256 checksums:

2dadb3f29eca148fb4e6ced4a334b7497e6c1149ff0bdf9e9adde6394853c951  openjdk8u322-b04-ea.tar.xz
f2b54f3ed8cdb2b02d606460deee6e6da583ce4104ea7fb701f58d4ef7641c7c  openjdk8u322-b04-ea.tar.xz.sig

They are listed at
https://openjdk-sources.osci.io/openjdk8/openjdk8u322-b04-ea.sha256

The tarball was built on RHEL 6 (x86, x86_64) and RHEL 7 (aarch64,
ppc, ppc64, ppc64le, s390x, x86, x86_64)

Changes in 8u322-b04:
  - JDK-8274407: (tz) Update Timezone Data to 2021c
  - JDK-8274467: TestZoneInfo310.java fails with tzdata2021b
  - JDK-8274468: TimeZoneTest.java fails with tzdata2021b

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From gnu.andrew at redhat.com  Tue Nov 30 03:34:53 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 30 Nov 2021 03:34:53 +0000
Subject: [8u] RFR: JDK-8275766: (tz) Update Timezone Data to 2021e
In-Reply-To: <65ba0eed-bbc5-22be-9f38-3beddefd711e@azul.com>
References: <f8979470-00dc-563e-cd10-9f441dd56460@azul.com>
 <03e3e2c4aacae2b85bbde8b078a93700a6e7712f.camel@redhat.com>
 <65ba0eed-bbc5-22be-9f38-3beddefd711e@azul.com>
Message-ID: <YaWb3aLdspO08r1A@hex.discworld.ac.uk>

On 14:40 Mon 29 Nov     , Dmitry Cherepanov wrote:
> Thanks Severin. Tagged for approval (this bug and JDK-8276536).
> 
> Dmitry
>

Please tag these as jdk8u-critical-request for 8u322. I don't see any
need to delay this to April.

It will need to be rebased onto the new monorepo: https://github.com/openjdk/jdk8u-dev

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From dcherepanov at azul.com  Tue Nov 30 07:08:47 2021
From: dcherepanov at azul.com (Dmitry Cherepanov)
Date: Tue, 30 Nov 2021 10:08:47 +0300
Subject: [8u] RFR: JDK-8275766: (tz) Update Timezone Data to 2021e
In-Reply-To: <YaWb3aLdspO08r1A@hex.discworld.ac.uk>
References: <f8979470-00dc-563e-cd10-9f441dd56460@azul.com>
 <03e3e2c4aacae2b85bbde8b078a93700a6e7712f.camel@redhat.com>
 <65ba0eed-bbc5-22be-9f38-3beddefd711e@azul.com>
 <YaWb3aLdspO08r1A@hex.discworld.ac.uk>
Message-ID: <75d3cea8-9556-7008-a255-e1fea5aa3fe5@azul.com>


On 30.11.2021 06:34, Andrew Hughes wrote:
> On 14:40 Mon 29 Nov     , Dmitry Cherepanov wrote:
>> Thanks Severin. Tagged for approval (this bug and JDK-8276536).
>>
>> Dmitry
>>
> Please tag these as jdk8u-critical-request for 8u322. I don't see any
> need to delay this to April.

Tagged as jdk8u-critical-request.

Thanks

Dmitry


>
> It will need to be rebased onto the new monorepo: https://github.com/openjdk/jdk8u-dev
>
> Thanks,