From andrew at openjdk.java.net  Tue Apr  5 21:20:46 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Tue, 5 Apr 2022 21:20:46 GMT
Subject: [jdk8u-dev] RFR: 8253424: Add support for running pre-submit
 testing using GitHub Actions [v20]
In-Reply-To: <RFQCgfdatdzSDQBqj_aaxTD1GgaFfXOR6pwwqqqcb-U=.47e7945d-48f3-42f8-a869-886682ff367f@github.com>
References: <n-1Y9ApII-VpZgDwqk5EezTW1BKJUiK819AX2Bo7ADw=.6e17a648-5d65-4f83-ba83-27a3b55d8311@github.com>
 <V3UhDAhapybVwoPZi9VAaQIadsrEvFujw2chAXeKjMc=.0ebfa844-b878-4b75-b6e5-bbacf7f58c17@github.com>
 <ACHIqF7JUha3oe8iZ0mwMacOu-HnXkq_Y8tf7IsAiEE=.b890f086-c969-401b-b386-487e5115abb2@github.com>
 <RFQCgfdatdzSDQBqj_aaxTD1GgaFfXOR6pwwqqqcb-U=.47e7945d-48f3-42f8-a869-886682ff367f@github.com>
Message-ID: <Va7H-bB61LP2LuCjD4N_-OmWJrUCyEhubMuZzA9pL-U=.39213701-ad65-4f82-9b6f-8141e111f528@github.com>

On Mon, 4 Apr 2022 15:08:26 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> > > This seems good enough for an initial integration. Better to have some (build) tests prior integration than nothing :)
> > > One question: Do we really need file `.github/workflows/freetype.vcxproj`? If not, please remove.
> > 
> > 
> > It was provided by Alex for the Windows build: [#3 (comment)](https://github.com/openjdk/jdk8u-dev/pull/3#issuecomment-1066169712)
> 
> OK. No expert on this either, so fine with me going in either way :-) It's certainly better than what we have currently.

Thanks. I've flagged the main bug for 8u approval now (I presume we can infer the others from that one).

> > > > This seems good enough for an initial integration. Better to have some (build) tests prior integration than nothing :)
> > > > One question: Do we really need file `.github/workflows/freetype.vcxproj`? If not, please remove.
> > > 
> > > 
> > > It was provided by Alex for the Windows build: [#3 (comment)](https://github.com/openjdk/jdk8u-dev/pull/3#issuecomment-1066169712)
> > 
> > 
> > OK. No expert on this either, so fine with me going in either way :-) It's certainly better than what we have currently.
> 
> This `freetype.vcxproj` file is used to replace the default FreeType build file. It has modifications to be buildable with VS2017. It is necessary for `--with-freetype-src` to work, with this flag FreeType is being built with msbuild (that used this build file) at configure time. We can avoid it by building FreeType by some other means (before running configure) and using `--with-freetype-lib` and `--with-freetype-include` instead. Just this `--with-freetype-src` seems to be "the most vanilla" way to build FreeType for 8u, so I suggest to continue using it.

Thanks for the explanation. That does make things a lot clearer for me.

A couple of questions: 

1. Does this mean the file is not needed for the VS2010 build? I duplicated your changes in that build and it seems to work at present.
2. Any idea why 11u (which this is backported from) works without this? Does it build FreeType in a different way?

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/3

From akasko at openjdk.java.net  Tue Apr  5 21:54:50 2022
From: akasko at openjdk.java.net (Alex Kasko)
Date: Tue, 5 Apr 2022 21:54:50 GMT
Subject: [jdk8u-dev] RFR: 8253424: Add support for running pre-submit
 testing using GitHub Actions [v20]
In-Reply-To: <Va7H-bB61LP2LuCjD4N_-OmWJrUCyEhubMuZzA9pL-U=.39213701-ad65-4f82-9b6f-8141e111f528@github.com>
References: <n-1Y9ApII-VpZgDwqk5EezTW1BKJUiK819AX2Bo7ADw=.6e17a648-5d65-4f83-ba83-27a3b55d8311@github.com>
 <V3UhDAhapybVwoPZi9VAaQIadsrEvFujw2chAXeKjMc=.0ebfa844-b878-4b75-b6e5-bbacf7f58c17@github.com>
 <ACHIqF7JUha3oe8iZ0mwMacOu-HnXkq_Y8tf7IsAiEE=.b890f086-c969-401b-b386-487e5115abb2@github.com>
 <RFQCgfdatdzSDQBqj_aaxTD1GgaFfXOR6pwwqqqcb-U=.47e7945d-48f3-42f8-a869-886682ff367f@github.com>
 <Va7H-bB61LP2LuCjD4N_-OmWJrUCyEhubMuZzA9pL-U=.39213701-ad65-4f82-9b6f-8141e111f528@github.com>
Message-ID: <hL7SVA0XdXjX-qlLfJABOU9EN7zqpGotELvkaBS_R4M=.dd0bafae-4c38-4378-89fd-dfe09365a22b@github.com>

On Tue, 5 Apr 2022 21:17:14 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> A couple of questions:
> 
> 1. Does this mean the file is not needed for the VS2010 build? I duplicated your changes in that build and it seems to work at present.

Yes, I believe it is not needed for VS2010. I haven't tried it with 32-bit VS2010 myself, but IIRC it worked out of the box with 64-bit VS2013 (freeware version of VS2010 doesn't support 64-bit, setup is possible with WinSDK7.1 toolchain, but it is complicated). Modified file was intended to change only 64-bit config (to make it working with 64-bit VS2017) so 32-bit config remained the same there. Thus `Copy FreeType project file` step on 32-bit most probably can be removed. 

> 
>  2. Any idea why 11u (which this is backported from) works without this? Does it build FreeType in a different way?

