From serguei.spitsyn at oracle.com  Tue Jan  4 23:04:46 2022
From: serguei.spitsyn at oracle.com (Serguei Spitsyn)
Date: Tue, 4 Jan 2022 23:04:46 +0000
Subject: [8u] RFR: 8173361: various crashes in
 JvmtiExport::post_compiled_method_load
In-Reply-To: <348b7a3fcfef4d66bb8f0a4c085e20d9@huawei.com>
References: <4dd54b5a943842868ec4b1c8aed2dbf3@huawei.com>
 <348b7a3fcfef4d66bb8f0a4c085e20d9@huawei.com>
Message-ID: <9EA91A8B-8D32-4652-A393-8F3685DC6F41@oracle.com>

Hi Hedongbo,

The backport looks okay to me.
But I do not see where I can mark it as approved.
Do you have a PR (Pool Request) or a backport bug number?

Thanks,
Serguei


?On 12/29/21, 7:58 PM, "jdk8u-dev on behalf of hedongbo" <jdk8u-dev-retn at openjdk.java.net on behalf of hedongbo at huawei.com> wrote:

    This problem has affected the customer's use at present. Can anyone help to take a look? Thanks.
    
    Thanks,
    hedongbo
    
    From: hedongbo
    Sent: Friday, December 17, 2021 9:35 AM
    To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
    Cc: 'serviceability-dev at openjdk.java.net' <serviceability-dev at openjdk.java.net>
    Subject: [8u] RFR: 8173361: various crashes in JvmtiExport::post_compiled_method_load
    
    
    Hi,
    
    Please review the backport of JDK-8173361 to 8u.
    Bug: https://bugs.openjdk.java.net/browse/JDK-8173361
    11u commit: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/99bdef096320
    8u webrev: https://cr.openjdk.java.net/~dongbohe/8173361/webrev.00/
    
    This patch doesn't apply cleanly.
    I turned NoSafepointVerifier to No_Safepoint_Verifier because JDK- 8146690[1] changed the naming convention.
    I removed the mutexLocker.cpp changeset because JDK-8047290[2]  does not exist in 8.
    I added the CLDClosure* to ServiceThread::oops_do because JDK- 8154580[3] does not exist in 8.
    
    Tested with tier1. No regression in tests.
    Follow-up fix JDK-8235218[4] is planned to be backported as well.
    
    [1] https://bugs.openjdk.java.net/browse/JDK-8146690
    [2] https://bugs.openjdk.java.net/browse/JDK-8047290
    [3] https://bugs.openjdk.java.net/browse/JDK-8154580
    [4] https://bugs.openjdk.java.net/browse/JDK-8235218
    
    
    Thanks,
    
    hedongbo
    
    
    
    
    


From hedongbo at huawei.com  Wed Jan  5 02:20:10 2022
From: hedongbo at huawei.com (hedongbo)
Date: Wed, 5 Jan 2022 02:20:10 +0000
Subject: [8u] RFR: 8173361: various crashes in
 JvmtiExport::post_compiled_method_load
In-Reply-To: <9EA91A8B-8D32-4652-A393-8F3685DC6F41@oracle.com>
References: <4dd54b5a943842868ec4b1c8aed2dbf3@huawei.com>
 <348b7a3fcfef4d66bb8f0a4c085e20d9@huawei.com>
 <9EA91A8B-8D32-4652-A393-8F3685DC6F41@oracle.com>
Message-ID: <510c8595d5124a8c9aeca33795ef92bd@huawei.com>

Thank you for your review, Serguei.

I have added jdk8u-fix-request label in JDK-8173361[1], and now I need to wait for an 8u maintainer to add jdk8u-fix-yes.
After that, the change can be commited by the committer, the recommended process is on the wiki of jdk8u#Contributing[2].

[1] https://bugs.openjdk.java.net/browse/JDK-8146690
[2] https://wiki.openjdk.java.net/display/jdk8u/Main

Thanks,
Hedongbo

-----Original Message-----
From: Serguei Spitsyn <serguei.spitsyn at oracle.com> 
Sent: Wednesday, January 5, 2022 7:05 AM
To: hedongbo <hedongbo at huawei.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>
Cc: serviceability-dev at openjdk.java.net
Subject: Re: [8u] RFR: 8173361: various crashes in JvmtiExport::post_compiled_method_load

Hi Hedongbo,

The backport looks okay to me.
But I do not see where I can mark it as approved.
Do you have a PR (Pool Request) or a backport bug number?

Thanks,
Serguei


?On 12/29/21, 7:58 PM, "jdk8u-dev on behalf of hedongbo" <jdk8u-dev-retn at openjdk.java.net on behalf of hedongbo at huawei.com> wrote:

    This problem has affected the customer's use at present. Can anyone help to take a look? Thanks.
    
    Thanks,
    hedongbo
    
    From: hedongbo
    Sent: Friday, December 17, 2021 9:35 AM
    To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
    Cc: 'serviceability-dev at openjdk.java.net' <serviceability-dev at openjdk.java.net>
    Subject: [8u] RFR: 8173361: various crashes in JvmtiExport::post_compiled_method_load
    
    
    Hi,
    
    Please review the backport of JDK-8173361 to 8u.
    Bug: https://bugs.openjdk.java.net/browse/JDK-8173361
    11u commit: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/99bdef096320
    8u webrev: https://cr.openjdk.java.net/~dongbohe/8173361/webrev.00/
    
    This patch doesn't apply cleanly.
    I turned NoSafepointVerifier to No_Safepoint_Verifier because JDK- 8146690[1] changed the naming convention.
    I removed the mutexLocker.cpp changeset because JDK-8047290[2]  does not exist in 8.
    I added the CLDClosure* to ServiceThread::oops_do because JDK- 8154580[3] does not exist in 8.
    
    Tested with tier1. No regression in tests.
    Follow-up fix JDK-8235218[4] is planned to be backported as well.
    
    [1] https://bugs.openjdk.java.net/browse/JDK-8146690
    [2] https://bugs.openjdk.java.net/browse/JDK-8047290
    [3] https://bugs.openjdk.java.net/browse/JDK-8154580
    [4] https://bugs.openjdk.java.net/browse/JDK-8235218
    
    
    Thanks,
    
    hedongbo
    
    
    
    
    


From hedongbo at huawei.com  Wed Jan  5 02:46:04 2022
From: hedongbo at huawei.com (hedongbo)
Date: Wed, 5 Jan 2022 02:46:04 +0000
Subject: [8u] PRF:8202142 :jfr/event/io/TestInstrumentation is unstable 
In-Reply-To: <8b406e0cda364daaa6ddd53a7859f2f2@huawei.com>
References: <8b406e0cda364daaa6ddd53a7859f2f2@huawei.com>
Message-ID: <b65e5cebeb594e9c94d521cebf3b8edd@huawei.com>

Ping?

From: hedongbo
Sent: Tuesday, December 21, 2021 2:42 PM
To: 'jdk8u-dev' <jdk8u-dev at openjdk.java.net>
Subject: [8u] PRF:8202142 :jfr/event/io/TestInstrumentation is unstable

Hi,

    Please review the backport of JDK-8202142 to 8u.
    Bug: https://bugs.openjdk.java.net/browse/JDK-8202142
    11u commit: https://github.com/openjdk/jdk11u-dev/commit/86c2995eae4b7ef57515445b9dd7505b6dc0bfa2
    8u webrev: https://cr.openjdk.java.net/~dongbohe/8202142/webrev.00/

    Patch does not apply cleanly: change to
    ProblemList.txt is excluded (was added in JDK-8199712), paths reshuffled.

    Testing: checked that TestInstrumentation.java fails without the patch
    and passes with the patch.


Thanks,
hedongbo

From hohensee at amazon.com  Wed Jan  5 16:23:33 2022
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 5 Jan 2022 16:23:33 +0000
Subject: [8u] RFR: 8173361: various crashes in
 JvmtiExport::post_compiled_method_load
Message-ID: <08BC1D48-65B6-47F8-8C8C-349A430CBFCD@amazon.com>

Hi, Serguei,

For 8u, we're still using mailing lists, not PRs. We'll move to PRs when 8u moves to github, which I believe is scheduled for real soon now (for 8u332). Hedong (I think I got his first name right!) just needs to tag the JBS issue with jdk8u-fix-request and add a Fix Request comment pointing to your review email (at https://mail.openjdk.java.net/pipermail/jdk8u-dev/). hg-updater will create a backport JBS issue after the commit.

Thanks,
Paul

?-----Original Message-----
From: serviceability-dev <serviceability-dev-retn at openjdk.java.net> on behalf of Serguei Spitsyn <serguei.spitsyn at oracle.com>
Date: Tuesday, January 4, 2022 at 3:05 PM
To: hedongbo <hedongbo at huawei.com>, jdk8u-dev <jdk8u-dev at openjdk.java.net>
Cc: "serviceability-dev at openjdk.java.net" <serviceability-dev at openjdk.java.net>
Subject: Re: [8u] RFR: 8173361: various crashes in JvmtiExport::post_compiled_method_load

Hi Hedongbo,

The backport looks okay to me.
But I do not see where I can mark it as approved.
Do you have a PR (Pool Request) or a backport bug number?

Thanks,
Serguei


On 12/29/21, 7:58 PM, "jdk8u-dev on behalf of hedongbo" <jdk8u-dev-retn at openjdk.java.net on behalf of hedongbo at huawei.com> wrote:

    This problem has affected the customer's use at present. Can anyone help to take a look? Thanks.

    Thanks,
    hedongbo

    From: hedongbo
    Sent: Friday, December 17, 2021 9:35 AM
    To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
    Cc: 'serviceability-dev at openjdk.java.net' <serviceability-dev at openjdk.java.net>
    Subject: [8u] RFR: 8173361: various crashes in JvmtiExport::post_compiled_method_load


    Hi,

    Please review the backport of JDK-8173361 to 8u.
    Bug: https://bugs.openjdk.java.net/browse/JDK-8173361
    11u commit: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/99bdef096320
    8u webrev: https://cr.openjdk.java.net/~dongbohe/8173361/webrev.00/

    This patch doesn't apply cleanly.
    I turned NoSafepointVerifier to No_Safepoint_Verifier because JDK- 8146690[1] changed the naming convention.
    I removed the mutexLocker.cpp changeset because JDK-8047290[2]  does not exist in 8.
    I added the CLDClosure* to ServiceThread::oops_do because JDK- 8154580[3] does not exist in 8.

    Tested with tier1. No regression in tests.
    Follow-up fix JDK-8235218[4] is planned to be backported as well.

    [1] https://bugs.openjdk.java.net/browse/JDK-8146690
    [2] https://bugs.openjdk.java.net/browse/JDK-8047290
    [3] https://bugs.openjdk.java.net/browse/JDK-8154580
    [4] https://bugs.openjdk.java.net/browse/JDK-8235218


    Thanks,

    hedongbo








From hohensee at amazon.com  Mon Jan 10 22:44:17 2022
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 10 Jan 2022 22:44:17 +0000
Subject: [8u] PRF:8202142 :jfr/event/io/TestInstrumentation is unstable 
Message-ID: <A306B6B6-87A2-4682-9013-B7B79D2DB6CB@amazon.com>

Lgtm.



Thanks,

Paul



hedongbo at huawei.com<mailto:hedongbo at huawei.com> wrote:

>Hi,

>

>    Please review the backport of JDK-8202142 to 8u.

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

>    11u commit: https://github.com/openjdk/jdk11u-dev/commit/86c2995eae4b7ef57515445b9dd7505b6dc0bfa2

>    8u webrev: https://cr.openjdk.java.net/~dongbohe/8202142/webrev.00/

>

>    Patch does not apply cleanly: change to

>    ProblemList.txt is excluded (was added in JDK-8199712), paths reshuffled.

>

>    Testing: checked that TestInstrumentation.java fails without the patch

>    and passes with the patch.

>

>

>Thanks,

>hedongbo




From hedongbo at huawei.com  Tue Jan 11 01:08:02 2022
From: hedongbo at huawei.com (hedongbo)
Date: Tue, 11 Jan 2022 01:08:02 +0000
Subject: [8u] PRF:8202142 :jfr/event/io/TestInstrumentation is unstable 
In-Reply-To: <A306B6B6-87A2-4682-9013-B7B79D2DB6CB@amazon.com>
References: <A306B6B6-87A2-4682-9013-B7B79D2DB6CB@amazon.com>
Message-ID: <27f47dbe585740258f58fbdecff2df15@huawei.com>

Thank you for your review, Paul. Tagged.

Thanks,
hedongbo

From: Hohensee, Paul <hohensee at amazon.com>
Sent: Tuesday, January 11, 2022 6:44 AM
To: hedongbo <hedongbo at huawei.com>; jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject: Re: [8u] PRF:8202142 :jfr/event/io/TestInstrumentation is unstable


Lgtm.



Thanks,

Paul



hedongbo at huawei.com<mailto:hedongbo at huawei.com> wrote:

>Hi,

>

>    Please review the backport of JDK-8202142 to 8u.

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

>    11u commit: https://github.com/openjdk/jdk11u-dev/commit/86c2995eae4b7ef57515445b9dd7505b6dc0bfa2

>    8u webrev: https://cr.openjdk.java.net/~dongbohe/8202142/webrev.00/

>

>    Patch does not apply cleanly: change to

>    ProblemList.txt is excluded (was added in JDK-8199712), paths reshuffled.

>

>    Testing: checked that TestInstrumentation.java fails without the patch

>    and passes with the patch.

>

>

>Thanks,

>hedongbo




From akashche at redhat.com  Tue Jan 11 13:31:34 2022
From: akashche at redhat.com (Alex Kashchenko)
Date: Tue, 11 Jan 2022 13:31:34 +0000
Subject: [8u] RFR: 8270290: NTLM authentication fails if HEAD request is used
Message-ID: <CABUxsJ1SU9iQnHTtqV4DQrGzbRxU+nieWrWhaLeGQqY12=byAQ@mail.gmail.com>

Hi,

Please review a backport of JDK-8270290 to 8u:

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

11u commit: https://github.com/openjdk/jdk11u-dev/commit/242bbefec901cee2da17a1a2b9b8485b8937ed00

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

Code change in 8u is the same, test has required minor adjustments:

1. paths changed

2. @library changed from "/test/lib" to
"../../../../../lib/testlibrary" (used this way in other www/http
tests)

3. stream.readAllBytes() changed to Utils.readAllBytes(stream)

Testing: checked that added test fails without the patch and passes
with the patch, ran jtreg:sun/net/www/protocol/http

-- 
-Alex


From hohensee at amazon.com  Tue Jan 11 17:09:47 2022
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 11 Jan 2022 17:09:47 +0000
Subject: [8u] RFR: 8270290: NTLM authentication fails if HEAD request is
 used
Message-ID: <4C7BED3B-8830-4C6F-957D-EF9D63215E58@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: Tuesday, January 11, 2022 at 5:32 AM
To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject: [8u] RFR: 8270290: NTLM authentication fails if HEAD request is used

Hi,

Please review a backport of JDK-8270290 to 8u:

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

11u commit: https://github.com/openjdk/jdk11u-dev/commit/242bbefec901cee2da17a1a2b9b8485b8937ed00

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

Code change in 8u is the same, test has required minor adjustments:

1. paths changed

2. @library changed from "/test/lib" to
"../../../../../lib/testlibrary" (used this way in other www/http
tests)

3. stream.readAllBytes() changed to Utils.readAllBytes(stream)

Testing: checked that added test fails without the patch and passes
with the patch, ran jtreg:sun/net/www/protocol/http

--
-Alex



From akashche at redhat.com  Tue Jan 11 17:31:15 2022
From: akashche at redhat.com (Alex Kashchenko)
Date: Tue, 11 Jan 2022 17:31:15 +0000
Subject: [8u] RFR: 8270290: NTLM authentication fails if HEAD request is
 used
In-Reply-To: <4C7BED3B-8830-4C6F-957D-EF9D63215E58@amazon.com>
References: <4C7BED3B-8830-4C6F-957D-EF9D63215E58@amazon.com>
Message-ID: <CABUxsJ1JHWWn3F2TmpjktxKpd+N8qvriumhqWoQfudAnji9E-Q@mail.gmail.com>

On 1/11/22, 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: Tuesday, January 11, 2022 at 5:32 AM
> To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
> Subject: [8u] RFR: 8270290: NTLM authentication fails if HEAD request is
> used
>
> Hi,
>
> Please review a backport of JDK-8270290 to 8u:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8270290
>
> 11u commit:
> https://github.com/openjdk/jdk11u-dev/commit/242bbefec901cee2da17a1a2b9b8485b8937ed00
>
> 8u webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8270290/webrev.00/
>
> Code change in 8u is the same, test has required minor adjustments:
>
> 1. paths changed
>
> 2. @library changed from "/test/lib" to
> "../../../../../lib/testlibrary" (used this way in other www/http
> tests)
>
> 3. stream.readAllBytes() changed to Utils.readAllBytes(stream)
>
> Testing: checked that added test fails without the patch and passes
> with the patch, ran jtreg:sun/net/www/protocol/http
>
> --
> -Alex
>
>
>


-- 
-Alex


From yibo.yl at alibaba-inc.com  Wed Jan 12 07:28:06 2022
From: yibo.yl at alibaba-inc.com (=?UTF-8?B?5p2o6b6ZKOS5ieaziik=?=)
Date: Wed, 12 Jan 2022 15:28:06 +0800
Subject: =?UTF-8?B?Wzh1XSBSRlI6IDgyNjA1ODk6IENyYXNoIGluIEpmclRyYWNlSWRMb2FkQmFycmllcjo6bG9h?=
 =?UTF-8?B?ZChfamNsYXNzKik=?=
Message-ID: <1fd986c0-90ff-4ab2-8c67-f9911493686a.yibo.yl@alibaba-inc.com>

Hi,
I would appreciate it if you could review the backport of JDK-8260589 to 8u.
This crash problem is very easy to reproduce, so I feel it is necessary to backport it to 8u.

Bug: https://bugs.openjdk.java.net/browse/JDK-8260589
11u commit: https://github.com/openjdk/jdk11u-dev/commit/1d204c554ffe969567161cc05992486ff47d346d
8u webrev: https://cr.openjdk.java.net/~ddong/8260589/webrev.00
Test: jdk/test/jdk/jfr/jvm/TestPrimitiveClasses.java passed.


Due to the differences between JFR in 11u and 17, Denghui made some changes when backporting this fix to 11u. 
Denghui's changes also apply to 8u, so I directly quote Denghui's list here. (4 in total)
1. use MaxJfrEventId + 101 instead of LAST_TYPE_ID + 1 as the klass id of void.class
2. jdk 11 doesn't support jfr streaming, so I removed the call `JfrTraceIdEpoch::set_changed_tag_state()` in `load_primitive`
3. the Class in jdk 11 doesn't have the field 'hidden', so I removed `writer->write<bool>(false);` in `write_primitive`
4. there are many differences in the API of JfrTraceId between 11u and tip

In addition to the above differences, I also make supplementary explanations for the modifications I made.
1. The static global variable clear_artifacts in 11u was introduced by the bugfix https://bugs.openjdk.java.net/browse/JDK-8231081, but this fix has not been backported to 8u, so I removed the code related to clear_artifacts. In 8u, the metadata of the primitive types will be written into the previous chunk on every chunk rotation.
2. In 11u, _artifacts and _class_unload are static global variables, but in 8u, they are static member variables of JfrTypeSet, so I also made necessary changes to the functions that use these two variables.

Thanks,
Long Yang


From hedongbo at huawei.com  Thu Jan 13 02:29:23 2022
From: hedongbo at huawei.com (hedongbo)
Date: Thu, 13 Jan 2022 02:29:23 +0000
Subject: [8u] PRF:8194154 :System property user.dir should not be changed
Message-ID: <17042e3e995f4c9895c41163848d2a6d@huawei.com>

Hi,

Please review the backport of JDK-8194154 to 8u.
Bug: https://bugs.openjdk.java.net/browse/JDK-8194154
Original commit: http://hg.openjdk.java.net/jdk/jdk/rev/847a988152b8
8u webrev: https://cr.openjdk.java.net/~dongbohe/8194154/webrev.00/

Patch doesn't apply cleanly but is trivial, because JDK-8154231[1] and JDK-8155775[2] does not exist in 8,
and some copyright year conflicts.

Testing: checked that added test fails without the patch and passes with the patch, tested with tier1.

[1] https://bugs.openjdk.java.net/browse/JDK-8154231
[2] https://bugs.openjdk.java.net/browse/JDK-8155775

Thanks,
hedongbo

From zgu at redhat.com  Mon Jan 17 15:42:34 2022
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 17 Jan 2022 10:42:34 -0500
Subject: [8u] RFR 8209178: Proxied HttpsURLConnection doesn't send BODY when
 retrying POST request
Message-ID: <c49960d2-8fc5-bad9-e09e-08d08e495d7d@redhat.com>

Please review the 8u backport for parity with Oracle 8u331.

The JDK11u patch does not apply cleanly, but the only conflict is the 
copyright year line  of HttpClient.java.

However, the new test needs to be modified to run.

1) Removed module line.
2) Changed test library /test/lib => /lib/testlibrary
3) Changed library import as well jdk.test.lib.net.URIBuilder => 
jdk.testlibrary.net.URIBuilder