Yes, in 8u FreeType is not included in-tree, it was always used as an external dependency and for "open" jdk only (Oracle JDK didn't use it). `--with-freetype-src` flag is relatively recent, it was added in [JDK-8057538](https://bugs.openjdk.java.net/browse/JDK-8057538). In 11u FreeType is [included in-tree](https://github.com/openjdk/jdk11u/tree/master/src/java.desktop/share/native/libfreetype) and is built the same way as other in-tree dep libs.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/3

From xliu at openjdk.java.net  Wed Apr  6 00:04:20 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Wed, 6 Apr 2022 00:04:20 GMT
Subject: [jdk8u-dev] RFR: 8235211:
 serviceability/attach/RemovingUnixDomainSocketTest.java fails with
 AttachNotSupportedException: Unable to open socket file [v3]
In-Reply-To: <hK4acmjE3fCMdejaICnkW6V5GS-36zcUx_cD8EzjfKI=.996f8254-7e4e-47c1-95ce-4d798e06f51f@github.com>
References: <hK4acmjE3fCMdejaICnkW6V5GS-36zcUx_cD8EzjfKI=.996f8254-7e4e-47c1-95ce-4d798e06f51f@github.com>
Message-ID: <28wtpv5RkiKCJQflaaNnUJlrnciqqvE6hLqYb2R-i8s=.c2a620b8-4407-4a2b-8934-2fa211b0b775@github.com>

> Hi, 
> 
> Could you review this backport of 8235211? This is a follow up of JDK-8225690.
> 
> 
> This patch can't be applied to jdk8u cleanly. We replace os::naked_yield with os::yield(), which is available in jdk8u and have same implementations on Linux/BSD/AIX.  Except for that, all other changes are just path adjustment. 
> 
> There's a deadlock in the original backport. Both Signal dispatcher(refer to S for short) and AttachListener(A) are Java Threads.  Therefore, they are subject to safepoint synchronization.
> 
> A sets `_state` to AL_INITIALIZED and then get blocked at a safepoint(maybe AttachListener::dequeue).
> If the socket file is deleted and JVM receive SIGQUIT the, S realizes that the socket file has gone in `check_socket_file` and start to reinitialize it. It falls into this loop and prevent itself from reaching the safepoint.
> 
>      while (AttachListener::transit_state(AL_INITIALIZING,
>                                            AL_NOT_INITIALIZED) != AL_NOT_INITIALIZED) {
>         os::naked_yield();
>       }
> 
> 
> If A waked up and realized that the socket has gone,  it would set `_state` to AL_NOT_INITIALIZED. Current code is adeadlock.  A can?t wake up because S hasn?t reached the safepoint yet. S can?t reach the safepoint because A hasn?t set _state to AL_NOT_INITIALIZED.  This patch avoids the deadlock by trapping into blocked state before the loop.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  fix typo when we manually edited the two test files.
  
  Currently, RemovingUnixDomainSocketTest.java isn't running because @test
  is taken away when we backport JDK-8225690. we try to keep the patch
  intact in case we enable it in the future.

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

Changes:
  - all: https://git.openjdk.java.net/jdk8u-dev/pull/32/files
  - new: https://git.openjdk.java.net/jdk8u-dev/pull/32/files/c9df0828..6f86e099

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

  Stats: 3 lines in 2 files changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/32.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/32/head:pull/32

PR: https://git.openjdk.java.net/jdk8u-dev/pull/32

From yyang at openjdk.java.net  Wed Apr  6 06:59:41 2022
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 6 Apr 2022 06:59:41 GMT
Subject: [jdk8u-dev] RFR: 8072422: Cleanup: Remove some unused flags/code
 in loop optimizations [v2]
In-Reply-To: <RntTetXtMEVRpvzLXan_f0j1OPL6k0uWY5sc0TF4Tc4=.1ac3efb4-26f2-448d-be5f-428449f5d4f0@github.com>
References: <aczlc1O_a-Lly8RApyOmj9Fm1Zj-VqcR2V_WPVQEgE0=.ea52bc36-bdd4-48e6-bcbc-31e9f88dab8b@github.com>
 <e0pijhWJI0doTEDW6DiYk16R3a_Lpvyv-SAPXxjie9Q=.eb6edbc0-a170-42a2-ab95-b881d0e66a9a@github.com>
 <RntTetXtMEVRpvzLXan_f0j1OPL6k0uWY5sc0TF4Tc4=.1ac3efb4-26f2-448d-be5f-428449f5d4f0@github.com>
Message-ID: <Q-uvylruqcRqmOcOeDUVWu_ea8lNIWkMkxcny1a-fWo=.fa490a54-eee7-492b-b271-c96f10f3eed8@github.com>

On Fri, 25 Mar 2022 10:27:51 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> > We do need the cleanup patch, because [alibaba/dragonwell8#305](https://github.com/alibaba/dragonwell8/issues/305) reports a crash due to use of UnrollLoopLimit, this flag is not supposed to be used by end users, it could be removed by cleanup patch. As I understand, the cleanup patch introduces another problem that can be fixed by JDK-8159715, so once cleanup backport is merged, I will backport JDK-8159715 as well.
> 
> So we have a work-around: Don't use `-XX:+UnlockDiagnosticVMOptions -XX:-UnrollLimitCheck`. We shouldn't take backporting non-critical fixes to JDK 8u lightly. This very much sounds like a `jdk8u-fix-no` candidate to me. Are you aware of this? https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/012002.html

Okay, I've read this guideline, it seems that the upstream mainline is not less willing to accept non-critical backports, I'm considering doing a backport in downstream.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/22

From yyang at openjdk.java.net  Wed Apr  6 06:59:41 2022
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 6 Apr 2022 06:59:41 GMT
Subject: [jdk8u-dev] Withdrawn: 8072422: Cleanup: Remove some unused flags/code
 in loop optimizations
In-Reply-To: <aczlc1O_a-Lly8RApyOmj9Fm1Zj-VqcR2V_WPVQEgE0=.ea52bc36-bdd4-48e6-bcbc-31e9f88dab8b@github.com>
References: <aczlc1O_a-Lly8RApyOmj9Fm1Zj-VqcR2V_WPVQEgE0=.ea52bc36-bdd4-48e6-bcbc-31e9f88dab8b@github.com>
Message-ID: <4UEPHDxQ3_qh4Oa-HlDNbaY2TLyrFI9RNRdVYPJHofA=.7357f14f-0364-4fe5-9d77-54f8a984c766@github.com>

On Fri, 25 Mar 2022 07:05:23 GMT, Yi Yang <yyang at openjdk.org> wrote:

> We encountered this problem in downstream JDK. This is a backport of JDK-8283672, which simply removes several diagnostic flags, build passed. There is a related fix https://bugs.openjdk.java.net/browse/JDK-8159715, I would backport it after the current fix merged.
> 
> Original changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a1e41855499b
> 
> Please help review it.
> 
> Thanks.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/22

From dongbohe at openjdk.java.net  Wed Apr  6 09:30:46 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Wed, 6 Apr 2022 09:30:46 GMT
Subject: [jdk8u-dev] RFR: 8281814: Debuginfo.diz contains redundant build
 path after backport JDK-8025936
In-Reply-To: <aHbBg4hcSAzhifdPCdsEoeHhIwB9nqJpFyO8EKA38G8=.688df3c7-306f-4eaf-9d61-e98ff54c9475@github.com>
References: <aHbBg4hcSAzhifdPCdsEoeHhIwB9nqJpFyO8EKA38G8=.688df3c7-306f-4eaf-9d61-e98ff54c9475@github.com>
Message-ID: <Vc7GVo_9SEaweEKgOAr_6_rd1G7U48raWY6oql7qSdo=.e101e95f-3d8b-419e-a476-2a71bab82d84@github.com>

On Wed, 30 Mar 2022 07:45:08 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

> Hi,
> 
> I would like to backport 8035134 to fix debuginfo regression, introduced by [JDK-8025936](https://bugs.openjdk.java.net/browse/JDK-8025936).
> As discussed on [JDK-8281814](https://bugs.openjdk.java.net/browse/JDK-8281814), we cannot see the details of the original patch.
> It is only a different context, no risk.
> 
> Testing: worked correctly after patch.

Got the push approval.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/26

From dongbohe at openjdk.java.net  Wed Apr  6 12:19:48 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Wed, 6 Apr 2022 12:19:48 GMT
Subject: [jdk8u-dev] Integrated: 8281814: Debuginfo.diz contains redundant
 build path after backport JDK-8025936
In-Reply-To: <aHbBg4hcSAzhifdPCdsEoeHhIwB9nqJpFyO8EKA38G8=.688df3c7-306f-4eaf-9d61-e98ff54c9475@github.com>
References: <aHbBg4hcSAzhifdPCdsEoeHhIwB9nqJpFyO8EKA38G8=.688df3c7-306f-4eaf-9d61-e98ff54c9475@github.com>
Message-ID: <Ubcr6jp6CnMQWTrSKVtd_TQ0ygfSuhQOWAMY1RyZ510=.cf27331b-6a76-4a80-b8dd-f7d225ad8f53@github.com>

On Wed, 30 Mar 2022 07:45:08 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

> Hi,
> 
> I would like to backport 8035134 to fix debuginfo regression, introduced by [JDK-8025936](https://bugs.openjdk.java.net/browse/JDK-8025936).
> As discussed on [JDK-8281814](https://bugs.openjdk.java.net/browse/JDK-8281814), we cannot see the details of the original patch.
> It is only a different context, no risk.
> 
> Testing: worked correctly after patch.

This pull request has now been integrated.

Changeset: 62bbb3e6
Author:    Dongbo He <dongbohe at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-dev/commit/62bbb3e6415d02173eaf443713f8ca3540c0126a
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8281814: Debuginfo.diz contains redundant build path after backport JDK-8025936

8u backport of JDK-8035134

Reviewed-by: sgehwolf

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/26

From phh at openjdk.java.net  Wed Apr  6 15:36:48 2022
From: phh at openjdk.java.net (Paul Hohensee)
Date: Wed, 6 Apr 2022 15:36:48 GMT
Subject: [jdk8u-dev] RFR: 8235211:
 serviceability/attach/RemovingUnixDomainSocketTest.java fails with
 AttachNotSupportedException: Unable to open socket file [v3]
In-Reply-To: <28wtpv5RkiKCJQflaaNnUJlrnciqqvE6hLqYb2R-i8s=.c2a620b8-4407-4a2b-8934-2fa211b0b775@github.com>
References: <hK4acmjE3fCMdejaICnkW6V5GS-36zcUx_cD8EzjfKI=.996f8254-7e4e-47c1-95ce-4d798e06f51f@github.com>
 <28wtpv5RkiKCJQflaaNnUJlrnciqqvE6hLqYb2R-i8s=.c2a620b8-4407-4a2b-8934-2fa211b0b775@github.com>
Message-ID: <mlI6994s6vGJ0vemaloU-fDyQdWsxymFUPHLREeJmKQ=.5185a13f-0fc6-47ec-ae3c-862dd1cf742b@github.com>

On Wed, 6 Apr 2022 00:04:20 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> Hi, 
>> 
>> Could you review this backport of 8235211? This is a follow up of JDK-8225690.
>> 
>> 
>> This patch can't be applied to jdk8u cleanly. We replace os::naked_yield with os::yield(), which is available in jdk8u and have same implementations on Linux/BSD/AIX.  Except for that, all other changes are just path adjustment. 
>> 
>> There's a deadlock in the original backport. Both Signal dispatcher(refer to S for short) and AttachListener(A) are Java Threads.  Therefore, they are subject to safepoint synchronization.
>> 
>> A sets `_state` to AL_INITIALIZED and then get blocked at a safepoint(maybe AttachListener::dequeue).
>> If the socket file is deleted and JVM receive SIGQUIT the, S realizes that the socket file has gone in `check_socket_file` and start to reinitialize it. It falls into this loop and prevent itself from reaching the safepoint.
>> 
>>      while (AttachListener::transit_state(AL_INITIALIZING,
>>                                            AL_NOT_INITIALIZED) != AL_NOT_INITIALIZED) {
>>         os::naked_yield();
>>       }
>> 
>> 
>> If A waked up and realized that the socket has gone,  it would set `_state` to AL_NOT_INITIALIZED. Current code is adeadlock.  A can?t wake up because S hasn?t reached the safepoint yet. S can?t reach the safepoint because A hasn?t set _state to AL_NOT_INITIALIZED.  This patch avoids the deadlock by trapping into blocked state before the loop.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo when we manually edited the two test files.
>   
>   Currently, RemovingUnixDomainSocketTest.java isn't running because @test
>   is taken away when we backport JDK-8225690. we try to keep the patch
>   intact in case we enable it in the future.

Lgtm.

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

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.java.net/jdk8u-dev/pull/32

From andrew at openjdk.java.net  Wed Apr  6 19:49:57 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 6 Apr 2022 19:49:57 GMT
Subject: [jdk8u-dev] RFR: 8253424: Add support for running pre-submit
 testing using GitHub Actions [v20]
In-Reply-To: <V3UhDAhapybVwoPZi9VAaQIadsrEvFujw2chAXeKjMc=.0ebfa844-b878-4b75-b6e5-bbacf7f58c17@github.com>
References: <n-1Y9ApII-VpZgDwqk5EezTW1BKJUiK819AX2Bo7ADw=.6e17a648-5d65-4f83-ba83-27a3b55d8311@github.com>
 <V3UhDAhapybVwoPZi9VAaQIadsrEvFujw2chAXeKjMc=.0ebfa844-b878-4b75-b6e5-bbacf7f58c17@github.com>
Message-ID: <5PmIo1w5aMMl4tDri2wQcWvc0_3qxOHtIv2W3miF51g=.798215d7-ec15-431d-9641-7fe6c1df7c09@github.com>

On Sun, 3 Apr 2022 21:38:31 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> Initial attempt to backport https://github.com/openjdk/jdk11u-dev/commit/1faefed218051c324bdb5c7c10369050d6c9dd44
>> 
>> Changes so far:
>> * `make/autoconf/version-numbers` -> `common/autoconf/version-numbers`
>> * Fix version variables (`JDK_MAJOR_VERSION`, `JDK_MINOR_VERSION` and `JDK_MICRO_VERSION` in 8u)
>> * Remove boot JDK for Linux (provided by build environment Ubuntu 20.04 in openjdk-8-jdk)
>> * Replace `--with-version-opt` with `--with-user-release-suffix`
>> * Drop `--enable-jtreg-failure-handler` (unsupported)
>> * Move make targets to make invocation (`--with-default-make-target` not supported)
>> * Drop `--with-msvc-toolset-version`
>> * Disable tests as we don't currently have the bundles required to support them
>
> Andrew John Hughes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   User Start-Process to run setup.exe

I see the bug now has `jdk8u-fix-yes`.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/3

From andrew at openjdk.java.net  Wed Apr  6 19:50:00 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 6 Apr 2022 19:50:00 GMT
Subject: [jdk8u-dev] RFR: 8253424: Add support for running pre-submit
 testing using GitHub Actions [v20]
In-Reply-To: <hL7SVA0XdXjX-qlLfJABOU9EN7zqpGotELvkaBS_R4M=.dd0bafae-4c38-4378-89fd-dfe09365a22b@github.com>
References: <n-1Y9ApII-VpZgDwqk5EezTW1BKJUiK819AX2Bo7ADw=.6e17a648-5d65-4f83-ba83-27a3b55d8311@github.com>
 <V3UhDAhapybVwoPZi9VAaQIadsrEvFujw2chAXeKjMc=.0ebfa844-b878-4b75-b6e5-bbacf7f58c17@github.com>
 <ACHIqF7JUha3oe8iZ0mwMacOu-HnXkq_Y8tf7IsAiEE=.b890f086-c969-401b-b386-487e5115abb2@github.com>
 <RFQCgfdatdzSDQBqj_aaxTD1GgaFfXOR6pwwqqqcb-U=.47e7945d-48f3-42f8-a869-886682ff367f@github.com>
 <Va7H-bB61LP2LuCjD4N_-OmWJrUCyEhubMuZzA9pL-U=.39213701-ad65-4f82-9b6f-8141e111f528@github.com>
 <hL7SVA0XdXjX-qlLfJABOU9EN7zqpGotELvkaBS_R4M=.dd0bafae-4c38-4378-89fd-dfe09365a22b@github.com>
Message-ID: <-4uRD1IJnZsg2fqz1bei8r99zm7fkkVQvqWHKu4GSdY=.d19621e1-1720-434b-a29a-e2c7243b3d0d@github.com>

On Tue, 5 Apr 2022 21:51:07 GMT, Alex Kasko <akasko at openjdk.org> wrote:

> > A couple of questions:
> > 
> > 1. Does this mean the file is not needed for the VS2010 build? I duplicated your changes in that build and it seems to work at present.
> 
> Yes, I believe it is not needed for VS2010. I haven't tried it with 32-bit VS2010 myself, but IIRC it worked out of the box with 64-bit VS2013 (freeware version of VS2010 doesn't support 64-bit, setup is possible with WinSDK7.1 toolchain, but it is complicated). Modified file was intended to change only 64-bit config (to make it working with 64-bit VS2017) so 32-bit config remained the same there. Thus `Copy FreeType project file` step on 32-bit most probably can be removed.
> 

Thanks. We can maybe try that in a follow-up PR.

> > 2. Any idea why 11u (which this is backported from) works without this? Does it build FreeType in a different way?
> 
> Yes, in 8u FreeType is not included in-tree, it was always used as an external dependency and for "open" jdk only (Oracle JDK didn't use it). `--with-freetype-src` flag is relatively recent, it was added in [JDK-8057538](https://bugs.openjdk.java.net/browse/JDK-8057538). In 11u FreeType is [included in-tree](https://github.com/openjdk/jdk11u/tree/master/src/java.desktop/share/native/libfreetype) and is built the same way as other in-tree dep libs.

Interesting, thanks. It may be worth considering whether to bring the FreeType sources into 8u as well.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/3

From andrew at openjdk.java.net  Wed Apr  6 19:50:03 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Wed, 6 Apr 2022 19:50:03 GMT
Subject: [jdk8u-dev] Integrated: 8253424: Add support for running pre-submit
 testing using GitHub Actions
In-Reply-To: <n-1Y9ApII-VpZgDwqk5EezTW1BKJUiK819AX2Bo7ADw=.6e17a648-5d65-4f83-ba83-27a3b55d8311@github.com>
References: <n-1Y9ApII-VpZgDwqk5EezTW1BKJUiK819AX2Bo7ADw=.6e17a648-5d65-4f83-ba83-27a3b55d8311@github.com>
Message-ID: <7CdAn9_BhtvhL2JJ87wJ0Kp9QRFMZGlNVxxRTZFr1VY=.c9ada3c5-d823-433c-a466-dedcda34910d@github.com>

On Sat, 5 Mar 2022 17:05:04 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Initial attempt to backport https://github.com/openjdk/jdk11u-dev/commit/1faefed218051c324bdb5c7c10369050d6c9dd44
> 
> Changes so far:
> * `make/autoconf/version-numbers` -> `common/autoconf/version-numbers`
> * Fix version variables (`JDK_MAJOR_VERSION`, `JDK_MINOR_VERSION` and `JDK_MICRO_VERSION` in 8u)
> * Remove boot JDK for Linux (provided by build environment Ubuntu 20.04 in openjdk-8-jdk)
> * Replace `--with-version-opt` with `--with-user-release-suffix`
> * Drop `--enable-jtreg-failure-handler` (unsupported)
> * Move make targets to make invocation (`--with-default-make-target` not supported)
> * Drop `--with-msvc-toolset-version`
> * Disable tests as we don't currently have the bundles required to support them

This pull request has now been integrated.

Changeset: 10029f78
Author:    Andrew John Hughes <andrew at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-dev/commit/10029f784ef7be458a7b6ff3cc21649ff0abb6f3
Stats:     3401 lines in 3 files changed: 3401 ins; 0 del; 0 mod

8253424: Add support for running pre-submit testing using GitHub Actions
8253865: Pre-submit testing using GitHub Actions does not detect failures reliably
8254054: Pre-submit testing using GitHub Actions should not use the deprecated set-env command
8254173: Add Zero, Minimal hotspot targets to submit workflow
8254175: Build no-pch configuration in debug mode for submit checks
8254282: Add Linux x86_32 builds to submit workflow
8255373: Submit workflow artifact name is always "test-results_.zip"
8255895: Submit workflow artifacts miss hs_errs/replays due to ZIP include mismatch
8256127: Add cross-compiled foreign architectures builds to submit workflow
8256277: Github Action build on macOS should define OS and Xcode versions
8256354: Github Action build on Windows should define OS and MSVC versions
8256414: add optimized build to submit workflow
8256393: Github Actions build on Linux should define OS and GCC versions
8256747: GitHub Actions: decouple the hotspot build-only jobs from Linux x64 testing
8257056: Submit workflow should apt-get update to avoid package installation errors
8259924: GitHub actions fail on Linux x86_32 with "Could not configure libc6:i386"
8260460: GitHub actions still fail on Linux x86_32 with "Could not configure libc6:i386"
8263667: Avoid running GitHub actions on branches named pr/*
8255305: Add Linux x86_32 tier1 to submit workflow
8255352: Archive important test outputs in submit workflow
8282225: GHA: Allow one concurrent run per PR only

Co-authored-by: Alex Kasko <akasko at openjdk.org>
Co-authored-by: Zden?k ?ambersk? <zzambers at redhat.com>
Reviewed-by: sgehwolf
Backport-of: 1faefed218051c324bdb5c7c10369050d6c9dd44

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/3

From andrew at openjdk.java.net  Thu Apr  7 01:22:41 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Thu, 7 Apr 2022 01:22:41 GMT
Subject: [jdk8u-dev] RFR: 8190753: (zipfs): Accessing a large entry (> 2^31
 bytes) leads to a negative initial size for ByteArrayOutputStream [v2]
In-Reply-To: <WWVthsDN83_lK326v4aYKmpJt7g8uwIolEJZbZn_eLw=.e0ae00ca-d82c-4c63-9051-b0cfe6dbc515@github.com>
References: <2f1WZB-7a95AbsGtWUlAX_cQhK19C6zRXx9NTANDNW0=.3082177e-e569-4aef-b630-60c29f83a41f@github.com>
 <WWVthsDN83_lK326v4aYKmpJt7g8uwIolEJZbZn_eLw=.e0ae00ca-d82c-4c63-9051-b0cfe6dbc515@github.com>
Message-ID: <UlCcwR-ViZ2zZMay_cwnZ9YLm35_pJifsjH1VmC73lU=.3ba6015d-81e8-4a0d-b6c0-b21193e53059@github.com>

On Tue, 5 Apr 2022 08:49:17 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

>> Hi!
>> 
>> Please review the backport of JDK-8190753 to 8u. The patch fixes IllegalArgumentException that takes place on accessing large (>2^31 bytes) entries in zipfs.
>> 
>> The original patch
>> 
>> https://github.com/openjdk/jdk11u-dev/pull/545
>> 
>> was applied with the following changes:
>> 
>> - changes to absent DeflatingEntryOutputStream class were skipped (in 8u EntryOutputStream handles both RAW and deflating streaming);
>> - the tests were updated to not use unsupported APIs like Path.of() and Map.of()
>> - timeout value for ZipFSOutputStreamTest was increased because the test is too greedy and may fail by timeout on low performance hosts
>> 
>> The changes were previously reviewed: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-December/014479.html
>> 
>> Verification/regression: jdk_other (20.04/amd64)
>
> Alexey Pavlyutkin has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fixing whitespace difference
>  - fixing whitespace difference

This version looks a lot better. There do still seem to be a few odd differences that have crept in, when compared to the patch in 11u, which I've noted in my review. These should be quick to fix, then we can get this in.

jdk/test/demo/zipfs/LargeCompressedEntrySizeTest.java line 92:

> 90:                 final long start = System.currentTimeMillis();
> 91:                 for (long l = 0; l < largeEntrySize; l += chunkSize) {
> 92:                     final int numToWrite = (int)Math.min(remaining, chunkSize);

11u has a space between `(int)` and `Math`.

jdk/test/demo/zipfs/ZipFSOutputStreamTest.java line 120:

> 118:                         totalRead += numRead;
> 119:                         // verify the content
> 120:                         for (int i = 0, chunkoffset = (int)((totalRead - numRead) % chunk.length);

Again, 11u has a space between `(int)` and `((totalRead`

jdk/test/demo/zipfs/ZipFSOutputStreamTest.java line 126:

> 124:                         }
> 125:                     }
> 126:                     Assert.assertEquals(totalRead, (long)entry.getValue(),

11u has a space between `(long)` and `entry`.

jdk/test/demo/zipfs/ZipFSOutputStreamTest.java line 141:

> 139:         long remaining = totalSize;
> 140:         for (long l = 0; l < totalSize; l += chunk.length) {
> 141:             final int numToWrite = (int)Math.min(remaining, chunk.length);

11u has a space between `(int)` and `Math`

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/17

From duke at openjdk.java.net  Thu Apr  7 05:17:26 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Thu, 7 Apr 2022 05:17:26 GMT
Subject: [jdk8u-dev] RFR: 8190753: (zipfs): Accessing a large entry (> 2^31
 bytes) leads to a negative initial size for ByteArrayOutputStream [v3]
In-Reply-To: <2f1WZB-7a95AbsGtWUlAX_cQhK19C6zRXx9NTANDNW0=.3082177e-e569-4aef-b630-60c29f83a41f@github.com>
References: <2f1WZB-7a95AbsGtWUlAX_cQhK19C6zRXx9NTANDNW0=.3082177e-e569-4aef-b630-60c29f83a41f@github.com>
Message-ID: <exwGOeKBAn21yhdvKt5pYySBt0tiEyvmUyhwxrwZ3qo=.cda11e81-d7c8-4ee1-9bfa-6f5258c968fd@github.com>

> Hi!
> 
> Please review the backport of JDK-8190753 to 8u. The patch fixes IllegalArgumentException that takes place on accessing large (>2^31 bytes) entries in zipfs.
> 
> The original patch
> 
> https://github.com/openjdk/jdk11u-dev/pull/545
> 
> was applied with the following changes:
> 
> - changes to absent DeflatingEntryOutputStream class were skipped (in 8u EntryOutputStream handles both RAW and deflating streaming);
> - the tests were updated to not use unsupported APIs like Path.of() and Map.of()
> - timeout value for ZipFSOutputStreamTest was increased because the test is too greedy and may fail by timeout on low performance hosts
> 
> The changes were previously reviewed: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-December/014479.html
> 
> Verification/regression: jdk_other (20.04/amd64)

Alexey Pavlyutkin has updated the pull request incrementally with three additional commits since the last revision:

 - eliminating unwanted delta with 11u
 - eliminating unwanted delta with 11u
 - eliminating unwanted delta with 11u

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

Changes:
  - all: https://git.openjdk.java.net/jdk8u-dev/pull/17/files
  - new: https://git.openjdk.java.net/jdk8u-dev/pull/17/files/f09b849c..8911a600

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

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/17.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/17/head:pull/17

PR: https://git.openjdk.java.net/jdk8u-dev/pull/17

From duke at openjdk.java.net  Thu Apr  7 19:11:15 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Thu, 7 Apr 2022 19:11:15 GMT
Subject: [jdk8u-dev] RFR: 8221988: add possibility to build with Visual Studio
 2019
Message-ID: <x2mVGiERq9FssKsmqM5KC0SgkzK9OQlG9CbIjklKe-I=.2490d700-8ca3-47ee-ab10-362397e51442@github.com>

Hi!

Please review backport of 8221988. This one opens a bunch of backports enabling support of VS2019. The 11u patch applied with the following changes:

- changes to absent documentation files skipped
- resolved baseline conflicts toolchain_windows.m4

Verification: `bash configure` under VS2019 prompt
Regression: `bash configure` under VS2017 prompt

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

Commit messages:
 - adding Devkit script
 - 8221988: add possibility to build with Visual Studio 2019

Changes: https://git.openjdk.java.net/jdk8u-dev/pull/33/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=33&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8221988
  Stats: 227 lines in 2 files changed: 223 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/33.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/33/head:pull/33

PR: https://git.openjdk.java.net/jdk8u-dev/pull/33

From serb at openjdk.java.net  Thu Apr  7 21:50:41 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 7 Apr 2022 21:50:41 GMT
Subject: [jdk8u-dev] Integrated: 8261107: ArrayIndexOutOfBoundsException in the
 ICC_Profile.getInstance(InputStream)
In-Reply-To: <B1ga2v1dh4btwF-HOyMgBpTHM7caIeUu5EiV3CGEG6E=.9db8d760-2817-49e5-b37a-8628dade6fca@github.com>
References: <B1ga2v1dh4btwF-HOyMgBpTHM7caIeUu5EiV3CGEG6E=.9db8d760-2817-49e5-b37a-8628dade6fca@github.com>
Message-ID: <LU7xLTdURtf04SsRJR7V4AEgjrgO8a0HO35pYklihdw=.13654a1c-efd6-4686-ac5d-59746bc4e9d9@github.com>

On Thu, 24 Mar 2022 03:35:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Hi all,
> This pull request contains a backport of commit [06b33a0a](https://github.com/openjdk/jdk/commit/06b33a0ad78d1577711af22020cf5fdf25112523) from the [openjdk/jdk](https://git.openjdk.java.net/jdk) repository.
> The commit being backported was authored by Sergey Bylokhov on 4 Feb 2021 and was reviewed by Alexander Zvegintsev and Prasanta Sadhukhan.
> 
> The new test failed before and works fine after the fix. No new issues were found by the java_desktop tests.
> To apply the patch I had to change the paths and some patch context. The changed lines are the same.
> 
> Thanks!

This pull request has now been integrated.

Changeset: b2491599
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-dev/commit/b2491599ca4de259682d140983ca645a70ea5723
Stats:     56 lines in 2 files changed: 54 ins; 0 del; 2 mod

8261107: ArrayIndexOutOfBoundsException in the ICC_Profile.getInstance(InputStream)

Reviewed-by: phh
Backport-of: 06b33a0ad78d1577711af22020cf5fdf25112523

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/21

From andrew at openjdk.java.net  Fri Apr  8 02:11:43 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Fri, 8 Apr 2022 02:11:43 GMT
Subject: [jdk8u-dev] RFR: 8190753: (zipfs): Accessing a large entry (> 2^31
 bytes) leads to a negative initial size for ByteArrayOutputStream [v3]
In-Reply-To: <exwGOeKBAn21yhdvKt5pYySBt0tiEyvmUyhwxrwZ3qo=.cda11e81-d7c8-4ee1-9bfa-6f5258c968fd@github.com>
References: <2f1WZB-7a95AbsGtWUlAX_cQhK19C6zRXx9NTANDNW0=.3082177e-e569-4aef-b630-60c29f83a41f@github.com>
 <exwGOeKBAn21yhdvKt5pYySBt0tiEyvmUyhwxrwZ3qo=.cda11e81-d7c8-4ee1-9bfa-6f5258c968fd@github.com>
Message-ID: <E2AQ3OoZkzY2OMGUDA2o3cdnKxwookHtAXCwalcRo7I=.d84155a2-e228-4cae-ac1c-5d171cfbb03c@github.com>

On Thu, 7 Apr 2022 05:17:26 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

>> Hi!
>> 
>> Please review the backport of JDK-8190753 to 8u. The patch fixes IllegalArgumentException that takes place on accessing large (>2^31 bytes) entries in zipfs.
>> 
>> The original patch
>> 
>> https://github.com/openjdk/jdk11u-dev/pull/545
>> 
>> was applied with the following changes:
>> 
>> - changes to absent DeflatingEntryOutputStream class were skipped (in 8u EntryOutputStream handles both RAW and deflating streaming);
>> - the tests were updated to not use unsupported APIs like Path.of() and Map.of()
>> - timeout value for ZipFSOutputStreamTest was increased because the test is too greedy and may fail by timeout on low performance hosts
>> 
>> The changes were previously reviewed: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-December/014479.html
>> 
>> Verification/regression: jdk_other (20.04/amd64)
>
> Alexey Pavlyutkin has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - eliminating unwanted delta with 11u
>  - eliminating unwanted delta with 11u
>  - eliminating unwanted delta with 11u

Brilliant, let's finally get this in.

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

Marked as reviewed by andrew (Reviewer).

PR: https://git.openjdk.java.net/jdk8u-dev/pull/17

From andrew at openjdk.java.net  Fri Apr  8 02:17:42 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Fri, 8 Apr 2022 02:17:42 GMT
Subject: [jdk8u-dev] RFR: 8190753: (zipfs): Accessing a large entry (> 2^31
 bytes) leads to a negative initial size for ByteArrayOutputStream [v3]
In-Reply-To: <exwGOeKBAn21yhdvKt5pYySBt0tiEyvmUyhwxrwZ3qo=.cda11e81-d7c8-4ee1-9bfa-6f5258c968fd@github.com>
References: <2f1WZB-7a95AbsGtWUlAX_cQhK19C6zRXx9NTANDNW0=.3082177e-e569-4aef-b630-60c29f83a41f@github.com>
 <exwGOeKBAn21yhdvKt5pYySBt0tiEyvmUyhwxrwZ3qo=.cda11e81-d7c8-4ee1-9bfa-6f5258c968fd@github.com>
Message-ID: <EOBIIbyBKMC6B-OfLKvSS9yVoEI-pflDsM8Vz4jbzJs=.9f8e34a4-ccb3-4f80-af5c-49c40183f90b@github.com>

On Thu, 7 Apr 2022 05:17:26 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

>> Hi!
>> 
>> Please review the backport of JDK-8190753 to 8u. The patch fixes IllegalArgumentException that takes place on accessing large (>2^31 bytes) entries in zipfs.
>> 
>> The original patch
>> 
>> https://github.com/openjdk/jdk11u-dev/pull/545
>> 
>> was applied with the following changes:
>> 
>> - changes to absent DeflatingEntryOutputStream class were skipped (in 8u EntryOutputStream handles both RAW and deflating streaming);
>> - the tests were updated to not use unsupported APIs like Path.of() and Map.of()
>> - timeout value for ZipFSOutputStreamTest was increased because the test is too greedy and may fail by timeout on low performance hosts
>> 
>> The changes were previously reviewed: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-December/014479.html
>> 
>> Verification/regression: jdk_other (20.04/amd64)
>
> Alexey Pavlyutkin has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - eliminating unwanted delta with 11u
>  - eliminating unwanted delta with 11u
>  - eliminating unwanted delta with 11u

I've added `jdk8u-fix-yes` to the bug.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/17

From duke at openjdk.java.net  Fri Apr  8 07:02:41 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Fri, 8 Apr 2022 07:02:41 GMT
Subject: [jdk8u-dev] Integrated: 8190753: (zipfs): Accessing a large entry (>
 2^31 bytes) leads to a negative initial size for ByteArrayOutputStream
In-Reply-To: <2f1WZB-7a95AbsGtWUlAX_cQhK19C6zRXx9NTANDNW0=.3082177e-e569-4aef-b630-60c29f83a41f@github.com>
References: <2f1WZB-7a95AbsGtWUlAX_cQhK19C6zRXx9NTANDNW0=.3082177e-e569-4aef-b630-60c29f83a41f@github.com>
Message-ID: <mt66xh-mlQ_fMnBK8nNHr0PqLN3-guNeWKIdhTOR4eU=.70934499-03b6-4d8c-a23c-9f6bc3d0131c@github.com>

On Fri, 18 Mar 2022 12:24:37 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

> Hi!
> 
> Please review the backport of JDK-8190753 to 8u. The patch fixes IllegalArgumentException that takes place on accessing large (>2^31 bytes) entries in zipfs.
> 
> The original patch
> 
> https://github.com/openjdk/jdk11u-dev/pull/545
> 
> was applied with the following changes:
> 
> - changes to absent DeflatingEntryOutputStream class were skipped (in 8u EntryOutputStream handles both RAW and deflating streaming);
> - the tests were updated to not use unsupported APIs like Path.of() and Map.of()
> - timeout value for ZipFSOutputStreamTest was increased because the test is too greedy and may fail by timeout on low performance hosts
> 
> The changes were previously reviewed: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-December/014479.html
> 
> Verification/regression: jdk_other (20.04/amd64)

This pull request has now been integrated.

Changeset: 3647d987
Author:    Alexey Pavlyutkin <apavlyutkin at azul.com>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-dev/commit/3647d987abad91eceef72900c71f8f4f55c8e92f
Stats:     365 lines in 3 files changed: 360 ins; 1 del; 4 mod

8190753: (zipfs): Accessing a large entry (> 2^31 bytes) leads to a negative initial size for ByteArrayOutputStream

Reviewed-by: phh, andrew
Backport-of: 8a9cda2d84513ab49a54e1d2a7b530f0bae05c61

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/17

From duke at openjdk.java.net  Fri Apr  8 09:52:18 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Fri, 8 Apr 2022 09:52:18 GMT
Subject: [jdk8u-dev] RFR: 8256722: handle VC++:1927 VS2019 in
 abstract_vm_version
Message-ID: <4iMO_KW4vtclo99ZkML4OxhBkdO5HK0dFGxjOLua06s=.3cff5a83-24e1-451d-8e9c-e6b0311e67eb@github.com>

Hi!

Here is the backport of 8256722 that extends the list recognizable VC++ compiler versions for VS2019. The patch from 11u applied cleanly except the path shuffling:

src/hotspot/share/runtime/abstract_vm_version.cpp -> hotspot/src/share/vm/runtime/vm_version.cpp

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

Commit messages:
 - 8256722: handle VC++:1927 VS2019 in  abstract_vm_version

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/34

From clanger at openjdk.java.net  Fri Apr  8 13:25:47 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Fri, 8 Apr 2022 13:25:47 GMT
Subject: [jdk8u-dev] RFR: 8221988: add possibility to build with Visual
 Studio 2019
In-Reply-To: <x2mVGiERq9FssKsmqM5KC0SgkzK9OQlG9CbIjklKe-I=.2490d700-8ca3-47ee-ab10-362397e51442@github.com>
References: <x2mVGiERq9FssKsmqM5KC0SgkzK9OQlG9CbIjklKe-I=.2490d700-8ca3-47ee-ab10-362397e51442@github.com>
Message-ID: <Hs9hjkOcQePg3rqzZPWxC_L9LW6Y83Y0gvCqnM3t3xU=.2cc2b9f8-9e0b-4ac8-96a6-b9974874bff2@github.com>

On Thu, 7 Apr 2022 19:03:44 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

> Hi!
> 
> Please review backport of 8221988. This one opens a bunch of backports enabling support of VS2019. The 11u patch applied with the following changes:
> 
> - changes to absent documentation files skipped
> - resolved baseline conflicts toolchain_windows.m4
> 
> Verification: `bash configure` under VS2019 prompt
> Regression: `bash configure` under VS2017 prompt
> 
> @RealCLanger @mdoerr if you take a look at this I will be very grateful

Hi @apavlyutkin,
apart from my other comment I think the backport looks okay. However, I've no means to test it. Probably somebody more involved with OpenJDK 8 (and its Windows build) should have a look...

common/autoconf/toolchain_windows.m4 line 28:

> 26: ################################################################################
> 27: # The order of these defines the priority by which we try to find them.
> 28: VALID_VS_VERSIONS="2017 2019 2013 2015 2012 2010"

I'm not sure whether it's appropriate to put 2017 and 2019 in front of the list - maybe for compatibilities sake we should add 2019 at the end?

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/33

From duke at openjdk.java.net  Fri Apr  8 14:02:48 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Fri, 8 Apr 2022 14:02:48 GMT
Subject: [jdk8u-dev] RFR: 8221988: add possibility to build with Visual
 Studio 2019
In-Reply-To: <Hs9hjkOcQePg3rqzZPWxC_L9LW6Y83Y0gvCqnM3t3xU=.2cc2b9f8-9e0b-4ac8-96a6-b9974874bff2@github.com>
References: <x2mVGiERq9FssKsmqM5KC0SgkzK9OQlG9CbIjklKe-I=.2490d700-8ca3-47ee-ab10-362397e51442@github.com>
 <Hs9hjkOcQePg3rqzZPWxC_L9LW6Y83Y0gvCqnM3t3xU=.2cc2b9f8-9e0b-4ac8-96a6-b9974874bff2@github.com>
Message-ID: <WEsmWfLyy3VloBzduVcYsa4W5WmYQBdISgiuPaSkzGA=.60805d83-09ea-42f0-9e6b-eaa28994c829@github.com>

On Fri, 8 Apr 2022 13:21:26 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> Hi!
>> 
>> Please review backport of 8221988. This one opens a bunch of backports enabling support of VS2019. The 11u patch applied with the following changes:
>> 
>> - changes to absent documentation files skipped
>> - resolved baseline conflicts toolchain_windows.m4
>> 
>> Verification: `bash configure` under VS2019 prompt
>> Regression: `bash configure` under VS2017 prompt
>> 
>> @RealCLanger @mdoerr if you take a look at this I will be very grateful
>
> common/autoconf/toolchain_windows.m4 line 28:
> 
>> 26: ################################################################################
>> 27: # The order of these defines the priority by which we try to find them.
>> 28: VALID_VS_VERSIONS="2017 2019 2013 2015 2012 2010"
> 
> I'm not sure whether it's appropriate to put 2017 and 2019 in front of the list - maybe for compatibilities sake we should add 2019 at the end?

I completely agree with you but that is how it comes from 11u. I'm not sure if it's a good idea to make such changes as part of the backport. On my last backport to 8u @gnu-andrew made me to eliminate every signle whitespace of unwanted delta.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/33

From clanger at openjdk.java.net  Fri Apr  8 14:33:53 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Fri, 8 Apr 2022 14:33:53 GMT
Subject: [jdk8u-dev] RFR: 8221988: add possibility to build with Visual
 Studio 2019
In-Reply-To: <WEsmWfLyy3VloBzduVcYsa4W5WmYQBdISgiuPaSkzGA=.60805d83-09ea-42f0-9e6b-eaa28994c829@github.com>
References: <x2mVGiERq9FssKsmqM5KC0SgkzK9OQlG9CbIjklKe-I=.2490d700-8ca3-47ee-ab10-362397e51442@github.com>
 <Hs9hjkOcQePg3rqzZPWxC_L9LW6Y83Y0gvCqnM3t3xU=.2cc2b9f8-9e0b-4ac8-96a6-b9974874bff2@github.com>
 <WEsmWfLyy3VloBzduVcYsa4W5WmYQBdISgiuPaSkzGA=.60805d83-09ea-42f0-9e6b-eaa28994c829@github.com>
Message-ID: <9vMZc_mv7lahwAw9ysjJENL1BiTApFf34MBBhE5Oznw=.cbfe68f6-d2da-481e-8a1d-6d3dc9168b7a@github.com>

On Fri, 8 Apr 2022 13:59:02 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

>> common/autoconf/toolchain_windows.m4 line 28:
>> 
>>> 26: ################################################################################
>>> 27: # The order of these defines the priority by which we try to find them.
>>> 28: VALID_VS_VERSIONS="2017 2019 2013 2015 2012 2010"
>> 
>> I'm not sure whether it's appropriate to put 2017 and 2019 in front of the list - maybe for compatibilities sake we should add 2019 at the end?
>
> I completely agree with you but that is how it comes from 11u. I'm not sure if it's a good idea to make such changes as part of the backport. On my last backport to 8u @gnu-andrew made me to eliminate every signle whitespace of unwanted delta.

Yes, let @gnu-andrew or @jerboaa deliver the judgement here.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/33

From sgehwolf at openjdk.java.net  Fri Apr  8 15:51:40 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 8 Apr 2022 15:51:40 GMT
Subject: [jdk8u-dev] RFR: 8221988: add possibility to build with Visual
 Studio 2019
In-Reply-To: <9vMZc_mv7lahwAw9ysjJENL1BiTApFf34MBBhE5Oznw=.cbfe68f6-d2da-481e-8a1d-6d3dc9168b7a@github.com>
References: <x2mVGiERq9FssKsmqM5KC0SgkzK9OQlG9CbIjklKe-I=.2490d700-8ca3-47ee-ab10-362397e51442@github.com>
 <Hs9hjkOcQePg3rqzZPWxC_L9LW6Y83Y0gvCqnM3t3xU=.2cc2b9f8-9e0b-4ac8-96a6-b9974874bff2@github.com>
 <WEsmWfLyy3VloBzduVcYsa4W5WmYQBdISgiuPaSkzGA=.60805d83-09ea-42f0-9e6b-eaa28994c829@github.com>
 <9vMZc_mv7lahwAw9ysjJENL1BiTApFf34MBBhE5Oznw=.cbfe68f6-d2da-481e-8a1d-6d3dc9168b7a@github.com>
Message-ID: <yZ867B2aI8SOtV1HovZZ7OlEYd-r1dhTyNTM66MOIkY=.7178d162-206d-4b6a-a6b6-d83a6e501c9f@github.com>

On Fri, 8 Apr 2022 14:30:16 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> I completely agree with you but that is how it comes from 11u. I'm not sure if it's a good idea to make such changes as part of the backport. On my last backport to 8u @gnu-andrew made me to eliminate every signle whitespace of unwanted delta.
>
> Yes, let @gnu-andrew or @jerboaa deliver the judgement here.

My understanding is that the order for different JDK releases may differ. Newer JDKs might want to build with the newest toolchain if possible. That's different for update releases. So if we backport this, versions for 2017 and 2019 should go to the end. See for example `8196108: Add build support for VS 2015/2017 ` which added this 4 years ago for 2015 and 2017.

TLDR; For compatibility we shall append.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/33

From duke at openjdk.java.net  Fri Apr  8 16:26:22 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Fri, 8 Apr 2022 16:26:22 GMT
Subject: [jdk8u-dev] RFR: 8221988: add possibility to build with Visual
 Studio 2019 [v2]
In-Reply-To: <x2mVGiERq9FssKsmqM5KC0SgkzK9OQlG9CbIjklKe-I=.2490d700-8ca3-47ee-ab10-362397e51442@github.com>
References: <x2mVGiERq9FssKsmqM5KC0SgkzK9OQlG9CbIjklKe-I=.2490d700-8ca3-47ee-ab10-362397e51442@github.com>
Message-ID: <IFQObOADDSUEfHfnRSoQ_hdtMptt6_tEykLpkZBo_84=.f9b11dad-9fbf-4900-83d3-5f546ec1ab89@github.com>

> Hi!
> 
> Please review backport of 8221988. This one opens a bunch of backports enabling support of VS2019. The 11u patch applied with the following changes:
> 
> - changes to absent documentation files skipped
> - resolved baseline conflicts toolchain_windows.m4
> 
> Verification: `bash configure` under VS2019 prompt
> Regression: `bash configure` under VS2017 prompt
> 
> @RealCLanger @mdoerr if you take a look at this I will be very grateful

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

  rearrange valid VS versions

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

Changes:
  - all: https://git.openjdk.java.net/jdk8u-dev/pull/33/files
  - new: https://git.openjdk.java.net/jdk8u-dev/pull/33/files/dcef37f5..f3e81fdb

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

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/33

From sgehwolf at openjdk.java.net  Fri Apr  8 17:04:42 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 8 Apr 2022 17:04:42 GMT
Subject: [jdk8u-dev] RFR: 8221988: add possibility to build with Visual
 Studio 2019 [v2]
In-Reply-To: <IFQObOADDSUEfHfnRSoQ_hdtMptt6_tEykLpkZBo_84=.f9b11dad-9fbf-4900-83d3-5f546ec1ab89@github.com>
References: <x2mVGiERq9FssKsmqM5KC0SgkzK9OQlG9CbIjklKe-I=.2490d700-8ca3-47ee-ab10-362397e51442@github.com>
 <IFQObOADDSUEfHfnRSoQ_hdtMptt6_tEykLpkZBo_84=.f9b11dad-9fbf-4900-83d3-5f546ec1ab89@github.com>
Message-ID: <D51N-MaVhcUrjtHtLq7S334753-iZYFLuYPo-ljIQDU=.eacc961f-8adc-48d0-ade7-cf6e435e0aa7@github.com>

On Fri, 8 Apr 2022 16:26:22 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

>> Hi!
>> 
>> Please review backport of 8221988. This one opens a bunch of backports enabling support of VS2019. The 11u patch applied with the following changes:
>> 
>> - changes to absent documentation files skipped
>> - resolved baseline conflicts toolchain_windows.m4
>> 
>> Verification: `bash configure` under VS2019 prompt
>> Regression: `bash configure` under VS2017 prompt
>> 
>> @RealCLanger @mdoerr if you take a look at this I will be very grateful
>
> Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rearrange valid VS versions

With which versions of Visual Studio has this been tested?

common/autoconf/toolchain_windows.m4 line 28:

> 26: ################################################################################
> 27: # The order of these defines the priority by which we try to find them.
> 28: VALID_VS_VERSIONS="2013 2015 2012 2010 2017 2019"

Order should be: `2010 2012 2013 2015 2017 2019`

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/33

From duke at openjdk.java.net  Fri Apr  8 17:46:57 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Fri, 8 Apr 2022 17:46:57 GMT
Subject: [jdk8u-dev] RFR: 8221988: add possibility to build with Visual
 Studio 2019 [v3]
In-Reply-To: <x2mVGiERq9FssKsmqM5KC0SgkzK9OQlG9CbIjklKe-I=.2490d700-8ca3-47ee-ab10-362397e51442@github.com>
References: <x2mVGiERq9FssKsmqM5KC0SgkzK9OQlG9CbIjklKe-I=.2490d700-8ca3-47ee-ab10-362397e51442@github.com>
Message-ID: <dW5P6oPVvCaaQpDqrUGIjqenRQ5OVCF3ncdSdJ-eHUQ=.c5f30ddf-bd97-441d-af03-2987389150f0@github.com>

> Hi!
> 
> Please review backport of 8221988. This one opens a bunch of backports enabling support of VS2019. The 11u patch applied with the following changes:
> 
> - changes to absent documentation files skipped
> - resolved baseline conflicts toolchain_windows.m4
> 
> Verification: `bash configure` under VS2019 prompt
> Regression: `bash configure` under VS2017 prompt
> 
> @RealCLanger @mdoerr if you take a look at this I will be very grateful

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

  rearrange valid VS versions

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

Changes:
  - all: https://git.openjdk.java.net/jdk8u-dev/pull/33/files
  - new: https://git.openjdk.java.net/jdk8u-dev/pull/33/files/f3e81fdb..36e603c1

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

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/33

From duke at openjdk.java.net  Fri Apr  8 17:53:47 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Fri, 8 Apr 2022 17:53:47 GMT
Subject: [jdk8u-dev] RFR: 8221988: add possibility to build with Visual
 Studio 2019 [v2]
In-Reply-To: <D51N-MaVhcUrjtHtLq7S334753-iZYFLuYPo-ljIQDU=.eacc961f-8adc-48d0-ade7-cf6e435e0aa7@github.com>
References: <x2mVGiERq9FssKsmqM5KC0SgkzK9OQlG9CbIjklKe-I=.2490d700-8ca3-47ee-ab10-362397e51442@github.com>
 <IFQObOADDSUEfHfnRSoQ_hdtMptt6_tEykLpkZBo_84=.f9b11dad-9fbf-4900-83d3-5f546ec1ab89@github.com>
 <D51N-MaVhcUrjtHtLq7S334753-iZYFLuYPo-ljIQDU=.eacc961f-8adc-48d0-ade7-cf6e435e0aa7@github.com>
Message-ID: <caWHvc13xLtyxFrd4RgARx9uosMl1YZX1WBJQE63hMk=.205ff265-30e1-413d-9944-628c00204c08@github.com>

On Fri, 8 Apr 2022 17:00:55 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rearrange valid VS versions
>
> common/autoconf/toolchain_windows.m4 line 28:
> 
>> 26: ################################################################################
>> 27: # The order of these defines the priority by which we try to find them.
>> 28: VALID_VS_VERSIONS="2013 2015 2012 2010 2017 2019"
> 
> Order should be: `2010 2012 2013 2015 2017 2019`

2017 (build) and 2019 (configuration). To me it's enough at this stage, the changes do not touch older toolkits, only define new 2019. Moreover it's a bit difficult to test for now, because 5-6 more backports required to enable VS2019, and few of them require complete regression. For now VS2019 build will fail immediately

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/33

From duke at openjdk.java.net  Mon Apr 11 00:46:47 2022
From: duke at openjdk.java.net (ktakakuri)
Date: Mon, 11 Apr 2022 00:46:47 GMT
Subject: [jdk8u-dev] RFR: 8278138: OpenJDK8 fails to start on Windows 8.1
 after upgrading compiler to VS2017
In-Reply-To: <EY6NkB82WC9qCoUsPJ7dIR5UFKZjdL0hmmjGtvXM8Fw=.aa052a7d-07e8-49c9-bcb7-da6041f567b7@github.com>
References: <EY6NkB82WC9qCoUsPJ7dIR5UFKZjdL0hmmjGtvXM8Fw=.aa052a7d-07e8-49c9-bcb7-da6041f567b7@github.com>
Message-ID: <BawO0Mi7Jb4cqmeCsCiYhgMcISGR-xBJv6yRuNTHlME=.07a917cf-d4f5-4820-9eb0-17d99d8deebc@github.com>

On Tue, 29 Mar 2022 06:43:24 GMT, ktakakuri <duke at openjdk.java.net> wrote:

> Could you please review the 8278138 bug fixes?
> 
> This problem is caused by missing DLL's which vcruntime140.dll depends on.
> I think it is needed to copy the missing DLL's into jdk/bin as like jdk/jre/bin.
> I fix to copy api-ms-win-*.dll files to jdk/bin when images directory is created.

Could someone please review this pull request?

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/25

From duke at openjdk.java.net  Mon Apr 11 09:38:52 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Mon, 11 Apr 2022 09:38:52 GMT
Subject: [jdk8u-dev] RFR: 8221988: add possibility to build with Visual
 Studio 2019 [v2]
In-Reply-To: <D51N-MaVhcUrjtHtLq7S334753-iZYFLuYPo-ljIQDU=.eacc961f-8adc-48d0-ade7-cf6e435e0aa7@github.com>
References: <x2mVGiERq9FssKsmqM5KC0SgkzK9OQlG9CbIjklKe-I=.2490d700-8ca3-47ee-ab10-362397e51442@github.com>
 <IFQObOADDSUEfHfnRSoQ_hdtMptt6_tEykLpkZBo_84=.f9b11dad-9fbf-4900-83d3-5f546ec1ab89@github.com>
 <D51N-MaVhcUrjtHtLq7S334753-iZYFLuYPo-ljIQDU=.eacc961f-8adc-48d0-ade7-cf6e435e0aa7@github.com>
Message-ID: <8QLfsPZMZzAce0XSglg-0coFlAGGMBBaz-4Rg8kRwys=.df5a82fd-e38e-4753-94dc-8b74c8dda280@github.com>

On Fri, 8 Apr 2022 17:00:55 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rearrange valid VS versions
>
> common/autoconf/toolchain_windows.m4 line 28:
> 
>> 26: ################################################################################
>> 27: # The order of these defines the priority by which we try to find them.
>> 28: VALID_VS_VERSIONS="2013 2015 2012 2010 2017 2019"
> 
> Order should be: `2010 2012 2013 2015 2017 2019`

Fixed. The patch tested for all 2010-2019 toolkits, the PR header was updated accordingly

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/33

From jnordstrom at openjdk.java.net  Mon Apr 11 19:23:39 2022
From: jnordstrom at openjdk.java.net (Joakim =?UTF-8?B?Tm9yZHN0csO2bQ==?=)
Date: Mon, 11 Apr 2022 19:23:39 GMT
Subject: [jdk8u-dev] RFR: 8278138: OpenJDK8 fails to start on Windows 8.1
 after upgrading compiler to VS2017
In-Reply-To: <EY6NkB82WC9qCoUsPJ7dIR5UFKZjdL0hmmjGtvXM8Fw=.aa052a7d-07e8-49c9-bcb7-da6041f567b7@github.com>
References: <EY6NkB82WC9qCoUsPJ7dIR5UFKZjdL0hmmjGtvXM8Fw=.aa052a7d-07e8-49c9-bcb7-da6041f567b7@github.com>
Message-ID: <s_FZI4QCjSQC5SyX5kF6FrCXlGIlR74DUpy1EQHr-Y0=.6362531a-eac8-45b0-bddd-f6c837fa4a1f@github.com>

On Tue, 29 Mar 2022 06:43:24 GMT, ktakakuri <duke at openjdk.java.net> wrote:

> Could you please review the 8278138 bug fixes?
> 
> This problem is caused by missing DLL's which vcruntime140.dll depends on.
> I think it is needed to copy the missing DLL's into jdk/bin as like jdk/jre/bin.
> I fix to copy api-ms-win-*.dll files to jdk/bin when images directory is created.

Hi,
Thank you for looking into this.
I've found that only copying the api-ms-* DLLs isn't sufficient. You also need to copy ucrtbase.dll among others. Instead of relying on the name, you can simply add all files from the the redistributable UCRT directory, in the same manner as in [CopyFiles.gmk.](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/make/CopyFiles.gmk#L250)

jdk/make/Images.gmk line 149:

> 147:     $(LIBRARY_PREFIX)jli$(SHARED_LIBRARY_SUFFIX) \
> 148:     $(notdir $(MSVCR_DLL)) \
> 149:     $(wildcard $(JDK_OUTPUTDIR)/bin/api-ms-win-*.dll)

By adding msvcp DLL, and all DLLs from the redistributable UCRT directory, we should get all files needed.
Suggestion:

    $(notdir $(MSVCP_DLL))

ifneq ($(UCRT_DLL_DIR), )
  WINDOWS_JDK_BIN_FILES += $(notdir $(wildcard $(UCRT_DLL_DIR)/*.dll))
endif

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

Changes requested by jnordstrom (no project role).

PR: https://git.openjdk.java.net/jdk8u-dev/pull/25

From andrew at openjdk.java.net  Tue Apr 12 19:07:23 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Tue, 12 Apr 2022 19:07:23 GMT
Subject: [jdk8u-dev] RFR: JDK-8284772: 8u GHA: Use GCC Major Version
 Dependencies Only
Message-ID: <9orZk-QXNP7EXd6GiWGqF_xsajhliPEPoZmuZTdjOjk=.fb226304-5bca-4c14-afe4-0f41eb99f74b@github.com>

Major versions of GCC often cause problems with OpenJDK. Fedora's eager adoption of them means we often encounter these early. [JDK-8282231](https://bugs.openjdk.java.net/browse/JDK-8282231) is just the latest example from the introduction of GCC 12.

However, the GHA workflow in OpenJDK doesn't just depend on a major version of GCC - which is actually contained in the Ubuntu package name of `gcc-9` itself - but the full revision number, even down to local packaging changes.

I believe this is overkill and leads to valuable time being wasted on issues like [JDK-8283778](https://bugs.openjdk.java.net/browse/JDK-8283778) where the GCC version itself didn't change at all, just the Ubuntu version suffix.

Rather than maintain this for 8u, I suggest we just depend on `gcc-9` which is already a pretty modern version for 8u. I have yet to see an issue be specific to a minor GCC version bump, whereas the current setup is pretty much guaranteed to mean further fixes to the GitHub workflow every time the Ubuntu packager produces a new build.

Note that the x86-32 Linux build already uses just `gcc-9-multilib` which is why it hasn't been broken by the latest GCC update.

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

Commit messages:
 - Remove specification of minor version and package release data from GCC dependency

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/35

From clanger at openjdk.java.net  Wed Apr 13 06:29:22 2022
From: clanger at openjdk.java.net (Christoph Langer)
Date: Wed, 13 Apr 2022 06:29:22 GMT
Subject: [jdk8u-dev] RFR: JDK-8284772: 8u GHA: Use GCC Major Version
 Dependencies Only
In-Reply-To: <9orZk-QXNP7EXd6GiWGqF_xsajhliPEPoZmuZTdjOjk=.fb226304-5bca-4c14-afe4-0f41eb99f74b@github.com>
References: <9orZk-QXNP7EXd6GiWGqF_xsajhliPEPoZmuZTdjOjk=.fb226304-5bca-4c14-afe4-0f41eb99f74b@github.com>
Message-ID: <W6tYYCY0hsk0djZhSGZl9e7HlJlQyduL22JQhPeq0Qk=.48a24ce4-df6a-492f-ad62-9cda97390b4d@github.com>

On Tue, 12 Apr 2022 18:59:41 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Major versions of GCC often cause problems with OpenJDK. Fedora's eager adoption of them means we often encounter these early. [JDK-8282231](https://bugs.openjdk.java.net/browse/JDK-8282231) is just the latest example from the introduction of GCC 12.
> 
> However, the GHA workflow in OpenJDK doesn't just depend on a major version of GCC - which is actually contained in the Ubuntu package name of `gcc-9` itself - but the full revision number, even down to local packaging changes.
> 
> I believe this is overkill and leads to valuable time being wasted on issues like [JDK-8283778](https://bugs.openjdk.java.net/browse/JDK-8283778) where the GCC version itself didn't change at all, just the Ubuntu version suffix.
> 
> Rather than maintain this for 8u, I suggest we just depend on `gcc-9` which is already a pretty modern version for 8u. I have yet to see an issue be specific to a minor GCC version bump, whereas the current setup is pretty much guaranteed to mean further fixes to the GitHub workflow every time the Ubuntu packager produces a new build.
> 
> Note that the x86-32 Linux build already uses just `gcc-9-multilib` which is why it hasn't been broken by the latest GCC update.

I would really love to see this type of change be done in jdk head and be backported to each active update release ??

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/35

From duke at openjdk.java.net  Wed Apr 13 08:27:13 2022
From: duke at openjdk.java.net (ktakakuri)
Date: Wed, 13 Apr 2022 08:27:13 GMT
Subject: [jdk8u-dev] RFR: 8278138: OpenJDK8 fails to start on Windows 8.1
 after upgrading compiler to VS2017 [v2]
In-Reply-To: <EY6NkB82WC9qCoUsPJ7dIR5UFKZjdL0hmmjGtvXM8Fw=.aa052a7d-07e8-49c9-bcb7-da6041f567b7@github.com>
References: <EY6NkB82WC9qCoUsPJ7dIR5UFKZjdL0hmmjGtvXM8Fw=.aa052a7d-07e8-49c9-bcb7-da6041f567b7@github.com>
Message-ID: <hIb2H4HpdR8n2Xydq-jAwU1kXD_wSNwt6SkPuAN2Blg=.7dcd092d-bf4a-4811-ae3a-64fc6f596a74@github.com>

> Could you please review the 8278138 bug fixes?
> 
> This problem is caused by missing DLL's which vcruntime140.dll depends on.
> I think it is needed to copy the missing DLL's into jdk/bin as like jdk/jre/bin.
> I fix to copy api-ms-win-*.dll files to jdk/bin when images directory is created.

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

  Update jdk/make/Images.gmk
  
  Co-authored-by: Joakim Nordstr?m <joakim.nordstrom at oracle.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk8u-dev/pull/25/files
  - new: https://git.openjdk.java.net/jdk8u-dev/pull/25/files/dda73cdd..be11289e

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

  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/25.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/25/head:pull/25

PR: https://git.openjdk.java.net/jdk8u-dev/pull/25

From duke at openjdk.java.net  Wed Apr 13 08:30:18 2022
From: duke at openjdk.java.net (ktakakuri)
Date: Wed, 13 Apr 2022 08:30:18 GMT
Subject: [jdk8u-dev] RFR: 8278138: OpenJDK8 fails to start on Windows 8.1
 after upgrading compiler to VS2017 [v2]
In-Reply-To: <s_FZI4QCjSQC5SyX5kF6FrCXlGIlR74DUpy1EQHr-Y0=.6362531a-eac8-45b0-bddd-f6c837fa4a1f@github.com>
References: <EY6NkB82WC9qCoUsPJ7dIR5UFKZjdL0hmmjGtvXM8Fw=.aa052a7d-07e8-49c9-bcb7-da6041f567b7@github.com>
 <s_FZI4QCjSQC5SyX5kF6FrCXlGIlR74DUpy1EQHr-Y0=.6362531a-eac8-45b0-bddd-f6c837fa4a1f@github.com>
Message-ID: <gKEZr6YqlwfDc4cIInaZx9RFAkc4T52KKo3TqPOLLqY=.bfcd8aec-d570-4b9e-a9b2-6fc8e2bb3042@github.com>

On Mon, 11 Apr 2022 19:20:54 GMT, Joakim Nordstr?m <jnordstrom at openjdk.org> wrote:

> Hi, Thank you for looking into this. I've found that only copying the api-ms-* DLLs isn't sufficient. You also need to copy ucrtbase.dll among others. Instead of relying on the name, you can simply add all files from the the redistributable UCRT directory, in the same manner as in [CopyFiles.gmk.](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/make/CopyFiles.gmk#L250)

Thank you for your review.
I think your comments are correct.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/25

From iris.clark at oracle.com  Wed Apr 13 16:11:28 2022
From: iris.clark at oracle.com (Iris Clark)
Date: Wed, 13 Apr 2022 16:11:28 +0000
Subject: Proposal: Improve java.lang.ref processing in Java SE 8 and JDK 8
Message-ID: <SJ0PR10MB544025DFEC356969DC496EEFFBEC9@SJ0PR10MB5440.namprd10.prod.outlook.com>

A critical issue has been identified in the Java SE 8 Platform, pertaining to
the cloning of java.lang.ref.Reference objects.

While investigating this issue, two related issues were identified in the
processing of Reference objects.

The issues are:

  - (Critical) The Java SE 8 Specification does not clearly define the
    semantics of cloning a Reference object.  During Java SE 11 development,
    it was determined that a Reference object cannot be meaningfully cloned
    since its reachability may change during garbage collection reference
    processing.  Thus, Reference.clone() was specified in Java SE 11 to always
    throw a CloneNotSupportedException. [0]

  - (Related) The Java SE 8 Specification does not prohibit the referent of a
    phantom reference from being retrieved between the time that the reference
    is enqueued and the time it is cleared by the garbage collector.  To
    eliminate this possibility, the specification of PhantomReference was
    updated in Java SE 9 to automatically clear reference objects when they
    are enqueued.  This update better aligned PhantomReference with
    SoftReference and WeakReference. [1]

  - (Related) The Java SE 8 Specification allows an application to explicitly
    add a Reference object to its registered queue before it is cleared by the
    garbage collector.  In Java SE 9, the specification of Reference.enqueue()
    was modified to always clear the reference object before it is enqueued.
    This aligns application code invocations of this method with the behaviour
    of garbage collectors. [2]

To resolve these issues for future JDK updates, I'll shortly propose a
Maintenance Release of the Java SE 8 Platform JSR [3] in the JCP to backport
these three changes from Java SE 9 and 11.  This will require updates to the
Specification and the Reference Implementation (RI), which I and my colleagues
at Oracle will provide.  The TCK does not require updates.  I expect the
Maintenance Release process to complete by July 2022, in time for these
changes to be merged into the October security releases of JDK 8.

Following the practice introduced in the previous Maintenance Release
(February 2020), we want to reduce risk by basing the open-source RI on
OpenJDK 8u41 [4], the RI for the previous Maintenance Release, rather than the
most recent OpenJDK 8 Updates release.  We propose to label the RI build as
"8u42" in order to convey that it is outside the contemporary train of update
releases, and (like the 8u41 build before it) is neither meant for production
use nor updated with security fixes.

If it's not too much work then we'll also contribute the changes required by
the MR to the next appropriate OpenJDK 8 Updates release, most likely 8u352.

Comments?

Iris

[0]: https://bugs.openjdk.java.net/browse/JDK-8202260
[1]: https://bugs.openjdk.java.net/browse/CCC-8071507
[2]: https://bugs.openjdk.java.net/browse/CCC-8175797
[3]: https://jcp.org/en/jsr/detail?id=337
[4]: https://hg.openjdk.java.net/jdk8u/jdk8u41

From volker.simonis at gmail.com  Wed Apr 13 16:55:55 2022
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 13 Apr 2022 18:55:55 +0200
Subject: Proposal: Improve java.lang.ref processing in Java SE 8 and JDK 8
In-Reply-To: <SJ0PR10MB544025DFEC356969DC496EEFFBEC9@SJ0PR10MB5440.namprd10.prod.outlook.com>
References: <SJ0PR10MB544025DFEC356969DC496EEFFBEC9@SJ0PR10MB5440.namprd10.prod.outlook.com>
Message-ID: <CA+3eh104wqCfm9kNvNV_BhFGMfQH41=ZPWUSoMhd7hUY58=ttA@mail.gmail.com>

Hi Iris,

Thanks for the heads-up. Is there any evidence where this has caused
compatibility issues?

Also, I see that JDK-8175797 [1] (which is the implementation
CCC-8175797) introduced the property
`jdk.lang.ref.disableClearBeforeEnqueue` which can be used to maintain
backward compatibility with the old behavior. However, this property
wasn't really functional until it was fixed by JDK-8178832. Do you
plan to downport JDK-8178832 as well?

Also, more generally, what is the "critical issue" that justifies a
new Java 8 MR? I expect there are a lot of fixes in later Java
specifications and it would be interesting to know when it is
appropriate and justified to downport them and create a new Java 8 MR?

Thank you and best regards,
Volker

[1] https://bugs.openjdk.java.net/browse/JDK-8175797
[2] https://bugs.openjdk.java.net/browse/JDK-8178832

On Wed, Apr 13, 2022 at 6:12 PM Iris Clark <iris.clark at oracle.com> wrote:
>
> A critical issue has been identified in the Java SE 8 Platform, pertaining to
> the cloning of java.lang.ref.Reference objects.
>
> While investigating this issue, two related issues were identified in the
> processing of Reference objects.
>
> The issues are:
>
>   - (Critical) The Java SE 8 Specification does not clearly define the
>     semantics of cloning a Reference object.  During Java SE 11 development,
>     it was determined that a Reference object cannot be meaningfully cloned
>     since its reachability may change during garbage collection reference
>     processing.  Thus, Reference.clone() was specified in Java SE 11 to always
>     throw a CloneNotSupportedException. [0]
>
>   - (Related) The Java SE 8 Specification does not prohibit the referent of a
>     phantom reference from being retrieved between the time that the reference
>     is enqueued and the time it is cleared by the garbage collector.  To
>     eliminate this possibility, the specification of PhantomReference was
>     updated in Java SE 9 to automatically clear reference objects when they
>     are enqueued.  This update better aligned PhantomReference with
>     SoftReference and WeakReference. [1]
>
>   - (Related) The Java SE 8 Specification allows an application to explicitly
>     add a Reference object to its registered queue before it is cleared by the
>     garbage collector.  In Java SE 9, the specification of Reference.enqueue()
>     was modified to always clear the reference object before it is enqueued.
>     This aligns application code invocations of this method with the behaviour
>     of garbage collectors. [2]
>
> To resolve these issues for future JDK updates, I'll shortly propose a
> Maintenance Release of the Java SE 8 Platform JSR [3] in the JCP to backport
> these three changes from Java SE 9 and 11.  This will require updates to the
> Specification and the Reference Implementation (RI), which I and my colleagues
> at Oracle will provide.  The TCK does not require updates.  I expect the
> Maintenance Release process to complete by July 2022, in time for these
> changes to be merged into the October security releases of JDK 8.
>
> Following the practice introduced in the previous Maintenance Release
> (February 2020), we want to reduce risk by basing the open-source RI on
> OpenJDK 8u41 [4], the RI for the previous Maintenance Release, rather than the
> most recent OpenJDK 8 Updates release.  We propose to label the RI build as
> "8u42" in order to convey that it is outside the contemporary train of update
> releases, and (like the 8u41 build before it) is neither meant for production
> use nor updated with security fixes.
>
> If it's not too much work then we'll also contribute the changes required by
> the MR to the next appropriate OpenJDK 8 Updates release, most likely 8u352.
>
> Comments?
>
> Iris
>
> [0]: https://bugs.openjdk.java.net/browse/JDK-8202260
> [1]: https://bugs.openjdk.java.net/browse/CCC-8071507
> [2]: https://bugs.openjdk.java.net/browse/CCC-8175797
> [3]: https://jcp.org/en/jsr/detail?id=337
> [4]: https://hg.openjdk.java.net/jdk8u/jdk8u41

From gnu.andrew at redhat.com  Thu Apr 14 16:54:14 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 14 Apr 2022 17:54:14 +0100
Subject: Pending Patches
Message-ID: <YlhRto3rzq3QS2d/@hex.discworld.ac.uk>

Hi all,

There are a number of patches in various states of review
and approval that have been caught in the move from first
the 8u forest to a mono repository, and then to Git.

For those that were tagged in the bug system with either
jdk8u-fix-request or jdk8u-needs-review, but didn't yet
have a Git PR, I have replaced the tag with jdk8u-needs-pr.

The following filter lists them:

https://bugs.openjdk.java.net/issues/?filter=42478

or you can just click the 'jdk8u-needs-pr' label.

This should round up a number of fixes that have
got lost in the mailing list and we can hopefully
get them reviewed and integrated into 8u.

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 erikj at openjdk.java.net  Thu Apr 14 21:26:43 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 14 Apr 2022 21:26:43 GMT
Subject: [jdk8u-ri] RFR: 8210283: Support git as an SCM alternative in the
 build
Message-ID: <eNW2C4V1QI07axyhtgmZKh_iQvDP5Po4EsWquLENBMA=.c90bbee8-fcf0-4d04-8a71-fb13dad8d2d5@github.com>

This is a backport of the changes needed to support building from Git repos. I've tried to keep the changes minimal. The patch differs quite a bit from the original jdk8u backport of this change, mainly in the parts that only really serve to interact with Oracle custom build logic, and likely aren't used by anyone in jdk8u main. For example, I chose to keep the existing .hgtip files instead of trying to rename them to something else (.gittip or .src-rev), as updating the external dependencies we have on these file names would be too much work for this release.

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

Commit messages:
 - Git support

Changes: https://git.openjdk.java.net/jdk8u-ri/pull/1/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-ri&pr=1&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8210283
  Stats: 79 lines in 5 files changed: 74 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk8u-ri/pull/1.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-ri pull/1/head:pull/1

PR: https://git.openjdk.java.net/jdk8u-ri/pull/1

From mikael at openjdk.java.net  Thu Apr 14 21:39:50 2022
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Thu, 14 Apr 2022 21:39:50 GMT
Subject: [jdk8u-ri] RFR: 8210283: Support git as an SCM alternative in the
 build
In-Reply-To: <eNW2C4V1QI07axyhtgmZKh_iQvDP5Po4EsWquLENBMA=.c90bbee8-fcf0-4d04-8a71-fb13dad8d2d5@github.com>
References: <eNW2C4V1QI07axyhtgmZKh_iQvDP5Po4EsWquLENBMA=.c90bbee8-fcf0-4d04-8a71-fb13dad8d2d5@github.com>
Message-ID: <-4iOwz102bkdp0ibnHvzhxOa0bNAZuqEKcGj6c3NpIA=.89fa2c3a-67a7-42b0-8938-411e760e0fcb@github.com>

On Thu, 14 Apr 2022 21:22:09 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This is a backport of the changes needed to support building from Git repos. I've tried to keep the changes minimal. The patch differs quite a bit from the original jdk8u backport of this change, mainly in the parts that only really serve to interact with Oracle custom build logic, and likely aren't used by anyone in jdk8u main. For example, I chose to keep the existing .hgtip files instead of trying to rename them to something else (.gittip or .src-rev), as updating the external dependencies we have on these file names would be too much work for this release.

Marked as reviewed by mikael (Author).

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/1

From erikj at openjdk.java.net  Thu Apr 14 22:29:34 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 14 Apr 2022 22:29:34 GMT
Subject: [jdk8u-ri] RFR: 8210283: Support git as an SCM alternative in the
 build [v2]
In-Reply-To: <eNW2C4V1QI07axyhtgmZKh_iQvDP5Po4EsWquLENBMA=.c90bbee8-fcf0-4d04-8a71-fb13dad8d2d5@github.com>
References: <eNW2C4V1QI07axyhtgmZKh_iQvDP5Po4EsWquLENBMA=.c90bbee8-fcf0-4d04-8a71-fb13dad8d2d5@github.com>
Message-ID: <oGMRcdAb8wN6gIpFuV5Aubd0NsV3CBX8DYhc99tgV2g=.c880f71e-698c-45c7-8f4d-c8cea15f42cc@github.com>

> This is a backport of the changes needed to support building from Git repos. I've tried to keep the changes minimal. The patch differs quite a bit from the original jdk8u backport of this change, mainly in the parts that only really serve to interact with Oracle custom build logic, and likely aren't used by anyone in jdk8u main. For example, I chose to keep the existing .hgtip files instead of trying to rename them to something else (.gittip or .src-rev), as updating the external dependencies we have on these file names would be too much work for this release.

Erik Joelsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  Git support

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

Changes: https://git.openjdk.java.net/jdk8u-ri/pull/1/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-ri&pr=1&range=01
  Stats: 79 lines in 5 files changed: 74 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk8u-ri/pull/1.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-ri pull/1/head:pull/1

PR: https://git.openjdk.java.net/jdk8u-ri/pull/1

From tbell at openjdk.java.net  Fri Apr 15 13:54:42 2022
From: tbell at openjdk.java.net (Tim Bell)
Date: Fri, 15 Apr 2022 13:54:42 GMT
Subject: [jdk8u-ri] RFR: 8210283: Support git as an SCM alternative in the
 build [v2]
In-Reply-To: <oGMRcdAb8wN6gIpFuV5Aubd0NsV3CBX8DYhc99tgV2g=.c880f71e-698c-45c7-8f4d-c8cea15f42cc@github.com>
References: <eNW2C4V1QI07axyhtgmZKh_iQvDP5Po4EsWquLENBMA=.c90bbee8-fcf0-4d04-8a71-fb13dad8d2d5@github.com>
 <oGMRcdAb8wN6gIpFuV5Aubd0NsV3CBX8DYhc99tgV2g=.c880f71e-698c-45c7-8f4d-c8cea15f42cc@github.com>
Message-ID: <uFGtna3VwXnZpH7fFO8DeTPt_y6BIgiEXG8I4B12Hbk=.f2e07f9a-30f5-439d-80d3-f59bcec9f820@github.com>

On Thu, 14 Apr 2022 22:29:34 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> This is a backport of the changes needed to support building from Git repos. I've tried to keep the changes minimal. The patch differs quite a bit from the original jdk8u backport of this change, mainly in the parts that only really serve to interact with Oracle custom build logic, and likely aren't used by anyone in jdk8u main. For example, I chose to keep the existing .hgtip files instead of trying to rename them to something else (.gittip or .src-rev), as updating the external dependencies we have on these file names would be too much work for this release.
>
> Erik Joelsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Git support

Looks good

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

Marked as reviewed by tbell (Reviewer).

PR: https://git.openjdk.java.net/jdk8u-ri/pull/1

From erikj at openjdk.java.net  Fri Apr 15 14:06:14 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 15 Apr 2022 14:06:14 GMT
Subject: [jdk8u-ri] RFR: 8284907: Compact profiles build fails with GNU make 4
Message-ID: <a1YomLgNSaaWS8vql36eCVvP8ga6HhI-UPNcrdbbktg=.075b1835-f304-4263-9446-589863eda5e2@github.com>

The compact profiles jar creation logic relies on what seems to be undefined behavior in GNU make. Pattern rules are unreliable when the file names contain '$'. The specific construct used in CreateJars.gmk works with GNU make 3.81, but fails with version 4 or higher.

This was originally fixed in 8u60 in [JDK-8067857](https://bugs.openjdk.java.net/browse/JDK-8067857). That change is quite big and not something we want to backport to 8u42. However, since then, GNU make 4 and higher have become quite common on Linux too, and not just in Cygwin where I believe this problem was first encountered. Because of this, I would like to extract just the fix for this, exactly as it was done in [JDK-8067857](https://bugs.openjdk.java.net/browse/JDK-8067857). Here is the original change:

https://github.com/openjdk/jdk8u-dev/commit/17421c860a6e71e14b0023e686b87c35b2049f69#diff-e580e7e55e76622c538ae8a1b55af984b3e12bba099e493582fff2925b9ae02aR314-R322

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

Commit messages:
 - Fix for newer make from JDK-8038189: Add cross-platform compact profiles support

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/2

From tbell at openjdk.java.net  Fri Apr 15 14:28:53 2022
From: tbell at openjdk.java.net (Tim Bell)
Date: Fri, 15 Apr 2022 14:28:53 GMT
Subject: [jdk8u-ri] RFR: 8284907: Compact profiles build fails with GNU
 make 4
In-Reply-To: <a1YomLgNSaaWS8vql36eCVvP8ga6HhI-UPNcrdbbktg=.075b1835-f304-4263-9446-589863eda5e2@github.com>
References: <a1YomLgNSaaWS8vql36eCVvP8ga6HhI-UPNcrdbbktg=.075b1835-f304-4263-9446-589863eda5e2@github.com>
Message-ID: <Fvt-0ARvAOHW0319ntBQzN56YM87XbU6F-VpprdO5SY=.ae657b66-0753-43cc-b2cd-ce662f82b248@github.com>

On Fri, 15 Apr 2022 13:48:24 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The compact profiles jar creation logic relies on what seems to be undefined behavior in GNU make. Pattern rules are unreliable when the file names contain '$'. The specific construct used in CreateJars.gmk works with GNU make 3.81, but fails with version 4 or higher.
> 
> This was originally fixed in 8u60 in [JDK-8067857](https://bugs.openjdk.java.net/browse/JDK-8067857). That change is quite big and not something we want to backport to 8u42. However, since then, GNU make 4 and higher have become quite common on Linux too, and not just in Cygwin where I believe this problem was first encountered. Because of this, I would like to extract just the fix for this, exactly as it was done in [JDK-8067857](https://bugs.openjdk.java.net/browse/JDK-8067857). Here is the original change:
> 
> https://github.com/openjdk/jdk8u-dev/commit/17421c860a6e71e14b0023e686b87c35b2049f69#diff-e580e7e55e76622c538ae8a1b55af984b3e12bba099e493582fff2925b9ae02aR314-R322

Looks good

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

Marked as reviewed by tbell (Reviewer).

PR: https://git.openjdk.java.net/jdk8u-ri/pull/2

From iris.clark at oracle.com  Fri Apr 15 17:59:22 2022
From: iris.clark at oracle.com (Iris Clark)
Date: Fri, 15 Apr 2022 17:59:22 +0000
Subject: [External] : Re: Proposal: Improve java.lang.ref processing in
 Java SE 8 and JDK 8
In-Reply-To: <CA+3eh104wqCfm9kNvNV_BhFGMfQH41=ZPWUSoMhd7hUY58=ttA@mail.gmail.com>
References: <SJ0PR10MB544025DFEC356969DC496EEFFBEC9@SJ0PR10MB5440.namprd10.prod.outlook.com>
 <CA+3eh104wqCfm9kNvNV_BhFGMfQH41=ZPWUSoMhd7hUY58=ttA@mail.gmail.com>
Message-ID: <SJ0PR10MB5440EDD7A080436E711BE633FBEE9@SJ0PR10MB5440.namprd10.prod.outlook.com>

Hi, Volker.

> Also, more generally, what is the "critical issue" that justifies a
> new Java 8 MR? I expect there are a lot of fixes in later Java
> specifications and it would be interesting to know when it is
> appropriate and justified to downport them and create a new Java 8 MR?

As the Maintenance Lead of Java SE 8 (JSR-337), Oracle works hard to
balance the benefits and the costs of a Maintenance Release (MR).

One reason for an MR is to make the Java Platform conform more fully and
usefully with critical external standards, such as Unicode and security
protocols. This was seen in the 2019 and 2020 Maintenance Releases.

Another reason for an MR is to address issues in the Specification that
have a high probability of leading to unsound or incorrect behaviour by
Implementations. Typically, these issues lie in the Specification of the
JVM or in the Specification of low-level APIs that interact with the JVM
(e.g., reference processing). The MR hardens these Specifications so
that programs cannot be hurt by edge cases where behavior of the Java
Platform is undefined.

This is the situation with the critical issue, 8202260, in the proposed
MR. The issue points to undefined behavior in a core low-level API. The
lack of specification results in, at worst, a reproducible VM crash. The
issue provides a Specification that is easy to understand, implement,
and verify. Oracle believes the benefit of addressing the issue is worth
the cost to the 8u community of having an MR.

Iris

From kim.barrett at oracle.com  Mon Apr 18 07:00:48 2022
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 18 Apr 2022 07:00:48 +0000
Subject: Proposal: Improve java.lang.ref processing in Java SE 8 and JDK 8
In-Reply-To: <CA+3eh104wqCfm9kNvNV_BhFGMfQH41=ZPWUSoMhd7hUY58=ttA@mail.gmail.com>
References: <SJ0PR10MB544025DFEC356969DC496EEFFBEC9@SJ0PR10MB5440.namprd10.prod.outlook.com>
 <CA+3eh104wqCfm9kNvNV_BhFGMfQH41=ZPWUSoMhd7hUY58=ttA@mail.gmail.com>
Message-ID: <EBDE0183-2944-44E4-90CC-DB6346607574@oracle.com>

> On Apr 13, 2022, at 12:55 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> Hi Iris,
> 
> Thanks for the heads-up. Is there any evidence where this has caused
> compatibility issues?

So far as I can tell, Oracle hasn't received any compatibility complaints
regarding any of these changes.

During the development of CCC-8175797 (enqueue first clears the reference) a
search of other projects was conducted and found that Reference.enqueue was
rarely used, and often in conjunction with clearing the reference too. The
property to revert to the older behavior was not publicly documented at the
time the change was made (the compatibility review process was non-public at
that time).

> Also, I see that JDK-8175797 [1] (which is the implementation
> CCC-8175797) introduced the property
> `jdk.lang.ref.disableClearBeforeEnqueue` which can be used to maintain
> backward compatibility with the old behavior. However, this property
> wasn't really functional until it was fixed by JDK-8178832. Do you
> plan to downport JDK-8178832 as well?

For JDK-8175797 our current plan is to backport all 3 of JDK-8175797,
JDK-8178832, and JDK-8193780 as a single commit. That is, the Reference
Implementation won't support reverting to the old behavior via setting a
property. I think such a backward compatibility mechanism doesn't belong in
the Reference Implementation, and just adds clutter to the specification
change being proposed for the MR. Maintainers of a production JDK could add
such a mechanism if necessary to meet the needs of their user community.



From duke at openjdk.java.net  Mon Apr 18 14:12:44 2022
From: duke at openjdk.java.net (ktakakuri)
Date: Mon, 18 Apr 2022 14:12:44 GMT
Subject: [jdk8u-dev] RFR: 8278138: OpenJDK8 fails to start on Windows 8.1
 after upgrading compiler to VS2017 [v2]
In-Reply-To: <s_FZI4QCjSQC5SyX5kF6FrCXlGIlR74DUpy1EQHr-Y0=.6362531a-eac8-45b0-bddd-f6c837fa4a1f@github.com>
References: <EY6NkB82WC9qCoUsPJ7dIR5UFKZjdL0hmmjGtvXM8Fw=.aa052a7d-07e8-49c9-bcb7-da6041f567b7@github.com>
 <s_FZI4QCjSQC5SyX5kF6FrCXlGIlR74DUpy1EQHr-Y0=.6362531a-eac8-45b0-bddd-f6c837fa4a1f@github.com>
Message-ID: <DPL-AG_GS7Y3rAnFh6FxsWa-szFor-atUH6yMeURy34=.ad37202f-9d2e-40f3-b0d7-20f9c1d230c5@github.com>

On Mon, 11 Apr 2022 19:20:54 GMT, Joakim Nordstr?m <jnordstrom at openjdk.org> wrote:

>> ktakakuri has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update jdk/make/Images.gmk
>>   
>>   Co-authored-by: Joakim Nordstr?m <joakim.nordstrom at oracle.com>
>
> Hi,
> Thank you for looking into this.
> I've found that only copying the api-ms-* DLLs isn't sufficient. You also need to copy ucrtbase.dll among others. Instead of relying on the name, you can simply add all files from the the redistributable UCRT directory, in the same manner as in [CopyFiles.gmk.](https://github.com/openjdk/jdk8u-dev/blob/master/jdk/make/CopyFiles.gmk#L250)

@jaokim 
I have committed your fix.
Could you please review it again?

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/25

From erikj at openjdk.java.net  Mon Apr 18 17:02:51 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 18 Apr 2022 17:02:51 GMT
Subject: [jdk8u-ri] Integrated: 8210283: Support git as an SCM alternative in
 the build
In-Reply-To: <eNW2C4V1QI07axyhtgmZKh_iQvDP5Po4EsWquLENBMA=.c90bbee8-fcf0-4d04-8a71-fb13dad8d2d5@github.com>
References: <eNW2C4V1QI07axyhtgmZKh_iQvDP5Po4EsWquLENBMA=.c90bbee8-fcf0-4d04-8a71-fb13dad8d2d5@github.com>
Message-ID: <l5Seo_UEJx2fNih0ChWwE7zM6Km1RAKxQ63RJ1YG1yI=.a540cad0-c43f-4da1-a466-1326908b57f7@github.com>

On Thu, 14 Apr 2022 21:22:09 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This is a backport of the changes needed to support building from Git repos. I've tried to keep the changes minimal. The patch differs quite a bit from the original jdk8u backport of this change, mainly in the parts that only really serve to interact with Oracle custom build logic, and likely aren't used by anyone in jdk8u main. For example, I chose to keep the existing .hgtip files instead of trying to rename them to something else (.gittip or .src-rev), as updating the external dependencies we have on these file names would be too much work for this release.

This pull request has now been integrated.

Changeset: dfcf70de
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-ri/commit/dfcf70dea5690d563e6ff443ca75535a96bb6b59
Stats:     79 lines in 5 files changed: 74 ins; 0 del; 5 mod

8210283: Support git as an SCM alternative in the build

Removes forest handling of SCM ids

Reviewed-by: mikael, tbell
Backport-of: 054b85b1f65254b2d3d2a1d343e14d8eabd1af40

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/1

From erikj at openjdk.java.net  Mon Apr 18 22:20:53 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 18 Apr 2022 22:20:53 GMT
Subject: [jdk8u-ri] RFR: 8079087: Add support for Cygwin 2.0
Message-ID: <QAmpP64jswlEXckMaTt8ujCgTgtOGhYb7J2lgpmXl2k=.aa1a997b-07b5-4a94-8f5c-be980d47d6fd@github.com>

This is a backport of three Cygwin related fixes from jdk8u. In order to better facilitate development in jdk8u-ri, I would like to get these fixes in, so that developers may use recent versions of Cygwin as build environment for this repository. I'm not even sure it's possible to install a pre Cygwin 2.0 environment anymore. All three fixes have been used successfully in jdk8u for years.

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

Commit messages:
 - Update copyright year
 - Backport 8179675: Build with error on windows with new Cygwin grep
 - Backport 8176033: New cygwin grep does not match \r as newline
 - Backport: 8079087: Add support for Cygwin 2.0

Changes: https://git.openjdk.java.net/jdk8u-ri/pull/3/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-ri&pr=3&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8079087
  Stats: 21 lines in 3 files changed: 5 ins; 0 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk8u-ri/pull/3.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-ri pull/3/head:pull/3

PR: https://git.openjdk.java.net/jdk8u-ri/pull/3

From dongbohe at openjdk.java.net  Tue Apr 19 08:51:08 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Tue, 19 Apr 2022 08:51:08 GMT
Subject: [jdk8u-dev] RFR: 8150669: C1 intrinsic for Class.isPrimitive
Message-ID: <xjKQPs3ITjdlBkX3b2zkgPaJa-55PmBmEyGIeAFLx6w=.a4283cdb-2aad-415c-817c-52ce867b5362@github.com>

Hi, 

Please review this backport. The original purpose is to backport fix for [JDK-8239477](https://bugs.openjdk.java.net/browse/JDK-8239477). But this depends on fix for [JDK-8150669](https://bugs.openjdk.java.net/browse/JDK-8150669) & [JDK-8233019](https://bugs.openjdk.java.net/browse/JDK-8233019).

Performed full jtreg test both on x86_64-linux-gnu and aarch64-linux-gnu platforms. 

This PR has been reviewed by Paul and approved before move to github: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-August/014155.html

Follow-up fix [JDK-8233019](https://bugs.openjdk.java.net/browse/JDK-8233019) is planned to be backported as well.

(I made this PR on behalf of fyang)

Thanks,
hedongbo

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

Commit messages:
 - Backport 890f94d7e6be731ac2ebae2f1ad3cc20ec836115

Changes: https://git.openjdk.java.net/jdk8u-dev/pull/37/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=37&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8150669
  Stats: 198 lines in 5 files changed: 197 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/37.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/37/head:pull/37

PR: https://git.openjdk.java.net/jdk8u-dev/pull/37

From zgu at openjdk.java.net  Tue Apr 19 13:02:10 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 19 Apr 2022 13:02:10 GMT
Subject: [jdk8u-dev] RFR: 8275811: Incorrect instance to dispose
Message-ID: <TOn1dlA-AObukIk8TAzbMyIFTPS_GlXDW9W7mr2zPQU=.15718c0f-a363-4aac-be9c-cdcfd7285299@github.com>

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

Bug: https://bugs.openjdk.java.net/browse/JDK-8275811
Patch: https://github.com/openjdk/jdk/commit/cddc6ce44695cba4614c3405eb2b194d7c76489b

The original patch does not apply cleanly to 8u. The only conflicts are 
in `OutputRecord.java`, due to line shifts. Resolved manually.

Origin code review thread: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-December/014478.html

Test:

- [x] jdk_security, no new failure

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

Commit messages:
 - 8275811: Incorrect instance to dispose

Changes: https://git.openjdk.java.net/jdk8u-dev/pull/38/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=38&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275811
  Stats: 35 lines in 4 files changed: 32 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/38.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/38/head:pull/38

PR: https://git.openjdk.java.net/jdk8u-dev/pull/38

From zgu at openjdk.java.net  Tue Apr 19 13:23:00 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 19 Apr 2022 13:23:00 GMT
Subject: [jdk8u-dev] RFR: 8065895: Synchronous signals during error reporting
 may terminate or hang VM process
Message-ID: <0Vn1Ez7yOsUtPcv4csXii-UtPDKa0RXAXMJQDn5yvbQ=.67da286d-0c31-4634-bf27-f8f418c3f9d2@github.com>

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

Bug: https://bugs.openjdk.java.net/browse/JDK-8065895
jdk9 patch: [http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6bfc40057b3f](https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6bfc40057b3f)


jdk9 patch does not apply cleanly. There is only one conflict in 
`debug.cpp`, due to line shifts.

Original cod review thread: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-July/014133.html
and it has been reviewed by the author @stuefe (not a jdk8u reviewer)

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

Commit messages:
 - 8065895: Synchronous signals during error reporting may terminate or hang VM process

Changes: https://git.openjdk.java.net/jdk8u-dev/pull/39/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=39&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8065895
  Stats: 199 lines in 8 files changed: 142 ins; 3 del; 54 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/39.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/39/head:pull/39

PR: https://git.openjdk.java.net/jdk8u-dev/pull/39

From zgu at openjdk.java.net  Tue Apr 19 13:36:57 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 19 Apr 2022 13:36:57 GMT
Subject: [jdk8u-dev] RFR: 8186902: jcmd GC.run should not be blocked by
 DisableExplicitGC
Message-ID: <CO7wy96H9oqfljcxe24Ed5o3xlmeGRegEOi_jkoRLns=.57a79b1c-d8de-4b79-91fc-e0a5873aa4bc@github.com>

I would like to backport this parity bug to openjdk8u.

Original bug: https://bugs.openjdk.java.net/browse/JDK-8186902
Original patch: 
[http://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/3d1150c7899c](https://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/3d1150c7899c)


The original patch does not apply cleanly. Besides line shifts, 8u does 
not define `GCCause::_dcmd_gc_run`, but `GCCause::_java_lang_system_gc` instead.

Original code review thread: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-September/014288.html

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

Commit messages:
 - 8186902: jcmd GC.run should not be blocked by DisableExplicitGC

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/40

From ihse at openjdk.java.net  Tue Apr 19 13:44:28 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 19 Apr 2022 13:44:28 GMT
Subject: [jdk8u-ri] RFR: 8284907: Compact profiles build fails with GNU
 make 4
In-Reply-To: <a1YomLgNSaaWS8vql36eCVvP8ga6HhI-UPNcrdbbktg=.075b1835-f304-4263-9446-589863eda5e2@github.com>
References: <a1YomLgNSaaWS8vql36eCVvP8ga6HhI-UPNcrdbbktg=.075b1835-f304-4263-9446-589863eda5e2@github.com>
Message-ID: <OVgyDS5XZiIMUC2P2R7C53Ttx6kIUsAP16fa8rrC8MM=.309a113c-ad39-49eb-b0ab-2cb1c52df73e@github.com>

On Fri, 15 Apr 2022 13:48:24 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The compact profiles jar creation logic relies on what seems to be undefined behavior in GNU make. Pattern rules are unreliable when the file names contain '$'. The specific construct used in CreateJars.gmk works with GNU make 3.81, but fails with version 4 or higher.
> 
> This was originally fixed in 8u60 in [JDK-8067857](https://bugs.openjdk.java.net/browse/JDK-8067857). That change is quite big and not something we want to backport to 8u42. However, since then, GNU make 4 and higher have become quite common on Linux too, and not just in Cygwin where I believe this problem was first encountered. Because of this, I would like to extract just the fix for this, exactly as it was done in [JDK-8067857](https://bugs.openjdk.java.net/browse/JDK-8067857). Here is the original change:
> 
> https://github.com/openjdk/jdk8u-dev/commit/17421c860a6e71e14b0023e686b87c35b2049f69#diff-e580e7e55e76622c538ae8a1b55af984b3e12bba099e493582fff2925b9ae02aR314-R322

Marked as reviewed by ihse (Committer).

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/2

From zgu at openjdk.java.net  Tue Apr 19 14:43:54 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 19 Apr 2022 14:43:54 GMT
Subject: [jdk8u-dev] RFR: 8266187: Memory leak in appendBootClassPath()
Message-ID: <IccMfz-Oa9XSbwL2j2ezlY6QxuYxY-t7kLSbqaqCMSw=.270ffb67-1d19-4b04-9a75-abd4d89dfafb@github.com>

ackport this patch for parity with Oracle 8u331. It fixes a memory leak 
and risk is low,

Bug: https://bugs.openjdk.java.net/browse/JDK-8266187
Patch: https://github.com/openjdk/jdk/commit/aa90df6f51940a73f9aa078a32768855c8568034

The original patch does not apply cleanly. The conflict is copyright year line. Resolved manually.

The original code review thread: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-December/014484.html

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

Commit messages:
 - 8266187: Memory leak in appendBootClassPath()

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/42

From iris at openjdk.java.net  Tue Apr 19 16:56:36 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 19 Apr 2022 16:56:36 GMT
Subject: [jdk8u-ri] RFR: 8079087: Add support for Cygwin 2.0
In-Reply-To: <QAmpP64jswlEXckMaTt8ujCgTgtOGhYb7J2lgpmXl2k=.aa1a997b-07b5-4a94-8f5c-be980d47d6fd@github.com>
References: <QAmpP64jswlEXckMaTt8ujCgTgtOGhYb7J2lgpmXl2k=.aa1a997b-07b5-4a94-8f5c-be980d47d6fd@github.com>
Message-ID: <VG0OXkY0vRrXSZWFxQ8uVvrZoJYuuUVqMaAaDHX2oTE=.46ff409e-f657-42a6-8bdf-6180718b348c@github.com>

On Mon, 18 Apr 2022 22:13:20 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This is a backport of three Cygwin related fixes from jdk8u. In order to better facilitate development in jdk8u-ri, I would like to get these fixes in, so that developers may use recent versions of Cygwin as build environment for this repository. I'm not even sure it's possible to install a pre Cygwin 2.0 environment anymore. All three fixes have been used successfully in jdk8u for years.

Marked as reviewed by iris (Author).

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/3

From xxinliu at amazon.com  Tue Apr 19 17:40:48 2022
From: xxinliu at amazon.com (Liu, Xin)
Date: Tue, 19 Apr 2022 10:40:48 -0700
Subject: RFR:8235211: serviceability/attach/RemovingUnixDomainSocketTest.java
 fails with AttachNotSupportedException: Unable to open socket file
Message-ID: <15a9d87b-7574-2f6c-61c0-123ce1ab1883@amazon.com>

Hi, 8u Maintainers,

Can I get reviewed on this issue? This is the follow-up fix of
JDK-8225690, which has been backported to jdk8u. We found that it may
encounter an unrecoverable safepoint deadlock It's hard to simulate the
deadlock in test, but we describe the scenario in the PR. please take a
look.

Bug: https://bugs.openjdk.java.net/browse/JDK-8235211
PR on github: https://github.com/openjdk/jdk8u-dev/pull/32

thanks,
--lx

From poonam at openjdk.java.net  Tue Apr 19 18:08:13 2022
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Tue, 19 Apr 2022 18:08:13 GMT
Subject: [jdk8u-ri] RFR: 8071507: (ref) Clear phantom reference as soft and
 weak references do
Message-ID: <ikjRTxf579yNfmrhx-6FN8nX4HwtBQw2jNEWmNsr98I=.de0ba7bc-ebd8-49c5-baba-2dec83c93b64@github.com>

These changes backport the following fixes to jdk8u-ri:
- 8071507: (ref) Clear phantom reference as soft and weak references do
- 8071931: Return of the phantom menace
- 8143847: Remove REF_CLEANER reference category

With these changes, phantom references are automatically cleared by the garbage collector as soft and weak references.

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

Commit messages:
 - 8071507: (ref) Clear phantom reference as soft and weak references do

Changes: https://git.openjdk.java.net/jdk8u-ri/pull/4/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-ri&pr=4&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8071507
  Stats: 170 lines in 10 files changed: 105 ins; 48 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk8u-ri/pull/4.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-ri pull/4/head:pull/4

PR: https://git.openjdk.java.net/jdk8u-ri/pull/4

From zgu at openjdk.java.net  Tue Apr 19 18:10:57 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 19 Apr 2022 18:10:57 GMT
Subject: [jdk8u-dev] RFR: 8129940: JRadioButton does not honor non-standard
 FocusTraversalKeys
Message-ID: <wK6jPnFflLU4aeXDYOweQuKDpXW-B8lEQYlYD7ugxeA=.f3e108e4-9d38-4712-9c85-5e255ad17445@github.com>

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

The original bug: https://bugs.openjdk.java.net/browse/JDK-8129940
The original patch: 
[http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fbf897c33625](https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fbf897c33625)

The jdk9 patch does not apply cleanly, but only conflict is copyright 
year of `BasicRadioButtonUI.java` file.

Test:
- [x] Included `FocusTraversal/FocusTraversal.java` test fails without patch and passes with it on Linux x86_64

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

Commit messages:
 - 8129940: JRadioButton does not honor non-standard FocusTraversalKeys

Changes: https://git.openjdk.java.net/jdk8u-dev/pull/41/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=41&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8129940
  Stats: 166 lines in 2 files changed: 154 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/41.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/41/head:pull/41

PR: https://git.openjdk.java.net/jdk8u-dev/pull/41

From tbell at openjdk.java.net  Wed Apr 20 00:19:26 2022
From: tbell at openjdk.java.net (Tim Bell)
Date: Wed, 20 Apr 2022 00:19:26 GMT
Subject: [jdk8u-ri] RFR: 8079087: Add support for Cygwin 2.0
In-Reply-To: <QAmpP64jswlEXckMaTt8ujCgTgtOGhYb7J2lgpmXl2k=.aa1a997b-07b5-4a94-8f5c-be980d47d6fd@github.com>
References: <QAmpP64jswlEXckMaTt8ujCgTgtOGhYb7J2lgpmXl2k=.aa1a997b-07b5-4a94-8f5c-be980d47d6fd@github.com>
Message-ID: <ipwT9mf3fZZZlJdDWnSaUkxEA22AMfoN_9zODYD_5Ng=.fb9eb6f1-38cc-41e6-aeca-cdb631bf8eea@github.com>

On Mon, 18 Apr 2022 22:13:20 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This is a backport of three Cygwin related fixes from jdk8u. In order to better facilitate development in jdk8u-ri, I would like to get these fixes in, so that developers may use recent versions of Cygwin as build environment for this repository. I'm not even sure it's possible to install a pre Cygwin 2.0 environment anymore. All three fixes have been used successfully in jdk8u for years.

Marked as reviewed by tbell (Reviewer).

Marked as reviewed by tbell (Reviewer).

Marked as reviewed by tbell (Reviewer).

Marked as reviewed by tbell (Reviewer).

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/3

From poonam at openjdk.java.net  Wed Apr 20 00:25:09 2022
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Wed, 20 Apr 2022 00:25:09 GMT
Subject: [jdk8u-ri] RFR: 8175797: (ref) Reference::enqueue method should clear
 the reference object before enqueuing
Message-ID: <1V-62a8ZWOHk65p2xhwZlqOu5RqTADUW-WCLXUTxVC4=.1a67a810-a015-4620-be8a-820858c3dbe5@github.com>

These changes backport the following fixes to jdk8u-ri:

- 8175797: (ref) Reference::enqueue method should clear the reference object before enqueuing
- 8178832: (ref) jdk.lang.ref.disableClearBeforeEnqueue property is ignored
- 8193780: (ref) Remove the undocumented jdk.lang.ref.disableClearBeforeEnqueue system property

With this fix, the enqueue method clears the reference before enqueuing it to the registered queue.

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

Commit messages:
 - 8175797: (ref) Reference::enqueue method should clear the reference object before enqueuing

Changes: https://git.openjdk.java.net/jdk8u-ri/pull/5/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-ri&pr=5&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8175797
  Stats: 61 lines in 3 files changed: 52 ins; 3 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk8u-ri/pull/5.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-ri pull/5/head:pull/5

PR: https://git.openjdk.java.net/jdk8u-ri/pull/5

From mchung at openjdk.java.net  Wed Apr 20 00:54:26 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 20 Apr 2022 00:54:26 GMT
Subject: [jdk8u-ri] RFR: 8071507: (ref) Clear phantom reference as soft and
 weak references do
In-Reply-To: <ikjRTxf579yNfmrhx-6FN8nX4HwtBQw2jNEWmNsr98I=.de0ba7bc-ebd8-49c5-baba-2dec83c93b64@github.com>
References: <ikjRTxf579yNfmrhx-6FN8nX4HwtBQw2jNEWmNsr98I=.de0ba7bc-ebd8-49c5-baba-2dec83c93b64@github.com>
Message-ID: <2XxNGLC06PljUemZxU7HtfIiYW1fidVpQwbNYSXDgy8=.2b388fb6-4d7d-4c42-b7ba-94a8532d3aa7@github.com>

On Tue, 19 Apr 2022 18:01:20 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> These changes backport the following fixes to jdk8u-ri:
> - 8071507: (ref) Clear phantom reference as soft and weak references do
> - 8143847: Remove REF_CLEANER reference category
> 
> With these changes, phantom references are automatically cleared by the garbage collector as soft and weak references.

The change looks good to me.

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

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk8u-ri/pull/4

From poonam at openjdk.java.net  Wed Apr 20 01:06:06 2022
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Wed, 20 Apr 2022 01:06:06 GMT
Subject: [jdk8u-ri] RFR: 8201793: (ref) Reference object should not support
 cloning
Message-ID: <K_wvGr0wKQKsVQzfYQu-5ehjn-BHPCDrx3EQ2ZAlhX0=.1504b393-7438-499d-ac1e-3af967e7a2eb@github.com>

This changeset backports the fix for 8201793 to jdk8u-ri.

With this change, `java.lang.ref.Reference::clone` method always throws `CloneNotSupportedException`.

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

Commit messages:
 - 8201793: (ref) Reference object should not support cloning

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/6

From mchung at openjdk.java.net  Wed Apr 20 02:00:26 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 20 Apr 2022 02:00:26 GMT
Subject: [jdk8u-ri] RFR: 8175797: (ref) Reference::enqueue method should
 clear the reference object before enqueuing
In-Reply-To: <1V-62a8ZWOHk65p2xhwZlqOu5RqTADUW-WCLXUTxVC4=.1a67a810-a015-4620-be8a-820858c3dbe5@github.com>
References: <1V-62a8ZWOHk65p2xhwZlqOu5RqTADUW-WCLXUTxVC4=.1a67a810-a015-4620-be8a-820858c3dbe5@github.com>
Message-ID: <l66ockM9dBo1nc6ARuM2GPFK2vytHrAqyZi15arKpzI=.585536a0-451d-44d0-a033-36126527f17a@github.com>

On Wed, 20 Apr 2022 00:15:58 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> These changes backport the following fixes to jdk8u-ri:
> 
> - 8175797: (ref) Reference::enqueue method should clear the reference object before enqueuing
> - 8178832: (ref) jdk.lang.ref.disableClearBeforeEnqueue property is ignored
> - 8193780: (ref) Remove the undocumented jdk.lang.ref.disableClearBeforeEnqueue system property
> 
> With this fix, the enqueue method clears the reference before enqueuing it to the registered queue.
> 
> The backport of changes to the file _jdk/test/java/lang/ref/ReferenceEnqueue.java_ needed some manual adjustment. Apart from that,  backport of changes to the rest of the files are exact match with the original fixes.

Looks good.   This patch is equivalent to 8175797 with the system property dropped.

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

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk8u-ri/pull/5

From mchung at openjdk.java.net  Wed Apr 20 02:04:25 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 20 Apr 2022 02:04:25 GMT
Subject: [jdk8u-ri] RFR: 8201793: (ref) Reference object should not support
 cloning
In-Reply-To: <K_wvGr0wKQKsVQzfYQu-5ehjn-BHPCDrx3EQ2ZAlhX0=.1504b393-7438-499d-ac1e-3af967e7a2eb@github.com>
References: <K_wvGr0wKQKsVQzfYQu-5ehjn-BHPCDrx3EQ2ZAlhX0=.1504b393-7438-499d-ac1e-3af967e7a2eb@github.com>
Message-ID: <OqBkxf-doBokpRtriKzAFQ8mqKeKkIcPPrI69sa5evg=.872eeea8-83d2-49f1-be44-0602eeb15b4d@github.com>

On Wed, 20 Apr 2022 00:59:26 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> This changeset backports the fix for 8201793 to jdk8u-ri.
> 
> With this change, `java.lang.ref.Reference::clone` method always throws `CloneNotSupportedException`.

Looks good.   The only diff from the original fix is `@since 8` as this is for 8u RI.

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

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk8u-ri/pull/6

From kbarrett at openjdk.java.net  Wed Apr 20 05:05:49 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 20 Apr 2022 05:05:49 GMT
Subject: [jdk8u-ri] RFR: 8201793: (ref) Reference object should not support
 cloning
In-Reply-To: <K_wvGr0wKQKsVQzfYQu-5ehjn-BHPCDrx3EQ2ZAlhX0=.1504b393-7438-499d-ac1e-3af967e7a2eb@github.com>
References: <K_wvGr0wKQKsVQzfYQu-5ehjn-BHPCDrx3EQ2ZAlhX0=.1504b393-7438-499d-ac1e-3af967e7a2eb@github.com>
Message-ID: <8JItXeXJcZvkXnm9XPgr3K_ZtgZcgQcgiUIn-AFQM1g=.e1328ba1-3da7-4659-ac24-1aed17de4798@github.com>

On Wed, 20 Apr 2022 00:59:26 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> This changeset backports the fix for 8201793 to jdk8u-ri.
> 
> With this change, `java.lang.ref.Reference::clone` method always throws `CloneNotSupportedException`.

Looks good.

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

Marked as reviewed by kbarrett (no project role).

PR: https://git.openjdk.java.net/jdk8u-ri/pull/6

From kbarrett at openjdk.java.net  Wed Apr 20 05:09:34 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 20 Apr 2022 05:09:34 GMT
Subject: [jdk8u-ri] RFR: 8175797: (ref) Reference::enqueue method should
 clear the reference object before enqueuing
In-Reply-To: <1V-62a8ZWOHk65p2xhwZlqOu5RqTADUW-WCLXUTxVC4=.1a67a810-a015-4620-be8a-820858c3dbe5@github.com>
References: <1V-62a8ZWOHk65p2xhwZlqOu5RqTADUW-WCLXUTxVC4=.1a67a810-a015-4620-be8a-820858c3dbe5@github.com>
Message-ID: <DzaaRYIRdJtxJ3HPt40LkTPrFlxBweKIOk986NPfxJA=.bf3afdec-5bda-45e3-b749-be8e1617eb9b@github.com>

On Wed, 20 Apr 2022 00:15:58 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> These changes backport the following fixes to jdk8u-ri:
> 
> - 8175797: (ref) Reference::enqueue method should clear the reference object before enqueuing
> - 8178832: (ref) jdk.lang.ref.disableClearBeforeEnqueue property is ignored
> - 8193780: (ref) Remove the undocumented jdk.lang.ref.disableClearBeforeEnqueue system property
> 
> With this fix, the enqueue method clears the reference before enqueuing it to the registered queue.
> 
> The backport of changes to the file _jdk/test/java/lang/ref/ReferenceEnqueue.java_ needed some manual adjustment. Apart from that,  backport of changes to the rest of the files are exact match with the original fixes.

Looks good.

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

Marked as reviewed by kbarrett (no project role).

PR: https://git.openjdk.java.net/jdk8u-ri/pull/5

From kbarrett at openjdk.java.net  Wed Apr 20 05:21:25 2022
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 20 Apr 2022 05:21:25 GMT
Subject: [jdk8u-ri] RFR: 8071507: (ref) Clear phantom reference as soft and
 weak references do
In-Reply-To: <ikjRTxf579yNfmrhx-6FN8nX4HwtBQw2jNEWmNsr98I=.de0ba7bc-ebd8-49c5-baba-2dec83c93b64@github.com>
References: <ikjRTxf579yNfmrhx-6FN8nX4HwtBQw2jNEWmNsr98I=.de0ba7bc-ebd8-49c5-baba-2dec83c93b64@github.com>
Message-ID: <PWMe7yYIlR5uq902EzZWZB8Q1dM-Me77hP96qblnMe0=.ada6bb66-8539-453a-b3b0-266564e9fea9@github.com>

On Tue, 19 Apr 2022 18:01:20 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> These changes backport the following fixes to jdk8u-ri:
> - 8071507: (ref) Clear phantom reference as soft and weak references do
> - 8143847: Remove REF_CLEANER reference category
> 
> With these changes, phantom references are automatically cleared by the garbage collector as soft and weak references.

Looks good.

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

Marked as reviewed by kbarrett (no project role).

PR: https://git.openjdk.java.net/jdk8u-ri/pull/4

From dongbohe at openjdk.java.net  Wed Apr 20 09:24:11 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Wed, 20 Apr 2022 09:24:11 GMT
Subject: [jdk8u-dev] RFR: 8233019: java.lang.Class.isPrimitive() (C1) returns
 wrong result if Klass* is aligned to 32bit
Message-ID: <TLsDcS6zsjACyQ9UNv1I4QPKaRlxAqoChoaTAwHxVjs=.06e2a15e-7990-48c5-ac40-4c84ccd1d169@github.com>

Hi,

I would like to backport this as follow up of [JDK-8150669](https://bugs.openjdk.java.net/browse/JDK-8150669)
This resolves the corner case that leads to incorrect result for C1 intrinsic,

Original patch for 11u: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/e1b6631cbd2f 
Patch does not apply cleanly to 8u: arm and s390 ports are not there and we don?t have c1 compiler support in ppc port in 8u.

Performed full jtreg test both on x86_64-linux-gnu and aarch64-linux-gnu platforms. 
(I made this PR on behalf of fyang)

Thanks,
hedongbo

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

Depends on: https://git.openjdk.java.net/jdk8u-dev/pull/37

Commit messages:
 - b67ca938f37f952e53f73d2e0b8ebcaf96139fda

Changes: https://git.openjdk.java.net/jdk8u-dev/pull/43/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=43&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8233019
  Stats: 36 lines in 5 files changed: 34 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/43.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/43/head:pull/43

PR: https://git.openjdk.java.net/jdk8u-dev/pull/43

From gnu.andrew at redhat.com  Wed Apr 20 12:34:34 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 20 Apr 2022 13:34:34 +0100
Subject: 8u332 Release
Message-ID: <Yl/92k7+fnwtzmuo@hex.discworld.ac.uk>

I have pushed jdk8u332-b09 with the April security updates to the
monojdk8u repository:

https://hg.openjdk.java.net/jdk8u/monojdk8u/

I will tag this as jdk8u332-ga once we have confirmation it has
passed 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 akasko at openjdk.java.net  Wed Apr 20 21:01:13 2022
From: akasko at openjdk.java.net (Alex Kasko)
Date: Wed, 20 Apr 2022 21:01:13 GMT
Subject: [jdk8u-dev] RFR: 8146215: (fs)
 java/nio/file/Files/probeContentType/Basic.java failed frequently on
 Solaris-sparc with Unexpected type: text/plain
Message-ID: <3rS5sGUvp1NafbhBEtFzkVNzTlGsytk9XEnDGqSHRqU=.82f5f510-7b89-462e-aa5b-782d52351a7c@github.com>

Backport of a NIO fix.

Original commit on jdk9: https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/44bb7c7997ca

Patch does not apply cleanly, differences from original commit: paths reshuffling, copyright year in
AbstractFileTypeDetector.java, list of issues numbers changed and checkOSXContentTypes() function removed in Basic.java test.

Related mailing list threads:

https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/012050.html
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-October/014321.html

Testing:

 - [x] jtreg:java/nio/file/Files/
 - [x] jtreg:java/net/URLConnection/

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

Commit messages:
 - 8146215: (fs) java/nio/file/Files/probeContentType/Basic.java failed frequently on Solaris-sparc with Unexpected type: text/plain

Changes: https://git.openjdk.java.net/jdk8u-dev/pull/44/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=44&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8146215
  Stats: 90 lines in 3 files changed: 40 ins; 37 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/44.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/44/head:pull/44

PR: https://git.openjdk.java.net/jdk8u-dev/pull/44

From akasko at openjdk.java.net  Wed Apr 20 21:17:04 2022
From: akasko at openjdk.java.net (Alex Kasko)
Date: Wed, 20 Apr 2022 21:17:04 GMT
Subject: [jdk8u-dev] RFR: 8280963: Incorrect PrintFlags formatting on Windows
Message-ID: <YVGFkcRvnEe4NsJubRYIMXztmWBAXS7lyW3H2cRuin4=.3238d04a-c453-49f2-b50d-ab7005adfd96@github.com>

A fix to 8u-only Windows-specific problem with -XX:+PrintFlags* output.

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

The problem was fixed in jdk9 as part of [JDK-8042893](https://bugs.openjdk.java.net/browse/JDK-8042893), but this [jdk9 change](https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/115188e14c15) doesn't look like a good candidate for the 8u backport according to [8u Best Practices](https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/012002.html). 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](https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/115188e14c15#l53.1).

Mailing list review: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-February/014532.html

Testing:

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

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

Commit messages:
 - fix line endings in test
 - 8280963: Incorrect PrintFlags formatting on Windows

Changes: https://git.openjdk.java.net/jdk8u-dev/pull/45/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=45&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8280963
  Stats: 53 lines in 2 files changed: 50 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/45.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/45/head:pull/45

PR: https://git.openjdk.java.net/jdk8u-dev/pull/45

From iris at openjdk.java.net  Wed Apr 20 21:37:40 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 20 Apr 2022 21:37:40 GMT
Subject: [jdk8u-ri] RFR: 8071507: (ref) Clear phantom reference as soft and
 weak references do
In-Reply-To: <ikjRTxf579yNfmrhx-6FN8nX4HwtBQw2jNEWmNsr98I=.de0ba7bc-ebd8-49c5-baba-2dec83c93b64@github.com>
References: <ikjRTxf579yNfmrhx-6FN8nX4HwtBQw2jNEWmNsr98I=.de0ba7bc-ebd8-49c5-baba-2dec83c93b64@github.com>
Message-ID: <OR32FzP8sZ2GYHqWEoLz11gNOdhGgbyDnZ6VS7p4_DM=.c720b1f2-2054-466b-99db-28f1a9ba3c92@github.com>

On Tue, 19 Apr 2022 18:01:20 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> These changes backport the following fixes to jdk8u-ri:
> - 8071507: (ref) Clear phantom reference as soft and weak references do
> - 8143847: Remove REF_CLEANER reference category
> 
> With these changes, phantom references are automatically cleared by the garbage collector as soft and weak references.

jdk/src/share/classes/java/lang/ref/package.html line 49:

> 47: for implementing canonicalizing mappings that do not prevent their keys (or
> 48: values) from being reclaimed, and phantom references are for scheduling
> 49: scheduling post-mortem cleanup actions.

Is the word "scheduling" repeated at both the end of unchanged line 48 and the beginning of new line 49?

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/4

From mchung at openjdk.java.net  Wed Apr 20 23:52:34 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 20 Apr 2022 23:52:34 GMT
Subject: [jdk8u-ri] RFR: 8071507: (ref) Clear phantom reference as soft and
 weak references do
In-Reply-To: <OR32FzP8sZ2GYHqWEoLz11gNOdhGgbyDnZ6VS7p4_DM=.c720b1f2-2054-466b-99db-28f1a9ba3c92@github.com>
References: <ikjRTxf579yNfmrhx-6FN8nX4HwtBQw2jNEWmNsr98I=.de0ba7bc-ebd8-49c5-baba-2dec83c93b64@github.com>
 <OR32FzP8sZ2GYHqWEoLz11gNOdhGgbyDnZ6VS7p4_DM=.c720b1f2-2054-466b-99db-28f1a9ba3c92@github.com>
Message-ID: <oMctO2qvU9xVPqdVLV9dfxrFQwa-QkTvHfJ0EZvEsnQ=.89d80c0e-7fb3-4c05-a6d7-dc28bfa3dc89@github.com>

On Wed, 20 Apr 2022 21:34:36 GMT, Iris Clark <iris at openjdk.org> wrote:

>> These changes backport the following fixes to jdk8u-ri:
>> - 8071507: (ref) Clear phantom reference as soft and weak references do
>> - 8143847: Remove REF_CLEANER reference category
>> 
>> With these changes, phantom references are automatically cleared by the garbage collector as soft and weak references.
>
> jdk/src/share/classes/java/lang/ref/package.html line 49:
> 
>> 47: for implementing canonicalizing mappings that do not prevent their keys (or
>> 48: values) from being reclaimed, and phantom references are for scheduling
>> 49: scheduling post-mortem cleanup actions.
> 
> Is the word "scheduling" repeated at both the end of unchanged line 48 and the beginning of new line 49?

Good catch!   Both Kim and I missed this.

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/4

From dongbohe at openjdk.java.net  Thu Apr 21 02:41:35 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Thu, 21 Apr 2022 02:41:35 GMT
Subject: [jdk8u-dev] RFR: 8202142: jfr/event/io/TestInstrumentation is
 unstable
In-Reply-To: <QekQtfc-1woi7LRM-mI5O-Pff5zYGEpTkKpLGHhPiv8=.37232abb-090d-45ee-9426-42eeaf0ee5d5@github.com>
References: <i99997MY_arGM_fjApfVzdmaew4SgkesOguSNb42mwE=.e9ce1b49-3f94-45fb-a68c-6d71f60002d8@github.com>
 <QekQtfc-1woi7LRM-mI5O-Pff5zYGEpTkKpLGHhPiv8=.37232abb-090d-45ee-9426-42eeaf0ee5d5@github.com>
Message-ID: <PeN9CCqaOiPjNwk_S--NZ6rrkR-bCZfbgFp28Kb9vlY=.6b7e0fb9-ed32-4911-b0bb-9fdcf746cea8@github.com>

On Thu, 17 Mar 2022 16:19:37 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Hi,
>> 
>> This PR has been reviewed by Paul before move to github: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-January/014489.html
>> 
>> Thanks,
>> hedongbo
>
> I think should backport [8223396](https://bugs.openjdk.java.net/browse/JDK-8223396) first to eliminate another out-of-order backport.

@zhengyu123 Could you please take another look?

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/10

From jnordstrom at openjdk.java.net  Thu Apr 21 06:52:35 2022
From: jnordstrom at openjdk.java.net (Joakim =?UTF-8?B?Tm9yZHN0csO2bQ==?=)
Date: Thu, 21 Apr 2022 06:52:35 GMT
Subject: [jdk8u-dev] RFR: 8278138: OpenJDK8 fails to start on Windows 8.1
 after upgrading compiler to VS2017 [v2]
In-Reply-To: <hIb2H4HpdR8n2Xydq-jAwU1kXD_wSNwt6SkPuAN2Blg=.7dcd092d-bf4a-4811-ae3a-64fc6f596a74@github.com>
References: <EY6NkB82WC9qCoUsPJ7dIR5UFKZjdL0hmmjGtvXM8Fw=.aa052a7d-07e8-49c9-bcb7-da6041f567b7@github.com>
 <hIb2H4HpdR8n2Xydq-jAwU1kXD_wSNwt6SkPuAN2Blg=.7dcd092d-bf4a-4811-ae3a-64fc6f596a74@github.com>
Message-ID: <Cng3mFfX_KY0kM-LmDUvbmDR8P5cz6klMGwMrt0ZUBA=.5c6e63ca-0018-4413-8d52-9c921fc6ac9e@github.com>

On Wed, 13 Apr 2022 08:27:13 GMT, ktakakuri <duke at openjdk.java.net> wrote:

>> Could you please review the 8278138 bug fixes?
>> 
>> This problem is caused by missing DLL's which vcruntime140.dll depends on.
>> I think it is needed to copy the missing DLL's into jdk/bin as like jdk/jre/bin.
>> I fix to copy api-ms-win-*.dll files to jdk/bin when images directory is created.
>
> ktakakuri has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update jdk/make/Images.gmk
>   
>   Co-authored-by: Joakim Nordstr?m <joakim.nordstrom at oracle.com>

Changes looks good to me!

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

Marked as reviewed by jnordstrom (no project role).

PR: https://git.openjdk.java.net/jdk8u-dev/pull/25

From erikj at openjdk.java.net  Thu Apr 21 13:06:38 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 21 Apr 2022 13:06:38 GMT
Subject: [jdk8u-dev] RFR: 8278138: OpenJDK8 fails to start on Windows 8.1
 after upgrading compiler to VS2017 [v2]
In-Reply-To: <hIb2H4HpdR8n2Xydq-jAwU1kXD_wSNwt6SkPuAN2Blg=.7dcd092d-bf4a-4811-ae3a-64fc6f596a74@github.com>
References: <EY6NkB82WC9qCoUsPJ7dIR5UFKZjdL0hmmjGtvXM8Fw=.aa052a7d-07e8-49c9-bcb7-da6041f567b7@github.com>
 <hIb2H4HpdR8n2Xydq-jAwU1kXD_wSNwt6SkPuAN2Blg=.7dcd092d-bf4a-4811-ae3a-64fc6f596a74@github.com>
Message-ID: <7R5mxoO1jxxf-q9-Ji6b1rKg9cP6zAm5XPRoa94r2Bw=.27a449bd-c532-43e6-80eb-8384562754c3@github.com>

On Wed, 13 Apr 2022 08:27:13 GMT, ktakakuri <duke at openjdk.java.net> wrote:

>> Could you please review the 8278138 bug fixes?
>> 
>> This problem is caused by missing DLL's which vcruntime140.dll depends on.
>> I think it is needed to copy the missing DLL's into jdk/bin as like jdk/jre/bin.
>> I fix to copy api-ms-win-*.dll files to jdk/bin when images directory is created.
>
> ktakakuri has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update jdk/make/Images.gmk
>   
>   Co-authored-by: Joakim Nordstr?m <joakim.nordstrom at oracle.com>

Marked as reviewed by erikj (Reviewer).

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/25

From poonam at openjdk.java.net  Thu Apr 21 16:05:25 2022
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Thu, 21 Apr 2022 16:05:25 GMT
Subject: [jdk8u-ri] RFR: 8071507: (ref) Clear phantom reference as soft and
 weak references do [v2]
In-Reply-To: <ikjRTxf579yNfmrhx-6FN8nX4HwtBQw2jNEWmNsr98I=.de0ba7bc-ebd8-49c5-baba-2dec83c93b64@github.com>
References: <ikjRTxf579yNfmrhx-6FN8nX4HwtBQw2jNEWmNsr98I=.de0ba7bc-ebd8-49c5-baba-2dec83c93b64@github.com>
Message-ID: <T6GQa0MGVpYjsxrymTvBDPsS5y8Z6ZmV-kJrzgrkoRE=.8d38b502-0bf5-437a-ae4a-41ea27b0643a@github.com>

> These changes backport the following fixes to jdk8u-ri:
> - 8071507: (ref) Clear phantom reference as soft and weak references do
> - 8143847: Remove REF_CLEANER reference category
> 
> With these changes, phantom references are automatically cleared by the garbage collector as soft and weak references.

Poonam Bajaj has updated the pull request incrementally with one additional commit since the last revision:

  Corrected documentation in package.html

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

Changes:
  - all: https://git.openjdk.java.net/jdk8u-ri/pull/4/files
  - new: https://git.openjdk.java.net/jdk8u-ri/pull/4/files/8bee95e2..35aa32d0

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

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/4

From poonam at openjdk.java.net  Thu Apr 21 16:05:26 2022
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Thu, 21 Apr 2022 16:05:26 GMT
Subject: [jdk8u-ri] RFR: 8071507: (ref) Clear phantom reference as soft and
 weak references do [v2]
In-Reply-To: <oMctO2qvU9xVPqdVLV9dfxrFQwa-QkTvHfJ0EZvEsnQ=.89d80c0e-7fb3-4c05-a6d7-dc28bfa3dc89@github.com>
References: <ikjRTxf579yNfmrhx-6FN8nX4HwtBQw2jNEWmNsr98I=.de0ba7bc-ebd8-49c5-baba-2dec83c93b64@github.com>
 <OR32FzP8sZ2GYHqWEoLz11gNOdhGgbyDnZ6VS7p4_DM=.c720b1f2-2054-466b-99db-28f1a9ba3c92@github.com>
 <oMctO2qvU9xVPqdVLV9dfxrFQwa-QkTvHfJ0EZvEsnQ=.89d80c0e-7fb3-4c05-a6d7-dc28bfa3dc89@github.com>
Message-ID: <NLSjXC98KcffWIa_sWOI8tWaMaQDo7yLb-_dp7M7U2o=.04c4b33d-885e-40c0-9f65-8913a57cea50@github.com>

On Wed, 20 Apr 2022 23:49:28 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> jdk/src/share/classes/java/lang/ref/package.html line 49:
>> 
>>> 47: for implementing canonicalizing mappings that do not prevent their keys (or
>>> 48: values) from being reclaimed, and phantom references are for scheduling
>>> 49: scheduling post-mortem cleanup actions.
>> 
>> Is the word "scheduling" repeated at both the end of unchanged line 48 and the beginning of new line 49?
>
> Good catch!   Both Kim and I missed this.

Thanks Iris. Removed the duplicate "scheduling".

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/4

From t.glaser at tarent.de  Thu Apr 21 19:34:57 2022
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Thu, 21 Apr 2022 21:34:57 +0200 (CEST)
Subject: 8u332 Release
In-Reply-To: <Yl/92k7+fnwtzmuo@hex.discworld.ac.uk>
References: <Yl/92k7+fnwtzmuo@hex.discworld.ac.uk>
Message-ID: <b841e884-142f-aeee-8842-18805412d3c@tarent.de>

Hi list(s),

On Wed, 20 Apr 2022, Andrew Hughes wrote:

> I have pushed jdk8u332-b09 with the April security updates to the
> monojdk8u repository:

any idea when the aarch64-shenandoah-jdk8u332-* will be available?

Thanks in advance,
//mirabilos (for Debian)
-- 
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 mchung at openjdk.java.net  Thu Apr 21 20:33:40 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 21 Apr 2022 20:33:40 GMT
Subject: [jdk8u-ri] RFR: 8201793: (ref) Reference object should not support
 cloning
In-Reply-To: <K_wvGr0wKQKsVQzfYQu-5ehjn-BHPCDrx3EQ2ZAlhX0=.1504b393-7438-499d-ac1e-3af967e7a2eb@github.com>
References: <K_wvGr0wKQKsVQzfYQu-5ehjn-BHPCDrx3EQ2ZAlhX0=.1504b393-7438-499d-ac1e-3af967e7a2eb@github.com>
Message-ID: <E_2_Y9oCqBYKlHn8V3JEXkdeimWqDnO07VudLXiBUas=.da0d0ad8-197b-4211-8478-d709d7296e0b@github.com>

On Wed, 20 Apr 2022 00:59:26 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> This changeset backports the fix for 8201793 to jdk8u-ri.
> 
> With this change, `java.lang.ref.Reference::clone` method always throws `CloneNotSupportedException`.

jdk/src/share/classes/java/lang/ref/Reference.java line 255:

> 253:      * @throws  CloneNotSupportedException always
> 254:      *
> 255:      * @since 8

This method is only present in JDK 8u42 (RI) and 8u352 and later releases.  It's not in existing 8u releases >= 8u45 and < 8u352.   Neither 8 or 8u42 would cause confusion.  A suggestion is to use `@apiNote` to indicate which MR this method is defined:


@apiNote This method is defined in Java SE 8 Maintenance Release 4.

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/6

From t.glaser at tarent.de  Thu Apr 21 20:48:02 2022
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Thu, 21 Apr 2022 22:48:02 +0200 (CEST)
Subject: encoding fixes
Message-ID: <2a068b-b8a9-f33d-be22-ebacaa2dc42a@tarent.de>

Hi,

I?ve seen the aarch64-shenandoah 323 carry the following fix,
which probably should be globally applied to fix the encoding:

--- xjdk-any.tar.gz/THIRD_PARTY_README	2021-09-28 15:30:27.000000000 +0200
+++ xjdk-aarch64.tar.gz/THIRD_PARTY_README	2022-01-20 16:51:28.000000000 +0100
@@ -7,7 +7,7 @@ OpenJDK 8.
 
 --- begin of LICENSE ---
 
-Copyright (c) 2000-2011 France T??l??com
+Copyright (c) 2000-2011 France T?l?com
 All rights reserved.
 
 Redistribution and use in source and binary forms, with or without
@@ -1035,7 +1035,7 @@ JRE 8, JDK 8, and OpenJDK 8.
 --- begin of LICENSE ---
 
 Copyright notice
-Copyright ?? 2011 Ecma International
+Copyright ? 2011 Ecma International
 Ecma International
 Rue du Rhone 114
 CH-1204 Geneva
@@ -2527,16 +2527,16 @@ which may be included with JRE 8, JDK 8,
 Unicode Terms of Use
 
 For the general privacy policy governing access to this site, see the Unicode
-Privacy Policy. For trademark usage, see the Unicode?? Consortium Name and
+Privacy Policy. For trademark usage, see the Unicode? Consortium Name and
 Trademark Usage Policy.
 
 A. Unicode Copyright.
-   1. Copyright ?? 1991-2013 Unicode, Inc. All rights reserved.
+   1. Copyright ? 1991-2013 Unicode, Inc. All rights reserved.
 
    2. Certain documents and files on this website contain a legend indicating
       that "Modification is permitted." Any person is hereby authorized,
       without fee, to modify such documents and files to create derivative
-      works conforming to the Unicode?? Standard, subject to Terms and
+      works conforming to the Unicode? Standard, subject to Terms and
       Conditions herein.
 
     3. Any person is hereby authorized, without fee, to view, use, reproduce,
@@ -2602,14 +2602,14 @@ D. Waiver of Damages. In no event shall
 
 E.Trademarks & Logos.
    1. The Unicode Word Mark and the Unicode Logo are trademarks of Unicode,
-      Inc.  ???The Unicode Consortium??? and ???Unicode, Inc.??? are trade names of
+      Inc.  ?The Unicode Consortium? and ?Unicode, Inc.? are trade names of
       Unicode, Inc.  Use of the information and materials found on this
-      website indicates your acknowledgement of Unicode, Inc.???s exclusive
+      website indicates your acknowledgement of Unicode, Inc.?s exclusive
       worldwide rights in the Unicode Word Mark, the Unicode Logo, and the
       Unicode trade names.
 
-   2. The Unicode Consortium Name and Trademark Usage Policy (???Trademark
-      Policy???) are incorporated herein by reference and you agree to abide by
+   2. The Unicode Consortium Name and Trademark Usage Policy (?Trademark
+      Policy?) are incorporated herein by reference and you agree to abide by
       the provisions of the Trademark Policy, which may be changed from time
       to time in the sole discretion of Unicode, Inc.
 
@@ -2632,12 +2632,12 @@ Miscellaneous.
 
    2. Modification by Unicode.  Unicode shall have the right to modify this
       Agreement at any time by posting it to this site. The user may not
-      assign any part of this Agreement without Unicode???s prior written
+      assign any part of this Agreement without Unicode?s prior written
       consent.
 
    3. Taxes. The user agrees to pay any taxes arising from access to this
       website or use of the information herein, except for those based on
-      Unicode???s net income.
+      Unicode?s net income.
 
    4. Severability.  If any provision of this Agreement is declared invalid or
       unenforceable, the remaining provisions of this Agreement shall remain
@@ -2666,7 +2666,7 @@ SOFTWARE.
 
 COPYRIGHT AND PERMISSION NOTICE
 
-Copyright ?? 1991-2012 Unicode, Inc. All rights reserved. Distributed under the
+Copyright ? 1991-2012 Unicode, Inc. All rights reserved. Distributed under the
 Terms of Use in http://www.unicode.org/copyright.html.
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
--- xjdk-any.tar.gz/corba/THIRD_PARTY_README	2021-09-28 15:30:27.000000000 +0200
+++ xjdk-aarch64.tar.gz/corba/THIRD_PARTY_README	2022-01-20 16:51:28.000000000 +0100
@@ -7,7 +7,7 @@ OpenJDK 8.
 
 --- begin of LICENSE ---
 
-Copyright (c) 2000-2011 France T??l??com
+Copyright (c) 2000-2011 France T?l?com
 All rights reserved.
 
 Redistribution and use in source and binary forms, with or without
@@ -1035,7 +1035,7 @@ JRE 8, JDK 8, and OpenJDK 8.
 --- begin of LICENSE ---
 
 Copyright notice
-Copyright ?? 2011 Ecma International
+Copyright ? 2011 Ecma International
 Ecma International
 Rue du Rhone 114
 CH-1204 Geneva
@@ -2527,16 +2527,16 @@ which may be included with JRE 8, JDK 8,
 Unicode Terms of Use
 
 For the general privacy policy governing access to this site, see the Unicode
-Privacy Policy. For trademark usage, see the Unicode?? Consortium Name and
+Privacy Policy. For trademark usage, see the Unicode? Consortium Name and
 Trademark Usage Policy.
 
 A. Unicode Copyright.
-   1. Copyright ?? 1991-2013 Unicode, Inc. All rights reserved.
+   1. Copyright ? 1991-2013 Unicode, Inc. All rights reserved.
 
    2. Certain documents and files on this website contain a legend indicating
       that "Modification is permitted." Any person is hereby authorized,
       without fee, to modify such documents and files to create derivative
-      works conforming to the Unicode?? Standard, subject to Terms and
+      works conforming to the Unicode? Standard, subject to Terms and
       Conditions herein.
 
     3. Any person is hereby authorized, without fee, to view, use, reproduce,
@@ -2602,14 +2602,14 @@ D. Waiver of Damages. In no event shall
 
 E.Trademarks & Logos.
    1. The Unicode Word Mark and the Unicode Logo are trademarks of Unicode,
-      Inc.  ???The Unicode Consortium??? and ???Unicode, Inc.??? are trade names of
+      Inc.  ?The Unicode Consortium? and ?Unicode, Inc.? are trade names of
       Unicode, Inc.  Use of the information and materials found on this
-      website indicates your acknowledgement of Unicode, Inc.???s exclusive
+      website indicates your acknowledgement of Unicode, Inc.?s exclusive
       worldwide rights in the Unicode Word Mark, the Unicode Logo, and the
       Unicode trade names.
 
-   2. The Unicode Consortium Name and Trademark Usage Policy (???Trademark
-      Policy???) are incorporated herein by reference and you agree to abide by
+   2. The Unicode Consortium Name and Trademark Usage Policy (?Trademark
+      Policy?) are incorporated herein by reference and you agree to abide by
       the provisions of the Trademark Policy, which may be changed from time
       to time in the sole discretion of Unicode, Inc.
 
@@ -2632,12 +2632,12 @@ Miscellaneous.
 
    2. Modification by Unicode.  Unicode shall have the right to modify this
       Agreement at any time by posting it to this site. The user may not
-      assign any part of this Agreement without Unicode???s prior written
+      assign any part of this Agreement without Unicode?s prior written
       consent.
 
    3. Taxes. The user agrees to pay any taxes arising from access to this
       website or use of the information herein, except for those based on
-      Unicode???s net income.
+      Unicode?s net income.
 
    4. Severability.  If any provision of this Agreement is declared invalid or
       unenforceable, the remaining provisions of this Agreement shall remain
@@ -2666,7 +2666,7 @@ SOFTWARE.
 
 COPYRIGHT AND PERMISSION NOTICE
 
-Copyright ?? 1991-2012 Unicode, Inc. All rights reserved. Distributed under the
+Copyright ? 1991-2012 Unicode, Inc. All rights reserved. Distributed under the
 Terms of Use in http://www.unicode.org/copyright.html.
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
--- xjdk-any.tar.gz/jaxp/THIRD_PARTY_README	2021-09-28 15:30:27.000000000 +0200
+++ xjdk-aarch64.tar.gz/jaxp/THIRD_PARTY_README	2022-01-20 16:51:28.000000000 +0100
@@ -7,7 +7,7 @@ OpenJDK 8.
 
 --- begin of LICENSE ---
 
-Copyright (c) 2000-2011 France T??l??com
+Copyright (c) 2000-2011 France T?l?com
 All rights reserved.
 
 Redistribution and use in source and binary forms, with or without
@@ -1035,7 +1035,7 @@ JRE 8, JDK 8, and OpenJDK 8.
 --- begin of LICENSE ---
 
 Copyright notice
-Copyright ?? 2011 Ecma International
+Copyright ? 2011 Ecma International
 Ecma International
 Rue du Rhone 114
 CH-1204 Geneva
@@ -2527,16 +2527,16 @@ which may be included with JRE 8, JDK 8,
 Unicode Terms of Use
 
 For the general privacy policy governing access to this site, see the Unicode
-Privacy Policy. For trademark usage, see the Unicode?? Consortium Name and
+Privacy Policy. For trademark usage, see the Unicode? Consortium Name and
 Trademark Usage Policy.
 
 A. Unicode Copyright.
-   1. Copyright ?? 1991-2013 Unicode, Inc. All rights reserved.
+   1. Copyright ? 1991-2013 Unicode, Inc. All rights reserved.
 
    2. Certain documents and files on this website contain a legend indicating
       that "Modification is permitted." Any person is hereby authorized,
       without fee, to modify such documents and files to create derivative
-      works conforming to the Unicode?? Standard, subject to Terms and
+      works conforming to the Unicode? Standard, subject to Terms and
       Conditions herein.
 
     3. Any person is hereby authorized, without fee, to view, use, reproduce,
@@ -2602,14 +2602,14 @@ D. Waiver of Damages. In no event shall
 
 E.Trademarks & Logos.
    1. The Unicode Word Mark and the Unicode Logo are trademarks of Unicode,
-      Inc.  ???The Unicode Consortium??? and ???Unicode, Inc.??? are trade names of
+      Inc.  ?The Unicode Consortium? and ?Unicode, Inc.? are trade names of
       Unicode, Inc.  Use of the information and materials found on this
-      website indicates your acknowledgement of Unicode, Inc.???s exclusive
+      website indicates your acknowledgement of Unicode, Inc.?s exclusive
       worldwide rights in the Unicode Word Mark, the Unicode Logo, and the
       Unicode trade names.
 
-   2. The Unicode Consortium Name and Trademark Usage Policy (???Trademark
-      Policy???) are incorporated herein by reference and you agree to abide by
+   2. The Unicode Consortium Name and Trademark Usage Policy (?Trademark
+      Policy?) are incorporated herein by reference and you agree to abide by
       the provisions of the Trademark Policy, which may be changed from time
       to time in the sole discretion of Unicode, Inc.
 
@@ -2632,12 +2632,12 @@ Miscellaneous.
 
    2. Modification by Unicode.  Unicode shall have the right to modify this
       Agreement at any time by posting it to this site. The user may not
-      assign any part of this Agreement without Unicode???s prior written
+      assign any part of this Agreement without Unicode?s prior written
       consent.
 
    3. Taxes. The user agrees to pay any taxes arising from access to this
       website or use of the information herein, except for those based on
-      Unicode???s net income.
+      Unicode?s net income.
 
    4. Severability.  If any provision of this Agreement is declared invalid or
       unenforceable, the remaining provisions of this Agreement shall remain
@@ -2666,7 +2666,7 @@ SOFTWARE.
 
 COPYRIGHT AND PERMISSION NOTICE
 
-Copyright ?? 1991-2012 Unicode, Inc. All rights reserved. Distributed under the
+Copyright ? 1991-2012 Unicode, Inc. All rights reserved. Distributed under the
 Terms of Use in http://www.unicode.org/copyright.html.
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
--- xjdk-any.tar.gz/jaxws/THIRD_PARTY_README	2021-09-28 15:30:27.000000000 +0200
+++ xjdk-aarch64.tar.gz/jaxws/THIRD_PARTY_README	2022-01-20 16:51:28.000000000 +0100
@@ -7,7 +7,7 @@ OpenJDK 8.
 
 --- begin of LICENSE ---
 
-Copyright (c) 2000-2011 France T??l??com
+Copyright (c) 2000-2011 France T?l?com
 All rights reserved.
 
 Redistribution and use in source and binary forms, with or without
@@ -1035,7 +1035,7 @@ JRE 8, JDK 8, and OpenJDK 8.
 --- begin of LICENSE ---
 
 Copyright notice
-Copyright ?? 2011 Ecma International
+Copyright ? 2011 Ecma International
 Ecma International
 Rue du Rhone 114
 CH-1204 Geneva
@@ -2527,16 +2527,16 @@ which may be included with JRE 8, JDK 8,
 Unicode Terms of Use
 
 For the general privacy policy governing access to this site, see the Unicode
-Privacy Policy. For trademark usage, see the Unicode?? Consortium Name and
+Privacy Policy. For trademark usage, see the Unicode? Consortium Name and
 Trademark Usage Policy.
 
 A. Unicode Copyright.
-   1. Copyright ?? 1991-2013 Unicode, Inc. All rights reserved.
+   1. Copyright ? 1991-2013 Unicode, Inc. All rights reserved.
 
    2. Certain documents and files on this website contain a legend indicating
       that "Modification is permitted." Any person is hereby authorized,
       without fee, to modify such documents and files to create derivative
-      works conforming to the Unicode?? Standard, subject to Terms and
+      works conforming to the Unicode? Standard, subject to Terms and
       Conditions herein.
 
     3. Any person is hereby authorized, without fee, to view, use, reproduce,
@@ -2602,14 +2602,14 @@ D. Waiver of Damages. In no event shall
 
 E.Trademarks & Logos.
    1. The Unicode Word Mark and the Unicode Logo are trademarks of Unicode,
-      Inc.  ???The Unicode Consortium??? and ???Unicode, Inc.??? are trade names of
+      Inc.  ?The Unicode Consortium? and ?Unicode, Inc.? are trade names of
       Unicode, Inc.  Use of the information and materials found on this
-      website indicates your acknowledgement of Unicode, Inc.???s exclusive
+      website indicates your acknowledgement of Unicode, Inc.?s exclusive
       worldwide rights in the Unicode Word Mark, the Unicode Logo, and the
       Unicode trade names.
 
-   2. The Unicode Consortium Name and Trademark Usage Policy (???Trademark
-      Policy???) are incorporated herein by reference and you agree to abide by
+   2. The Unicode Consortium Name and Trademark Usage Policy (?Trademark
+      Policy?) are incorporated herein by reference and you agree to abide by
       the provisions of the Trademark Policy, which may be changed from time
       to time in the sole discretion of Unicode, Inc.
 
@@ -2632,12 +2632,12 @@ Miscellaneous.
 
    2. Modification by Unicode.  Unicode shall have the right to modify this
       Agreement at any time by posting it to this site. The user may not
-      assign any part of this Agreement without Unicode???s prior written
+      assign any part of this Agreement without Unicode?s prior written
       consent.
 
    3. Taxes. The user agrees to pay any taxes arising from access to this
       website or use of the information herein, except for those based on
-      Unicode???s net income.
+      Unicode?s net income.
 
    4. Severability.  If any provision of this Agreement is declared invalid or
       unenforceable, the remaining provisions of this Agreement shall remain
@@ -2666,7 +2666,7 @@ SOFTWARE.
 
 COPYRIGHT AND PERMISSION NOTICE
 
-Copyright ?? 1991-2012 Unicode, Inc. All rights reserved. Distributed under the
+Copyright ? 1991-2012 Unicode, Inc. All rights reserved. Distributed under the
 Terms of Use in http://www.unicode.org/copyright.html.
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
--- xjdk-any.tar.gz/jdk/THIRD_PARTY_README	2021-09-28 15:30:27.000000000 +0200
+++ xjdk-aarch64.tar.gz/jdk/THIRD_PARTY_README	2022-01-20 16:51:28.000000000 +0100
@@ -7,7 +7,7 @@ OpenJDK 8.
 
 --- begin of LICENSE ---
 
-Copyright (c) 2000-2011 France T??l??com
+Copyright (c) 2000-2011 France T?l?com
 All rights reserved.
 
 Redistribution and use in source and binary forms, with or without
@@ -1035,7 +1035,7 @@ JRE 8, JDK 8, and OpenJDK 8.
 --- begin of LICENSE ---
 
 Copyright notice
-Copyright ?? 2011 Ecma International
+Copyright ? 2011 Ecma International
 Ecma International
 Rue du Rhone 114
 CH-1204 Geneva
@@ -2527,16 +2527,16 @@ which may be included with JRE 8, JDK 8,
 Unicode Terms of Use
 
 For the general privacy policy governing access to this site, see the Unicode
-Privacy Policy. For trademark usage, see the Unicode?? Consortium Name and
+Privacy Policy. For trademark usage, see the Unicode? Consortium Name and
 Trademark Usage Policy.
 
 A. Unicode Copyright.
-   1. Copyright ?? 1991-2013 Unicode, Inc. All rights reserved.
+   1. Copyright ? 1991-2013 Unicode, Inc. All rights reserved.
 
    2. Certain documents and files on this website contain a legend indicating
       that "Modification is permitted." Any person is hereby authorized,
       without fee, to modify such documents and files to create derivative
-      works conforming to the Unicode?? Standard, subject to Terms and
+      works conforming to the Unicode? Standard, subject to Terms and
       Conditions herein.
 
     3. Any person is hereby authorized, without fee, to view, use, reproduce,
@@ -2602,14 +2602,14 @@ D. Waiver of Damages. In no event shall
 
 E.Trademarks & Logos.
    1. The Unicode Word Mark and the Unicode Logo are trademarks of Unicode,
-      Inc.  ???The Unicode Consortium??? and ???Unicode, Inc.??? are trade names of
+      Inc.  ?The Unicode Consortium? and ?Unicode, Inc.? are trade names of
       Unicode, Inc.  Use of the information and materials found on this
-      website indicates your acknowledgement of Unicode, Inc.???s exclusive
+      website indicates your acknowledgement of Unicode, Inc.?s exclusive
       worldwide rights in the Unicode Word Mark, the Unicode Logo, and the
       Unicode trade names.
 
-   2. The Unicode Consortium Name and Trademark Usage Policy (???Trademark
-      Policy???) are incorporated herein by reference and you agree to abide by
+   2. The Unicode Consortium Name and Trademark Usage Policy (?Trademark
+      Policy?) are incorporated herein by reference and you agree to abide by
       the provisions of the Trademark Policy, which may be changed from time
       to time in the sole discretion of Unicode, Inc.
 
@@ -2632,12 +2632,12 @@ Miscellaneous.
 
    2. Modification by Unicode.  Unicode shall have the right to modify this
       Agreement at any time by posting it to this site. The user may not
-      assign any part of this Agreement without Unicode???s prior written
+      assign any part of this Agreement without Unicode?s prior written
       consent.
 
    3. Taxes. The user agrees to pay any taxes arising from access to this
       website or use of the information herein, except for those based on
-      Unicode???s net income.
+      Unicode?s net income.
 
    4. Severability.  If any provision of this Agreement is declared invalid or
       unenforceable, the remaining provisions of this Agreement shall remain
@@ -2666,7 +2666,7 @@ SOFTWARE.
 
 COPYRIGHT AND PERMISSION NOTICE
 
-Copyright ?? 1991-2012 Unicode, Inc. All rights reserved. Distributed under the
+Copyright ? 1991-2012 Unicode, Inc. All rights reserved. Distributed under the
 Terms of Use in http://www.unicode.org/copyright.html.
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
--- xjdk-any.tar.gz/jdk/src/share/classes/java/lang/invoke/LambdaFormEditor.java	2021-09-28 15:30:27.000000000 +0200
+++ xjdk-aarch64.tar.gz/jdk/src/share/classes/java/lang/invoke/LambdaFormEditor.java	2022-01-20 16:51:28.000000000 +0100
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2014, 2017, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
--- xjdk-any.tar.gz/langtools/THIRD_PARTY_README	2021-09-28 15:30:27.000000000 +0200
+++ xjdk-aarch64.tar.gz/langtools/THIRD_PARTY_README	2022-01-20 16:51:28.000000000 +0100
@@ -7,7 +7,7 @@ OpenJDK 8.
 
 --- begin of LICENSE ---
 
-Copyright (c) 2000-2011 France T??l??com
+Copyright (c) 2000-2011 France T?l?com
 All rights reserved.
 
 Redistribution and use in source and binary forms, with or without
@@ -1035,7 +1035,7 @@ JRE 8, JDK 8, and OpenJDK 8.
 --- begin of LICENSE ---
 
 Copyright notice
-Copyright ?? 2011 Ecma International
+Copyright ? 2011 Ecma International
 Ecma International
 Rue du Rhone 114
 CH-1204 Geneva
@@ -2527,16 +2527,16 @@ which may be included with JRE 8, JDK 8,
 Unicode Terms of Use
 
 For the general privacy policy governing access to this site, see the Unicode
-Privacy Policy. For trademark usage, see the Unicode?? Consortium Name and
+Privacy Policy. For trademark usage, see the Unicode? Consortium Name and
 Trademark Usage Policy.
 
 A. Unicode Copyright.
-   1. Copyright ?? 1991-2013 Unicode, Inc. All rights reserved.
+   1. Copyright ? 1991-2013 Unicode, Inc. All rights reserved.
 
    2. Certain documents and files on this website contain a legend indicating
       that "Modification is permitted." Any person is hereby authorized,
       without fee, to modify such documents and files to create derivative
-      works conforming to the Unicode?? Standard, subject to Terms and
+      works conforming to the Unicode? Standard, subject to Terms and
       Conditions herein.
 
     3. Any person is hereby authorized, without fee, to view, use, reproduce,
@@ -2602,14 +2602,14 @@ D. Waiver of Damages. In no event shall
 
 E.Trademarks & Logos.
    1. The Unicode Word Mark and the Unicode Logo are trademarks of Unicode,
-      Inc.  ???The Unicode Consortium??? and ???Unicode, Inc.??? are trade names of
+      Inc.  ?The Unicode Consortium? and ?Unicode, Inc.? are trade names of
       Unicode, Inc.  Use of the information and materials found on this
-      website indicates your acknowledgement of Unicode, Inc.???s exclusive
+      website indicates your acknowledgement of Unicode, Inc.?s exclusive
       worldwide rights in the Unicode Word Mark, the Unicode Logo, and the
       Unicode trade names.
 
-   2. The Unicode Consortium Name and Trademark Usage Policy (???Trademark
-      Policy???) are incorporated herein by reference and you agree to abide by
+   2. The Unicode Consortium Name and Trademark Usage Policy (?Trademark
+      Policy?) are incorporated herein by reference and you agree to abide by
       the provisions of the Trademark Policy, which may be changed from time
       to time in the sole discretion of Unicode, Inc.
 
@@ -2632,12 +2632,12 @@ Miscellaneous.
 
    2. Modification by Unicode.  Unicode shall have the right to modify this
       Agreement at any time by posting it to this site. The user may not
-      assign any part of this Agreement without Unicode???s prior written
+      assign any part of this Agreement without Unicode?s prior written
       consent.
 
    3. Taxes. The user agrees to pay any taxes arising from access to this
       website or use of the information herein, except for those based on
-      Unicode???s net income.
+      Unicode?s net income.
 
    4. Severability.  If any provision of this Agreement is declared invalid or
       unenforceable, the remaining provisions of this Agreement shall remain
@@ -2666,7 +2666,7 @@ SOFTWARE.
 
 COPYRIGHT AND PERMISSION NOTICE
 
-Copyright ?? 1991-2012 Unicode, Inc. All rights reserved. Distributed under the
+Copyright ? 1991-2012 Unicode, Inc. All rights reserved. Distributed under the
 Terms of Use in http://www.unicode.org/copyright.html.
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
--- xjdk-any.tar.gz/nashorn/THIRD_PARTY_README	2021-09-28 15:30:27.000000000 +0200
+++ xjdk-aarch64.tar.gz/nashorn/THIRD_PARTY_README	2022-01-20 16:51:28.000000000 +0100
@@ -7,7 +7,7 @@ OpenJDK 8.
 
 --- begin of LICENSE ---
 
-Copyright (c) 2000-2011 France T??l??com
+Copyright (c) 2000-2011 France T?l?com
 All rights reserved.
 
 Redistribution and use in source and binary forms, with or without
@@ -1035,7 +1035,7 @@ JRE 8, JDK 8, and OpenJDK 8.
 --- begin of LICENSE ---
 
 Copyright notice
-Copyright ?? 2011 Ecma International
+Copyright ? 2011 Ecma International
 Ecma International
 Rue du Rhone 114
 CH-1204 Geneva
@@ -2527,16 +2527,16 @@ which may be included with JRE 8, JDK 8,
 Unicode Terms of Use
 
 For the general privacy policy governing access to this site, see the Unicode
-Privacy Policy. For trademark usage, see the Unicode?? Consortium Name and
+Privacy Policy. For trademark usage, see the Unicode? Consortium Name and
 Trademark Usage Policy.
 
 A. Unicode Copyright.
-   1. Copyright ?? 1991-2013 Unicode, Inc. All rights reserved.
+   1. Copyright ? 1991-2013 Unicode, Inc. All rights reserved.
 
    2. Certain documents and files on this website contain a legend indicating
       that "Modification is permitted." Any person is hereby authorized,
       without fee, to modify such documents and files to create derivative
-      works conforming to the Unicode?? Standard, subject to Terms and
+      works conforming to the Unicode? Standard, subject to Terms and
       Conditions herein.
 
     3. Any person is hereby authorized, without fee, to view, use, reproduce,
@@ -2602,14 +2602,14 @@ D. Waiver of Damages. In no event shall
 
 E.Trademarks & Logos.
    1. The Unicode Word Mark and the Unicode Logo are trademarks of Unicode,
-      Inc.  ???The Unicode Consortium??? and ???Unicode, Inc.??? are trade names of
+      Inc.  ?The Unicode Consortium? and ?Unicode, Inc.? are trade names of
       Unicode, Inc.  Use of the information and materials found on this
-      website indicates your acknowledgement of Unicode, Inc.???s exclusive
+      website indicates your acknowledgement of Unicode, Inc.?s exclusive
       worldwide rights in the Unicode Word Mark, the Unicode Logo, and the
       Unicode trade names.
 
-   2. The Unicode Consortium Name and Trademark Usage Policy (???Trademark
-      Policy???) are incorporated herein by reference and you agree to abide by
+   2. The Unicode Consortium Name and Trademark Usage Policy (?Trademark
+      Policy?) are incorporated herein by reference and you agree to abide by
       the provisions of the Trademark Policy, which may be changed from time
       to time in the sole discretion of Unicode, Inc.
 
@@ -2632,12 +2632,12 @@ Miscellaneous.
 
    2. Modification by Unicode.  Unicode shall have the right to modify this
       Agreement at any time by posting it to this site. The user may not
-      assign any part of this Agreement without Unicode???s prior written
+      assign any part of this Agreement without Unicode?s prior written
       consent.
 
    3. Taxes. The user agrees to pay any taxes arising from access to this
       website or use of the information herein, except for those based on
-      Unicode???s net income.
+      Unicode?s net income.
 
    4. Severability.  If any provision of this Agreement is declared invalid or
       unenforceable, the remaining provisions of this Agreement shall remain
@@ -2666,7 +2666,7 @@ SOFTWARE.
 
 COPYRIGHT AND PERMISSION NOTICE
 
-Copyright ?? 1991-2012 Unicode, Inc. All rights reserved. Distributed under the
+Copyright ? 1991-2012 Unicode, Inc. All rights reserved. Distributed under the
 Terms of Use in http://www.unicode.org/copyright.html.
 
 Permission is hereby granted, free of charge, to any person obtaining a copy


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 iris at openjdk.java.net  Thu Apr 21 21:19:36 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 21 Apr 2022 21:19:36 GMT
Subject: [jdk8u-ri] RFR: 8201793: (ref) Reference object should not support
 cloning
In-Reply-To: <K_wvGr0wKQKsVQzfYQu-5ehjn-BHPCDrx3EQ2ZAlhX0=.1504b393-7438-499d-ac1e-3af967e7a2eb@github.com>
References: <K_wvGr0wKQKsVQzfYQu-5ehjn-BHPCDrx3EQ2ZAlhX0=.1504b393-7438-499d-ac1e-3af967e7a2eb@github.com>
Message-ID: <3fRpMhGJraPEJMe1jTIu51PecUfU3NXYkKJkSNjwO9c=.b93ad2ee-769d-49bb-999a-335b27c01fdc@github.com>

On Wed, 20 Apr 2022 00:59:26 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> This changeset backports the fix for 8201793 to jdk8u-ri.
> 
> With this change, `java.lang.ref.Reference::clone` method always throws `CloneNotSupportedException`.

The proposed spec changes look good with the addition of the proposed @apinote.

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

Marked as reviewed by iris (Author).

PR: https://git.openjdk.java.net/jdk8u-ri/pull/6

From iris at openjdk.java.net  Thu Apr 21 21:19:38 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 21 Apr 2022 21:19:38 GMT
Subject: [jdk8u-ri] RFR: 8201793: (ref) Reference object should not support
 cloning
In-Reply-To: <E_2_Y9oCqBYKlHn8V3JEXkdeimWqDnO07VudLXiBUas=.da0d0ad8-197b-4211-8478-d709d7296e0b@github.com>
References: <K_wvGr0wKQKsVQzfYQu-5ehjn-BHPCDrx3EQ2ZAlhX0=.1504b393-7438-499d-ac1e-3af967e7a2eb@github.com>
 <E_2_Y9oCqBYKlHn8V3JEXkdeimWqDnO07VudLXiBUas=.da0d0ad8-197b-4211-8478-d709d7296e0b@github.com>
Message-ID: <6U3mveYLnjInCwQS_exfV4xArFp-7TaPFFC7ua50KcQ=.7838d1e1-c4ba-4f33-9556-4752f4842e7f@github.com>

On Thu, 21 Apr 2022 20:29:49 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This changeset backports the fix for 8201793 to jdk8u-ri.
>> 
>> With this change, `java.lang.ref.Reference::clone` method always throws `CloneNotSupportedException`.
>
> jdk/src/share/classes/java/lang/ref/Reference.java line 255:
> 
>> 253:      * @throws  CloneNotSupportedException always
>> 254:      *
>> 255:      * @since 8
> 
> This method is only present in JDK 8u42 (RI) and 8u352 and later releases.  It's not in existing 8u releases >= 8u45 and < 8u352.   Neither 8 or 8u42 would cause confusion.  A suggestion is to use `@apiNote` to indicate which MR this method is defined:
> 
> 
> @apiNote This method is defined in Java SE 8 Maintenance Release 4.

The proposed `@apinote` looks good.

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/6

From iris at openjdk.java.net  Thu Apr 21 21:23:38 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 21 Apr 2022 21:23:38 GMT
Subject: [jdk8u-ri] RFR: 8071507: (ref) Clear phantom reference as soft and
 weak references do [v2]
In-Reply-To: <T6GQa0MGVpYjsxrymTvBDPsS5y8Z6ZmV-kJrzgrkoRE=.8d38b502-0bf5-437a-ae4a-41ea27b0643a@github.com>
References: <ikjRTxf579yNfmrhx-6FN8nX4HwtBQw2jNEWmNsr98I=.de0ba7bc-ebd8-49c5-baba-2dec83c93b64@github.com>
 <T6GQa0MGVpYjsxrymTvBDPsS5y8Z6ZmV-kJrzgrkoRE=.8d38b502-0bf5-437a-ae4a-41ea27b0643a@github.com>
Message-ID: <DN_66RdBpczB-IOapDjosXQyg6njG0y3-wvojo52FWE=.e3b20b5f-8e5c-4f9b-8228-86f38124f0b4@github.com>

On Thu, 21 Apr 2022 16:05:25 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

>> These changes backport the following fixes to jdk8u-ri:
>> - 8071507: (ref) Clear phantom reference as soft and weak references do
>> - 8143847: Remove REF_CLEANER reference category
>> 
>> With these changes, phantom references are automatically cleared by the garbage collector as soft and weak references.
>
> Poonam Bajaj has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Corrected documentation in package.html

Update spec looks good.

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

Marked as reviewed by iris (Author).

PR: https://git.openjdk.java.net/jdk8u-ri/pull/4

From iris at openjdk.java.net  Thu Apr 21 21:26:29 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 21 Apr 2022 21:26:29 GMT
Subject: [jdk8u-ri] RFR: 8175797: (ref) Reference::enqueue method should
 clear the reference object before enqueuing
In-Reply-To: <1V-62a8ZWOHk65p2xhwZlqOu5RqTADUW-WCLXUTxVC4=.1a67a810-a015-4620-be8a-820858c3dbe5@github.com>
References: <1V-62a8ZWOHk65p2xhwZlqOu5RqTADUW-WCLXUTxVC4=.1a67a810-a015-4620-be8a-820858c3dbe5@github.com>
Message-ID: <l5CYNYqp837g_1dm476gRTrF5HwvsY1UzQ93WnfHyS8=.c833c1ff-02aa-4aa2-b15a-32c4db931283@github.com>

On Wed, 20 Apr 2022 00:15:58 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> These changes backport the following fixes to jdk8u-ri:
> 
> - 8175797: (ref) Reference::enqueue method should clear the reference object before enqueuing
> - 8178832: (ref) jdk.lang.ref.disableClearBeforeEnqueue property is ignored
> - 8193780: (ref) Remove the undocumented jdk.lang.ref.disableClearBeforeEnqueue system property
> 
> With this fix, the enqueue method clears the reference before enqueuing it to the registered queue.
> 
> The backport of changes to the file _jdk/test/java/lang/ref/ReferenceEnqueue.java_ needed some manual adjustment. Apart from that,  backport of changes to the rest of the files are exact match with the original fixes.

Spec changes look good.

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

Marked as reviewed by iris (Author).

PR: https://git.openjdk.java.net/jdk8u-ri/pull/5

From dongbohe at openjdk.java.net  Fri Apr 22 07:28:35 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Fri, 22 Apr 2022 07:28:35 GMT
Subject: [jdk8u-dev] RFR: 8170530: bash configure output contains a typo in
 a suggested library name
In-Reply-To: <UXqCEc71ix0Ck9WguJnG0OOEsycAed8FRxF9LFmIo2c=.4972f002-c98d-4cf6-bc36-dc4f48cb6911@github.com>
References: <UXqCEc71ix0Ck9WguJnG0OOEsycAed8FRxF9LFmIo2c=.4972f002-c98d-4cf6-bc36-dc4f48cb6911@github.com>
Message-ID: <Oy-LJdd9ojFMW3gAD-yOa7gdKV3FIxY0bD2xQhDaud0=.3e01826d-0434-4550-96b4-023fc8760f72@github.com>

On Fri, 1 Apr 2022 01:55:54 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

> Hi,
> 
> I would like to backport this patch to fix a typo in a suggested library name.
> I updated `DATE_WHEN_GENERATED` with `date +%s`, and other parts are clean.
> 
> Testing: worked correctly after patch.

ping...

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/28

From sgehwolf at openjdk.java.net  Fri Apr 22 09:02:30 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 22 Apr 2022 09:02:30 GMT
Subject: [jdk8u-dev] RFR: 8170530: bash configure output contains a typo in
 a suggested library name
In-Reply-To: <UXqCEc71ix0Ck9WguJnG0OOEsycAed8FRxF9LFmIo2c=.4972f002-c98d-4cf6-bc36-dc4f48cb6911@github.com>
References: <UXqCEc71ix0Ck9WguJnG0OOEsycAed8FRxF9LFmIo2c=.4972f002-c98d-4cf6-bc36-dc4f48cb6911@github.com>
Message-ID: <uf6YmKj41Ocfg5RiiofiCSkTmErwJSUVyt1lgb4AaZk=.54f23f71-2041-4804-b9ad-f5d3f75616e8@github.com>

On Fri, 1 Apr 2022 01:55:54 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

> Hi,
> 
> I would like to backport this patch to fix a typo in a suggested library name.
> I updated `DATE_WHEN_GENERATED` with `date +%s`, and other parts are clean.
> 
> Testing: worked correctly after patch.

Looks fine. generated-configure.sh needs to be re-generated with `autogen.sh`, though.

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

Marked as reviewed by sgehwolf (Reviewer).

PR: https://git.openjdk.java.net/jdk8u-dev/pull/28

From dongbohe at openjdk.java.net  Fri Apr 22 09:32:33 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Fri, 22 Apr 2022 09:32:33 GMT
Subject: [jdk8u-dev] RFR: 8170530: bash configure output contains a typo in
 a suggested library name
In-Reply-To: <UXqCEc71ix0Ck9WguJnG0OOEsycAed8FRxF9LFmIo2c=.4972f002-c98d-4cf6-bc36-dc4f48cb6911@github.com>
References: <UXqCEc71ix0Ck9WguJnG0OOEsycAed8FRxF9LFmIo2c=.4972f002-c98d-4cf6-bc36-dc4f48cb6911@github.com>
Message-ID: <VZsEwKlRf4gI-6Lx8GcPJkyip0dWW7Tifj97v7IQvxg=.ac213403-4548-477c-ad16-ecdc5472e9dd@github.com>

On Fri, 1 Apr 2022 01:55:54 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

> Hi,
> 
> I would like to backport this patch to fix a typo in a suggested library name.
> I updated `DATE_WHEN_GENERATED` with `date +%s`, and other parts are clean.
> 
> Testing: worked correctly after patch.

Thanks Severin, Tagged the JBS issue with jdk8u-fix-request.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/28

From duke at openjdk.java.net  Fri Apr 22 10:15:37 2022
From: duke at openjdk.java.net (Alexey Pavlyutkin)
Date: Fri, 22 Apr 2022 10:15:37 GMT
Subject: [jdk8u-dev] RFR: 8221988: add possibility to build with Visual
 Studio 2019 [v2]
In-Reply-To: <8QLfsPZMZzAce0XSglg-0coFlAGGMBBaz-4Rg8kRwys=.df5a82fd-e38e-4753-94dc-8b74c8dda280@github.com>
References: <x2mVGiERq9FssKsmqM5KC0SgkzK9OQlG9CbIjklKe-I=.2490d700-8ca3-47ee-ab10-362397e51442@github.com>
 <IFQObOADDSUEfHfnRSoQ_hdtMptt6_tEykLpkZBo_84=.f9b11dad-9fbf-4900-83d3-5f546ec1ab89@github.com>
 <D51N-MaVhcUrjtHtLq7S334753-iZYFLuYPo-ljIQDU=.eacc961f-8adc-48d0-ade7-cf6e435e0aa7@github.com>
 <8QLfsPZMZzAce0XSglg-0coFlAGGMBBaz-4Rg8kRwys=.df5a82fd-e38e-4753-94dc-8b74c8dda280@github.com>
Message-ID: <2hjak7Mwl3TQmvE0QtkjRmqfmuKsYIV70SfwZeZsfi0=.514c71d3-b708-4339-904a-68e6d9b31657@github.com>

On Mon, 11 Apr 2022 09:35:14 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

>> common/autoconf/toolchain_windows.m4 line 28:
>> 
>>> 26: ################################################################################
>>> 27: # The order of these defines the priority by which we try to find them.
>>> 28: VALID_VS_VERSIONS="2013 2015 2012 2010 2017 2019"
>> 
>> Order should be: `2010 2012 2013 2015 2017 2019`
>
> Fixed. The patch tested for all 2010-2019 toolkits, the PR header was updated accordingly

Ping

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/33

From zgu at openjdk.java.net  Fri Apr 22 12:06:11 2022
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 22 Apr 2022 12:06:11 GMT
Subject: [jdk8u-dev] RFR: 8166140: C1: Possible integer overflow in
 LIRGenerator::generate_address on several platforms
Message-ID: <bewq2-9tRiBHq9XBksQrrPdbPxmvODqIXWOC1ae9jfg=.38d18744-9790-404a-b5ae-cfd346309d92@github.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](https://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/f6c1ea29110e)

The patch does not apply cleanly:
1. ppc does not have compiler port in 8u.
2. Changes for `LIRGenerator::emit_array_address()` in `c1_LIRGenerator_x86.cpp` is obsoleted by [JDK-8272014](https://github.com/openjdk/jdk8u-dev/commit/3e26fd987a70473778e9ae06aa8dd5054483fa59)

Original code review thread: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-January/014517.html

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

Commit messages:
 - 8166140: C1: Possible integer overflow in LIRGenerator::generate_address on several platforms

Changes: https://git.openjdk.java.net/jdk8u-dev/pull/46/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=46&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8166140
  Stats: 31 lines in 3 files changed: 2 ins; 0 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/46.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/46/head:pull/46

PR: https://git.openjdk.java.net/jdk8u-dev/pull/46

From gnu.andrew at redhat.com  Fri Apr 22 17:19:51 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 22 Apr 2022 18:19:51 +0100
Subject: OpenJDK 8u332 Released
Message-ID: <YmLjt6K+lFbhtHEO@hex.discworld.ac.uk>

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

The source tarball is available from:

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

The tarball is accompanied by a digital signature available at:

* https://openjdk-sources.osci.io/openjdk8/openjdk8u332-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:

590001738c39b8a3156bb660b14fd5f3e87f49421c7ce7627670d101167b92f6  openjdk8u332-b09.tar.xz
92cfbbe0200f3be31cecece0e3dec7437b61860b6dbc110349cbc192480dbb40  openjdk8u332-b09.tar.xz.sig

The checksums can be downloaded from:

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

New in release OpenJDK 8u332 (2022-04-22):
===========================================
Live versions of these release notes can be found at:
  * https://bit.ly/openjdk8u332
  * https://builds.shipilev.net/backports-monitor/release-notes-openjdk8u332.txt

* Security fixes
  - JDK-8269938: Enhance XML processing passes redux
  - JDK-8270504, CVE-2022-21426: Better XPath expression handling
  - JDK-8272255: Completely handle MIDI files
  - JDK-8272261: Improve JFR recording file processing
  - JDK-8272594: Better record of recordings
  - JDK-8274221: More definite BER encodings
  - JDK-8275151, CVE-2022-21443: Improved Object Identification
  - JDK-8277227: Better identification of OIDs
  - JDK-8277672, CVE-2022-21434: Better invocation handler handling
  - JDK-8278008, CVE-2022-21476: Improve Santuario processing
  - JDK-8278356: Improve file creation
  - JDK-8278449: Improve keychain support
  - JDK-8278805: Enhance BMP image loading
  - JDK-8278972, CVE-2022-21496: Improve URL supports
  - JDK-8281388: Change wrapping of EncryptedPrivateKeyInfo
* Other changes
  - JDK-8033980: Xerces Update: datatype XMLGregorianCalendarImpl and DurationImpl
  - JDK-8035437: Xerces Update: xml/serialize/DOMSerializerImpl
  - JDK-8035577: Xerces Update: impl/xpath/regex/RangeToken.java
  - JDK-8037259: xerces update: xpointer update
  - JDK-8041523: Xerces Update: Serializer improvements from Xalan
  - JDK-8141508: java.lang.invoke.LambdaConversionException: Invalid receiver type
  - JDK-8162572: Update License Header for all JAXP sources
  - JDK-8167014: jdeps: Missing message: warn.skipped.entry
  - JDK-8198411: [TEST_BUG] Two java2d tests are unstable in mach5
  - JDK-8202822: Add .git to .hgignore
  - JDK-8205540: test/hotspot/jtreg/vmTestbase/nsk/jdb/trace/trace001/trace001.java fails with Debuggee did not exit after 15 <cont> commands
  - JDK-8209178: Proxied HttpsURLConnection doesn't send BODY when retrying POST request
  - JDK-8210283: Support git as an SCM alternative in the build
  - JDK-8218682: [TEST_BUG] DashOffset fails in mach5
  - JDK-8225690: Multiple AttachListener threads can be created
  - JDK-8227738: jvmti/DataDumpRequest/datadumpreq001 failed due to "exit code is 134"
  - JDK-8227815: Minimal VM: set_state is not a member of AttachListener
  - JDK-8240633: Memory leaks in the implementations of FileChooserUI
  - JDK-8241768: git needs .gitattributes
  - JDK-8247766: [aarch64] guarantee(val < (1U << nbits)) failed: Field too big for insn
  - JDK-8253147: The javax/swing/JPopupMenu/7154841/bug7154841.java fail on big screens
  - JDK-8253353: Crash in C2: guarantee(n != NULL) failed: No Node
  - JDK-8266749: AArch64: Backtracing broken on PAC enabled systems
  - JDK-8270290: NTLM authentication fails if HEAD request is used
  - JDK-8273229: Update OS detection code to recognize Windows Server 2022
  - JDK-8273341: Update Siphash to version 1.0
  - JDK-8273575: memory leak in appendBootClassPath(), paths must be deallocated
  - JDK-8274524: SSLSocket.close() hangs if it is called during the ssl handshake
  - JDK-8277224: sun.security.pkcs.PKCS9Attributes.toString() throws NPE
  - JDK-8277488: Add expiry exception for Digicert (geotrustglobalca) expiring in May 2022
  - JDK-8279077: JFR crashes on Linux ppc due to missing crash protector in signal handler
  - JDK-8280060: The sun/rmi/server/Activation.java class use Thread.dumpStack()
  - JDK-8282300: Throws NamingException instead of InvalidNameException after JDK-8278972
  - JDK-8282397: createTempFile method of java.io.File is failing when called with suffix of spaces character
  - JDK-8284548: Invalid XPath expression causes StringIndexOutOfBoundsException
  - JDK-8284920: Incorrect Token type causes XPath expression to return empty result
  - JDK-8284936: Fix Java 7 bootstrap breakage due to use of Arrays.stream

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 poonam at openjdk.java.net  Fri Apr 22 17:20:33 2022
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Fri, 22 Apr 2022 17:20:33 GMT
Subject: [jdk8u-ri] RFR: 8201793: (ref) Reference object should not support
 cloning [v2]
In-Reply-To: <K_wvGr0wKQKsVQzfYQu-5ehjn-BHPCDrx3EQ2ZAlhX0=.1504b393-7438-499d-ac1e-3af967e7a2eb@github.com>
References: <K_wvGr0wKQKsVQzfYQu-5ehjn-BHPCDrx3EQ2ZAlhX0=.1504b393-7438-499d-ac1e-3af967e7a2eb@github.com>
Message-ID: <q2PVwf_VGTJ-8HdurxrWOVw-0ZJDr34-dpdC2xwp3Oc=.1e2aa826-abe2-46d0-add7-5701a734089d@github.com>

> This changeset backports the fix for 8201793 to jdk8u-ri.
> 
> With this change, `java.lang.ref.Reference::clone` method always throws `CloneNotSupportedException`.

Poonam Bajaj has updated the pull request incrementally with one additional commit since the last revision:

  Fixed the javadoc comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk8u-ri/pull/6/files
  - new: https://git.openjdk.java.net/jdk8u-ri/pull/6/files/365622e1..a0966941

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

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk8u-ri/pull/6.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-ri pull/6/head:pull/6

PR: https://git.openjdk.java.net/jdk8u-ri/pull/6

From mchung at openjdk.java.net  Fri Apr 22 17:22:17 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 22 Apr 2022 17:22:17 GMT
Subject: [jdk8u-ri] RFR: 8201793: (ref) Reference object should not support
 cloning [v2]
In-Reply-To: <q2PVwf_VGTJ-8HdurxrWOVw-0ZJDr34-dpdC2xwp3Oc=.1e2aa826-abe2-46d0-add7-5701a734089d@github.com>
References: <K_wvGr0wKQKsVQzfYQu-5ehjn-BHPCDrx3EQ2ZAlhX0=.1504b393-7438-499d-ac1e-3af967e7a2eb@github.com>
 <q2PVwf_VGTJ-8HdurxrWOVw-0ZJDr34-dpdC2xwp3Oc=.1e2aa826-abe2-46d0-add7-5701a734089d@github.com>
Message-ID: <vlM96HQl3oyNgh9fuSVBpxSA93KuT1O1dkZlcyUc8ds=.06a1e09a-7feb-4cb2-92e7-8ca876f3e346@github.com>

On Fri, 22 Apr 2022 17:20:33 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

>> This changeset backports the fix for 8201793 to jdk8u-ri.
>> 
>> With this change, `java.lang.ref.Reference::clone` method always throws `CloneNotSupportedException`.
>
> Poonam Bajaj has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the javadoc comments

Marked as reviewed by mchung (Reviewer).

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/6

From peter.tribble at gmail.com  Fri Apr 22 19:40:25 2022
From: peter.tribble at gmail.com (Peter Tribble)
Date: Fri, 22 Apr 2022 20:40:25 +0100
Subject: OpenJDK 8u332 Released
In-Reply-To: <YmLjt6K+lFbhtHEO@hex.discworld.ac.uk>
References: <YmLjt6K+lFbhtHEO@hex.discworld.ac.uk>
Message-ID: <CAEgYsbH9qqE4jNdnwLXabio5K6kw2SeCagUW-T0r0RYEpZPm_g@mail.gmail.com>

Hi,

On Fri, Apr 22, 2022 at 6:20 PM Andrew Hughes <gnu.andrew at redhat.com> wrote:

> We are pleased to announce the release of OpenJDK 8u332.
>
> The source tarball is available from:
>
> * https://openjdk-sources.osci.io/openjdk8/openjdk8u332-ga.tar.xz
>

Building from the tarball fails for me. (I'm on illumos, but I'm not sure
it should
make any difference given what I see.) The make just hangs silently. The
problem
appears to be that without any scm information the various SCM_ variables
end
up empty, and if they aren't quoted mess up the shell constructs. A patch
that
fixes the problem and allows the build to proceed (thanks to the OmniOS
folks)
follows, but I wonder if the release tarballs need to contain the scm tip
file(s).

diff -wpruN '--exclude=*.orig' a~/make/common/MakeBase.gmk
a/make/common/MakeBase.gmk
--- a~/make/common/MakeBase.gmk 1970-01-01 00:00:00
+++ a/make/common/MakeBase.gmk 1970-01-01 00:00:00
@@ -318,9 +318,9 @@ SCM_TIP_FILECMD := $(PRINTF) "$(SCM):%s"
 # Emit the scm:id pair to $@
 define GetSourceTips
  $(CD) $(SRC_ROOT) ; \
- if [ -d $(SCM_DIR) -a "$(SCM_VERSION)" != "" ] ; then \
+ if [ -d "$(SCM_DIR)" -a "$(SCM_VERSION)" != "" ] ; then \
   $(ID_COMMAND) >> $@ ; \
- elif [ -f $(SCM_TIP_FILENAME) ] ; then \
+ elif [ -f "$(SCM_TIP_FILENAME)" ] ; then \
           $(SCM_TIP_FILECMD) >> $@ ; \
  fi;
  $(PRINTF) "\n" >> $@

 Thanks,

The tarball is accompanied by a digital signature available at:
>
> * https://openjdk-sources.osci.io/openjdk8/openjdk8u332-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:
>
> 590001738c39b8a3156bb660b14fd5f3e87f49421c7ce7627670d101167b92f6
> openjdk8u332-b09.tar.xz
> 92cfbbe0200f3be31cecece0e3dec7437b61860b6dbc110349cbc192480dbb40
> openjdk8u332-b09.tar.xz.sig
>
> The checksums can be downloaded from:
>
> * https://openjdk-sources.osci.io/openjdk8/openjdk8u332-ga.sha256
>
> New in release OpenJDK 8u332 (2022-04-22):
> ===========================================
> Live versions of these release notes can be found at:
>   * https://bit.ly/openjdk8u332
>   *
> https://builds.shipilev.net/backports-monitor/release-notes-openjdk8u332.txt
>
> * Security fixes
>   - JDK-8269938: Enhance XML processing passes redux
>   - JDK-8270504, CVE-2022-21426: Better XPath expression handling
>   - JDK-8272255: Completely handle MIDI files
>   - JDK-8272261: Improve JFR recording file processing
>   - JDK-8272594: Better record of recordings
>   - JDK-8274221: More definite BER encodings
>   - JDK-8275151, CVE-2022-21443: Improved Object Identification
>   - JDK-8277227: Better identification of OIDs
>   - JDK-8277672, CVE-2022-21434: Better invocation handler handling
>   - JDK-8278008, CVE-2022-21476: Improve Santuario processing
>   - JDK-8278356: Improve file creation
>   - JDK-8278449: Improve keychain support
>   - JDK-8278805: Enhance BMP image loading
>   - JDK-8278972, CVE-2022-21496: Improve URL supports
>   - JDK-8281388: Change wrapping of EncryptedPrivateKeyInfo
> * Other changes
>   - JDK-8033980: Xerces Update: datatype XMLGregorianCalendarImpl and
> DurationImpl
>   - JDK-8035437: Xerces Update: xml/serialize/DOMSerializerImpl
>   - JDK-8035577: Xerces Update: impl/xpath/regex/RangeToken.java
>   - JDK-8037259: xerces update: xpointer update
>   - JDK-8041523: Xerces Update: Serializer improvements from Xalan
>   - JDK-8141508: java.lang.invoke.LambdaConversionException: Invalid
> receiver type
>   - JDK-8162572: Update License Header for all JAXP sources
>   - JDK-8167014: jdeps: Missing message: warn.skipped.entry
>   - JDK-8198411: [TEST_BUG] Two java2d tests are unstable in mach5
>   - JDK-8202822: Add .git to .hgignore
>   - JDK-8205540:
> test/hotspot/jtreg/vmTestbase/nsk/jdb/trace/trace001/trace001.java fails
> with Debuggee did not exit after 15 <cont> commands
>   - JDK-8209178: Proxied HttpsURLConnection doesn't send BODY when
> retrying POST request
>   - JDK-8210283: Support git as an SCM alternative in the build
>   - JDK-8218682: [TEST_BUG] DashOffset fails in mach5
>   - JDK-8225690: Multiple AttachListener threads can be created
>   - JDK-8227738: jvmti/DataDumpRequest/datadumpreq001 failed due to "exit
> code is 134"
>   - JDK-8227815: Minimal VM: set_state is not a member of AttachListener
>   - JDK-8240633: Memory leaks in the implementations of FileChooserUI
>   - JDK-8241768: git needs .gitattributes
>   - JDK-8247766: [aarch64] guarantee(val < (1U << nbits)) failed: Field
> too big for insn
>   - JDK-8253147: The javax/swing/JPopupMenu/7154841/bug7154841.java fail
> on big screens
>   - JDK-8253353: Crash in C2: guarantee(n != NULL) failed: No Node
>   - JDK-8266749: AArch64: Backtracing broken on PAC enabled systems
>   - JDK-8270290: NTLM authentication fails if HEAD request is used
>   - JDK-8273229: Update OS detection code to recognize Windows Server 2022
>   - JDK-8273341: Update Siphash to version 1.0
>   - JDK-8273575: memory leak in appendBootClassPath(), paths must be
> deallocated
>   - JDK-8274524: SSLSocket.close() hangs if it is called during the ssl
> handshake
>   - JDK-8277224: sun.security.pkcs.PKCS9Attributes.toString() throws NPE
>   - JDK-8277488: Add expiry exception for Digicert (geotrustglobalca)
> expiring in May 2022
>   - JDK-8279077: JFR crashes on Linux ppc due to missing crash protector
> in signal handler
>   - JDK-8280060: The sun/rmi/server/Activation.java class use
> Thread.dumpStack()
>   - JDK-8282300: Throws NamingException instead of InvalidNameException
> after JDK-8278972
>   - JDK-8282397: createTempFile method of java.io.File is failing when
> called with suffix of spaces character
>   - JDK-8284548: Invalid XPath expression causes
> StringIndexOutOfBoundsException
>   - JDK-8284920: Incorrect Token type causes XPath expression to return
> empty result
>   - JDK-8284936: Fix Java 7 bootstrap breakage due to use of Arrays.stream
>
> 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
>


-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/

From gnu.andrew at redhat.com  Sun Apr 24 17:16:49 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Sun, 24 Apr 2022 18:16:49 +0100
Subject: OpenJDK 8u332 Released
In-Reply-To: <CAEgYsbH9qqE4jNdnwLXabio5K6kw2SeCagUW-T0r0RYEpZPm_g@mail.gmail.com>
References: <YmLjt6K+lFbhtHEO@hex.discworld.ac.uk>
 <CAEgYsbH9qqE4jNdnwLXabio5K6kw2SeCagUW-T0r0RYEpZPm_g@mail.gmail.com>
Message-ID: <YmWGAXZ0fMKv1cJK@hex.discworld.ac.uk>

On 20:40 Fri 22 Apr     , Peter Tribble wrote:
> Hi,
> 
> On Fri, Apr 22, 2022 at 6:20 PM Andrew Hughes <gnu.andrew at redhat.com> wrote:
> 
> > We are pleased to announce the release of OpenJDK 8u332.
> >
> > The source tarball is available from:
> >
> > * https://openjdk-sources.osci.io/openjdk8/openjdk8u332-ga.tar.xz
> >
> 
> Building from the tarball fails for me. (I'm on illumos, but I'm not sure
> it should
> make any difference given what I see.) The make just hangs silently. The
> problem
> appears to be that without any scm information the various SCM_ variables
> end
> up empty, and if they aren't quoted mess up the shell constructs. A patch
> that
> fixes the problem and allows the build to proceed (thanks to the OmniOS
> folks)
> follows, but I wonder if the release tarballs need to contain the scm tip
> file(s).
> 
> diff -wpruN '--exclude=*.orig' a~/make/common/MakeBase.gmk
> a/make/common/MakeBase.gmk
> --- a~/make/common/MakeBase.gmk 1970-01-01 00:00:00
> +++ a/make/common/MakeBase.gmk 1970-01-01 00:00:00
> @@ -318,9 +318,9 @@ SCM_TIP_FILECMD := $(PRINTF) "$(SCM):%s"
>  # Emit the scm:id pair to $@
>  define GetSourceTips
>   $(CD) $(SRC_ROOT) ; \
> - if [ -d $(SCM_DIR) -a "$(SCM_VERSION)" != "" ] ; then \
> + if [ -d "$(SCM_DIR)" -a "$(SCM_VERSION)" != "" ] ; then \
>    $(ID_COMMAND) >> $@ ; \
> - elif [ -f $(SCM_TIP_FILENAME) ] ; then \
> + elif [ -f "$(SCM_TIP_FILENAME)" ] ; then \
>            $(SCM_TIP_FILECMD) >> $@ ; \
>   fi;
>   $(PRINTF) "\n" >> $@
> 
>  Thanks,
> 

I build the tarballs on several architectures before posting them,
though admittedly these are all Linux systems. I'm guessing Illumos is
an OpenSolaris variant?  Each commit is tested on Linux, MacOS and
Windows as provided by GitHub now, but sadly we don't have any regular
testing on Solaris.

The line in question seems to be unique to the recent backport
of JDK-8210283 [0]. Did previous release tarballs work for you
(i.e. 8u322 and before)? Does a current Git checkout of
https://github.com/openjdk/jdk8u work?

The fix above suggests a problem with spaces in the filenames.
It'd be interesting to see build logs for the failure if you
have them.

[0] https://github.com/openjdk/jdk8u/commit/054b85b1f65254b2d3d2a1d343e14d8eabd1af40

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  Sun Apr 24 17:39:53 2022
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Sun, 24 Apr 2022 19:39:53 +0200 (CEST)
Subject: OpenJDK 8u332 Released
In-Reply-To: <YmWGAXZ0fMKv1cJK@hex.discworld.ac.uk>
References: <YmLjt6K+lFbhtHEO@hex.discworld.ac.uk>
 <CAEgYsbH9qqE4jNdnwLXabio5K6kw2SeCagUW-T0r0RYEpZPm_g@mail.gmail.com>
 <YmWGAXZ0fMKv1cJK@hex.discworld.ac.uk>
Message-ID: <fe649ab-115-accf-a257-69e42ddd667a@tarent.de>

On Sun, 24 Apr 2022, Andrew Hughes wrote:

> > - if [ -d $(SCM_DIR) -a "$(SCM_VERSION)" != "" ] ; then \
> > + if [ -d "$(SCM_DIR)" -a "$(SCM_VERSION)" != "" ] ; then \

> The fix above suggests a problem with spaces in the filenames.

No, it?s just mixing shell and make.

If SCM_DIR and SCM_VERSION are unset/empty, the shell gets:

	if [ -d -a "" != "" ]; then

This is an invalid construct. I?d personally even single-quote
make variable expansions to avoid problems with $, `, \ in paths:

	if test -d '$(SCM_DIR)' && test -n '$(SCM_VERSION)'; then

This also fixes the -a issue (-a is not POSIX) and issues with
empty comparisons (while POSIX, still not portable).

bye,
//mirabilos

PS: I?m experimenting with switching Debian/arm64 away from
    Shenandoah, to get on with the update.
-- 
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 gnu.andrew at redhat.com  Sun Apr 24 22:47:35 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Sun, 24 Apr 2022 23:47:35 +0100
Subject: [aarch64-port-dev ] 8u332 Release
In-Reply-To: <b841e884-142f-aeee-8842-18805412d3c@tarent.de>
References: <Yl/92k7+fnwtzmuo@hex.discworld.ac.uk>
 <b841e884-142f-aeee-8842-18805412d3c@tarent.de>
Message-ID: <YmXThyOqbDDv+Ezd@hex.discworld.ac.uk>

On 21:34 Thu 21 Apr     , Thorsten Glaser wrote:
> Hi list(s),
> 
> On Wed, 20 Apr 2022, Andrew Hughes wrote:
> 
> > I have pushed jdk8u332-b09 with the April security updates to the
> > monojdk8u repository:
> 
> any idea when the aarch64-shenandoah-jdk8u332-* will be available?
> 
> Thanks in advance,
> //mirabilos (for Debian)
> -- 
> 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!
>                         ****************************************************
> 

It's going to take a while to get the changes into the official
repository - https://github.com/openjdk/shenandoah-jdk8u - because
we're still fighting with the SKARA commit system there.

In the meantime, I've made the changes available in a branch
of my personal fork:

https://github.com/gnu-andrew/shenandoah-jdk8u/releases/tag/shenandoah-jdk8u332-b09

The final version will be the same code, but the changeset IDs will be
different. That shouldn't matter for a source tarball.

Note that we've dropped the 'aarch64-' prefix from this release on, as
the AArch64 port has been in upstream 8u for some time; the only
difference in this fork is the availability of the Shenandoah garbage
collector.

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  Sun Apr 24 22:48:29 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Sun, 24 Apr 2022 23:48:29 +0100
Subject: encoding fixes
In-Reply-To: <2a068b-b8a9-f33d-be22-ebacaa2dc42a@tarent.de>
References: <2a068b-b8a9-f33d-be22-ebacaa2dc42a@tarent.de>
Message-ID: <YmXTvdbmMp02tnop@hex.discworld.ac.uk>

On 22:48 Thu 21 Apr     , Thorsten Glaser wrote:
> Hi,
> 
> I?ve seen the aarch64-shenandoah 323 carry the following fix,
> which probably should be globally applied to fix the encoding:
>

Yes, I'm aware of this and will try and upstream it once the
Git transition is finally complete.

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  Sun Apr 24 22:55:45 2022
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Mon, 25 Apr 2022 00:55:45 +0200 (CEST)
Subject: [aarch64-port-dev ] 8u332 Release
In-Reply-To: <YmXThyOqbDDv+Ezd@hex.discworld.ac.uk>
References: <Yl/92k7+fnwtzmuo@hex.discworld.ac.uk>
 <b841e884-142f-aeee-8842-18805412d3c@tarent.de>
 <YmXThyOqbDDv+Ezd@hex.discworld.ac.uk>
Message-ID: <ac63933-2d67-6a8c-47da-a214e47886be@tarent.de>

Hi Andrew,

> It's going to take a while to get the changes into the official
> repository - https://github.com/openjdk/shenandoah-jdk8u - because
> we're still fighting with the SKARA commit system there.

oh, ouch. What does SKARA stand for, anyway? (Or is it not an acronym?)

> Note that we've dropped the 'aarch64-' prefix from this release on, as
> the AArch64 port has been in upstream 8u for some time; the only
> difference in this fork is the availability of the Shenandoah garbage
> collector.

Indeed; someone, maybe you, wrote something like this a few months ago,
and I recalled that and, over this weekend, did test whether we can use
just the normal code for arm64, leaving us with only the aarch32 stuff
for armhf (armel uses Zero) as extra repository. I was able to confirm
it works (for several, albeit smallish, Maven projects) on a porterbox
and am switching the Debian packaging of OpenJDK 8 to it.

Thanks,
//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 duke at openjdk.java.net  Mon Apr 25 08:14:45 2022
From: duke at openjdk.java.net (ktakakuri)
Date: Mon, 25 Apr 2022 08:14:45 GMT
Subject: [jdk8u-dev] RFR: 8248876: LoadObject with bad base address created for
 exec file on linux
Message-ID: <4Dj9YlKq8P29Rj4dWeokie_HEME7KRMItQpXomF6Fqs=.fb15c3af-748e-4a7f-bc77-117aebf6332e@github.com>

I would like to backport
8248876: LoadObject with bad base address created for exec file on linux.

The original patch does not apply cleanly to 8u, and this is a clean backport from 11u.

Testing:
build on Linux x86_64
tier1 on Linux x86_64

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

Commit messages:
 - 8248876: LoadObject with bad base address created for exec file on linux
 - 8248876: LoadObject with bad base address created for exec file on linux

Changes: https://git.openjdk.java.net/jdk8u-dev/pull/47/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=47&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8248876
  Stats: 18 lines in 2 files changed: 4 ins; 3 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/47.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/47/head:pull/47

PR: https://git.openjdk.java.net/jdk8u-dev/pull/47

From poonam at openjdk.java.net  Mon Apr 25 21:20:11 2022
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Mon, 25 Apr 2022 21:20:11 GMT
Subject: [jdk8u-ri] RFR: 8285400: Add '@apiNote' to the APIs defined in Java SE
 8 MR 3
Message-ID: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>

This change adds "apiNote This method is defined in Java SE 8 Maintenance Release 3." to the doc comments of the new APIs added with the following changesets in Java SE MR3 :

1. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/b26b096d4c89
2. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/6bada58189de

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

Commit messages:
 - 8285400: Add '@apiNote' to the APIs defined in Java SE 8 MR 3

Changes: https://git.openjdk.java.net/jdk8u-ri/pull/7/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-ri&pr=7&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285400
  Stats: 24 lines in 10 files changed: 20 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk8u-ri/pull/7.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-ri pull/7/head:pull/7

PR: https://git.openjdk.java.net/jdk8u-ri/pull/7

From valeriep at openjdk.java.net  Mon Apr 25 23:25:57 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 25 Apr 2022 23:25:57 GMT
Subject: [jdk8u-ri] RFR: 8285400: Add '@apiNote' to the APIs defined in
 Java SE 8 MR 3
In-Reply-To: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
References: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
Message-ID: <tSNPjJZhDXGtEDNG3jBuC1ZluHmrKW9uMODFmneHjIU=.40d9fe78-d404-4e16-9089-b25be5c6310e@github.com>

On Mon, 25 Apr 2022 21:02:05 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> This change adds "apiNote This method is defined in Java SE 8 Maintenance Release 3." to the doc comments of the new APIs added with the following changesets in Java SE MR3 :
> 
> 1. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/b26b096d4c89
> 2. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/6bada58189de

How about the SHA512_224 and SHA512_256 constants in java/security/spec/MGF1ParameterSpec.java? Should add the since and apiNot javadoc tags as well?

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/7

From wetmore at openjdk.java.net  Mon Apr 25 23:36:55 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Mon, 25 Apr 2022 23:36:55 GMT
Subject: [jdk8u-ri] RFR: 8285400: Add '@apiNote' to the APIs defined in
 Java SE 8 MR 3
In-Reply-To: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
References: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
Message-ID: <mMt4HcbKVZofx5dBqwJpIBXyxBA6PVY5urykecVla0Q=.c2f4aeb7-342e-4b33-b27d-9c529008a3af@github.com>

On Mon, 25 Apr 2022 21:02:05 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> This change adds "apiNote This method is defined in Java SE 8 Maintenance Release 3." to the doc comments of the new APIs added with the following changesets in Java SE MR3 :
> 
> 1. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/b26b096d4c89
> 2. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/6bada58189de

Is the word choice confirmed/approved, or still up for editing?  Seems like this should be in past tense, IMHO.

`This method was added in Java SE 8 Maintenance Release 3.`

Shouldn't the copyright dates be updated to 2022?  These are significant changes to the files involved.

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/7

From valeriep at openjdk.java.net  Mon Apr 25 23:36:55 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 25 Apr 2022 23:36:55 GMT
Subject: [jdk8u-ri] RFR: 8285400: Add '@apiNote' to the APIs defined in
 Java SE 8 MR 3
In-Reply-To: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
References: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
Message-ID: <m1wvMPeFA9EjM8WpAqd9c1ZrXfBLQKr6nWR1xmnhrr8=.00597abe-05a2-4f0c-af41-9d858e85fa15@github.com>

On Mon, 25 Apr 2022 21:02:05 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> This change adds "apiNote This method is defined in Java SE 8 Maintenance Release 3." to the doc comments of the new APIs added with the following changesets in Java SE MR3 :
> 
> 1. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/b26b096d4c89
> 2. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/6bada58189de

jdk/src/share/classes/java/security/Signature.java line 587:

> 585:      * {@code InvalidKeyException} is thrown.
> 586:      *
> 587:      * @apiNote This method is defined in Java SE 8 Maintenance Release 3.

Hmm, there are other pkg private methods added in the maintenance release which do not have the `@since` javadoc tag. For consistency sake, maybe removing the `@since` tag here and no need to add `@apiNote` then?

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/7

From wetmore at openjdk.java.net  Mon Apr 25 23:49:57 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Mon, 25 Apr 2022 23:49:57 GMT
Subject: [jdk8u-ri] RFR: 8285400: Add '@apiNote' to the APIs defined in
 Java SE 8 MR 3
In-Reply-To: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
References: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
Message-ID: <ofo3ZvFoJG_8KKgrcFhgHDtnPm1qqToovB5HmSiEol0=.af17f970-c2f5-48c7-b30e-50c410918fff@github.com>

On Mon, 25 Apr 2022 21:02:05 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> This change adds "apiNote This method is defined in Java SE 8 Maintenance Release 3." to the doc comments of the new APIs added with the following changesets in Java SE MR3 :
> 
> 1. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/b26b096d4c89
> 2. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/6bada58189de

jdk/src/share/classes/javax/net/ssl/SSLEngine.java line 1356:

> 1354:      *
> 1355:      * @apiNote This method is defined in Java SE 8 Maintenance Release 3.
> 1356:      *

IMHO, this needs a separator here to separate the existing API from the addition.  Or maybe a second `@apiNote`?   It currently renders as this.

    API Note:
    This method is defined in Java SE 8 Maintenance Release 3. This method 
    should be called by TLS server application...

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/7

From serb at openjdk.java.net  Mon Apr 25 23:50:06 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 25 Apr 2022 23:50:06 GMT
Subject: [jdk8u-dev] RFR: JDK-8284772: 8u GHA: Use GCC Major Version
 Dependencies Only
In-Reply-To: <9orZk-QXNP7EXd6GiWGqF_xsajhliPEPoZmuZTdjOjk=.fb226304-5bca-4c14-afe4-0f41eb99f74b@github.com>
References: <9orZk-QXNP7EXd6GiWGqF_xsajhliPEPoZmuZTdjOjk=.fb226304-5bca-4c14-afe4-0f41eb99f74b@github.com>
Message-ID: <4Uxl3-p-q0i5YdshD3dPGatT3RoYumAjsLx3d-nxT1Y=.77f8ad28-af62-4027-ad7c-b8d81023ce6a@github.com>

On Tue, 12 Apr 2022 18:59:41 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Major versions of GCC often cause problems with OpenJDK. Fedora's eager adoption of them means we often encounter these early. [JDK-8282231](https://bugs.openjdk.java.net/browse/JDK-8282231) is just the latest example from the introduction of GCC 12.
> 
> However, the GHA workflow in OpenJDK doesn't just depend on a major version of GCC - which is actually contained in the Ubuntu package name of `gcc-9` itself - but the full revision number, even down to local packaging changes.
> 
> I believe this is overkill and leads to valuable time being wasted on issues like [JDK-8283778](https://bugs.openjdk.java.net/browse/JDK-8283778) where the GCC version itself didn't change at all, just the Ubuntu version suffix.
> 
> Rather than maintain this for 8u, I suggest we just depend on `gcc-9` which is already a pretty modern version for 8u. I have yet to see an issue be specific to a minor GCC version bump, whereas the current setup is pretty much guaranteed to mean further fixes to the GitHub workflow every time the Ubuntu packager produces a new build.
> 
> Note that the x86-32 Linux build already uses just `gcc-9-multilib` which is why it hasn't been broken by the latest GCC update.

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/35

From valeriep at openjdk.java.net  Mon Apr 25 23:49:56 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 25 Apr 2022 23:49:56 GMT
Subject: [jdk8u-ri] RFR: 8285400: Add '@apiNote' to the APIs defined in
 Java SE 8 MR 3
In-Reply-To: <tSNPjJZhDXGtEDNG3jBuC1ZluHmrKW9uMODFmneHjIU=.40d9fe78-d404-4e16-9089-b25be5c6310e@github.com>
References: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
 <tSNPjJZhDXGtEDNG3jBuC1ZluHmrKW9uMODFmneHjIU=.40d9fe78-d404-4e16-9089-b25be5c6310e@github.com>
Message-ID: <bOShxP_07X036E33YOt1Te0YrB3Bhu6IZldL4rqI1mk=.b7b5d036-2276-4d0b-8dda-a8382613ef49@github.com>

On Mon, 25 Apr 2022 23:21:47 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> How about the SHA512_224 and SHA512_256 constants in java/security/spec/MGF1ParameterSpec.java? Should add the since and apiNot javadoc tags as well?

The `PSSParameterSpec.TRAILER_FIELD_BC` needs the `@apiNote` too?

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/7

From wetmore at openjdk.java.net  Mon Apr 25 23:53:57 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Mon, 25 Apr 2022 23:53:57 GMT
Subject: [jdk8u-ri] RFR: 8285400: Add '@apiNote' to the APIs defined in
 Java SE 8 MR 3
In-Reply-To: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
References: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
Message-ID: <Fj44cuvtfh9fZGJMf97zLXJB-WX86rUfsNY1rp99E6Y=.76ed18e2-1e82-4df1-99c1-8e2025b9a8a6@github.com>

On Mon, 25 Apr 2022 21:02:05 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> This change adds "apiNote This method is defined in Java SE 8 Maintenance Release 3." to the doc comments of the new APIs added with the following changesets in Java SE MR3 :
> 
> 1. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/b26b096d4c89
> 2. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/6bada58189de

jdk/src/share/classes/javax/net/ssl/SSLSocket.java line 765:

> 763:      * }</pre>
> 764:      *
> 765:      * @apiNote This method is defined in Java SE 8 Maintenance Release 3.

Same concern here about either a second `@apiNote` or a separator.

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/7

From wetmore at openjdk.java.net  Tue Apr 26 00:13:57 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 26 Apr 2022 00:13:57 GMT
Subject: [jdk8u-ri] RFR: 8285400: Add '@apiNote' to the APIs defined in
 Java SE 8 MR 3
In-Reply-To: <bOShxP_07X036E33YOt1Te0YrB3Bhu6IZldL4rqI1mk=.b7b5d036-2276-4d0b-8dda-a8382613ef49@github.com>
References: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
 <tSNPjJZhDXGtEDNG3jBuC1ZluHmrKW9uMODFmneHjIU=.40d9fe78-d404-4e16-9089-b25be5c6310e@github.com>
 <bOShxP_07X036E33YOt1Te0YrB3Bhu6IZldL4rqI1mk=.b7b5d036-2276-4d0b-8dda-a8382613ef49@github.com>
Message-ID: <UMdrubx26YUJAFN9wUXohGhLwyz0TeQzdPMgV8IglW4=.3339468c-768f-4d3d-87b3-0bd796d20ad1@github.com>

On Mon, 25 Apr 2022 23:45:12 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> How about the SHA512_224 and SHA512_256 constants in java/security/spec/MGF1ParameterSpec.java? Should add the since and apiNot javadoc tags as well?
>
>> How about the SHA512_224 and SHA512_256 constants in java/security/spec/MGF1ParameterSpec.java? Should add the since and apiNot javadoc tags as well?
> 
> The `PSSParameterSpec.TRAILER_FIELD_BC` needs the `@apiNote` too?

Same concern as  @valeriepeng on both the `MGF1ParameterSpec` and `PSSParameterSpec` field omissions.  We did add a `@since` in `PSSParameterSpec`, but not `MGF1ParameterSpec`.

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/7

From wetmore at openjdk.java.net  Tue Apr 26 00:26:57 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 26 Apr 2022 00:26:57 GMT
Subject: [jdk8u-ri] RFR: 8285400: Add '@apiNote' to the APIs defined in
 Java SE 8 MR 3
In-Reply-To: <m1wvMPeFA9EjM8WpAqd9c1ZrXfBLQKr6nWR1xmnhrr8=.00597abe-05a2-4f0c-af41-9d858e85fa15@github.com>
References: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
 <m1wvMPeFA9EjM8WpAqd9c1ZrXfBLQKr6nWR1xmnhrr8=.00597abe-05a2-4f0c-af41-9d858e85fa15@github.com>
Message-ID: <06bTUJzXwcfCtSGmEtSa46iL3CxUpjz14OBydtOvZkQ=.595277f9-0763-4460-91ea-62a42f8c8a79@github.com>

On Mon, 25 Apr 2022 23:33:25 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> This change adds "apiNote This method is defined in Java SE 8 Maintenance Release 3." to the doc comments of the new APIs added with the following changesets in Java SE MR3 :
>> 
>> 1. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/b26b096d4c89
>> 2. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/6bada58189de
>
> jdk/src/share/classes/java/security/Signature.java line 587:
> 
>> 585:      * {@code InvalidKeyException} is thrown.
>> 586:      *
>> 587:      * @apiNote This method is defined in Java SE 8 Maintenance Release 3.
> 
> Hmm, there are other pkg private methods added in the maintenance release which do not have the `@since` javadoc tag. For consistency sake, maybe removing the `@since` tag here and no need to add `@apiNote` then?

I apparently let this slip through, this `@since` should not have been there.  Please remove it and the `@apiNote`.  Thanks.

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/7

From mchung at openjdk.java.net  Tue Apr 26 00:31:55 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 26 Apr 2022 00:31:55 GMT
Subject: [jdk8u-ri] RFR: 8285400: Add '@apiNote' to the APIs defined in
 Java SE 8 MR 3
In-Reply-To: <ofo3ZvFoJG_8KKgrcFhgHDtnPm1qqToovB5HmSiEol0=.af17f970-c2f5-48c7-b30e-50c410918fff@github.com>
References: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
 <ofo3ZvFoJG_8KKgrcFhgHDtnPm1qqToovB5HmSiEol0=.af17f970-c2f5-48c7-b30e-50c410918fff@github.com>
Message-ID: <0kTIOj70nXzBdXmB-M7I08KdmQpWLdtI5d602hqLy2g=.0e20d00d-b2ef-4a3c-836a-b2cdd7f754f5@github.com>

On Mon, 25 Apr 2022 23:46:10 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> This change adds "apiNote This method is defined in Java SE 8 Maintenance Release 3." to the doc comments of the new APIs added with the following changesets in Java SE MR3 :
>> 
>> 1. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/b26b096d4c89
>> 2. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/6bada58189de
>
> jdk/src/share/classes/javax/net/ssl/SSLEngine.java line 1356:
> 
>> 1354:      *
>> 1355:      * @apiNote This method is defined in Java SE 8 Maintenance Release 3.
>> 1356:      *
> 
> IMHO, this needs a separator here to separate the existing API from the addition.  Or maybe a second `@apiNote`?   It currently renders as this:
> 
>     API Note:
>     This method is defined in Java SE 8 Maintenance Release 3. This method 
>     should be called by TLS server application...

I suggest using <p> to start with a new paragraph.

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/7

From wetmore at openjdk.java.net  Tue Apr 26 00:41:54 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 26 Apr 2022 00:41:54 GMT
Subject: [jdk8u-ri] RFR: 8285400: Add '@apiNote' to the APIs defined in
 Java SE 8 MR 3
In-Reply-To: <0kTIOj70nXzBdXmB-M7I08KdmQpWLdtI5d602hqLy2g=.0e20d00d-b2ef-4a3c-836a-b2cdd7f754f5@github.com>
References: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
 <ofo3ZvFoJG_8KKgrcFhgHDtnPm1qqToovB5HmSiEol0=.af17f970-c2f5-48c7-b30e-50c410918fff@github.com>
 <0kTIOj70nXzBdXmB-M7I08KdmQpWLdtI5d602hqLy2g=.0e20d00d-b2ef-4a3c-836a-b2cdd7f754f5@github.com>
Message-ID: <IVk_f1nRJeKC3uXruMTcD53jgn7sYsjXJJ88rtOi7rU=.4e6456a3-8cd3-4d7e-8fa3-d1dc8cabd136@github.com>

On Tue, 26 Apr 2022 00:28:38 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> jdk/src/share/classes/javax/net/ssl/SSLEngine.java line 1356:
>> 
>>> 1354:      *
>>> 1355:      * @apiNote This method is defined in Java SE 8 Maintenance Release 3.
>>> 1356:      *
>> 
>> IMHO, this needs a separator here to separate the existing API from the addition.  Or maybe a second `@apiNote`?   It currently renders as this:
>> 
>>     API Note:
>>     This method is defined in Java SE 8 Maintenance Release 3. This method 
>>     should be called by TLS server application...
>
> I suggest using `<p>`  to start with a new paragraph.

I'm guessing @mlchung meant `<p>`.  Her suggestion didn't render correctly.

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/7

From mchung at openjdk.java.net  Tue Apr 26 00:41:54 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 26 Apr 2022 00:41:54 GMT
Subject: [jdk8u-ri] RFR: 8285400: Add '@apiNote' to the APIs defined in
 Java SE 8 MR 3
In-Reply-To: <IVk_f1nRJeKC3uXruMTcD53jgn7sYsjXJJ88rtOi7rU=.4e6456a3-8cd3-4d7e-8fa3-d1dc8cabd136@github.com>
References: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
 <ofo3ZvFoJG_8KKgrcFhgHDtnPm1qqToovB5HmSiEol0=.af17f970-c2f5-48c7-b30e-50c410918fff@github.com>
 <0kTIOj70nXzBdXmB-M7I08KdmQpWLdtI5d602hqLy2g=.0e20d00d-b2ef-4a3c-836a-b2cdd7f754f5@github.com>
 <IVk_f1nRJeKC3uXruMTcD53jgn7sYsjXJJ88rtOi7rU=.4e6456a3-8cd3-4d7e-8fa3-d1dc8cabd136@github.com>
Message-ID: <EqH4PmM-gYUQFFbmcikZTDzoVb8mIh3jq4kntE7UuPw=.d9ab6eac-1e40-4af7-b9ec-fe1299c48ea4@github.com>

On Tue, 26 Apr 2022 00:35:18 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> I suggest using `<p>`  to start with a new paragraph.
>
> I'm guessing @mlchung meant `<p>`.  Her suggestion didn't render correctly.

Yes, that's what I meant.  I updated the formatting of my comment.

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/7

From wetmore at openjdk.java.net  Tue Apr 26 00:41:54 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 26 Apr 2022 00:41:54 GMT
Subject: [jdk8u-ri] RFR: 8285400: Add '@apiNote' to the APIs defined in
 Java SE 8 MR 3
In-Reply-To: <EqH4PmM-gYUQFFbmcikZTDzoVb8mIh3jq4kntE7UuPw=.d9ab6eac-1e40-4af7-b9ec-fe1299c48ea4@github.com>
References: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
 <ofo3ZvFoJG_8KKgrcFhgHDtnPm1qqToovB5HmSiEol0=.af17f970-c2f5-48c7-b30e-50c410918fff@github.com>
 <0kTIOj70nXzBdXmB-M7I08KdmQpWLdtI5d602hqLy2g=.0e20d00d-b2ef-4a3c-836a-b2cdd7f754f5@github.com>
 <IVk_f1nRJeKC3uXruMTcD53jgn7sYsjXJJ88rtOi7rU=.4e6456a3-8cd3-4d7e-8fa3-d1dc8cabd136@github.com>
 <EqH4PmM-gYUQFFbmcikZTDzoVb8mIh3jq4kntE7UuPw=.d9ab6eac-1e40-4af7-b9ec-fe1299c48ea4@github.com>
Message-ID: <Hxg-LuLh9IZD3R1BsFdcos3uH6LCpy0GYuJoiPG_9UY=.48be9d1a-9661-442c-9388-a8fc87bf8854@github.com>

On Tue, 26 Apr 2022 00:38:44 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> I'm guessing @mlchung meant `<p>`.  Her suggestion didn't render correctly.
>
> Yes, that's what I meant.  I updated the formatting of my comment.

FYI: a second `@apiNote` does not render correctly, suggest using <p> which I've verified does.

    API Note:
    This method is defined in Java SE 8 Maintenance Release 3.

    This method should be called by TLS server...

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/7

From duke at openjdk.java.net  Tue Apr 26 05:23:02 2022
From: duke at openjdk.java.net (ktakakuri)
Date: Tue, 26 Apr 2022 05:23:02 GMT
Subject: [jdk8u-dev] RFR: 8278138: OpenJDK8 fails to start on Windows 8.1
 after upgrading compiler to VS2017 [v2]
In-Reply-To: <7R5mxoO1jxxf-q9-Ji6b1rKg9cP6zAm5XPRoa94r2Bw=.27a449bd-c532-43e6-80eb-8384562754c3@github.com>
References: <EY6NkB82WC9qCoUsPJ7dIR5UFKZjdL0hmmjGtvXM8Fw=.aa052a7d-07e8-49c9-bcb7-da6041f567b7@github.com>
 <hIb2H4HpdR8n2Xydq-jAwU1kXD_wSNwt6SkPuAN2Blg=.7dcd092d-bf4a-4811-ae3a-64fc6f596a74@github.com>
 <7R5mxoO1jxxf-q9-Ji6b1rKg9cP6zAm5XPRoa94r2Bw=.27a449bd-c532-43e6-80eb-8384562754c3@github.com>
Message-ID: <8aAc8tbabdHcDCg7QSx1WcFsyFoPacZt0fgEZfTg7m0=.e855ec7f-af9c-4c8b-b5db-6d377f3ff803@github.com>

On Thu, 21 Apr 2022 13:03:59 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> ktakakuri has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update jdk/make/Images.gmk
>>   
>>   Co-authored-by: Joakim Nordstr?m <joakim.nordstrom at oracle.com>
>
> Marked as reviewed by erikj (Reviewer).

@erikj79 
Would you be willing to be a sponsor?

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/25

From jnordstrom at openjdk.java.net  Tue Apr 26 06:26:55 2022
From: jnordstrom at openjdk.java.net (Joakim =?UTF-8?B?Tm9yZHN0csO2bQ==?=)
Date: Tue, 26 Apr 2022 06:26:55 GMT
Subject: [jdk8u-dev] RFR: 8278138: OpenJDK8 fails to start on Windows 8.1
 after upgrading compiler to VS2017 [v2]
In-Reply-To: <hIb2H4HpdR8n2Xydq-jAwU1kXD_wSNwt6SkPuAN2Blg=.7dcd092d-bf4a-4811-ae3a-64fc6f596a74@github.com>
References: <EY6NkB82WC9qCoUsPJ7dIR5UFKZjdL0hmmjGtvXM8Fw=.aa052a7d-07e8-49c9-bcb7-da6041f567b7@github.com>
 <hIb2H4HpdR8n2Xydq-jAwU1kXD_wSNwt6SkPuAN2Blg=.7dcd092d-bf4a-4811-ae3a-64fc6f596a74@github.com>
Message-ID: <_GJVqpp416f4KQK5veJZh2YRsaZRgnLfT4sCzjLlvKs=.aff167f8-0513-42ef-832d-396023fa72f2@github.com>

On Wed, 13 Apr 2022 08:27:13 GMT, ktakakuri <duke at openjdk.java.net> wrote:

>> Could you please review the 8278138 bug fixes?
>> 
>> This problem is caused by missing DLL's which vcruntime140.dll depends on.
>> I think it is needed to copy the missing DLL's into jdk/bin as like jdk/jre/bin.
>> I fix to copy api-ms-win-*.dll files to jdk/bin when images directory is created.
>
> ktakakuri has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update jdk/make/Images.gmk
>   
>   Co-authored-by: Joakim Nordstr?m <joakim.nordstrom at oracle.com>

This needs to be approved according to https://wiki.openjdk.java.net/display/jdk8u/Main#Main-FixApprovals
I'm in the process of adding the needed labels to the JBS issue, and then a maintainer will take care of the approval.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/25

From dongbohe at openjdk.java.net  Tue Apr 26 07:23:57 2022
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Tue, 26 Apr 2022 07:23:57 GMT
Subject: [jdk8u-dev] RFR: 8173361: various crashes in
 JvmtiExport::post_compiled_method_load
In-Reply-To: <XYwkEcOZQzAj1pJk9SBS6SO4GG90ETqkVbZaWlkM4ME=.530b79e3-d82f-40c3-a553-46ea1a5377f8@github.com>
References: <XYwkEcOZQzAj1pJk9SBS6SO4GG90ETqkVbZaWlkM4ME=.530b79e3-d82f-40c3-a553-46ea1a5377f8@github.com>
Message-ID: <OYQSI3BEb0C-cx7PLz78GfDLVNdWmA2yi2Vgq4RUogo=.dc6c2f5b-f32b-42cb-8a22-9716878b1d3f@github.com>

On Thu, 17 Mar 2022 11:07:23 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

> Hi,
> 
> This PR has been reviewed before move to github: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-January/014487.html
> 
> Thanks,
> hedongbo

ping...

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/9

From aph at redhat.com  Tue Apr 26 10:01:46 2022
From: aph at redhat.com (Andrew Haley)
Date: Tue, 26 Apr 2022 11:01:46 +0100
Subject: hg.ojn/aarch64-port: Repos still in use?
Message-ID: <7c2f4404-ffef-711b-b167-cf24b134a7df@redhat.com>

Do we still need http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/?

It's finished now, so we should move it to read-only.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From aph-open at littlepinkcloud.com  Tue Apr 26 14:43:11 2022
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Tue, 26 Apr 2022 15:43:11 +0100
Subject: hg.ojn/aarch64-port: Repos still in use?
Message-ID: <a6a1c988-3f9e-1339-8595-6868c18c3ecd@littlepinkcloud.com>

Do we still need http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/?

It's finished now, so we should move it to read-only.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From iris.clark at oracle.com  Tue Apr 26 16:30:00 2022
From: iris.clark at oracle.com (Iris Clark)
Date: Tue, 26 Apr 2022 16:30:00 +0000
Subject: hg.ojn/aarch64-port: Repos still in use?
In-Reply-To: <a6a1c988-3f9e-1339-8595-6868c18c3ecd@littlepinkcloud.com>
References: <a6a1c988-3f9e-1339-8595-6868c18c3ecd@littlepinkcloud.com>
Message-ID: <SJ0PR10MB5440F3B4ECA09C574978E2B3FBFB9@SJ0PR10MB5440.namprd10.prod.outlook.com>

Done!

https://hg.openjdk.java.net/aarch64-port

Thanks,
Iris

________________________________
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Andrew Haley <aph-open at littlepinkcloud.com>
Sent: Tuesday, April 26, 2022 7:43 AM
To: jdk8u-dev at openjdk.java.net <jdk8u-dev at openjdk.java.net>
Subject: hg.ojn/aarch64-port: Repos still in use?

Do we still need http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/?

It's finished now, so we should move it to read-only.

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From andrew at openjdk.java.net  Tue Apr 26 17:31:09 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Tue, 26 Apr 2022 17:31:09 GMT
Subject: [jdk8u-dev] RFR: JDK-8284772: 8u GHA: Use GCC Major Version
 Dependencies Only
In-Reply-To: <4Uxl3-p-q0i5YdshD3dPGatT3RoYumAjsLx3d-nxT1Y=.77f8ad28-af62-4027-ad7c-b8d81023ce6a@github.com>
References: <9orZk-QXNP7EXd6GiWGqF_xsajhliPEPoZmuZTdjOjk=.fb226304-5bca-4c14-afe4-0f41eb99f74b@github.com>
 <4Uxl3-p-q0i5YdshD3dPGatT3RoYumAjsLx3d-nxT1Y=.77f8ad28-af62-4027-ad7c-b8d81023ce6a@github.com>
Message-ID: <iYCI1fuJ3wj_MgfgTyXnRs9CrQROI42b-ofPoxFnHeo=.068dc00b-f371-4692-8470-7adc47c87e07@github.com>

On Mon, 25 Apr 2022 23:47:05 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Major versions of GCC often cause problems with OpenJDK. Fedora's eager adoption of them means we often encounter these early. [JDK-8282231](https://bugs.openjdk.java.net/browse/JDK-8282231) is just the latest example from the introduction of GCC 12.
>> 
>> However, the GHA workflow in OpenJDK doesn't just depend on a major version of GCC - which is actually contained in the Ubuntu package name of `gcc-9` itself - but the full revision number, even down to local packaging changes.
>> 
>> I believe this is overkill and leads to valuable time being wasted on issues like [JDK-8283778](https://bugs.openjdk.java.net/browse/JDK-8283778) where the GCC version itself didn't change at all, just the Ubuntu version suffix.
>> 
>> Rather than maintain this for 8u, I suggest we just depend on `gcc-9` which is already a pretty modern version for 8u. I have yet to see an issue be specific to a minor GCC version bump, whereas the current setup is pretty much guaranteed to mean further fixes to the GitHub workflow every time the Ubuntu packager produces a new build.
>> 
>> Note that the x86-32 Linux build already uses just `gcc-9-multilib` which is why it hasn't been broken by the latest GCC update.
>
> Marked as reviewed by serb (Reviewer).

Thanks @mrserb. I've flagged this for 8u approval.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/35

From hohensee at amazon.com  Tue Apr 26 18:41:37 2022
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 26 Apr 2022 18:41:37 +0000
Subject: [jdk8u-dev] RFR: 8266187: Memory leak in appendBootClassPath()
Message-ID: <161F9C2B-2CF3-4775-9D93-B3D108FB59ED@amazon.com>

I believe new patches go to the jdk8u-dev github repo, not the old mercurial one.

Thanks,
Paul

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Zhengyu Gu <zgu at openjdk.java.net>
Date: Tuesday, April 19, 2022 at 7:45 AM
To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: [jdk8u-dev] RFR: 8266187: Memory leak in appendBootClassPath()

ackport this patch for parity with Oracle 8u331. It fixes a memory leak
and risk is low,

Bug: https://bugs.openjdk.java.net/browse/JDK-8266187
Patch: https://github.com/openjdk/jdk/commit/aa90df6f51940a73f9aa078a32768855c8568034

The original patch does not apply cleanly. The conflict is copyright year line. Resolved manually.

The original code review thread: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-December/014484.html

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

Commit messages:
 - 8266187: Memory leak in appendBootClassPath()

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/42


From hohensee at amazon.com  Tue Apr 26 18:43:08 2022
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 26 Apr 2022 18:43:08 +0000
Subject: [jdk8u-dev] RFR: 8266187: Memory leak in appendBootClassPath()
In-Reply-To: <161F9C2B-2CF3-4775-9D93-B3D108FB59ED@amazon.com>
References: <161F9C2B-2CF3-4775-9D93-B3D108FB59ED@amazon.com>
Message-ID: <16510E49-FD6E-43F9-806E-1F4C00DAE6C6@amazon.com>

Whoops, never mind, didn't read all the way to the bottom (

?-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of "Hohensee, Paul" <hohensee at amazon.com>
Date: Tuesday, April 26, 2022 at 11:42 AM
To: Zhengyu Gu <zgu at openjdk.java.net>, "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: Re: [jdk8u-dev] RFR: 8266187: Memory leak in appendBootClassPath()

I believe new patches go to the jdk8u-dev github repo, not the old mercurial one.

Thanks,
Paul

-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.java.net> on behalf of Zhengyu Gu <zgu at openjdk.java.net>
Date: Tuesday, April 19, 2022 at 7:45 AM
To: "jdk8u-dev at openjdk.java.net" <jdk8u-dev at openjdk.java.net>
Subject: [jdk8u-dev] RFR: 8266187: Memory leak in appendBootClassPath()

ackport this patch for parity with Oracle 8u331. It fixes a memory leak
and risk is low,

Bug: https://bugs.openjdk.java.net/browse/JDK-8266187
Patch: https://github.com/openjdk/jdk/commit/aa90df6f51940a73f9aa078a32768855c8568034

The original patch does not apply cleanly. The conflict is copyright year line. Resolved manually.

The original code review thread: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-December/014484.html

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

Commit messages:
 - 8266187: Memory leak in appendBootClassPath()

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/42



From poonam at openjdk.java.net  Tue Apr 26 18:57:57 2022
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Tue, 26 Apr 2022 18:57:57 GMT
Subject: [jdk8u-ri] RFR: 8285400: Add '@apiNote' to the APIs defined in
 Java SE 8 MR 3 [v2]
In-Reply-To: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
References: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
Message-ID: <zidFCQF28dvyVvqmW2ERI3CyhYT8u9XvIj7J8xAX3Cg=.1c5a4d44-cd8c-4bc9-94b9-5258d4bb1689@github.com>

> This change adds "apiNote This method is defined in Java SE 8 Maintenance Release 3." to the doc comments of the new APIs added with the following changesets in Java SE MR3 :
> 
> 1. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/b26b096d4c89
> 2. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/6bada58189de

Poonam Bajaj has updated the pull request incrementally with one additional commit since the last revision:

  addressed the review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk8u-ri/pull/7/files
  - new: https://git.openjdk.java.net/jdk8u-ri/pull/7/files/ead32fc1..7cdcb51c

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

  Stats: 14 lines in 5 files changed: 7 ins; 3 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk8u-ri/pull/7.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-ri pull/7/head:pull/7

PR: https://git.openjdk.java.net/jdk8u-ri/pull/7

From poonam at openjdk.java.net  Tue Apr 26 18:57:57 2022
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Tue, 26 Apr 2022 18:57:57 GMT
Subject: [jdk8u-ri] RFR: 8285400: Add '@apiNote' to the APIs defined in
 Java SE 8 MR 3
In-Reply-To: <UMdrubx26YUJAFN9wUXohGhLwyz0TeQzdPMgV8IglW4=.3339468c-768f-4d3d-87b3-0bd796d20ad1@github.com>
References: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
 <tSNPjJZhDXGtEDNG3jBuC1ZluHmrKW9uMODFmneHjIU=.40d9fe78-d404-4e16-9089-b25be5c6310e@github.com>
 <bOShxP_07X036E33YOt1Te0YrB3Bhu6IZldL4rqI1mk=.b7b5d036-2276-4d0b-8dda-a8382613ef49@github.com>
 <UMdrubx26YUJAFN9wUXohGhLwyz0TeQzdPMgV8IglW4=.3339468c-768f-4d3d-87b3-0bd796d20ad1@github.com>
Message-ID: <Z5CzQU4e7YOBJAA2to2UYSZHzUl3L3eZHAv2txK3UtM=.764c28ad-d46e-48ee-aa7f-7fae36b4c114@github.com>

On Tue, 26 Apr 2022 00:10:56 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>>> How about the SHA512_224 and SHA512_256 constants in java/security/spec/MGF1ParameterSpec.java? Should add the since and apiNot javadoc tags as well?
>> 
>> The `PSSParameterSpec.TRAILER_FIELD_BC` needs the `@apiNote` too?
>
> Same concern as  @valeriepeng on both the `MGF1ParameterSpec` and `PSSParameterSpec` field omissions.  We did add a `@since` in `PSSParameterSpec`, but not `MGF1ParameterSpec`.

@bradfordwetmore @valeriepeng I have addressed all the concerns and have updated the PR. Please take a look.

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/7

From wetmore at openjdk.java.net  Tue Apr 26 19:03:03 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 26 Apr 2022 19:03:03 GMT
Subject: [jdk8u-ri] RFR: 8285400: Add '@apiNote' to the APIs defined in
 Java SE 8 MR 3 [v2]
In-Reply-To: <zidFCQF28dvyVvqmW2ERI3CyhYT8u9XvIj7J8xAX3Cg=.1c5a4d44-cd8c-4bc9-94b9-5258d4bb1689@github.com>
References: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
 <zidFCQF28dvyVvqmW2ERI3CyhYT8u9XvIj7J8xAX3Cg=.1c5a4d44-cd8c-4bc9-94b9-5258d4bb1689@github.com>
Message-ID: <cu2hLI13LPS-wMtjBtUZvpEWhimj9gznM6vfvkBtlh4=.472bafdb-7572-451d-9ea6-28d33a8e0bab@github.com>

On Tue, 26 Apr 2022 18:57:57 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

>> This change adds "apiNote This method is defined in Java SE 8 Maintenance Release 3." to the doc comments of the new APIs added with the following changesets in Java SE MR3 :
>> 
>> 1. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/b26b096d4c89
>> 2. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/6bada58189de
>
> Poonam Bajaj has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressed the review comments

Copyright date updates not complete.

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/7

From mchung at openjdk.java.net  Tue Apr 26 19:10:54 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 26 Apr 2022 19:10:54 GMT
Subject: [jdk8u-ri] RFR: 8285400: Add '@apiNote' to the APIs defined in
 Java SE 8 MR 3 [v2]
In-Reply-To: <zidFCQF28dvyVvqmW2ERI3CyhYT8u9XvIj7J8xAX3Cg=.1c5a4d44-cd8c-4bc9-94b9-5258d4bb1689@github.com>
References: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
 <zidFCQF28dvyVvqmW2ERI3CyhYT8u9XvIj7J8xAX3Cg=.1c5a4d44-cd8c-4bc9-94b9-5258d4bb1689@github.com>
Message-ID: <M6h8AMa7HW0noZ3MQG0TvbcgNcTP4AIOWZk4Cp8dVNM=.b5686e74-cfc0-420a-951a-c9b395da4096@github.com>

On Tue, 26 Apr 2022 18:57:57 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

>> This change adds "apiNote This method is defined in Java SE 8 Maintenance Release 3." to the doc comments of the new APIs added with the following changesets in Java SE MR3 :
>> 
>> 1. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/b26b096d4c89
>> 2. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/6bada58189de
>
> Poonam Bajaj has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressed the review comments

This change looks good to me.  Thanks for doing this update.   

Can you file a JBS issue to fix in the mainline to add back `@since` in the constants in `MGF1ParameterSpec` class?  Thanks.

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

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk8u-ri/pull/7

From wetmore at openjdk.java.net  Tue Apr 26 20:25:47 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 26 Apr 2022 20:25:47 GMT
Subject: [jdk8u-ri] RFR: 8285400: Add '@apiNote' to the APIs defined in
 Java SE 8 MR 3 [v2]
In-Reply-To: <M6h8AMa7HW0noZ3MQG0TvbcgNcTP4AIOWZk4Cp8dVNM=.b5686e74-cfc0-420a-951a-c9b395da4096@github.com>
References: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
 <zidFCQF28dvyVvqmW2ERI3CyhYT8u9XvIj7J8xAX3Cg=.1c5a4d44-cd8c-4bc9-94b9-5258d4bb1689@github.com>
 <M6h8AMa7HW0noZ3MQG0TvbcgNcTP4AIOWZk4Cp8dVNM=.b5686e74-cfc0-420a-951a-c9b395da4096@github.com>
Message-ID: <ee-HhFkxJ7sLCY-9-DeJo3S4Tep6TW3bKUdCBFc24dY=.7f617cc2-588a-4ae3-8c50-612c2481aa07@github.com>

On Tue, 26 Apr 2022 19:07:11 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This change looks good to me. Thanks for doing this update.
> 
> Can you file a JBS issue to fix in the mainline to add back `@since` in the constants in `MGF1ParameterSpec` class? Thanks.

Good idea, thanks @mlchung!

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/7

From valeriep at openjdk.java.net  Tue Apr 26 20:30:50 2022
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 26 Apr 2022 20:30:50 GMT
Subject: [jdk8u-ri] RFR: 8285400: Add '@apiNote' to the APIs defined in
 Java SE 8 MR 3 [v2]
In-Reply-To: <zidFCQF28dvyVvqmW2ERI3CyhYT8u9XvIj7J8xAX3Cg=.1c5a4d44-cd8c-4bc9-94b9-5258d4bb1689@github.com>
References: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
 <zidFCQF28dvyVvqmW2ERI3CyhYT8u9XvIj7J8xAX3Cg=.1c5a4d44-cd8c-4bc9-94b9-5258d4bb1689@github.com>
Message-ID: <8NIGBcebPhNjFHZRTXoyw2RbFxOlknhy1fUg4kTores=.49963d1d-2571-4e45-a7b9-831f4a854159@github.com>

On Tue, 26 Apr 2022 18:57:57 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

>> This change adds "apiNote This method is defined in Java SE 8 Maintenance Release 3." to the doc comments of the new APIs added with the following changesets in Java SE MR3 :
>> 
>> 1. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/b26b096d4c89
>> 2. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/6bada58189de
>
> Poonam Bajaj has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressed the review comments

Marked as reviewed by valeriep (Reviewer).

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/7

From poonam at openjdk.java.net  Tue Apr 26 20:55:42 2022
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Tue, 26 Apr 2022 20:55:42 GMT
Subject: [jdk8u-ri] RFR: 8285400: Add '@apiNote' to the APIs defined in
 Java SE 8 MR 3 [v3]
In-Reply-To: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
References: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
Message-ID: <h0n_14ofAkOkTgaq7ej1u6ER-Xzdn1-h1ZPos9XNB8s=.fc96b1fa-f278-4d06-9997-9f0d1a86c6d2@github.com>

> This change adds "apiNote This method is defined in Java SE 8 Maintenance Release 3." to the doc comments of the new APIs added with the following changesets in Java SE MR3 :
> 
> 1. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/b26b096d4c89
> 2. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/6bada58189de

Poonam Bajaj has updated the pull request incrementally with one additional commit since the last revision:

  updated copyrights

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

Changes:
  - all: https://git.openjdk.java.net/jdk8u-ri/pull/7/files
  - new: https://git.openjdk.java.net/jdk8u-ri/pull/7/files/7cdcb51c..0006dac8

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

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/7

From wetmore at openjdk.java.net  Tue Apr 26 20:55:42 2022
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 26 Apr 2022 20:55:42 GMT
Subject: [jdk8u-ri] RFR: 8285400: Add '@apiNote' to the APIs defined in
 Java SE 8 MR 3 [v3]
In-Reply-To: <h0n_14ofAkOkTgaq7ej1u6ER-Xzdn1-h1ZPos9XNB8s=.fc96b1fa-f278-4d06-9997-9f0d1a86c6d2@github.com>
References: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
 <h0n_14ofAkOkTgaq7ej1u6ER-Xzdn1-h1ZPos9XNB8s=.fc96b1fa-f278-4d06-9997-9f0d1a86c6d2@github.com>
Message-ID: <v_orAjaJecxillLNDv31pmQWpr7EecxheOGO03arXtI=.b918379e-4096-4c68-b050-9cd2806de5d1@github.com>

On Tue, 26 Apr 2022 20:52:56 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

>> This change adds "apiNote This method is defined in Java SE 8 Maintenance Release 3." to the doc comments of the new APIs added with the following changesets in Java SE MR3 :
>> 
>> 1. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/b26b096d4c89
>> 2. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/6bada58189de
>
> Poonam Bajaj has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated copyrights

LGTM.

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

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.java.net/jdk8u-ri/pull/7

From duke at openjdk.java.net  Wed Apr 27 23:05:24 2022
From: duke at openjdk.java.net (Long Yang)
Date: Wed, 27 Apr 2022 23:05:24 GMT
Subject: [jdk8u-dev] RFR: 8260589: Crash in
 JfrTraceIdLoadBarrier::load(_jclass*)
Message-ID: <s3gnxE6q7VA8DMcUl6HeLBjf0La8dw6-a9mkE45tC18=.ec1f7e5b-eb11-4dc0-b593-019baa76ea28@github.com>

Hi!

Please review the backport of JDK-8260589 to 8u.
This crash problem is easy to reproduce, so I feel it is necessary to backport it to 8u.

3 months ago, I launched webrev and it has been reviewed by Zhengyu Gu ([the review mail link](https://mail.openjdk.java.net/pipermail/jdk8u-dev/2022-March/014715.html)), thanks a lot to Zhengyu and Mario.
Recently, I learned that the review method of 8u was changed to github, so I re-launched it in the new way.

Bug: https://bugs.openjdk.java.net/browse/JDK-8260589
11u commit: https://github.com/openjdk/jdk11u-dev/commit/1d204c554ffe969567161cc05992486ff47d346d
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

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

Commit messages:
 - 8260589: Crash in JfrTraceIdLoadBarrier::load(_jclass*)

Changes: https://git.openjdk.java.net/jdk8u-dev/pull/36/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=36&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260589
  Stats: 230 lines in 6 files changed: 219 ins; 8 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/36.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/36/head:pull/36

PR: https://git.openjdk.java.net/jdk8u-dev/pull/36

From andrew at openjdk.java.net  Thu Apr 28 02:11:37 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Thu, 28 Apr 2022 02:11:37 GMT
Subject: [jdk8u-dev] RFR: Merge jdk8u:master
Message-ID: <dOVSEU5e0XH9bedS_jvw-TmetHhrzxdc-VU6dITgk4s=.12607676-af65-4c24-849f-4df014e1b5d1@github.com>

Merge jdk8u332-ga back into 8u-dev

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

Commit messages:
 - Merge jdk8u:master
 - Added tag jdk8u332-b09 for changeset 37aca7715d13
 - 8284936: Fix Java 7 bootstrap breakage due to use of Arrays.stream
 - Added tag jdk8u332-b08 for changeset 95b31159fdfd
 - 8284920: Incorrect Token type causes XPath expression to return empty result
 - Added tag jdk8u332-b07 for changeset 6d526dbc3432
 - 8284548: Invalid XPath expression causes StringIndexOutOfBoundsException
 - 8281388: Change wrapping of EncryptedPrivateKeyInfo
 - 8282300: Throws NamingException instead of InvalidNameException after JDK-8278972
 - 8278972: Improve URL supports
 - ... and 16 more: https://git.openjdk.java.net/jdk8u-dev/compare/3647d987...f7174b49

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=48&range=00.0
 - jdk8u:master: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=48&range=00.1

Changes: https://git.openjdk.java.net/jdk8u-dev/pull/48/files
  Stats: 3532 lines in 63 files changed: 2406 ins; 729 del; 397 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/48.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/48/head:pull/48

PR: https://git.openjdk.java.net/jdk8u-dev/pull/48

From iris at openjdk.java.net  Thu Apr 28 07:34:51 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 28 Apr 2022 07:34:51 GMT
Subject: [jdk8u-ri] RFR: 8201793: (ref) Reference object should not support
 cloning [v2]
In-Reply-To: <q2PVwf_VGTJ-8HdurxrWOVw-0ZJDr34-dpdC2xwp3Oc=.1e2aa826-abe2-46d0-add7-5701a734089d@github.com>
References: <K_wvGr0wKQKsVQzfYQu-5ehjn-BHPCDrx3EQ2ZAlhX0=.1504b393-7438-499d-ac1e-3af967e7a2eb@github.com>
 <q2PVwf_VGTJ-8HdurxrWOVw-0ZJDr34-dpdC2xwp3Oc=.1e2aa826-abe2-46d0-add7-5701a734089d@github.com>
Message-ID: <799Xg3u3txM5OoKJchMAfdHAJipEVvb0Qvllc9WZETM=.0c47d9b3-27f1-456e-a3e8-d7d14f5d279c@github.com>

On Fri, 22 Apr 2022 17:20:33 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

>> This changeset backports the fix for 8201793 to jdk8u-ri.
>> 
>> With this change, `java.lang.ref.Reference::clone` method always throws `CloneNotSupportedException`.
>
> Poonam Bajaj has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed the javadoc comments

Updated @apiNote looks good.

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

Marked as reviewed by iris (Author).

PR: https://git.openjdk.java.net/jdk8u-ri/pull/6

From duke at openjdk.java.net  Thu Apr 28 08:28:45 2022
From: duke at openjdk.java.net (ktakakuri)
Date: Thu, 28 Apr 2022 08:28:45 GMT
Subject: [jdk8u-dev] RFR: 8248876: LoadObject with bad base address created
 for exec file on linux
In-Reply-To: <4Dj9YlKq8P29Rj4dWeokie_HEME7KRMItQpXomF6Fqs=.fb15c3af-748e-4a7f-bc77-117aebf6332e@github.com>
References: <4Dj9YlKq8P29Rj4dWeokie_HEME7KRMItQpXomF6Fqs=.fb15c3af-748e-4a7f-bc77-117aebf6332e@github.com>
Message-ID: <V7hbgDLQNXYCfrMMoQDF3JDTxo6Lb-lOzva7_u5_ECI=.e2d37c86-e491-481c-8cdd-c18e28b691f3@github.com>

On Mon, 25 Apr 2022 08:08:21 GMT, ktakakuri <duke at openjdk.java.net> wrote:

> I would like to backport
> 8248876: LoadObject with bad base address created for exec file on linux.
> 
> The original patch does not apply cleanly to 8u, and this is a clean backport from 11u.
> 
> Testing:
> build on Linux x86_64
> tier1 on Linux x86_64

Could anyone review this backport please?

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/47

From andrew at openjdk.java.net  Thu Apr 28 09:34:29 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Thu, 28 Apr 2022 09:34:29 GMT
Subject: [jdk8u-dev] RFR: Merge jdk8u:master [v2]
In-Reply-To: <dOVSEU5e0XH9bedS_jvw-TmetHhrzxdc-VU6dITgk4s=.12607676-af65-4c24-849f-4df014e1b5d1@github.com>
References: <dOVSEU5e0XH9bedS_jvw-TmetHhrzxdc-VU6dITgk4s=.12607676-af65-4c24-849f-4df014e1b5d1@github.com>
Message-ID: <6nFHPfnjQ8bCaINt5-u1atu605WcS-adsZJJe2pnCzI=.eb16f8f6-f5f1-4d9b-8ec2-73d2e00ebadf@github.com>

> Merge jdk8u332-ga back into 8u-dev

Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Merge jdk8u:master
 - 8190753: (zipfs): Accessing a large entry (> 2^31 bytes) leads to a negative initial size for ByteArrayOutputStream
   
   Reviewed-by: phh, andrew
   Backport-of: 8a9cda2d84513ab49a54e1d2a7b530f0bae05c61
 - 8261107: ArrayIndexOutOfBoundsException in the ICC_Profile.getInstance(InputStream)
   
   Reviewed-by: phh
   Backport-of: 06b33a0ad78d1577711af22020cf5fdf25112523
 - 8253424: Add support for running pre-submit testing using GitHub Actions
   8253865: Pre-submit testing using GitHub Actions does not detect failures reliably
   8254054: Pre-submit testing using GitHub Actions should not use the deprecated set-env command
   8254173: Add Zero, Minimal hotspot targets to submit workflow
   8254175: Build no-pch configuration in debug mode for submit checks
   8254282: Add Linux x86_32 builds to submit workflow
   8255373: Submit workflow artifact name is always "test-results_.zip"
   8255895: Submit workflow artifacts miss hs_errs/replays due to ZIP include mismatch
   8256127: Add cross-compiled foreign architectures builds to submit workflow
   8256277: Github Action build on macOS should define OS and Xcode versions
   8256354: Github Action build on Windows should define OS and MSVC versions
   8256414: add optimized build to submit workflow
   8256393: Github Actions build on Linux should define OS and GCC versions
   8256747: GitHub Actions: decouple the hotspot build-only jobs from Linux x64 testing
   8257056: Submit workflow should apt-get update to avoid package installation errors
   8259924: GitHub actions fail on Linux x86_32 with "Could not configure libc6:i386"
   8260460: GitHub actions still fail on Linux x86_32 with "Could not configure libc6:i386"
   8263667: Avoid running GitHub actions on branches named pr/*
   8255305: Add Linux x86_32 tier1 to submit workflow
   8255352: Archive important test outputs in submit workflow
   8282225: GHA: Allow one concurrent run per PR only
   
   Co-authored-by: Alex Kasko <akasko at openjdk.org>
   Co-authored-by: Zden?k ?ambersk? <zzambers at redhat.com>
   Reviewed-by: sgehwolf
   Backport-of: 1faefed218051c324bdb5c7c10369050d6c9dd44
 - 8281814: Debuginfo.diz contains redundant build path after backport JDK-8025936
   
   8u backport of JDK-8035134
   
   Reviewed-by: sgehwolf
 - 8255239: The timezone of the hs_err_pid log file is corrupted in Japanese locale
   
   Reviewed-by: andrew
   Backport-of: b46d73bee808af7891b699df30a5a6dec3f5139f
 - 8274751: Drag And Drop hangs on Windows
   
   Backport-of: 7a0a6c95a53c6cb3340328d6543a97807320b740
 - 8274658: ISO 4217 Amendment 170 Update
   
   Reviewed-by: sgehwolf
   Backport-of: f2404d60de2b58c590bf885f5cce50c289073673
 - 8132256: jaxp: Investigate removal of com/sun/org/apache/bcel/internal/util/ClassPath.java
   
   Com/sun/org/apache/bcel/internal/util/ClassPath.java removed
   
   Reviewed-by: andrew
   Backport-of: 6e586e8a3b8807652218c4caf97ef501f42d7f36
 - 8129572: Cleanup usage of getResourceAsStream in jaxp
   
   Reviewed-by: andrew
   Backport-of: 4ebbfc918f558e73c05f471cfd3ab2b11dcf5a75
 - ... and 8 more: https://git.openjdk.java.net/jdk8u-dev/compare/cc541e91...f7174b49

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

Changes: https://git.openjdk.java.net/jdk8u-dev/pull/48/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=48&range=01
  Stats: 7047 lines in 74 files changed: 5854 ins; 926 del; 267 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/48.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/48/head:pull/48

PR: https://git.openjdk.java.net/jdk8u-dev/pull/48

From andrew at openjdk.java.net  Thu Apr 28 09:34:29 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Thu, 28 Apr 2022 09:34:29 GMT
Subject: [jdk8u-dev] RFR: Merge jdk8u:master
In-Reply-To: <dOVSEU5e0XH9bedS_jvw-TmetHhrzxdc-VU6dITgk4s=.12607676-af65-4c24-849f-4df014e1b5d1@github.com>
References: <dOVSEU5e0XH9bedS_jvw-TmetHhrzxdc-VU6dITgk4s=.12607676-af65-4c24-849f-4df014e1b5d1@github.com>
Message-ID: <bOSxeQYwF3_cwqKm6bhLesfc1dxe_Bq5YD-ioEqAPUM=.6ae5f4e4-0676-4c01-99d2-cb8545de781d@github.com>

On Thu, 28 Apr 2022 02:05:58 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Merge jdk8u332-ga back into 8u-dev

Both build failures are not new to this merge. Linux x86_64 failure will be fixed when JDK-8284772 is approved. We need to investigate why MacOS has regressed.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/48

From andrew at openjdk.java.net  Thu Apr 28 09:34:29 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Thu, 28 Apr 2022 09:34:29 GMT
Subject: [jdk8u-dev] Integrated: Merge jdk8u:master
In-Reply-To: <dOVSEU5e0XH9bedS_jvw-TmetHhrzxdc-VU6dITgk4s=.12607676-af65-4c24-849f-4df014e1b5d1@github.com>
References: <dOVSEU5e0XH9bedS_jvw-TmetHhrzxdc-VU6dITgk4s=.12607676-af65-4c24-849f-4df014e1b5d1@github.com>
Message-ID: <pJTMIVI4ed1Q1-WPWOhBCavYTuebUp8nmOWBxNZ9SiQ=.bfc8cd14-02de-40df-90b1-89ec1d7633e2@github.com>

On Thu, 28 Apr 2022 02:05:58 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Merge jdk8u332-ga back into 8u-dev

This pull request has now been integrated.

Changeset: 65c4a5d4
Author:    Andrew John Hughes <andrew at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-dev/commit/65c4a5d42e05135754774406389b903e2146758c
Stats:     3532 lines in 63 files changed: 2406 ins; 729 del; 397 mod

Merge

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/48

From andrew at openjdk.java.net  Thu Apr 28 14:43:01 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Thu, 28 Apr 2022 14:43:01 GMT
Subject: [jdk8u-dev] RFR: JDK-8284772: 8u GHA: Use GCC Major Version
 Dependencies Only
In-Reply-To: <9orZk-QXNP7EXd6GiWGqF_xsajhliPEPoZmuZTdjOjk=.fb226304-5bca-4c14-afe4-0f41eb99f74b@github.com>
References: <9orZk-QXNP7EXd6GiWGqF_xsajhliPEPoZmuZTdjOjk=.fb226304-5bca-4c14-afe4-0f41eb99f74b@github.com>
Message-ID: <XmzZq6ynFpGpPesfWxQ5nsZCjsKCADSVePuXodigR9A=.a34f4a30-92e3-482d-a9a7-6c0a10169e00@github.com>

On Tue, 12 Apr 2022 18:59:41 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Major versions of GCC often cause problems with OpenJDK. Fedora's eager adoption of them means we often encounter these early. [JDK-8282231](https://bugs.openjdk.java.net/browse/JDK-8282231) is just the latest example from the introduction of GCC 12.
> 
> However, the GHA workflow in OpenJDK doesn't just depend on a major version of GCC - which is actually contained in the Ubuntu package name of `gcc-9` itself - but the full revision number, even down to local packaging changes.
> 
> I believe this is overkill and leads to valuable time being wasted on issues like [JDK-8283778](https://bugs.openjdk.java.net/browse/JDK-8283778) where the GCC version itself didn't change at all, just the Ubuntu version suffix.
> 
> Rather than maintain this for 8u, I suggest we just depend on `gcc-9` which is already a pretty modern version for 8u. I have yet to see an issue be specific to a minor GCC version bump, whereas the current setup is pretty much guaranteed to mean further fixes to the GitHub workflow every time the Ubuntu packager produces a new build.
> 
> Note that the x86-32 Linux build already uses just `gcc-9-multilib` which is why it hasn't been broken by the latest GCC update.

I see `jdk8u-fix-yes`.

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/35

From andrew at openjdk.java.net  Thu Apr 28 14:44:59 2022
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Thu, 28 Apr 2022 14:44:59 GMT
Subject: [jdk8u-dev] Integrated: JDK-8284772: 8u GHA: Use GCC Major Version
 Dependencies Only
In-Reply-To: <9orZk-QXNP7EXd6GiWGqF_xsajhliPEPoZmuZTdjOjk=.fb226304-5bca-4c14-afe4-0f41eb99f74b@github.com>
References: <9orZk-QXNP7EXd6GiWGqF_xsajhliPEPoZmuZTdjOjk=.fb226304-5bca-4c14-afe4-0f41eb99f74b@github.com>
Message-ID: <VoBajORPvu5IwyU_7iRdCdcA7Qxkr7ei5Zz3OwGwjZk=.47e9d14e-e616-4be2-96c2-9617df82507b@github.com>

On Tue, 12 Apr 2022 18:59:41 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Major versions of GCC often cause problems with OpenJDK. Fedora's eager adoption of them means we often encounter these early. [JDK-8282231](https://bugs.openjdk.java.net/browse/JDK-8282231) is just the latest example from the introduction of GCC 12.
> 
> However, the GHA workflow in OpenJDK doesn't just depend on a major version of GCC - which is actually contained in the Ubuntu package name of `gcc-9` itself - but the full revision number, even down to local packaging changes.
> 
> I believe this is overkill and leads to valuable time being wasted on issues like [JDK-8283778](https://bugs.openjdk.java.net/browse/JDK-8283778) where the GCC version itself didn't change at all, just the Ubuntu version suffix.
> 
> Rather than maintain this for 8u, I suggest we just depend on `gcc-9` which is already a pretty modern version for 8u. I have yet to see an issue be specific to a minor GCC version bump, whereas the current setup is pretty much guaranteed to mean further fixes to the GitHub workflow every time the Ubuntu packager produces a new build.
> 
> Note that the x86-32 Linux build already uses just `gcc-9-multilib` which is why it hasn't been broken by the latest GCC update.

This pull request has now been integrated.

Changeset: 62defc3d
Author:    Andrew John Hughes <andrew at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-dev/commit/62defc3dfc4b9ba5adfe3189f34fe8b3f59b94a0
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8284772: 8u GHA: Use GCC Major Version Dependencies Only

Reviewed-by: serb

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/35

From gnu.andrew at redhat.com  Thu Apr 28 16:02:15 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 28 Apr 2022 17:02:15 +0100
Subject: JDK-8285445 'cannot open file "NUL:"' Windows issue and Potential
 Respin
Message-ID: <Ymq6hwDxlNk3ei+Y@hex.discworld.ac.uk>

Hi all,

8u332 introduced a regression via one of the security fixes which
leads to "NUL:" no longer being usable as a filename on Windows
platforms.

There are already workarounds in place for this; "NUL" will work as
will passing -Djdk.io.File.enableADS=true

There is a fix already in trunk and several Oracle trees which turns
enableADS on by default, so that the current failing behaviour is only
seen when -Djdk.io.File.enableADS=false

Now that the security updates have been merged to 8u-dev [0], we will
be integrating this fix. It will thus appear in the 8u342 release in
July.

What I'm wondering is if people see this as a critical enough issue
to do an 8u335 respin now with this change, rather than waiting for
July? Have you encountered this problem? Are you already having
to patch it locally in your builds?

Note that this only affects the Windows platform, so an 8u335 release
on other platforms would be identical to 8u332 and so there is no
need to rebuild there.

[0] https://github.com/openjdk/jdk8u-dev/commit/65c4a5d42e05135754774406389b903e2146758c

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 erikj at openjdk.java.net  Thu Apr 28 17:04:52 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 28 Apr 2022 17:04:52 GMT
Subject: [jdk8u-ri] Integrated: 8284907: Compact profiles build fails with GNU
 make 4
In-Reply-To: <a1YomLgNSaaWS8vql36eCVvP8ga6HhI-UPNcrdbbktg=.075b1835-f304-4263-9446-589863eda5e2@github.com>
References: <a1YomLgNSaaWS8vql36eCVvP8ga6HhI-UPNcrdbbktg=.075b1835-f304-4263-9446-589863eda5e2@github.com>
Message-ID: <EmtYKt3a3cX-EC_rICzAr4FMw7c1Dx5wcgqjohb6TXQ=.77c88df9-8c27-4048-bf46-7b4cfbad0d3f@github.com>

On Fri, 15 Apr 2022 13:48:24 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The compact profiles jar creation logic relies on what seems to be undefined behavior in GNU make. Pattern rules are unreliable when the file names contain '$'. The specific construct used in CreateJars.gmk works with GNU make 3.81, but fails with version 4 or higher.
> 
> This was originally fixed in 8u60 in [JDK-8067857](https://bugs.openjdk.java.net/browse/JDK-8067857). That change is quite big and not something we want to backport to 8u42. However, since then, GNU make 4 and higher have become quite common on Linux too, and not just in Cygwin where I believe this problem was first encountered. Because of this, I would like to extract just the fix for this, exactly as it was done in [JDK-8067857](https://bugs.openjdk.java.net/browse/JDK-8067857). Here is the original change:
> 
> https://github.com/openjdk/jdk8u-dev/commit/17421c860a6e71e14b0023e686b87c35b2049f69#diff-e580e7e55e76622c538ae8a1b55af984b3e12bba099e493582fff2925b9ae02aR314-R322

This pull request has now been integrated.

Changeset: d63ed0a5
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-ri/commit/d63ed0a562f7f124a38074ae407d7a4e7feb0e58
Stats:     9 lines in 1 file changed: 9 ins; 0 del; 0 mod

8284907: Compact profiles build fails with GNU make 4

Reviewed-by: tbell, ihse

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/2

From scrater at microsoft.com  Thu Apr 28 17:16:09 2022
From: scrater at microsoft.com (Stephanie Crater)
Date: Thu, 28 Apr 2022 17:16:09 +0000
Subject: Port of JEP 386: Alpine Linux Port to jdk8u
Message-ID: <DM6PR21MB161059D978862BE722863B9AA1FD9@DM6PR21MB1610.namprd21.prod.outlook.com>

Hi,

Would the community be open to a port of JEP 386: Alpine Linux Port [1]/JDK-8247589 [2] to OpenJDK jdk8u? A backport of JDK-8247589 to 11u has recently been integrated by BellSoft, and many OpenJDK vendors (BellSoft Liberica, Azul Zulu, Amazon Corretto) provide a jdk8 for Alpine Linux. We believe there is sufficient user demand for Alpine/musl support on jdk8u, but would be interested in the opinions of other vendors on this as well.

Microsoft is part of the Eclipse Adoptium Working Group and has recently trialed a patch which was applied to the 8u322 tag on the jdk8u source tree (for Eclipse Temurin binary production)[3]. That 8u322 based binary passes builds on all platforms (i.e. No regressions on other platforms) and the AQAVit test suite. The Eclipse Temurin Compliance group also reported that the TCK passed.

We would be willing to maintain Alpine Linux in jdk8u but would prefer that there is broad support. Please let me know what you think or if there are any concerns you may have regarding the proposal of this backport.

Thanks,
Stephanie

[1] https://openjdk.java.net/jeps/386
[2] https://bugs.openjdk.java.net/browse/JDK-8247589
[3] https://github.com/adoptium/jdk8u/pull/9


From mchung at openjdk.java.net  Thu Apr 28 17:33:54 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 28 Apr 2022 17:33:54 GMT
Subject: [jdk8u-ri] RFR: 8071507: (ref) Clear phantom reference as soft and
 weak references do [v2]
In-Reply-To: <T6GQa0MGVpYjsxrymTvBDPsS5y8Z6ZmV-kJrzgrkoRE=.8d38b502-0bf5-437a-ae4a-41ea27b0643a@github.com>
References: <ikjRTxf579yNfmrhx-6FN8nX4HwtBQw2jNEWmNsr98I=.de0ba7bc-ebd8-49c5-baba-2dec83c93b64@github.com>
 <T6GQa0MGVpYjsxrymTvBDPsS5y8Z6ZmV-kJrzgrkoRE=.8d38b502-0bf5-437a-ae4a-41ea27b0643a@github.com>
Message-ID: <DH_H_9fIJ20y1k4iXfBOVdeTocuIDXCFg6jblBWechM=.db27725e-9ae0-4feb-800a-3c4edac44ce4@github.com>

On Thu, 21 Apr 2022 16:05:25 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

>> These changes backport the following fixes to jdk8u-ri:
>> - 8071507: (ref) Clear phantom reference as soft and weak references do
>> - 8143847: Remove REF_CLEANER reference category
>> 
>> With these changes, phantom references are automatically cleared by the garbage collector as soft and weak references.
>
> Poonam Bajaj has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Corrected documentation in package.html

[JDK-8285096](https://bugs.openjdk.java.net/browse/JDK-8285096) is the CSR.   Looks like it was not recognized that blocked the integration.  Taking `/csr` out seems to help.

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/4

From poonam at openjdk.java.net  Thu Apr 28 17:33:56 2022
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Thu, 28 Apr 2022 17:33:56 GMT
Subject: [jdk8u-ri] Integrated: 8071507: (ref) Clear phantom reference as soft
 and weak references do
In-Reply-To: <ikjRTxf579yNfmrhx-6FN8nX4HwtBQw2jNEWmNsr98I=.de0ba7bc-ebd8-49c5-baba-2dec83c93b64@github.com>
References: <ikjRTxf579yNfmrhx-6FN8nX4HwtBQw2jNEWmNsr98I=.de0ba7bc-ebd8-49c5-baba-2dec83c93b64@github.com>
Message-ID: <OdIIybMpJ2CZKbSDKoyn6Y5vPb84mTKCaq1Z8EYTifQ=.f2c07593-9171-4e5a-88f5-85fef2f529c7@github.com>

On Tue, 19 Apr 2022 18:01:20 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> These changes backport the following fixes to jdk8u-ri:
> - 8071507: (ref) Clear phantom reference as soft and weak references do
> - 8143847: Remove REF_CLEANER reference category
> 
> With these changes, phantom references are automatically cleared by the garbage collector as soft and weak references.

This pull request has now been integrated.

Changeset: ad6cdea5
Author:    Poonam Bajaj <poonam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-ri/commit/ad6cdea5ae385623afa86251a8278c9c5274f4c1
Stats:     170 lines in 10 files changed: 105 ins; 48 del; 17 mod

8071507: (ref) Clear phantom reference as soft and weak references do
8143847: Remove REF_CLEANER reference category

Reviewed-by: mchung, kbarrett, iris

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/4

From poonam at openjdk.java.net  Thu Apr 28 17:39:56 2022
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Thu, 28 Apr 2022 17:39:56 GMT
Subject: [jdk8u-ri] Integrated: 8175797: (ref) Reference::enqueue method should
 clear the reference object before enqueuing
In-Reply-To: <1V-62a8ZWOHk65p2xhwZlqOu5RqTADUW-WCLXUTxVC4=.1a67a810-a015-4620-be8a-820858c3dbe5@github.com>
References: <1V-62a8ZWOHk65p2xhwZlqOu5RqTADUW-WCLXUTxVC4=.1a67a810-a015-4620-be8a-820858c3dbe5@github.com>
Message-ID: <oCJWGwtMJNquvDxd3lysZQNA7C4Y6axFG301EihRS4o=.3573c4b8-2810-4508-9c33-98d87e168021@github.com>

On Wed, 20 Apr 2022 00:15:58 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> These changes backport the following fixes to jdk8u-ri:
> 
> - 8175797: (ref) Reference::enqueue method should clear the reference object before enqueuing
> - 8178832: (ref) jdk.lang.ref.disableClearBeforeEnqueue property is ignored
> - 8193780: (ref) Remove the undocumented jdk.lang.ref.disableClearBeforeEnqueue system property
> 
> With this fix, the enqueue method clears the reference before enqueuing it to the registered queue.
> 
> The backport of changes to the file _jdk/test/java/lang/ref/ReferenceEnqueue.java_ needed some manual adjustment. Apart from that,  backport of changes to the rest of the files are exact match with the original fixes.

This pull request has now been integrated.

Changeset: 330d63d2
Author:    Poonam Bajaj <poonam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-ri/commit/330d63d2f9e18ba069e11868d4381059c66f480f
Stats:     61 lines in 3 files changed: 52 ins; 3 del; 6 mod

8175797: (ref) Reference::enqueue method should clear the reference object before enqueuing
8178832: (ref) jdk.lang.ref.disableClearBeforeEnqueue property is ignored
8193780: (ref) Remove the undocumented "jdk.lang.ref.disableClearBeforeEnqueue" system property

Reviewed-by: mchung, kbarrett, iris

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/5

From poonam at openjdk.java.net  Thu Apr 28 20:30:15 2022
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Thu, 28 Apr 2022 20:30:15 GMT
Subject: [jdk8u-ri] RFR: 8201793: (ref) Reference object should not support
 cloning [v3]
In-Reply-To: <K_wvGr0wKQKsVQzfYQu-5ehjn-BHPCDrx3EQ2ZAlhX0=.1504b393-7438-499d-ac1e-3af967e7a2eb@github.com>
References: <K_wvGr0wKQKsVQzfYQu-5ehjn-BHPCDrx3EQ2ZAlhX0=.1504b393-7438-499d-ac1e-3af967e7a2eb@github.com>
Message-ID: <tWdCv2Qvr6rCzNTfXRhfSLEWNa00Gj2PYMANXfPqvck=.bc3c2843-5862-4216-9eac-a00eea00d5d6@github.com>

> This changeset backports the fix for 8201793 to jdk8u-ri.
> 
> With this change, `java.lang.ref.Reference::clone` method always throws `CloneNotSupportedException`.

Poonam Bajaj has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - fixed merge conflict
 - Fixed the javadoc comments
 - 8201793: (ref) Reference object should not support cloning

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

Changes: https://git.openjdk.java.net/jdk8u-ri/pull/6/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-ri&pr=6&range=02
  Stats: 121 lines in 2 files changed: 121 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk8u-ri/pull/6.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-ri pull/6/head:pull/6

PR: https://git.openjdk.java.net/jdk8u-ri/pull/6

From poonam at openjdk.java.net  Thu Apr 28 20:45:45 2022
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Thu, 28 Apr 2022 20:45:45 GMT
Subject: [jdk8u-ri] Integrated: 8201793: (ref) Reference object should not
 support cloning
In-Reply-To: <K_wvGr0wKQKsVQzfYQu-5ehjn-BHPCDrx3EQ2ZAlhX0=.1504b393-7438-499d-ac1e-3af967e7a2eb@github.com>
References: <K_wvGr0wKQKsVQzfYQu-5ehjn-BHPCDrx3EQ2ZAlhX0=.1504b393-7438-499d-ac1e-3af967e7a2eb@github.com>
Message-ID: <6JOfcc_mfzBOs1LzC2oV7orNJekH3VIy_XtkYubQUHo=.008f3d48-9409-4afa-a7cb-5bf5f1f6d643@github.com>

On Wed, 20 Apr 2022 00:59:26 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> This changeset backports the fix for 8201793 to jdk8u-ri.
> 
> With this change, `java.lang.ref.Reference::clone` method always throws `CloneNotSupportedException`.

This pull request has now been integrated.

Changeset: 58ec25de
Author:    Poonam Bajaj <poonam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-ri/commit/58ec25de2f383144417eb000efacecb78b30395c
Stats:     121 lines in 2 files changed: 121 ins; 0 del; 0 mod

8201793: (ref) Reference object should not support cloning

Reviewed-by: mchung, kbarrett, iris
Backport-of: bd18ef4c18081d04c89ee9f94e98fd2ef1e2bf38

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/6

From serb at openjdk.java.net  Thu Apr 28 22:17:34 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 28 Apr 2022 22:17:34 GMT
Subject: [jdk8u-dev] RFR: 8285445: cannot open file "NUL:"
Message-ID: <yvKXQV1WpBF_0PSsKX5pLC2rqKlOtr9cejkmWMlpq-4=.25fced26-a745-4676-b05b-0d57e533671b@github.com>

Hi all,
This pull request contains a backport of commit [03cbb48e](https://github.com/openjdk/jdk/commit/03cbb48e6a1d806f204a39bbdbb4bc9be9e57a41) from the [openjdk/jdk](https://git.openjdk.java.net/jdk) repository.
The commit being backported was authored by Brian Burkhalter on 23 Apr 2022 and was reviewed by Mikael Vidstedt.
Thanks!

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

Commit messages:
 - Backport 03cbb48e6a1d806f204a39bbdbb4bc9be9e57a41

Changes: https://git.openjdk.java.net/jdk8u-dev/pull/49/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=49&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285445
  Stats: 57 lines in 2 files changed: 52 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/49.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/49/head:pull/49

PR: https://git.openjdk.java.net/jdk8u-dev/pull/49

From poonam at openjdk.java.net  Fri Apr 29 16:45:50 2022
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Fri, 29 Apr 2022 16:45:50 GMT
Subject: [jdk8u-ri] Integrated: 8285400: Add '@apiNote' to the APIs defined in
 Java SE 8 MR 3
In-Reply-To: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
References: <eHsoGKaRJb7b-l3gPibI026dE1gCUOUj5oxW3ycsUQM=.c7f3aa9b-3be4-4f4b-9626-93fe12789d57@github.com>
Message-ID: <RY3hw0LTr1m1WHYhIZqZmzQ2QkaCAtgxPS3fePoMFTw=.5623b3bc-bfd1-4ca8-8430-0800c4455b7b@github.com>

On Mon, 25 Apr 2022 21:02:05 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> This change adds "apiNote This method is defined in Java SE 8 Maintenance Release 3." to the doc comments of the new APIs added with the following changesets in Java SE MR3 :
> 
> 1. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/b26b096d4c89
> 2. https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/6bada58189de

This pull request has now been integrated.

Changeset: 3740d05c
Author:    Poonam Bajaj <poonam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-ri/commit/3740d05c063e1f80a0808a969a2cc136cafa48cb
Stats:     42 lines in 12 files changed: 26 ins; 2 del; 14 mod

8285400: Add '@apiNote' to the APIs defined in Java SE 8 MR 3

Reviewed-by: wetmore, mchung, valeriep

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/7

From erikj at openjdk.java.net  Fri Apr 29 17:11:44 2022
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 29 Apr 2022 17:11:44 GMT
Subject: [jdk8u-ri] Integrated: 8079087: Add support for Cygwin 2.0
In-Reply-To: <QAmpP64jswlEXckMaTt8ujCgTgtOGhYb7J2lgpmXl2k=.aa1a997b-07b5-4a94-8f5c-be980d47d6fd@github.com>
References: <QAmpP64jswlEXckMaTt8ujCgTgtOGhYb7J2lgpmXl2k=.aa1a997b-07b5-4a94-8f5c-be980d47d6fd@github.com>
Message-ID: <Jv5RcWtdDYJQu65zTxi6pYSWiB1bwiXON4HNg0c5YGo=.208aea30-4b17-4e62-982c-77e9761d9338@github.com>

On Mon, 18 Apr 2022 22:13:20 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This is a backport of three Cygwin related fixes from jdk8u. In order to better facilitate development in jdk8u-ri, I would like to get these fixes in, so that developers may use recent versions of Cygwin as build environment for this repository. I'm not even sure it's possible to install a pre Cygwin 2.0 environment anymore. All three fixes have been used successfully in jdk8u for years.

This pull request has now been integrated.

Changeset: a30a007b
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-ri/commit/a30a007bb2e29c13f764de33a65a7c4d202c42c4
Stats:     21 lines in 3 files changed: 5 ins; 0 del; 16 mod

8079087: Add support for Cygwin 2.0
8176033: New cygwin grep does not match \r as newline
8179675: Build with error on windows with new Cygwin grep

Reviewed-by: iris, tbell
Backport-of: a90ed05109da57e35b9c158cd9aac893f04a6af5

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

PR: https://git.openjdk.java.net/jdk8u-ri/pull/3

From aph at openjdk.java.net  Fri Apr 29 17:46:13 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 29 Apr 2022 17:46:13 GMT
Subject: [jdk8u-dev] RFR: 8285802: AArch64: Consistently handle offsets in
 MacroAssembler as 64-bit quantities
Message-ID: <2yoqXw0kfLZDt3bbPkmgV5zN3AAwFIZ9kLxBwFs-FPM=.4172d6b7-ec13-4416-b7f8-37b08469ddd9@github.com>

This is a backport of [8285802](https://github.com/openjdk/jdk/commit/df4d5cf5f53c1451487e6301d31c196fac029f7a) from the openjdk/jdk repository. It's almost clean, but upstream mainline has a few
cleanups of integer type handling, so there is some additional backporting risk.

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

Commit messages:
 - 8285802: AArch64: Consistently handle offsets in MacroAssembler as 64-bit quantities

Changes: https://git.openjdk.java.net/jdk8u-dev/pull/50/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk8u-dev&pr=50&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8285802
  Stats: 13 lines in 3 files changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk8u-dev/pull/50.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk8u-dev pull/50/head:pull/50

PR: https://git.openjdk.java.net/jdk8u-dev/pull/50

From serb at openjdk.java.net  Fri Apr 29 23:16:59 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 29 Apr 2022 23:16:59 GMT
Subject: [jdk8u-dev] Integrated: 8285445: cannot open file "NUL:"
In-Reply-To: <yvKXQV1WpBF_0PSsKX5pLC2rqKlOtr9cejkmWMlpq-4=.25fced26-a745-4676-b05b-0d57e533671b@github.com>
References: <yvKXQV1WpBF_0PSsKX5pLC2rqKlOtr9cejkmWMlpq-4=.25fced26-a745-4676-b05b-0d57e533671b@github.com>
Message-ID: <HL1lfitgubc-7HP4AyLfuPbNUZJRf65VIUnItbfxFjU=.828b7c6c-2e21-4d98-b4cb-a836f7806d92@github.com>

On Thu, 28 Apr 2022 21:22:10 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Hi all,
> This pull request contains a backport of commit [03cbb48e](https://github.com/openjdk/jdk/commit/03cbb48e6a1d806f204a39bbdbb4bc9be9e57a41) from the [openjdk/jdk](https://git.openjdk.java.net/jdk) repository.
> The commit being backported was authored by Brian Burkhalter on 23 Apr 2022 and was reviewed by Mikael Vidstedt.
> Thanks!

This pull request has now been integrated.

Changeset: 607b14e2
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk8u-dev/commit/607b14e2ba79668abfc1af8e96c47adf176e77af
Stats:     57 lines in 2 files changed: 52 ins; 1 del; 4 mod

8285445: cannot open file "NUL:"

Backport-of: 03cbb48e6a1d806f204a39bbdbb4bc9be9e57a41

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/49

From duke at openjdk.java.net  Sat Apr 30 01:11:43 2022
From: duke at openjdk.java.net (Martijn Verburg)
Date: Sat, 30 Apr 2022 01:11:43 GMT
Subject: [jdk8u-dev] RFR: 8221988: add possibility to build with Visual
 Studio 2019 [v3]
In-Reply-To: <dW5P6oPVvCaaQpDqrUGIjqenRQ5OVCF3ncdSdJ-eHUQ=.c5f30ddf-bd97-441d-af03-2987389150f0@github.com>
References: <x2mVGiERq9FssKsmqM5KC0SgkzK9OQlG9CbIjklKe-I=.2490d700-8ca3-47ee-ab10-362397e51442@github.com>
 <dW5P6oPVvCaaQpDqrUGIjqenRQ5OVCF3ncdSdJ-eHUQ=.c5f30ddf-bd97-441d-af03-2987389150f0@github.com>
Message-ID: <lD9Y-WNIHXlZoWZPGFroDHnoRQ_UvNN4saLOt24XYik=.d438c454-cb60-4244-ab4f-d51ace7eb6ec@github.com>

On Fri, 8 Apr 2022 17:46:57 GMT, Alexey Pavlyutkin <duke at openjdk.java.net> wrote:

>> Hi!
>> 
>> Please review backport of 8221988. This one opens a bunch of backports enabling support of VS2019. **WARNING**: the patch DOES NOT enable the building with MSVS2019 toolkit, that requires 5-6 more backports. The patch ONLY adds recognition of MSVS2019 to the build system.
>> 
>> The 11u patch applied with the following changes:
>> 
>> - changes to absent documentation files skipped
>> - resolved baseline conflicts toolchain_windows.m4
>> - valid MSVS versions were ascending sorted
>> 
>> Verification: `bash configure` under VS2019 prompt.
>> 
>> Regression:
>> 
>> - VS2017 full build (both 64/32-bit): ok
>> - VS2015 full build: ok (requires --with-extra-cflags='/EHsc /wd4091' --with-extra-cxxflags='/EHsc /wd4091')
>> - VS2013 full build: ok
>> - VS2012 full build: ok
>> - VS2010 full build: ok
>> 
>> @RealCLanger @mdoerr if you take a look at this I will be very grateful
>
> Alexey Pavlyutkin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rearrange valid VS versions

Hey all - missed this whilst travelling.  Happy to help test this internally at MSFT

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

PR: https://git.openjdk.java.net/jdk8u-dev/pull/33