Bug: https://bugs.openjdk.java.net/browse/JDK-8209178
11u webrev: https://cr.openjdk.java.net/~vkempik/8209178/webrev.00/

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

Test:
   New test passes.

Thanks,

-Zhengyu


From hohensee at amazon.com  Mon Jan 17 20:31:52 2022
From: hohensee at amazon.com (Hohensee, Paul)
Date: Mon, 17 Jan 2022 20:31:52 +0000
Subject: [8u] RFR 8209178: Proxied HttpsURLConnection doesn't send BODY
 when retrying POST request
Message-ID: <44066DD0-3ED6-4E21-863D-B3FE69A6269B@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: Monday, January 17, 2022 at 7:43 AM
To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject: [8u] RFR 8209178: Proxied HttpsURLConnection doesn't send BODY when retrying POST request

Please review the 8u backport for parity with Oracle 8u331.

The JDK11u patch does not apply cleanly, but the only conflict is the
copyright year line  of HttpClient.java.

However, the new test needs to be modified to run.

1) Removed module line.
2) Changed test library /test/lib => /lib/testlibrary
3) Changed library import as well jdk.test.lib.net.URIBuilder =>
jdk.testlibrary.net.URIBuilder


Bug: https://bugs.openjdk.java.net/browse/JDK-8209178
11u webrev: https://cr.openjdk.java.net/~vkempik/8209178/webrev.00/

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

Test:
   New test passes.

Thanks,

-Zhengyu



From zgu at redhat.com  Mon Jan 17 20:38:30 2022
From: zgu at redhat.com (Zhengyu Gu)
Date: Mon, 17 Jan 2022 15:38:30 -0500
Subject: [8u] RFR 8209178: Proxied HttpsURLConnection doesn't send BODY
 when retrying POST request
In-Reply-To: <44066DD0-3ED6-4E21-863D-B3FE69A6269B@amazon.com>
References: <44066DD0-3ED6-4E21-863D-B3FE69A6269B@amazon.com>
Message-ID: <d258a6f5-54f8-0a78-dc4e-5d7a8923a7cb@redhat.com>

Thanks, Paul.

Tagged for approval.

-Zhengyu

On 1/17/22 15:31, 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: Monday, January 17, 2022 at 7:43 AM
> To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
> Subject: [8u] RFR 8209178: Proxied HttpsURLConnection doesn't send BODY when retrying POST request
> 
> Please review the 8u backport for parity with Oracle 8u331.
> 
> The JDK11u patch does not apply cleanly, but the only conflict is the
> copyright year line  of HttpClient.java.
> 
> However, the new test needs to be modified to run.
> 
> 1) Removed module line.
> 2) Changed test library /test/lib => /lib/testlibrary
> 3) Changed library import as well jdk.test.lib.net.URIBuilder =>
> jdk.testlibrary.net.URIBuilder
> 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8209178
> 11u webrev: https://cr.openjdk.java.net/~vkempik/8209178/webrev.00/
> 
> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8209178-8u/webrev.00/
> 
> Test:
>     New test passes.
> 
> Thanks,
> 
> -Zhengyu
> 
> 


From julia.boes at oracle.com  Tue Jan 18 10:29:32 2022
From: julia.boes at oracle.com (Julia Boes)
Date: Tue, 18 Jan 2022 10:29:32 +0000
Subject: [8u] RFR 8209178: Proxied HttpsURLConnection doesn't send BODY when
 retrying POST request
Message-ID: <d027dbe4-0adb-ef75-23a2-15a599c3e41c@oracle.com>

LGTM

> ?-----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Zhengyu Gu
<zgu at redhat.com>
> Date: Monday, January 17, 2022 at 7:43 AM
> To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
> Subject: [8u] RFR 8209178: Proxied HttpsURLConnection doesn't send BODY when
retrying POST request
>
> Please review the 8u backport for parity with Oracle 8u331.
>
> The JDK11u patch does not apply cleanly, but the only conflict is the
> copyright year line  of HttpClient.java.
>
> However, the new test needs to be modified to run.
>
> 1) Removed module line.
> 2) Changed test library /test/lib => /lib/testlibrary
> 3) Changed library import as well jdk.test.lib.net.URIBuilder =>
> jdk.testlibrary.net.URIBuilder
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8209178
> 11u webrev: https://cr.openjdk.java.net/~vkempik/8209178/webrev.00/
>
> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8209178-8u/webrev.00/
>
> Test:
>     New test passes.
>
> Thanks,
>
> -Zhengyu
>
>

From zgu at redhat.com  Tue Jan 18 13:35:55 2022
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 18 Jan 2022 08:35:55 -0500
Subject: [8u] RFR 8209178: Proxied HttpsURLConnection doesn't send BODY
 when retrying POST request
In-Reply-To: <d027dbe4-0adb-ef75-23a2-15a599c3e41c@oracle.com>
References: <d027dbe4-0adb-ef75-23a2-15a599c3e41c@oracle.com>
Message-ID: <0eda5388-ce72-6537-c143-eba251284bee@redhat.com>

Thanks, Julia.

-Zhengyu

On 1/18/22 05:29, Julia Boes wrote:
> LGTM
> 
>> ?-----Original Message-----
>> From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Zhengyu Gu
> <zgu at redhat.com>
>> Date: Monday, January 17, 2022 at 7:43 AM
>> To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
>> Subject: [8u] RFR 8209178: Proxied HttpsURLConnection doesn't send BODY when
> retrying POST request
>>
>> Please review the 8u backport for parity with Oracle 8u331.
>>
>> The JDK11u patch does not apply cleanly, but the only conflict is the
>> copyright year line  of HttpClient.java.
>>
>> However, the new test needs to be modified to run.
>>
>> 1) Removed module line.
>> 2) Changed test library /test/lib => /lib/testlibrary
>> 3) Changed library import as well jdk.test.lib.net.URIBuilder =>
>> jdk.testlibrary.net.URIBuilder
>>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8209178
>> 11u webrev: https://cr.openjdk.java.net/~vkempik/8209178/webrev.00/
>>
>> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8209178-8u/webrev.00/
>>
>> Test:
>>      New test passes.
>>
>> Thanks,
>>
>> -Zhengyu
>>
>>
> 


From hohensee at amazon.com  Tue Jan 18 16:20:07 2022
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 18 Jan 2022 16:20:07 +0000
Subject: RFR [8u] JDK-8044051 : Test
 jdk/lambda/vm/InterfaceAccessFlagsTest.java gets IOException during
 compilation
Message-ID: <184A8656-DD3C-4593-9196-C14AAA1EC00F@amazon.com>

For a clean backport, you can just tag the JBS issue with jdk8u-fix-request and add a Fix Request (8u) comment.

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of panxuefeng <panxuefeng at loongson.cn>
Date: Tuesday, January 18, 2022 at 2:58 AM
To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: RFR [8u] JDK-8044051 : Test jdk/lambda/vm/InterfaceAccessFlagsTest.java gets IOException during compilation

Hi ,

Please review the backport of  JDK-8044051:

Original bug: https://bugs.openjdk.java.net/browse/JDK-8044051

Original commit: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/157b0a8bf65c

Webrev: http://cr.openjdk.java.net/~aoqi/8044051/webrev.8u.01/

Patch applies clean. 8u specific changes are only to path and copyright header. Testing:
ran jtreg: jdk/lambda/vm/InterfaceAccessFlagsTest.java.

Thanks,

Pan xuefeng


From gnu.andrew at redhat.com  Wed Jan 19 04:42:16 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 19 Jan 2022 04:42:16 +0000
Subject: 8u322 Release Update
Message-ID: <YeeWqG6avIyGibau@hex.discworld.ac.uk>

I have pushed the security fixes for 8u to the monojdk8u repository.
These have all been backported and reviewed within the vulnerability
group.

I have not yet added the jdk8u322-ga tag. I will do this, and make a
release announcement + tarball, once the update has successfully
completed our testing.

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 zgu at redhat.com  Wed Jan 19 15:07:54 2022
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 19 Jan 2022 10:07:54 -0500
Subject: [8u] RFR 8273341: Update Siphash to version 1.0
Message-ID: <2fe541d1-fccc-c89d-6722-3001f3744e20@redhat.com>

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


Bug: https://bugs.openjdk.java.net/browse/JDK-8273341
Patch: 
https://github.com/openjdk/jdk/commit/6cf4cd1aa46414d9af17f3704b27d0d381a17ee8

The only conflict in 8u backport is copyright year line of altHashing.hpp

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

Test:
   hotspot runtime


Thanks,

-Zhengyu


From gnu.andrew at redhat.com  Wed Jan 19 15:58:11 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 19 Jan 2022 15:58:11 +0000
Subject: [8u] RFR 8273341: Update Siphash to version 1.0
In-Reply-To: <2fe541d1-fccc-c89d-6722-3001f3744e20@redhat.com>
References: <2fe541d1-fccc-c89d-6722-3001f3744e20@redhat.com>
Message-ID: <Yeg1E+x/6YiOpABF@hex.discworld.ac.uk>

On 10:07 Wed 19 Jan     , Zhengyu Gu wrote:
> I would like to backport this patch to 8u for parity with Oracle 8u331.
> 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8273341
> Patch: 
> https://github.com/openjdk/jdk/commit/6cf4cd1aa46414d9af17f3704b27d0d381a17ee8
> 
> The only conflict in 8u backport is copyright year line of altHashing.hpp
> 
> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8273341-8u/webrev.00/
> 
> Test:
>    hotspot runtime
> 
> 
> Thanks,
> 
> -Zhengyu
> 

Looks fine.

The main change causing the copyright difference seems to be
JDK-8164738: "Convert AltHashing_test to GTest", which doesn't
make sense for 8u.

I would, however, hold off on approval for 8u until this is
in 11u & 17u. It still seems to be in process there at the
present time.

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 zgu at redhat.com  Wed Jan 19 16:05:24 2022
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 19 Jan 2022 11:05:24 -0500
Subject: [8u] RFR 8273341: Update Siphash to version 1.0
In-Reply-To: <Yeg1E+x/6YiOpABF@hex.discworld.ac.uk>
References: <2fe541d1-fccc-c89d-6722-3001f3744e20@redhat.com>
 <Yeg1E+x/6YiOpABF@hex.discworld.ac.uk>
Message-ID: <5e307bd3-1d21-779a-2374-be714a545499@redhat.com>

>>
>> -Zhengyu
>>
> 
> Looks fine.
> 
> The main change causing the copyright difference seems to be
> JDK-8164738: "Convert AltHashing_test to GTest", which doesn't
> make sense for 8u.
> 
> I would, however, hold off on approval for 8u until this is
> in 11u & 17u. It still seems to be in process there at the
> present time.
> 

Yes, I always wait till a patch in 11u (if apply) before push 8u patch.

Thanks,

-Zhengyu

> Thanks,


From zgu at redhat.com  Thu Jan 20 14:22:55 2022
From: zgu at redhat.com (Zhengyu Gu)
Date: Thu, 20 Jan 2022 09:22:55 -0500
Subject: [8u] RFR 8273341: Update Siphash to version 1.0
In-Reply-To: <Yeg1E+x/6YiOpABF@hex.discworld.ac.uk>
References: <2fe541d1-fccc-c89d-6722-3001f3744e20@redhat.com>
 <Yeg1E+x/6YiOpABF@hex.discworld.ac.uk>
Message-ID: <90ca212f-bb2b-b6c2-a7ae-3b3ca749005c@redhat.com>

Hi Andrew,

>> Thanks,
>>
>> -Zhengyu
>>
> 
> Looks fine.
> 
> The main change causing the copyright difference seems to be
> JDK-8164738: "Convert AltHashing_test to GTest", which doesn't
> make sense for 8u.
> 
> I would, however, hold off on approval for 8u until this is
> in 11u & 17u. It still seems to be in process there at the
> present time.

This patch has been integrated in 17u and 11u. Could you please approve 
the patch for 8u?

Thanks,

-Zhengyu

> 
> Thanks,


From bylokhov at amazon.com  Fri Jan 21 03:00:23 2022
From: bylokhov at amazon.com (Sergey Bylokhov)
Date: Thu, 20 Jan 2022 19:00:23 -0800
Subject: [8u] RFR 8280060: The sun/rmi/server/Activation.java class use
 Thread.dumpStack()
Message-ID: <39ecffa9-9af6-031a-1928-b87bdbebad06@amazon.com>

Hello,

Please review the fix for JDK-8280060.

JBS: https://bugs.openjdk.java.net/browse/JDK-8280060
Webrev: http://cr.openjdk.java.net/~serb/8280060/webrev.00

This change removes the "Thread.dumpStack()" from the Activation class which seems was used for 
debugging. In jdk8 It was added by the JDK-8174770 here:
http://hg.openjdk.java.net/jdk8u/monojdk8u/annotate/98c3f2812caf/jdk/src/share/classes/sun/rmi/server/Activation.java#l538

The same patch for jdk11 does not have it:
https://github.com/openjdk/jdk11u/commit/4ce7b5f28063abca8391d5d7173a45210191e269#diff-fe5b09c998a43189c85b9465455d866b07b32131b2b0f85a6e5801176b22362aR548


-- 
Best regards, Sergey.

From hohensee at amazon.com  Fri Jan 21 15:59:06 2022
From: hohensee at amazon.com (Hohensee, Paul)
Date: Fri, 21 Jan 2022 15:59:06 +0000
Subject: [8u] RFR 8280060: The sun/rmi/server/Activation.java class use
 Thread.dumpStack()
Message-ID: <17CB02AE-91F3-449F-AE9B-949D185C1B3E@amazon.com>

It's not in jdk9 either. I dug around a bit but couldn't find where it was removed.

Lgtm.

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Sergey Bylokhov <bylokhov at amazon.com>
Date: Thursday, January 20, 2022 at 7:01 PM
To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: [8u] RFR 8280060: The sun/rmi/server/Activation.java class use Thread.dumpStack()

Hello,

Please review the fix for JDK-8280060.

JBS: https://bugs.openjdk.java.net/browse/JDK-8280060
Webrev: http://cr.openjdk.java.net/~serb/8280060/webrev.00

This change removes the "Thread.dumpStack()" from the Activation class which seems was used for 
debugging. In jdk8 It was added by the JDK-8174770 here:
http://hg.openjdk.java.net/jdk8u/monojdk8u/annotate/98c3f2812caf/jdk/src/share/classes/sun/rmi/server/Activation.java#l538

The same patch for jdk11 does not have it:
https://github.com/openjdk/jdk11u/commit/4ce7b5f28063abca8391d5d7173a45210191e269#diff-fe5b09c998a43189c85b9465455d866b07b32131b2b0f85a6e5801176b22362aR548


-- 
Best regards, Sergey.


From t.glaser at tarent.de  Sat Jan 22 21:07:10 2022
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Sat, 22 Jan 2022 22:07:10 +0100 (CET)
Subject: jdk8u322 release and packaging
Message-ID: <df7b8b73-9399-a796-c06b-325f74c75048@tarent.de>

Hi,

I?m currently packaging openjdk-8 for Debian (unstable, where
it is tested for LTS/ELTS updating older releases). I have
taken it over from the previous maintainer, but I am ?mostly?
keeping this alive.

I see that the 8u322 release (which I had put into my calendar
https://wiki.openjdk.java.net/display/jdk8u/Main#Main-Timelines
from ?) seems to be delayed because of repository changes.

These repository changes are a problem. The packaging depends
heavily on being able to download the individual hg releases?
tarballs, plus aarch32 and aarch64-shenandoah, separately and
put them together in suitable ways depending on the architecture
building for.

As I said above, I?ve taken this over because nobody else was
doing it so I?m not heavily invested in this packaging. I?m
trying to not change too much.

Is there any way (which will stay stable, even when you?re going
to move repositories *again*, to git) to split the download into
what the old repositories have been, so I can still get my tarballs
in the way the current packaging requires?

Otherwise I?d have to change things a lot, which will be tricky
*and* time-consuming (and I?d have to ask $employer for more time
than I can currently use for this).

I?d prefer best if you would just push the new releases also to
the old repositories and tag them appropriately. But I understand
chances for this going to happen are small as you seem to be very
interested in this new-fangled git thingy :/

Thanks in advance,
//mirabilos
-- 
Infrastrukturexperte ? tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/
Telephon +49 228 54881-393 ? Fax: +49 228 54881-235
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/?\ The UTF-8 Ribbon
??? Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
??? HTML eMail! Also,     https://www.tarent.de/newsletter
??? header encryption!
                        ****************************************************

From apavlyutkin at azul.com  Mon Jan 24 05:48:43 2022
From: apavlyutkin at azul.com (Alexey Pavlyutkin)
Date: Mon, 24 Jan 2022 05:48:43 +0000
Subject: [8u] RFR 8190753: (zipfs): Accessing a large entry (> 2^31 bytes)
 leads to a negative initial size for ByteArrayOutputStream
In-Reply-To: <MWHPR11MB12480453EE9F31D460F4EB96C97B9@MWHPR11MB1248.namprd11.prod.outlook.com>
References: <CH0PR11MB552330D2B65F5A08B0AA68D5C9629@CH0PR11MB5523.namprd11.prod.outlook.com>
 <af6738c9303f847a3c8b7a4aef59824c80aedfe6.camel@redhat.com>
 <CH0PR11MB5523A99FA95DA23124661EE5C9749@CH0PR11MB5523.namprd11.prod.outlook.com>
 <YbgNjUh8/TDYX8MF@hex.discworld.ac.uk>
 <MWHPR11MB12480453EE9F31D460F4EB96C97B9@MWHPR11MB1248.namprd11.prod.outlook.com>
Message-ID: <MW4PR11MB5935EEDA25A59251F48288C3C95E9@MW4PR11MB5935.namprd11.prod.outlook.com>

Sorry guys, any update? Thank you

Cheers,
Alex

-----Original Message-----
From: Alexey Pavlyutkin 
Sent: Monday, December 20, 2021 12:01 PM
To: Andrew Hughes <gnu.andrew at redhat.com>
Cc: Severin Gehwolf <sgehwolf at redhat.com>; jdk8u-dev at openjdk.java.net
Subject: RE: [8u] RFR 8190753: (zipfs): Accessing a large entry (> 2^31 bytes) leads to a negative initial size for ByteArrayOutputStream

Hello Andrew,

I rebased the patch to monojdk8u.

The reason for the earlier occurrence of FileRolloverOutputStream is that there is some new code above in 11u. Particularly in 11u EntryOutputStream is being broken apart for the cases of deflating and RAW streaming with introduction of new DeflatingEntryOutputStream class.

The Map objects were fixed to be unmodifiable, accidental delta was eliminated.

The changes are available at

http://cr.openjdk.java.net/~yan/8190753/webrev.01/

I though the changes were already successfully reviewed. Sorry for that

Thank you

Regards,
Alex

-----Original Message-----
From: Andrew Hughes <gnu.andrew at redhat.com> 
Sent: Tuesday, December 14, 2021 6:21 AM
To: Alexey Pavlyutkin <apavlyutkin at azul.com>
Cc: Severin Gehwolf <sgehwolf at redhat.com>; jdk8u-dev at openjdk.java.net
Subject: Re: [8u] RFR 8190753: (zipfs): Accessing a large entry (> 2^31 bytes) leads to a negative initial size for ByteArrayOutputStream

On 20:42 Mon 13 Dec     , Alexey Pavlyutkin wrote:
> Hi Severin!
> 
> I have no idea. I did not do that advisedly. Probably I did them occasionally configuring jcheck tool. Anyway as I understand the changes are to be rebased to monorepo. Should I fix it before rebasing?
>

Please do.

There are some other issues with the patch:

* The placement of FileRolloverOutputStream seems to occur earlier in
  the 8u patch than in the 11u one. Can you confirm it ends up in the
  same or similar place in the file?

* Map.of creates unmodifiable Map instances. The replacement with emptyMap is fine, but the others need to be made unmodifiable. See the examples in jdk/test/sun/security/krb5/auto/KDC.java which was also converted from Map.of usage.

Please don't flag issues for approval with jdk8u-fix-request until they have been satisfactorily reviewed on the list.

> Thanks,
> Alex

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 hedongbo at huawei.com  Mon Jan 24 07:55:11 2022
From: hedongbo at huawei.com (hedongbo)
Date: Mon, 24 Jan 2022 07:55:11 +0000
Subject: [8u] PRF:8194154 :System property user.dir should not be changed
In-Reply-To: <17042e3e995f4c9895c41163848d2a6d@huawei.com>
References: <17042e3e995f4c9895c41163848d2a6d@huawei.com>
Message-ID: <07afb1ecf87a4ff4a79065616e9b514c@huawei.com>

Ping?

Thanks,
hedongbo

From: hedongbo
Sent: Thursday, January 13, 2022 10:29 AM
To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject: [8u] PRF:8194154 :System property user.dir should not be changed

Hi,

Please review the backport of JDK-8194154 to 8u.
Bug: https://bugs.openjdk.java.net/browse/JDK-8194154
Original commit: http://hg.openjdk.java.net/jdk/jdk/rev/847a988152b8
8u webrev: https://cr.openjdk.java.net/~dongbohe/8194154/webrev.00/

Patch doesn't apply cleanly but is trivial, because JDK-8154231[1] and JDK-8155775[2] does not exist in 8,
and some copyright year conflicts.

Testing: checked that added test fails without the patch and passes with the patch, tested with tier1.

[1] https://bugs.openjdk.java.net/browse/JDK-8154231
[2] https://bugs.openjdk.java.net/browse/JDK-8155775

Thanks,
hedongbo

From ebaron at redhat.com  Mon Jan 24 21:15:58 2022
From: ebaron at redhat.com (Elliott Baron)
Date: Mon, 24 Jan 2022 16:15:58 -0500
Subject: 8037259: xerces update: xpointer update
Message-ID: <eeb96a02-393b-268a-8322-a80558645834@redhat.com>


Hi,

I'm requesting a backport of 8037259 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 piece of context in 
ElementSchemePointer, caused by "8048021: Remove @version tag in jaxp repo".

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

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

Thanks,
Elliott


From zgu at redhat.com  Tue Jan 25 19:58:34 2022
From: zgu at redhat.com (Zhengyu Gu)
Date: Tue, 25 Jan 2022 14:58:34 -0500
Subject: [8u] RFR 8166140: C1: Possible integer overflow in
 LIRGenerator::generate_address on several platforms
Message-ID: <71e3e5e1-4966-ec19-e26e-ad6dfe88fa6e@redhat.com>

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

Bug: https://bugs.openjdk.java.net/browse/JDK-8166140
Patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/f6c1ea29110e

The patch applies mostly cleanly, except ppc does not have compiler port 
in 8u.

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

Test:
   compiler tests on Linux x86_64 and aarch64

Thanks,

-Zhengyu


From hohensee at amazon.com  Wed Jan 26 21:25:05 2022
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 26 Jan 2022 21:25:05 +0000
Subject: 8037259: xerces update: xpointer update
Message-ID: <F7ECF680-0115-4C33-9BBD-04B604242CA6@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: Monday, January 24, 2022 at 1:17 PM
To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject: 8037259: xerces update: xpointer update

Hi,

I'm requesting a backport of 8037259 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 piece of context in
ElementSchemePointer, caused by "8048021: Remove @version tag in jaxp repo".

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

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

Thanks,
Elliott



From hohensee at amazon.com  Wed Jan 26 22:20:29 2022
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 26 Jan 2022 22:20:29 +0000
Subject: [8u] RFR 8166140: C1: Possible integer overflow in
 LIRGenerator::generate_address on several platforms
Message-ID: <E8806EFB-36A0-4F42-9FCF-38794CB59890@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: Tuesday, January 25, 2022 at 11:59 AM
To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
Subject: [8u] RFR 8166140: C1: Possible integer overflow in LIRGenerator::generate_address on several platforms

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

Bug: https://bugs.openjdk.java.net/browse/JDK-8166140
Patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/f6c1ea29110e

The patch applies mostly cleanly, except ppc does not have compiler port
in 8u.

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

Test:
   compiler tests on Linux x86_64 and aarch64

Thanks,

-Zhengyu



From zgu at redhat.com  Thu Jan 27 01:08:19 2022
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 26 Jan 2022 20:08:19 -0500
Subject: [8u] RFR 8166140: C1: Possible integer overflow in
 LIRGenerator::generate_address on several platforms
In-Reply-To: <E8806EFB-36A0-4F42-9FCF-38794CB59890@amazon.com>
References: <E8806EFB-36A0-4F42-9FCF-38794CB59890@amazon.com>
Message-ID: <743a3249-b16e-60b7-a598-3aabe706ca47@redhat.com>

Thanks, Paul.

-Zhengyu

On 1/26/22 17:20, 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: Tuesday, January 25, 2022 at 11:59 AM
> To: jdk8u-dev <jdk8u-dev at openjdk.java.net>
> Subject: [8u] RFR 8166140: C1: Possible integer overflow in LIRGenerator::generate_address on several platforms
> 
> I would like to backport this patch to 8u for parity with Oracle 8u331.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8166140
> Patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/f6c1ea29110e
> 
> The patch applies mostly cleanly, except ppc does not have compiler port
> in 8u.
> 
> 8u webrev: http://cr.openjdk.java.net/~zgu/JDK-8166140-8u/webrev.00/
> 
> Test:
>     compiler tests on Linux x86_64 and aarch64
> 
> Thanks,
> 
> -Zhengyu
> 
> 


From sudipm.mukherjee at gmail.com  Fri Jan 28 15:04:18 2022
From: sudipm.mukherjee at gmail.com (Sudip Mukherjee)
Date: Fri, 28 Jan 2022 15:04:18 +0000
Subject: 8u322 Release Update
In-Reply-To: <YeeWqG6avIyGibau@hex.discworld.ac.uk>
References: <YeeWqG6avIyGibau@hex.discworld.ac.uk>
Message-ID: <YfQF8iekdZ7PySJ1@debian>

Hi Andrew,

Not sure if you received my earlier mail, it did not appear on the
list. So, trying again.

On Wed, Jan 19, 2022 at 04:42:16AM +0000, Andrew Hughes wrote:
> I have pushed the security fixes for 8u to the monojdk8u repository.
> These have all been backported and reviewed within the vulnerability
> group.

Thanks a lot. We had been waiting for few of the fixes.

> 
> I have not yet added the jdk8u322-ga tag. I will do this, and make a
> release announcement + tarball, once the update has successfully
> completed our testing.

Any idea when this can be expected?

--
Regards
Sudip

From gnu.andrew at redhat.com  Mon Jan 31 01:06:35 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Mon, 31 Jan 2022 01:06:35 +0000
Subject: OpenJDK 8u322 Released
Message-ID: <Yfc2G1rGTYwN5/Fg@hex.discworld.ac.uk>

We are pleased to announce the release of OpenJDK 8u322.

The source tarball is available from:

* https://openjdk-sources.osci.io/openjdk8/openjdk8u322-ga.tar.xz

The tarball is accompanied by a digital signature available at:

* https://openjdk-sources.osci.io/openjdk8/openjdk8u322-ga.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 = CA5F 11C6 CE22 644D 42C6  AC44 92EF 8D39 DC13 168F

SHA256 checksums:

e1ce7fc5def4446ca62df355f70548b2deb53fdcad548b0b3550ceaa96395247  openjdk8u322-ga.tar.xz
1f8cc08c2c03d68c865409bd9c4f07c4121a7f179dfd6d081fd2938f0246f56e  openjdk8u322-ga.tar.xz.sig

The checksums can be downloaded from:

* https://openjdk-sources.osci.io/openjdk8/openjdk8u322-ga.sha256

New in release OpenJDK 8u322 (2022-01-30):
===========================================
Live versions of these release notes can be found at:
  * https://bitly.com/openjdk8u322
  * https://builds.shipilev.net/backports-monitor/release-notes-openjdk8u322.txt

* Security fixes
  - JDK-8264934, CVE-2022-21248: Enhance cross VM serialization
  - JDK-8268488: More valuable DerValues
  - JDK-8268494: Better inlining of inlined interfaces
  - JDK-8268512: More content for ContentInfo
  - JDK-8268795: Enhance digests of Jar files
  - JDK-8268801: Improve PKCS attribute handling
  - JDK-8268813, CVE-2022-21283: Better String matching
  - JDK-8269151: Better construction of EncryptedPrivateKeyInfo
  - JDK-8269944: Better HTTP transport redux
  - JDK-8270392, CVE-2022-21293: Improve String constructions
  - JDK-8270416, CVE-2022-21294: Enhance construction of Identity maps
  - JDK-8270492, CVE-2022-21282: Better resolution of URIs
  - JDK-8270498, CVE-2022-21296: Improve SAX Parser configuration management
  - JDK-8270646, CVE-2022-21299: Improved scanning of XML entities
  - JDK-8271962: Better TrueType font loading
  - JDK-8271968: Better canonical naming
  - JDK-8271987: Manifest improved manifest entries
  - JDK-8272014, CVE-2022-21305: Better array indexing
  - JDK-8272026, CVE-2022-21340: Verify Jar Verification
  - JDK-8272236, CVE-2022-21341: Improve serial forms for transport
  - JDK-8272272: Enhance jcmd communication
  - JDK-8272462: Enhance image handling
  - JDK-8273290: Enhance sound handling
  - JDK-8273748, CVE-2022-21349: Improve Solaris font rendering
  - JDK-8273756, CVE-2022-21360: Enhance BMP image support
  - JDK-8273838, CVE-2022-21365: Enhanced BMP processing
* Other changes
  - JDK-6801613: Cross-platform pageDialog and printDialog top margin entry broken
  - 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-8048021: Remove @version tag in jaxp repo
  - JDK-8049348: compiler/intrinsics/bmi/verifycode tests on lzcnt and tzcnt use incorrect assumption about REXB prefix usage
  - JDK-8060027: Tests java/beans/XMLEncoder/Test4903007.java and java/beans/XMLEncoder/java_awt_GridBagLayout.java
  - JDK-8066588: javax/management/remote/mandatory/connection/RMIConnector_NPETest.java fails to compile
  - JDK-8066652: Default TimeZone is GMT not local if user.timezone is invalid on Mac OS
  - 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-8140329: [TEST_BUG] test FullScreenAfterSplash.java failed because image was not generated
  - JDK-8140472: java/net/ipv6tests/TcpTest.java failed intermittently with java.net.BindException: Address already in use: NET_Bind
  - JDK-8147051: StaxEntityResolverWrapper should create StaxXMLInputSource with a resolver indicator
  - JDK-8148915: Intermittent failures of bug6400879.java
  - 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-8190482: InnocuousThread creation should not require the caller to possess enableContextClassLoaderOverride
  - JDK-8190793: Httpserver does not detect truncated request body
  - JDK-8196572: Tests ColConvCCMTest.java and MTColConvTest.java fail
  - JDK-8202788: Explicitly reclaim cached thread-local direct buffers at thread exit
  - JDK-8210058: Algorithmic Italic font leans opposite angle in Printing
  - JDK-8220150: macos10.14 Mojave returns anti-aliased glyphs instead of aliased B&W glyphs
  - 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-8231254: (fs) Add test for macOS Catalina changes to protect system software
  - JDK-8231438: [macOS] Dark mode for the desktop is not supported
  - JDK-8232178: MacVolumesTest failed after upgrade to MacOS Catalina
  - JDK-8232226: [macos 10.15] test/jdk/java/awt/color/EqualityTest/EqualityTest.java may fail
  - JDK-8235153: [TESTBUG] [macos 10.15] java/awt/Graphics/DrawImageBG/SystemBgColorTest.java fails
  - JDK-8236897: Fix the copyright header for pkcs11gcm2.h
  - 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-8273308: PatternMatchTest.java fails on CI
  - JDK-8273342: Null pointer dereference in classFileParser.cpp:2817
  - JDK-8273826: Correct Manifest file name and NPE checks
  - JDK-8273968: JCK javax_xml tests fail in CI
  - JDK-8274407: (tz) Update Timezone Data to 2021c
  - JDK-8274467: TestZoneInfo310.java fails with tzdata2021b
  - JDK-8274468: TimeZoneTest.java fails with tzdata2021b
  - JDK-8274595: DisableRMIOverHTTPTest failed: connection refused
  - JDK-8274779: HttpURLConnection: HttpClient and HttpsClient incorrectly check request method when set to POST
  - JDK-8275766: (tz) Update Timezone Data to 2021e
  - JDK-8275849: TestZoneInfo310.java fails with tzdata2021e
  - JDK-8276536: Update TimeZoneNames files to follow the changes made by JDK-8275766

Notes on individual issues:
===========================

security-libs/java.security:

JDK-8271434: Removed IdenTrust Root Certificate
===============================================
The following root certificate from IdenTrust has been removed from
the `cacerts` keystore:

Alias Name: identrustdstx3 [jdk]
Distinguished Name: CN=DST Root CA X3, O=Digital Signature Trust Co.

JDK-8272535: Removed Google's GlobalSign Root Certificate
=========================================================
The following root certificate from Google has been removed from the
`cacerts` keystore:

Alias Name: globalsignr2ca [jdk]
Distinguished Name: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2

core-libs/java.time:

JDK-8274857:  Update Timezone Data to 2021c
===========================================
IANA Time Zone Database, on which JDK's Date/Time libraries are based,
has been updated to version 2021c
(https://mm.icann.org/pipermail/tz-announce/2021-October/000067.html). Note
that with this update, some of the time zone rules prior to the year
1970 have been modified according to the changes which were introduced
with 2021b. For more detail, refer to the announcement of 2021b
(https://mm.icann.org/pipermail/tz-announce/2021-September/000066.html)

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 t.glaser at tarent.de  Mon Jan 31 15:02:23 2022
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Mon, 31 Jan 2022 16:02:23 +0100 (CET)
Subject: OpenJDK 8u322 Released
In-Reply-To: <Yfc2G1rGTYwN5/Fg@hex.discworld.ac.uk>
References: <Yfc2G1rGTYwN5/Fg@hex.discworld.ac.uk>
Message-ID: <35ec318a-b1fd-67fb-dfd7-ca54f71fc3f@tarent.de>

Hi,

> We are pleased to announce the release of OpenJDK 8u322.
> 
> The source tarball is available from:

did you see my question regarding making the release, and subsequent
ones, available in the split format previous releases used to have?

> The tarball is accompanied by a digital signature available at:
> 
> * https://openjdk-sources.osci.io/openjdk8/openjdk8u322-ga.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 = CA5F 11C6 CE22 644D 42C6  AC44 92EF 8D39 DC13 168F

Would be nice to have a trust path to that (that doesn?t involve
expired/revoked/1024-bit keys)? currently it looks like this:

92EF8D39DC13168F OpenJDK Team ? A5CD6035332FA671 Andrew Haley (rsa2048 2009-05-18)

A5CD6035332FA671 ? 672F2227C2C07028 Andrew Haley (dsa1024 2003-05-15 revoked)
A5CD6035332FA671 ? 33C16EF5E22673CF Andrew Gross (rsa4096 2018-01-18)
A5CD6035332FA671 ? FBB7576BA7CB0B6B David Howells (rsa4096 2011-10-05)
A5CD6035332FA671 ? F286F14F66484681 Omair Majid (rsa4096 2012-01-18 expired 2017)
A5CD6035332FA671 ? 69DA36AE31C5C4B3 Andrew Dinn (rsa2048 2010-07-20)

33C16EF5E22673CF is not signed by anyone else.
FBB7576BA7CB0B6B is not signed by anyone else.
69DA36AE31C5C4B3 is not signed by anyone else.

F286F14F66484681 (expired) was signed
 by 3B96A578248BDC07 (Andrew Hughes) (rsa4096 2011-09-28 expired 2012)

This is rather sad?

bye,
//mirabilos (Debian Developer)
-- 
Infrastrukturexperte ? tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/
Telephon +49 228 54881-393 ? Fax: +49 228 54881-235
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/?\ The UTF-8 Ribbon
??? Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
??? HTML eMail! Also,     https://www.tarent.de/newsletter
??? header encryption!
                        ****************************************************

From sgehwolf at redhat.com  Mon Jan 31 15:45:46 2022
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 31 Jan 2022 16:45:46 +0100
Subject: jdk8u322 release and packaging
In-Reply-To: <df7b8b73-9399-a796-c06b-325f74c75048@tarent.de>
References: <df7b8b73-9399-a796-c06b-325f74c75048@tarent.de>
Message-ID: <1d4018db87332ee2a4d1966931aa368139b39443.camel@redhat.com>

Hi,

On Sat, 2022-01-22 at 22:07 +0100, Thorsten Glaser wrote:
> Hi,
> 
> I?m currently packaging openjdk-8 for Debian (unstable, where
> it is tested for LTS/ELTS updating older releases). I have
> taken it over from the previous maintainer, but I am ?mostly?
> keeping this alive.
> 
> I see that the 8u322 release (which I had put into my calendar
> https://wiki.openjdk.java.net/display/jdk8u/Main#Main-Timelines
> from ?) seems to be delayed because of repository changes.
> 
> These repository changes are a problem. The packaging depends
> heavily on being able to download the individual hg releases?
> tarballs, plus aarch32 and aarch64-shenandoah, separately and
> put them together in suitable ways depending on the architecture
> building for.
> 
> As I said above, I?ve taken this over because nobody else was
> doing it so I?m not heavily invested in this packaging. I?m
> trying to not change too much.
> 
> Is there any way (which will stay stable, even when you?re going
> to move repositories *again*, to git) to split the download into
> what the old repositories have been, so I can still get my tarballs
> in the way the current packaging requires?

The currently actively maintained tree is the jdk8u-monorepo[1] tree.
There is a *live* git mirror of it here:
https://github.com/openjdk/jdk8u

For packaging purposes the git mirror can be used. It'll stay. Once we
switch from HG to git the mirror becomes the main tree and the HG repo
gets switched to read-only mode.

I believe the same is true for aarch32[2] and shenandoah trees[3].

HTH,
Severin

[1] https://hg.openjdk.java.net/jdk8u/monojdk8u
[2] https://github.com/openjdk/aarch32-port-jdk8u
[3] https://bugs.openjdk.java.net/browse/SKARA-1290
    i.e. https://github.com/openjdk/shenandoah-jdk8u


> Otherwise I?d have to change things a lot, which will be tricky
> *and* time-consuming (and I?d have to ask $employer for more time
> than I can currently use for this).
> 
> I?d prefer best if you would just push the new releases also to
> the old repositories and tag them appropriately. But I understand
> chances for this going to happen are small as you seem to be very
> interested in this new-fangled git thingy :/
> 
> Thanks in advance,
> //mirabilos


From t.glaser at tarent.de  Mon Jan 31 15:52:27 2022
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Mon, 31 Jan 2022 16:52:27 +0100 (CET)
Subject: jdk8u322 release and packaging
In-Reply-To: <1d4018db87332ee2a4d1966931aa368139b39443.camel@redhat.com>
References: <df7b8b73-9399-a796-c06b-325f74c75048@tarent.de>
 <1d4018db87332ee2a4d1966931aa368139b39443.camel@redhat.com>
Message-ID: <97cd9637-3c67-d530-df5a-b6127b47486d@tarent.de>

On Mon, 31 Jan 2022, Severin Gehwolf wrote:

> The currently actively maintained tree is the jdk8u-monorepo[1] tree.

OK, this is a problem.

How does that repository map back to the old multi-repo structure?

bye,
//mirabilos
-- 
Infrastrukturexperte ? tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/
Telephon +49 228 54881-393 ? Fax: +49 228 54881-235
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/?\ The UTF-8 Ribbon
??? Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
??? HTML eMail! Also,     https://www.tarent.de/newsletter
??? header encryption!
                        ****************************************************

From sgehwolf at redhat.com  Mon Jan 31 16:11:14 2022
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 31 Jan 2022 17:11:14 +0100
Subject: jdk8u322 release and packaging
In-Reply-To: <97cd9637-3c67-d530-df5a-b6127b47486d@tarent.de>
References: <df7b8b73-9399-a796-c06b-325f74c75048@tarent.de>
 <1d4018db87332ee2a4d1966931aa368139b39443.camel@redhat.com>
 <97cd9637-3c67-d530-df5a-b6127b47486d@tarent.de>
Message-ID: <3792ad6cc7c51106695fcd5f9a68af09ef10d431.camel@redhat.com>

On Mon, 2022-01-31 at 16:52 +0100, Thorsten Glaser wrote:
> On Mon, 31 Jan 2022, Severin Gehwolf wrote:
> 
> > The currently actively maintained tree is the jdk8u-monorepo[1] tree.
> 
> OK, this is a problem.
> 
> How does that repository map back to the old multi-repo structure?

The files itself are the same. The difference is that is a single clone
vs. a clone from 8 different repos ("top", jdk, hotspot, jaxp, jaxws,
hotspot, corba, nashorn) into the right folder names.

The source repo history is different as the forest needed to be
consolidated. I don't know how exaclty that was done.

If you are working from sources you get a single source tarball now vs.
from 8 previously. It should make life easier for you. YMMV.

Thanks,
Severin


From t.glaser at tarent.de  Mon Jan 31 16:17:19 2022
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Mon, 31 Jan 2022 17:17:19 +0100 (CET)
Subject: jdk8u322 release and packaging
In-Reply-To: <3792ad6cc7c51106695fcd5f9a68af09ef10d431.camel@redhat.com>
References: <df7b8b73-9399-a796-c06b-325f74c75048@tarent.de>
 <1d4018db87332ee2a4d1966931aa368139b39443.camel@redhat.com>
 <97cd9637-3c67-d530-df5a-b6127b47486d@tarent.de>
 <3792ad6cc7c51106695fcd5f9a68af09ef10d431.camel@redhat.com>
Message-ID: <fea5fd32-7b94-ff11-cb3b-78a06c57fa22@tarent.de>

On Mon, 31 Jan 2022, Severin Gehwolf wrote:

> The source repo history is different as the forest needed to be
> consolidated. I don't know how exaclty that was done.

This sounds like there?s no way to map the new structure back to
the old structure? It?s not ?just? subdirectories as you wrote in
the paragraph above that?

> If you are working from sources you get a single source tarball now vs.
> from 8 previously. It should make life easier for you. YMMV.

No, it makes it MASSIVELY harder. First I need to completely rework
packaging for something totally legacy that was designed by someone
else years ago for quite more functionality than is currently used.
Then, I need to swap in aarch32 and aarch64-shenandoah, and at least
the former seems to also only publish a monorepo now, but if they are
ever going to change more than hotspot things will explode, and this
means I will also need to check *that*.

It would really be so much better if you?d made the conversion in a
reversible way and continue to push that to the old repositories. No
professional stable software does changes that profound to something
declared stable normally. And maintainers not even knowing how the
merge was exactly done (file-wise) makes me worry even more. We have
promises of stability in Debian? apparently, not in others?

bye,
//mirabilos
-- 
Infrastrukturexperte ? tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/
Telephon +49 228 54881-393 ? Fax: +49 228 54881-235
HRB AG Bonn 5168 ? USt-ID (VAT): DE122264941
Gesch?ftsf?hrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/?\ The UTF-8 Ribbon
??? Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
??? HTML eMail! Also,     https://www.tarent.de/newsletter
??? header encryption!
                        ****************************************************

From akashche at redhat.com  Mon Jan 31 17:09:51 2022
From: akashche at redhat.com (Alex Kashchenko)
Date: Mon, 31 Jan 2022 17:09:51 +0000
Subject: [8u] RFR: 8280963: Incorrect PrintFlags formatting on Windows
Message-ID: <CABUxsJ3ZQSe-RHFzCPUCOqx4jd3dAEh0=de9wNe_9NFUHxSKdg@mail.gmail.com>

Hi,

Please review a fix to 8u-only Windows-specific problem with
-XX:+PrintFlags* output:

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

Webrev: https://cr.openjdk.java.net/~akasko/jdk8u/8280963/webrev.01/

Problem description on Stack Overflow by Andrei Pangin:
https://stackoverflow.com/a/63309395

The problem was fixed in jdk9 as part of JDK-8042893 [1], but this
jdk9 change [2] doesn't look like a good candidate for the 8u backport
according to 8u Best Practices [3]. Still the problem manifests itself
as a customer-visible bug on Windows because people do use
-XX:+PrintFlagsFinal to find out the actual flags picked up by JVM and
can be confused by unexpected zeros in the output. Proposed patch
cherry-picks the minimal change from JDK-8042893 commit [4].

Testing:

 - regression test is included with the proposed patch
 - checked that it builds on Windows 64-bit and 32-bit on VS2017 and VS2010
 - ran jtreg:hotspot/test/runtime on Windows and Linux


[1] https://bugs.openjdk.java.net/browse/JDK-8042893
[2] https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/115188e14c15
[3] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/012002.html
[4] https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/115188e14c15#l53.1


-- 
-Alex