From duke at openjdk.org  Fri Jul  1 01:24:51 2022
From: duke at openjdk.org (Poison)
Date: Fri, 1 Jul 2022 01:24:51 GMT
Subject: [jdk8u-dev] RFR: 8214427: probable bug in logic of
 ConcurrentHashMap.addCount()
In-Reply-To: <QCQg7KlhetYqnhjptw0IYTJy9X6h_Y3LLHUtl0-43Gk=.3188d4c9-381e-43f5-b8a7-f9ee3af4073e@github.com>
References: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
 <QCQg7KlhetYqnhjptw0IYTJy9X6h_Y3LLHUtl0-43Gk=.3188d4c9-381e-43f5-b8a7-f9ee3af4073e@github.com>
Message-ID: <CizVcBGympScf_xBuQgEnl1cSeFOBNlp-DhinzdtqIc=.8a0800df-62b2-478b-9e17-546565738098@github.com>

On Thu, 12 May 2022 18:40:26 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> 8214427: probable bug in logic of ConcurrentHashMap.addCount()
>> 
>> This backport fixes the problem that the MAX_RESIZERS control does not take effect when multi-threaded expansion in ConcurrentHashMap.
>
> This is not in 11u as far as I can see. It should go there first before going into 8.

@jerboaa 11u now includes a backport of 8214427.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/18

From sgehwolf at openjdk.org  Mon Jul  4 08:59:39 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 4 Jul 2022 08:59:39 GMT
Subject: [jdk8u-dev] RFR: 8214427: probable bug in logic of
 ConcurrentHashMap.addCount()
In-Reply-To: <CizVcBGympScf_xBuQgEnl1cSeFOBNlp-DhinzdtqIc=.8a0800df-62b2-478b-9e17-546565738098@github.com>
References: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
 <QCQg7KlhetYqnhjptw0IYTJy9X6h_Y3LLHUtl0-43Gk=.3188d4c9-381e-43f5-b8a7-f9ee3af4073e@github.com>
 <CizVcBGympScf_xBuQgEnl1cSeFOBNlp-DhinzdtqIc=.8a0800df-62b2-478b-9e17-546565738098@github.com>
Message-ID: <2EllIPiRrAfzgwTWVIETeROCQqC4B0jYA5WcoEpLlHs=.ba18f6ec-92f0-456e-b188-fa9a2163ead1@github.com>

On Fri, 1 Jul 2022 01:21:47 GMT, Poison <duke at openjdk.org> wrote:

>> This is not in 11u as far as I can see. It should go there first before going into 8.
>
> @jerboaa 11u now includes a backport of 8214427.

@tianshuang Please enable testing (see the `Details` link), and merge the current master branch and push to the PR again, so that pre-integration tests run properly.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/18

From duke at openjdk.org  Mon Jul  4 09:11:46 2022
From: duke at openjdk.org (Poison)
Date: Mon, 4 Jul 2022 09:11:46 GMT
Subject: [jdk8u-dev] RFR: 8214427: probable bug in logic of
 ConcurrentHashMap.addCount() [v2]
In-Reply-To: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
References: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
Message-ID: <vtdVLByJ-U5hK3ZxqijdhQcezk43ljmSEqrkUmNbZgI=.fe061860-ba0c-4d31-a588-2596e3d41f76@github.com>

> 8214427: probable bug in logic of ConcurrentHashMap.addCount()
> 
> This backport fixes the problem that the MAX_RESIZERS control does not take effect when multi-threaded expansion in ConcurrentHashMap.

Poison has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'openjdk:master' into backport-8214427
 - Backport 8846159987f902bb6e2b966eb4656da4b6d9469d

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

Changes:
  - all: https://git.openjdk.org/jdk8u-dev/pull/18/files
  - new: https://git.openjdk.org/jdk8u-dev/pull/18/files/7658e302..0fbcdcaa

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

  Stats: 12042 lines in 191 files changed: 9014 ins; 1858 del; 1170 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/18.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/18/head:pull/18

PR: https://git.openjdk.org/jdk8u-dev/pull/18

From duke at openjdk.org  Mon Jul  4 10:31:50 2022
From: duke at openjdk.org (Poison)
Date: Mon, 4 Jul 2022 10:31:50 GMT
Subject: [jdk8u-dev] RFR: 8214427: probable bug in logic of
 ConcurrentHashMap.addCount()
In-Reply-To: <2EllIPiRrAfzgwTWVIETeROCQqC4B0jYA5WcoEpLlHs=.ba18f6ec-92f0-456e-b188-fa9a2163ead1@github.com>
References: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
 <QCQg7KlhetYqnhjptw0IYTJy9X6h_Y3LLHUtl0-43Gk=.3188d4c9-381e-43f5-b8a7-f9ee3af4073e@github.com>
 <CizVcBGympScf_xBuQgEnl1cSeFOBNlp-DhinzdtqIc=.8a0800df-62b2-478b-9e17-546565738098@github.com>
 <2EllIPiRrAfzgwTWVIETeROCQqC4B0jYA5WcoEpLlHs=.ba18f6ec-92f0-456e-b188-fa9a2163ead1@github.com>
Message-ID: <9j6VgAnCMjbL1BAcABBgyLxCho4LWq9zcX6gh2K7Lek=.fa3a226e-d8c7-4225-b458-2c7b8b15855a@github.com>

On Mon, 4 Jul 2022 08:56:33 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> @jerboaa 11u now includes a backport of 8214427.
>
> @tianshuang Please enable testing (see the `Details` link), and merge the current master branch and push to the PR again, so that pre-integration tests run properly.

@jerboaa Test has passed.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/18

From duke at openjdk.org  Mon Jul  4 23:49:31 2022
From: duke at openjdk.org (duke)
Date: Mon, 4 Jul 2022 23:49:31 GMT
Subject: [jdk8u-dev] Withdrawn: 8073464: GC workers do not have thread names
In-Reply-To: <trkPo6JqGGK5Y0EihU8AsEGB3HBHSSXV9kbX-k_EO4I=.08584ca0-fdaa-47dc-8776-f816ce409985@github.com>
References: <trkPo6JqGGK5Y0EihU8AsEGB3HBHSSXV9kbX-k_EO4I=.08584ca0-fdaa-47dc-8776-f816ce409985@github.com>
Message-ID: <QQFD5Ucsk5HhwI6dWBUWRhbuEhNULTOOw9wRzL10pv8=.a4c71ca2-f56a-4bcd-83d8-95072ef8e7f9@github.com>

On Mon, 9 May 2022 19:00:06 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Backport for parity with Oracle 8u351.
> 
> The original patch does not apply cleanly, applied manully.
> 
> Test:
> 
> - [x] runtime on Linux x86_64

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/56

From k.takakuri at fujitsu.com  Tue Jul  5 08:41:06 2022
From: k.takakuri at fujitsu.com (k.takakuri at fujitsu.com)
Date: Tue, 5 Jul 2022 08:41:06 +0000
Subject: Fix request for jdk8u
Message-ID: <OS0PR01MB57789EECDBF37BE7ABF5C80188819@OS0PR01MB5778.jpnprd01.prod.outlook.com>

Hello.
Could someone please check the fix requests for jdk8u?

JDK-8130895
JDK-8136354

I would appreciate your help.

Regards,
K. Takakuri

From dongbohe at openjdk.org  Tue Jul  5 08:54:52 2022
From: dongbohe at openjdk.org (Dongbo He)
Date: Tue, 5 Jul 2022 08:54:52 GMT
Subject: [jdk8u-dev] RFR: 8235218: Minimal VM is broken after JDK-8173361
 [v2]
In-Reply-To: <CHMC3GAJlHCCl1V1Fo_FLWKJ7E6HmkHm3niVNluVJJw=.d0703b83-58b7-4463-97e4-5bd50fba33d4@github.com>
References: <rKZfPWwNN8FbdXjtnA6ZVOWkmpPo2e5Iaqs7G2qiYRQ=.b42361aa-1b70-4cc9-9c9c-3b23a803aa9c@github.com>
 <j_AxGhcYEsf2Lg1fC44xMONuYkrsRNNNE1lIRfCuWwY=.dcd8ecd1-9f53-4092-951c-bcb92791db08@github.com>
 <CHMC3GAJlHCCl1V1Fo_FLWKJ7E6HmkHm3niVNluVJJw=.d0703b83-58b7-4463-97e4-5bd50fba33d4@github.com>
Message-ID: <kGcH4-zdhP45Q7lPMZfaKA1qxj7fzdrEQNUl_Jc1KYQ=.f21ca1a5-2cc9-4621-9ae2-8d9e1060af9e@github.com>

On Wed, 29 Jun 2022 16:36:16 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> Dongbo He has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8235218
>>  - Backport c10f731b11f314c97660df08c62f3c3d2f718f54
>>  - 8173361: various crashes in JvmtiExport::post_compiled_method_load
>>    
>>    Backport-of: b1d915ef80ebdf511dc2897b20ada78b3dc44241
>
> The target of this PR seems wrong. It should be 8u/master not 8u/pr/9. Maybe easier to start fresh?

@gnu-andrew Hi, Andrew. Could you please take another look?

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

PR: https://git.openjdk.org/jdk8u-dev/pull/19

From duke at openjdk.org  Thu Jul  7 11:44:52 2022
From: duke at openjdk.org (ktakakuri)
Date: Thu, 7 Jul 2022 11:44:52 GMT
Subject: [jdk8u-dev] Integrated: 8136354: [TEST_BUG] Test
 java/awt/image/RescaleOp/RescaleAlphaTest.java with Bad action for script
In-Reply-To: <XST-lITtZCk9FIWOQi7f4TbBvlILbVIu4pQfqD7txzg=.d2821f63-5d27-4aae-8d54-d89744a13d8f@github.com>
References: <XST-lITtZCk9FIWOQi7f4TbBvlILbVIu4pQfqD7txzg=.d2821f63-5d27-4aae-8d54-d89744a13d8f@github.com>
Message-ID: <L4r3yciirVsaigrQ1ibhDQMKD94YNrokVywFYJu8Mgo=.20a2cbb8-b5c4-45c9-b0bb-ace86b134122@github.com>

On Thu, 23 Jun 2022 06:29:57 GMT, ktakakuri <duke at openjdk.org> wrote:

> This is a clean backport of JDK-8136354: [TEST_BUG] Test java/awt/image/RescaleOp/RescaleAlphaTest.java with Bad action for script.
> The test passed by applying this backport.
> 
> Could you please review this PR?

This pull request has now been integrated.

Changeset: ce73401e
Author:    Takakuri <k.takakuri at fujitsu.com>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/ce73401ef42bbe758aa1ed6e6b3412bf70ef63b4
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8136354: [TEST_BUG] Test  java/awt/image/RescaleOp/RescaleAlphaTest.java with Bad action for script

Backport-of: da688f57c3822e0327ad717290bed88baa73bd17

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

PR: https://git.openjdk.org/jdk8u-dev/pull/78

From sgehwolf at openjdk.org  Fri Jul  8 12:03:52 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 8 Jul 2022 12:03:52 GMT
Subject: [jdk8u-dev] RFR: 8235218: Minimal VM is broken after JDK-8173361
 [v3]
In-Reply-To: <1y_wu-EgA43QwzyZ-LGb35mygX2OOKC8jUjTxmgIqhI=.6b844676-e90d-405e-b4be-29fa383a1ef1@github.com>
References: <rKZfPWwNN8FbdXjtnA6ZVOWkmpPo2e5Iaqs7G2qiYRQ=.b42361aa-1b70-4cc9-9c9c-3b23a803aa9c@github.com>
 <1y_wu-EgA43QwzyZ-LGb35mygX2OOKC8jUjTxmgIqhI=.6b844676-e90d-405e-b4be-29fa383a1ef1@github.com>
Message-ID: <gGvCJpOTdKBWNoK9luUFmdWwLaPY2KuRmDx5SwkqigA=.c93b5e57-4c19-4b8a-9bac-2714e47d318a@github.com>

On Thu, 30 Jun 2022 03:26:33 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to backport this as follow up of [JDK-8173361](https://bugs.openjdk.java.net/browse/JDK-8173361), only a different context.
>> 
>> Thanks,
>> hedongbo
>
> Dongbo He has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge master
>  - Merge branch 'master' into 8235218
>  - Backport c10f731b11f314c97660df08c62f3c3d2f718f54
>  - 8173361: various crashes in JvmtiExport::post_compiled_method_load
>    
>    Backport-of: b1d915ef80ebdf511dc2897b20ada78b3dc44241

Looks OK.

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

Marked as reviewed by sgehwolf (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/19

From dongbohe at openjdk.org  Fri Jul  8 14:30:44 2022
From: dongbohe at openjdk.org (Dongbo He)
Date: Fri, 8 Jul 2022 14:30:44 GMT
Subject: [jdk8u-dev] RFR: 8150669: C1 intrinsic for Class.isPrimitive [v2]
In-Reply-To: <Y_0Iht_YlYNLjdofvo_TAAkLrkACpAAI3U8wlvpZo9o=.5409a720-6d7a-4f60-ab95-5a8a81847ee3@github.com>
References: <xjKQPs3ITjdlBkX3b2zkgPaJa-55PmBmEyGIeAFLx6w=.a4283cdb-2aad-415c-817c-52ce867b5362@github.com>
 <Y_0Iht_YlYNLjdofvo_TAAkLrkACpAAI3U8wlvpZo9o=.5409a720-6d7a-4f60-ab95-5a8a81847ee3@github.com>
Message-ID: <qBhSfm2xecvWLK8d5S1GStcr2Rhl7BmoExvl4rEFmPI=.c1f0f7f5-dde0-4d93-a08f-5f85f559d0cc@github.com>

On Thu, 16 Jun 2022 02:03:12 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

>> 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
>
> Dongbo He has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8150669
>  - Backport 890f94d7e6be731ac2ebae2f1ad3cc20ec836115

Got the push approval.

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

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

From jbachorik at openjdk.org  Fri Jul  8 14:32:54 2022
From: jbachorik at openjdk.org (Jaroslav Bachorik)
Date: Fri, 8 Jul 2022 14:32:54 GMT
Subject: [jdk8u-dev] Integrated: 8283849: AsyncGetCallTrace may crash JVM on
 guarantee
In-Reply-To: <dUtP1EByyqoRHSRLWcoErKDekZTpQADy6bpYG-Wwee0=.cc0e8bd0-0ccf-4f32-8b8e-901d85653a59@github.com>
References: <dUtP1EByyqoRHSRLWcoErKDekZTpQADy6bpYG-Wwee0=.cc0e8bd0-0ccf-4f32-8b8e-901d85653a59@github.com>
Message-ID: <awANVhc6OqYq_jUjAEtzmqzGFCnwx9YwrFY45cg5Y3I=.ba157e8e-0f30-47b9-a57c-0b43703b55d8@github.com>

On Wed, 15 Jun 2022 14:40:52 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

> This backport required some changes in the original changeset due to:
> - different source structure (the affected files are physically located in a different file hierarchy)
> - missing `current_thread->as_java_thread()` method - fully replaceable by `((JavaThread*)current_thread)` cast
> - missing `Thread::current_or_null_safe()` - replaced by `Thread::curent_or_null()` which has 100% same implementation as `Thread::current_or_null_safe()` in JDK 17

This pull request has now been integrated.

Changeset: 6e8292f1
Author:    Jaroslav Bachorik <jbachorik at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/6e8292f1d997aa160a9826967ee4467e93585bc7
Stats:     20 lines in 4 files changed: 18 ins; 0 del; 2 mod

8283849: AsyncGetCallTrace may crash JVM on guarantee

Reviewed-by: phh
Backport-of: 19639855311a47ed532547743ea3873eb8b016d3

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

PR: https://git.openjdk.org/jdk8u-dev/pull/73

From sgehwolf at openjdk.org  Fri Jul  8 12:21:44 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 8 Jul 2022 12:21:44 GMT
Subject: [jdk8u-dev] RFR: 8256722: handle VC++:1927 VS2019 in
 abstract_vm_version
In-Reply-To: <4iMO_KW4vtclo99ZkML4OxhBkdO5HK0dFGxjOLua06s=.3cff5a83-24e1-451d-8e9c-e6b0311e67eb@github.com>
References: <4iMO_KW4vtclo99ZkML4OxhBkdO5HK0dFGxjOLua06s=.3cff5a83-24e1-451d-8e9c-e6b0311e67eb@github.com>
Message-ID: <BG7mOC3CKNGdpSTPoK_IoDZNlW3vt4tRsRzor18TL9g=.b563627e-1c4f-477e-9c9b-c74cc33fe3f6@github.com>

On Fri, 8 Apr 2022 09:41:57 GMT, Alexey Pavlyutkin <duke at openjdk.org> wrote:

> 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

I've approved this, feel free to re-open and integrate.

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

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

From phh at openjdk.org  Fri Jul  8 12:05:54 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 8 Jul 2022 12:05:54 GMT
Subject: [jdk8u-dev] RFR: 8130895: Test
 javax/swing/system/6799345/TestShutdown.java fails on Solaris11 Sparcv9
In-Reply-To: <D7PKan3D8ZK7ibDqqruId0TF2Eral72PsPBOuz8_4qM=.e0e6b15c-bcb8-4911-99b9-e4f355ab6ac9@github.com>
References: <D7PKan3D8ZK7ibDqqruId0TF2Eral72PsPBOuz8_4qM=.e0e6b15c-bcb8-4911-99b9-e4f355ab6ac9@github.com>
Message-ID: <iKT4-DUv-sHA1Avg8dTdflRzFz9WCZnPM8_sqTOyKSs=.70c50a5e-cb62-4a47-b384-4f3378da9487@github.com>

On Wed, 11 May 2022 06:37:29 GMT, ktakakuri <duke at openjdk.org> wrote:

> I would like to backport
> JDK-8130895: Test javax/swing/system/6799345/TestShutdown.java fails on Solaris11 Sparcv9
> The original patch applies cleanly after paths changes.
> 
> Testing:
> build on Solaris11.4 sparcv9
> tire1, jdk_awt and javax/swing/system/6799345/TestShutdown.java on Solaris11.4 sparcv9

If you add a /integrate comment, I can sponsor.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/57

From dongbohe at openjdk.org  Fri Jul  8 14:28:53 2022
From: dongbohe at openjdk.org (Dongbo He)
Date: Fri, 8 Jul 2022 14:28:53 GMT
Subject: [jdk8u-dev] RFR: 8235218: Minimal VM is broken after JDK-8173361
 [v3]
In-Reply-To: <1y_wu-EgA43QwzyZ-LGb35mygX2OOKC8jUjTxmgIqhI=.6b844676-e90d-405e-b4be-29fa383a1ef1@github.com>
References: <rKZfPWwNN8FbdXjtnA6ZVOWkmpPo2e5Iaqs7G2qiYRQ=.b42361aa-1b70-4cc9-9c9c-3b23a803aa9c@github.com>
 <1y_wu-EgA43QwzyZ-LGb35mygX2OOKC8jUjTxmgIqhI=.6b844676-e90d-405e-b4be-29fa383a1ef1@github.com>
Message-ID: <DH9T42WE_dak4vwobrrKwFA8hfiqpWASevVt3VeNrko=.271b3774-1579-4f03-a62c-3c5cd6c19aae@github.com>

On Thu, 30 Jun 2022 03:26:33 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to backport this as follow up of [JDK-8173361](https://bugs.openjdk.java.net/browse/JDK-8173361), only a different context.
>> 
>> Thanks,
>> hedongbo
>
> Dongbo He has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge master
>  - Merge branch 'master' into 8235218
>  - Backport c10f731b11f314c97660df08c62f3c3d2f718f54
>  - 8173361: various crashes in JvmtiExport::post_compiled_method_load
>    
>    Backport-of: b1d915ef80ebdf511dc2897b20ada78b3dc44241

Got the push approval.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/19

From dongbohe at openjdk.org  Fri Jul  8 18:01:04 2022
From: dongbohe at openjdk.org (Dongbo He)
Date: Fri, 8 Jul 2022 18:01:04 GMT
Subject: [jdk8u-dev] Integrated: 8150669: C1 intrinsic for Class.isPrimitive
In-Reply-To: <xjKQPs3ITjdlBkX3b2zkgPaJa-55PmBmEyGIeAFLx6w=.a4283cdb-2aad-415c-817c-52ce867b5362@github.com>
References: <xjKQPs3ITjdlBkX3b2zkgPaJa-55PmBmEyGIeAFLx6w=.a4283cdb-2aad-415c-817c-52ce867b5362@github.com>
Message-ID: <7UA476-1Wkxy7julFaZBeiRT3shzuBmy6lEHAp0OLKI=.c32d06d1-39b4-47d8-b8af-4624d44880f3@github.com>

On Tue, 19 Apr 2022 08:42:37 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

> 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

This pull request has now been integrated.

Changeset: eeef4de5
Author:    Dongbo He <dongbohe at openjdk.org>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/eeef4de5dcf3bd9c5aff971ac9181c13c64a66f8
Stats:     198 lines in 5 files changed: 197 ins; 0 del; 1 mod

8150669: C1 intrinsic for Class.isPrimitive

Reviewed-by: phh
Backport-of: 890f94d7e6be731ac2ebae2f1ad3cc20ec836115

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

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

From dongbohe at openjdk.org  Sat Jul  9 04:04:34 2022
From: dongbohe at openjdk.org (Dongbo He)
Date: Sat, 9 Jul 2022 04:04:34 GMT
Subject: [jdk8u-dev] RFR: 8233019: java.lang.Class.isPrimitive() (C1)
 returns wrong result if Klass* is aligned to 32bit [v4]
In-Reply-To: <TLsDcS6zsjACyQ9UNv1I4QPKaRlxAqoChoaTAwHxVjs=.06e2a15e-7990-48c5-ac40-4c84ccd1d169@github.com>
References: <TLsDcS6zsjACyQ9UNv1I4QPKaRlxAqoChoaTAwHxVjs=.06e2a15e-7990-48c5-ac40-4c84ccd1d169@github.com>
Message-ID: <PcSA7VAJcE57L-LCgA_lJy4W9gJiaEiGLb8bedzHrh4=.df077294-730d-4a9c-bccd-157a94dbc110@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

Dongbo He has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge master
 - Merge branch '8150669' into 8233019
 - Merge branch 'master' into 8150669
 - b67ca938f37f952e53f73d2e0b8ebcaf96139fda
 - Backport 890f94d7e6be731ac2ebae2f1ad3cc20ec836115

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

Changes:
  - all: https://git.openjdk.org/jdk8u-dev/pull/43/files
  - new: https://git.openjdk.org/jdk8u-dev/pull/43/files/5274a23f..69b5b2f8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=43&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=43&range=02-03

  Stats: 507 lines in 22 files changed: 435 ins; 15 del; 57 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/43.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/43/head:pull/43

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

From andrew at openjdk.org  Sat Jul  9 19:13:51 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 9 Jul 2022 19:13:51 GMT
Subject: [jdk8u-dev] RFR: 8235218: Minimal VM is broken after JDK-8173361
 [v2]
In-Reply-To: <6QHNbNiAySEuXw1GnU19zjLRkEoY7Kzk2g0guzMFfy4=.dd6dce8f-4058-4e80-83b0-712ec860e281@github.com>
References: <rKZfPWwNN8FbdXjtnA6ZVOWkmpPo2e5Iaqs7G2qiYRQ=.b42361aa-1b70-4cc9-9c9c-3b23a803aa9c@github.com>
 <j_AxGhcYEsf2Lg1fC44xMONuYkrsRNNNE1lIRfCuWwY=.dcd8ecd1-9f53-4092-951c-bcb92791db08@github.com>
 <6QHNbNiAySEuXw1GnU19zjLRkEoY7Kzk2g0guzMFfy4=.dd6dce8f-4058-4e80-83b0-712ec860e281@github.com>
Message-ID: <dX1kDNBv-iVaZMMTudItWiZ1oCIc2TzLYunc0NahlLA=.7d4ff762-c61d-4e1e-9c8b-a99b5582c943@github.com>

On Thu, 30 Jun 2022 03:22:20 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

> According to the description of [New Skara feature: dependent pull requests](https://mail.openjdk.org/pipermail/jdk-dev/2021-March/005232.html), we need to target to pr/9.
> 
> It seems that I need to merge master, I will try.

Ah ok, that's the first I've heard of that. It seems the mail was only sent to jdk-dev and not the jdk-updates or jdk8u lists.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/19

From andrew at openjdk.org  Sat Jul  9 19:18:51 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 9 Jul 2022 19:18:51 GMT
Subject: [jdk8u-dev] RFR: 8235218: Minimal VM is broken after JDK-8173361
 [v3]
In-Reply-To: <1y_wu-EgA43QwzyZ-LGb35mygX2OOKC8jUjTxmgIqhI=.6b844676-e90d-405e-b4be-29fa383a1ef1@github.com>
References: <rKZfPWwNN8FbdXjtnA6ZVOWkmpPo2e5Iaqs7G2qiYRQ=.b42361aa-1b70-4cc9-9c9c-3b23a803aa9c@github.com>
 <1y_wu-EgA43QwzyZ-LGb35mygX2OOKC8jUjTxmgIqhI=.6b844676-e90d-405e-b4be-29fa383a1ef1@github.com>
Message-ID: <7ANkR0y4UK5Zl7GZSF_AVPqJtXKcVZ3DopwiOxj8Xtw=.1228814f-852b-468d-aaba-e2919455d653@github.com>

On Thu, 30 Jun 2022 03:26:33 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

>> Hi,
>> 
>> I would like to backport this as follow up of [JDK-8173361](https://bugs.openjdk.java.net/browse/JDK-8173361), only a different context.
>> 
>> Thanks,
>> hedongbo
>
> Dongbo He has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge master
>  - Merge branch 'master' into 8235218
>  - Backport c10f731b11f314c97660df08c62f3c3d2f718f54
>  - 8173361: various crashes in JvmtiExport::post_compiled_method_load
>    
>    Backport-of: b1d915ef80ebdf511dc2897b20ada78b3dc44241

Backport itself looks clean.

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

Marked as reviewed by andrew (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/19

From dongbohe at openjdk.org  Sun Jul 10 15:23:50 2022
From: dongbohe at openjdk.org (Dongbo He)
Date: Sun, 10 Jul 2022 15:23:50 GMT
Subject: [jdk8u-dev] Integrated: 8235218: Minimal VM is broken after
 JDK-8173361
In-Reply-To: <rKZfPWwNN8FbdXjtnA6ZVOWkmpPo2e5Iaqs7G2qiYRQ=.b42361aa-1b70-4cc9-9c9c-3b23a803aa9c@github.com>
References: <rKZfPWwNN8FbdXjtnA6ZVOWkmpPo2e5Iaqs7G2qiYRQ=.b42361aa-1b70-4cc9-9c9c-3b23a803aa9c@github.com>
Message-ID: <pmJ3OT5p94RI-2V0B7jL7R69RqtsWfCmBBv3lh98btY=.e48e16f6-3ef2-4b27-b4c2-c8fa33156c02@github.com>

On Mon, 21 Mar 2022 06:51:21 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

> Hi,
> 
> I would like to backport this as follow up of [JDK-8173361](https://bugs.openjdk.java.net/browse/JDK-8173361), only a different context.
> 
> Thanks,
> hedongbo

This pull request has now been integrated.

Changeset: e0051850
Author:    Dongbo He <dongbohe at openjdk.org>
Committer: Andrew John Hughes <andrew at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/e005185072cbf0b79b62bcfa7a37f9e1a2e03af2
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8235218: Minimal VM is broken after JDK-8173361

Reviewed-by: sgehwolf, andrew
Backport-of: c10f731b11f314c97660df08c62f3c3d2f718f54

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

PR: https://git.openjdk.org/jdk8u-dev/pull/19

From andrew at openjdk.org  Sun Jul 10 15:38:52 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sun, 10 Jul 2022 15:38:52 GMT
Subject: [jdk8u-dev] RFR: 8214427: probable bug in logic of
 ConcurrentHashMap.addCount() [v2]
In-Reply-To: <vtdVLByJ-U5hK3ZxqijdhQcezk43ljmSEqrkUmNbZgI=.fe061860-ba0c-4d31-a588-2596e3d41f76@github.com>
References: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
 <vtdVLByJ-U5hK3ZxqijdhQcezk43ljmSEqrkUmNbZgI=.fe061860-ba0c-4d31-a588-2596e3d41f76@github.com>
Message-ID: <uEjYJCoo0-jELcORGgzEOoP37oLZoTtDi67I0LFwGcY=.a9878873-5b89-436f-9ae6-754042e42555@github.com>

On Mon, 4 Jul 2022 09:11:46 GMT, Poison <duke at openjdk.org> wrote:

>> 8214427: probable bug in logic of ConcurrentHashMap.addCount()
>> 
>> This backport fixes the problem that the MAX_RESIZERS control does not take effect when multi-threaded expansion in ConcurrentHashMap.
>
> Poison has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into backport-8214427
>  - Backport 8846159987f902bb6e2b966eb4656da4b6d9469d

> I've opened a PR for the 11u backport: [openjdk/jdk11u-dev#1114](https://github.com/openjdk/jdk11u-dev/pull/1114)
> 
> Can you merge this with jdk8u-dev/master so that the full set of build checks run?
> 
> I've see some whitespace differences with the 8u version:
> 
> ```
> -+                        (nt = nextTable) == null || transferIndex <= 0)
> ++                            (nt = nextTable) == null || transferIndex <= 0)
> ```
> 
> ```
> -+                    transferIndex <= 0)
> ++                        transferIndex <= 0)
> ```
> 
> Do you see this locally or is it introduced by the `webrev` tool?
> 
> The change from `compareAndSetInt` to `compareAndSwapInt` looks correct to match the 8u version.

These whitespace issues are still not resolved in the current patch.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/18

From andrew at openjdk.org  Sun Jul 10 15:44:44 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sun, 10 Jul 2022 15:44:44 GMT
Subject: [jdk8u-dev] RFR: 8214427: probable bug in logic of
 ConcurrentHashMap.addCount() [v2]
In-Reply-To: <uEjYJCoo0-jELcORGgzEOoP37oLZoTtDi67I0LFwGcY=.a9878873-5b89-436f-9ae6-754042e42555@github.com>
References: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
 <vtdVLByJ-U5hK3ZxqijdhQcezk43ljmSEqrkUmNbZgI=.fe061860-ba0c-4d31-a588-2596e3d41f76@github.com>
 <uEjYJCoo0-jELcORGgzEOoP37oLZoTtDi67I0LFwGcY=.a9878873-5b89-436f-9ae6-754042e42555@github.com>
Message-ID: <cNN-C6AiNW0gQRBlmTCjw5ffwSf_N7o1f67uustobMg=.5714ba1c-bc21-4fb7-8b71-7ab508432139@github.com>

On Sun, 10 Jul 2022 15:35:39 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> Poison has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into backport-8214427
>>  - Backport 8846159987f902bb6e2b966eb4656da4b6d9469d
>
>> I've opened a PR for the 11u backport: [openjdk/jdk11u-dev#1114](https://github.com/openjdk/jdk11u-dev/pull/1114)
>> 
>> Can you merge this with jdk8u-dev/master so that the full set of build checks run?
>> 
>> I've see some whitespace differences with the 8u version:
>> 
>> ```
>> -+                        (nt = nextTable) == null || transferIndex <= 0)
>> ++                            (nt = nextTable) == null || transferIndex <= 0)
>> ```
>> 
>> ```
>> -+                    transferIndex <= 0)
>> ++                        transferIndex <= 0)
>> ```
>> 
>> Do you see this locally or is it introduced by the `webrev` tool?
>> 
>> The change from `compareAndSetInt` to `compareAndSwapInt` looks correct to match the 8u version.
> 
> These whitespace issues are still not resolved in the current patch.

> @gnu-andrew The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 1 (with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)).

"The requirements are in addition to the ones specified by the .jcheck/conf file. "

Clearly not, because 1 (from jcheck) + 1 (from reviewers command) should equal 2.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/18

From dongbohe at openjdk.org  Mon Jul 11 02:32:42 2022
From: dongbohe at openjdk.org (Dongbo He)
Date: Mon, 11 Jul 2022 02:32:42 GMT
Subject: [jdk8u-dev] RFR: 8233019: java.lang.Class.isPrimitive() (C1)
 returns wrong result if Klass* is aligned to 32bit [v4]
In-Reply-To: <PcSA7VAJcE57L-LCgA_lJy4W9gJiaEiGLb8bedzHrh4=.df077294-730d-4a9c-bccd-157a94dbc110@github.com>
References: <TLsDcS6zsjACyQ9UNv1I4QPKaRlxAqoChoaTAwHxVjs=.06e2a15e-7990-48c5-ac40-4c84ccd1d169@github.com>
 <PcSA7VAJcE57L-LCgA_lJy4W9gJiaEiGLb8bedzHrh4=.df077294-730d-4a9c-bccd-157a94dbc110@github.com>
Message-ID: <gkYF8O5aiphSahaEaeRQwHoBlfXG6fqX2ukLyMtLJ1U=.e49bff8a-460f-4d55-90d8-d11bf6ca2247@github.com>

On Sat, 9 Jul 2022 04:04:34 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

>> 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
>
> Dongbo He has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge master
>  - Merge branch '8150669' into 8233019
>  - Merge branch 'master' into 8150669
>  - b67ca938f37f952e53f73d2e0b8ebcaf96139fda
>  - Backport 890f94d7e6be731ac2ebae2f1ad3cc20ec836115

Got the push approval.

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

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

From dongbohe at openjdk.org  Mon Jul 11 02:53:50 2022
From: dongbohe at openjdk.org (Dongbo He)
Date: Mon, 11 Jul 2022 02:53:50 GMT
Subject: [jdk8u-dev] Integrated: 8233019: java.lang.Class.isPrimitive() (C1)
 returns wrong result if Klass* is aligned to 32bit
In-Reply-To: <TLsDcS6zsjACyQ9UNv1I4QPKaRlxAqoChoaTAwHxVjs=.06e2a15e-7990-48c5-ac40-4c84ccd1d169@github.com>
References: <TLsDcS6zsjACyQ9UNv1I4QPKaRlxAqoChoaTAwHxVjs=.06e2a15e-7990-48c5-ac40-4c84ccd1d169@github.com>
Message-ID: <AabVVS-edQLD6Cbtq_5z9BRAlyH7lSfnwlMK6j0_-S0=.1e8af0dc-3ce8-4782-bbac-105eeb02254c@github.com>

On Wed, 20 Apr 2022 09:14:28 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

> 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

This pull request has now been integrated.

Changeset: 972112ed
Author:    Dongbo He <dongbohe at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/972112ed520b8f5465ae15c47e6af2db92aa3a58
Stats:     36 lines in 5 files changed: 34 ins; 0 del; 2 mod

8233019: java.lang.Class.isPrimitive() (C1) returns wrong result if Klass* is aligned to 32bit

Reviewed-by: phh
Backport-of: b67ca938f37f952e53f73d2e0b8ebcaf96139fda

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

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

From duke at openjdk.org  Mon Jul 11 06:29:52 2022
From: duke at openjdk.org (Alexey Pavlyutkin)
Date: Mon, 11 Jul 2022 06:29:52 GMT
Subject: [jdk8u-dev] Integrated: 8256722: handle VC++:1927 VS2019 in
 abstract_vm_version
In-Reply-To: <4iMO_KW4vtclo99ZkML4OxhBkdO5HK0dFGxjOLua06s=.3cff5a83-24e1-451d-8e9c-e6b0311e67eb@github.com>
References: <4iMO_KW4vtclo99ZkML4OxhBkdO5HK0dFGxjOLua06s=.3cff5a83-24e1-451d-8e9c-e6b0311e67eb@github.com>
Message-ID: <gQdZGtmeNn5WtruFu9OLISnft6mppVWc381ZHQ18OkA=.2ce88b59-4401-427c-8367-c700cbd2181f@github.com>

On Fri, 8 Apr 2022 09:41:57 GMT, Alexey Pavlyutkin <duke at openjdk.org> wrote:

> 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

This pull request has now been integrated.

Changeset: 4f7dd0ca
Author:    Alexey Pavlyutkin <apavlyutkin at azul.com>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/4f7dd0ca1625e9b870174ee21f9423cb4ff7ae09
Stats:     10 lines in 1 file changed: 10 ins; 0 del; 0 mod

8256722: handle VC++:1927 VS2019 in  abstract_vm_version

Backport-of: 146fe86ff68095b5eb0ce1387061699738280c06

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

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

From duke at openjdk.org  Mon Jul 11 07:15:52 2022
From: duke at openjdk.org (Alexey Pavlyutkin)
Date: Mon, 11 Jul 2022 07:15:52 GMT
Subject: [jdk8u-dev] RFR: 8273176: handle latest VS2019 in abstract_vm_version
Message-ID: <uIJWs-lus-eBiXhSKL3_1O9PbEGCcHW3s-PHRdc9-Oo=.4b3dd440-827b-4b2b-bdfa-519c4a251689@github.com>

Hi! Here is another backport from MSVS 2019 seria. This one additionally extends the list of supported VC++ compilers. The patch from 11u is applied cleanly except the path shuffling:

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

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

Commit messages:
 - 8273176: handle latest VS2019 in abstract_vm_version

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

PR: https://git.openjdk.org/jdk8u-dev/pull/82

From omikhaltcova at openjdk.org  Mon Jul 11 11:13:54 2022
From: omikhaltcova at openjdk.org (Olga Mikhaltsova)
Date: Mon, 11 Jul 2022 11:13:54 GMT
Subject: [jdk8u-dev] Integrated: 8282538: PKCS11 tests fail on CentOS Stream 9
In-Reply-To: <2CZhV2W69JZ7b4DLOpnbkSjA6Jp8DnG0uWjToNe9Eyo=.c50a6110-2eaf-4e79-aa8b-b4237bf32afe@github.com>
References: <2CZhV2W69JZ7b4DLOpnbkSjA6Jp8DnG0uWjToNe9Eyo=.c50a6110-2eaf-4e79-aa8b-b4237bf32afe@github.com>
Message-ID: <JDQYW-nQtJ3vzBYo8AQYTKPH43KiIYcTwQuxDvEjn0M=.cc6d5e13-d201-4718-8c8f-ccc1fa9a6a04@github.com>

On Tue, 21 Jun 2022 23:08:59 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

> It's backport of JDK-8282538 to jdk8u.
> The same failure of the regression tests group (test/jdk/sun/security/pkcs11/Signature/) is observed on CentOS Stream 9 because of missing cert9.db and key4.db which are required by NSS 3.35 and above.
> Applied manually due to the location difference:
> `test/jdk/sun/security/pkcs11/nss/db/cert9.db`  ->  `jdk/test/sun/security/pkcs11/nss/db/cert9.db`
> `test/jdk/sun/security/pkcs11/nss/db/key4.db`  ->  `jdk/test/sun/security/pkcs11/nss/db/key4.db`
> Tested manually on CentOS Stream 9 with above mentioned tests group.

This pull request has now been integrated.

Changeset: 0de66bd8
Author:    Olga Mikhaltsova <omikhaltcova at openjdk.org>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/0de66bd811c89d8648d3751f60fe46aaa2eb26fc
Stats:     0 lines in 2 files changed: 0 ins; 0 del; 0 mod

8282538: PKCS11 tests fail on CentOS Stream 9

Backport-of: d8fd22239bafecdaaedb8985ab6d709ed846e808

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

PR: https://git.openjdk.org/jdk8u-dev/pull/76

From omikhaltcova at openjdk.org  Mon Jul 11 11:15:54 2022
From: omikhaltcova at openjdk.org (Olga Mikhaltsova)
Date: Mon, 11 Jul 2022 11:15:54 GMT
Subject: [jdk8u-dev] Integrated: 8194873: right ALT key hotkeys no longer work
 in Swing components
In-Reply-To: <f7zrvmf2PcsDiLqIm8ftljRiWMVTKRbeQmWmPgfwnDc=.71905fc4-ccfe-4ecb-bd68-55ea5efafcee@github.com>
References: <f7zrvmf2PcsDiLqIm8ftljRiWMVTKRbeQmWmPgfwnDc=.71905fc4-ccfe-4ecb-bd68-55ea5efafcee@github.com>
Message-ID: <ieGRhEwaWH9Yf0H8wLMkOLk8hC6x-V5QfzUTYRP8Xsc=.453d60e9-49ab-4242-aecc-e84fcd570b4c@github.com>

On Tue, 17 May 2022 18:31:23 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

> I'd like to backport JDK-8194873 to jdk8u. The same issue is observed there.
> The original patch for JDK-8194873 applied not cleanly due to 2 files:   
>>  MotifLookAndFeel.java - differences in the header and in the context;
>>  SwingUtilities2.java - difference in the context.
> 
> The backport for JDK-8155742
> 
> 8155742: [Windows] robot.keyPress(KeyEvent.VK_ALT_GRAPH) throws java.lang.IllegalArgumentException in windows
> 
> was included as a part of this patch due to dependency on it of the regression test "jdk/test/javax/swing/event/RightAltKeyTest.java" included into the patch for JDK-8194873 (this test fails without the patch for JDK-8155742 as was pointed out below by Anton Litvinov).
> The original patch For JDK-8155742 applied not cleanly due to 1 file:
>> AltGraphModifierTest.java - differences in the header and slight in the context.
> 
> Tested on Windows. All regular tests passed.

This pull request has now been integrated.

Changeset: de9f1497
Author:    Olga Mikhaltsova <omikhaltcova at openjdk.org>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/de9f14976a285fcf1ea073c374582d6965e4f0dd
Stats:     401 lines in 14 files changed: 372 ins; 11 del; 18 mod

8194873: right ALT key hotkeys no longer work in Swing components
8155742: [Windows] robot.keyPress(KeyEvent.VK_ALT_GRAPH) throws java.lang.IllegalArgumentException in windows

Reviewed-by: alitvinov, yan, serb
Backport-of: 91f281c8d713e489ddc282f935ebd879485c4b41

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

PR: https://git.openjdk.org/jdk8u-dev/pull/60

From duke at openjdk.org  Mon Jul 11 12:24:12 2022
From: duke at openjdk.org (George Adams)
Date: Mon, 11 Jul 2022 12:24:12 GMT
Subject: [jdk8u-dev] RFR: 8254178: Remove .hgignore
Message-ID: <5TGmgU7qapZp0KVHY2bjAvqLNlX_dvfr1AXlXZ0vswM=.dee1c450-28a4-4d28-97a1-5de7d3500c15@github.com>

backports https://bugs.openjdk.org/browse/JDK-8254178 as it's a low-risk change

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

Commit messages:
 - Backport 736e077335ec53c3804537a6abefa79087efd3ad

Changes: https://git.openjdk.org/jdk8u-dev/pull/83/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=83&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8254178
  Stats: 71 lines in 8 files changed: 0 ins; 71 del; 0 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/83.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/83/head:pull/83

PR: https://git.openjdk.org/jdk8u-dev/pull/83

From duke at openjdk.org  Tue Jul 12 12:06:06 2022
From: duke at openjdk.org (ktakakuri)
Date: Tue, 12 Jul 2022 12:06:06 GMT
Subject: [jdk8u-dev] Integrated: 8130895: Test
 javax/swing/system/6799345/TestShutdown.java fails on Solaris11 Sparcv9
In-Reply-To: <D7PKan3D8ZK7ibDqqruId0TF2Eral72PsPBOuz8_4qM=.e0e6b15c-bcb8-4911-99b9-e4f355ab6ac9@github.com>
References: <D7PKan3D8ZK7ibDqqruId0TF2Eral72PsPBOuz8_4qM=.e0e6b15c-bcb8-4911-99b9-e4f355ab6ac9@github.com>
Message-ID: <THMOMOpZGHU7tiKRRdH_9UYdLIvR63EKsstXfyvSnPE=.b4318251-db31-4558-889e-e707b8fc1466@github.com>

On Wed, 11 May 2022 06:37:29 GMT, ktakakuri <duke at openjdk.org> wrote:

> I would like to backport
> JDK-8130895: Test javax/swing/system/6799345/TestShutdown.java fails on Solaris11 Sparcv9
> The original patch applies cleanly after paths changes.
> 
> Testing:
> build on Solaris11.4 sparcv9
> tire1, jdk_awt and javax/swing/system/6799345/TestShutdown.java on Solaris11.4 sparcv9

This pull request has now been integrated.

Changeset: 40a18594
Author:    Takakuri <k.takakuri at fujitsu.com>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/40a18594ba21d7a345ff82792fc361f7e691e669
Stats:     49 lines in 2 files changed: 25 ins; 17 del; 7 mod

8130895: Test javax/swing/system/6799345/TestShutdown.java fails on Solaris11 Sparcv9

Backport-of: 4140fd05a447c888856c54aee22c475173030833

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

PR: https://git.openjdk.org/jdk8u-dev/pull/57

From duke at openjdk.org  Wed Jul 13 11:19:13 2022
From: duke at openjdk.org (George Adams)
Date: Wed, 13 Jul 2022 11:19:13 GMT
Subject: [jdk8u-dev] RFR: 8253424: Add support for running pre-submit
 testing using GitHub Actions [v20]
In-Reply-To: <-4uRD1IJnZsg2fqz1bei8r99zm7fkkVQvqWHKu4GSdY=.d19621e1-1720-434b-a29a-e2c7243b3d0d@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>
 <-4uRD1IJnZsg2fqz1bei8r99zm7fkkVQvqWHKu4GSdY=.d19621e1-1720-434b-a29a-e2c7243b3d0d@github.com>
Message-ID: <Oe8k_jo5DW8JtIBjOKVkfGCD8_v62TT0-bC7w0JSeQk=.a8a844fb-11c5-4a33-ab0d-75fb94f13d46@github.com>

On Wed, 6 Apr 2022 19:46:21 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

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

@gnu-andrew I'm currently on a backport of https://github.com/openjdk/jdk11u/commit/58ff4ee8c4ec399528338b59eadea996110366a0 to JDK8u. If I can get it to work I'll submit a backport PR here for review. It should make the FreeType maintenance easier going forwards and should allow us to progress from 2.8.x which has some published vulnerabilities.

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

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

From phh at openjdk.org  Wed Jul 13 16:27:22 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 13 Jul 2022 16:27:22 GMT
Subject: [jdk8u-dev] RFR: 8254178: Remove .hgignore
In-Reply-To: <5TGmgU7qapZp0KVHY2bjAvqLNlX_dvfr1AXlXZ0vswM=.dee1c450-28a4-4d28-97a1-5de7d3500c15@github.com>
References: <5TGmgU7qapZp0KVHY2bjAvqLNlX_dvfr1AXlXZ0vswM=.dee1c450-28a4-4d28-97a1-5de7d3500c15@github.com>
Message-ID: <VQtx40lGAtvyNhM7sCAXyxNACYl_HDGI9ksHWEVtKok=.307c3726-950f-4eda-ba28-d2f79e5f8938@github.com>

On Mon, 11 Jul 2022 12:16:34 GMT, George Adams <duke at openjdk.org> wrote:

> backports https://bugs.openjdk.org/browse/JDK-8254178 as it's a low-risk change

Lgtm.

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

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/83

From duke at openjdk.org  Wed Jul 13 16:29:43 2022
From: duke at openjdk.org (George Adams)
Date: Wed, 13 Jul 2022 16:29:43 GMT
Subject: [jdk8u-dev] RFR: 8254178: Remove .hgignore
In-Reply-To: <VQtx40lGAtvyNhM7sCAXyxNACYl_HDGI9ksHWEVtKok=.307c3726-950f-4eda-ba28-d2f79e5f8938@github.com>
References: <5TGmgU7qapZp0KVHY2bjAvqLNlX_dvfr1AXlXZ0vswM=.dee1c450-28a4-4d28-97a1-5de7d3500c15@github.com>
 <VQtx40lGAtvyNhM7sCAXyxNACYl_HDGI9ksHWEVtKok=.307c3726-950f-4eda-ba28-d2f79e5f8938@github.com>
Message-ID: <m1qgQrXg_y5AXWuItbllhFQnchqkcSL_UaJ5uqsoGBo=.8d149e17-3ca7-4b83-88b6-fdd809dae776@github.com>

On Wed, 13 Jul 2022 16:24:31 GMT, Paul Hohensee <phh at openjdk.org> wrote:

>> backports https://bugs.openjdk.org/browse/JDK-8254178 as it's a low-risk change
>
> Lgtm.

@phohensee would you mind adding the fix request label to the issue on my behalf?

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

PR: https://git.openjdk.org/jdk8u-dev/pull/83

From phh at openjdk.org  Wed Jul 13 16:44:11 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 13 Jul 2022 16:44:11 GMT
Subject: [jdk8u-dev] RFR: 8254178: Remove .hgignore
In-Reply-To: <5TGmgU7qapZp0KVHY2bjAvqLNlX_dvfr1AXlXZ0vswM=.dee1c450-28a4-4d28-97a1-5de7d3500c15@github.com>
References: <5TGmgU7qapZp0KVHY2bjAvqLNlX_dvfr1AXlXZ0vswM=.dee1c450-28a4-4d28-97a1-5de7d3500c15@github.com>
Message-ID: <Fkr0tgDZnGi6_x-B1bjXlhgYjlD6fw5UwVnge1Y57LA=.27a7f75c-8d09-4003-9295-c5a92062c899@github.com>

On Mon, 11 Jul 2022 12:16:34 GMT, George Adams <duke at openjdk.org> wrote:

> backports https://bugs.openjdk.org/browse/JDK-8254178 as it's a low-risk change

Done.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/83

From t.glaser at tarent.de  Wed Jul 13 17:23:17 2022
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Wed, 13 Jul 2022 19:23:17 +0200 (CEST)
Subject: [jdk8u-dev] RFR: 8254178: Remove .hgignore
In-Reply-To: <VQtx40lGAtvyNhM7sCAXyxNACYl_HDGI9ksHWEVtKok=.307c3726-950f-4eda-ba28-d2f79e5f8938@github.com>
References: <5TGmgU7qapZp0KVHY2bjAvqLNlX_dvfr1AXlXZ0vswM=.dee1c450-28a4-4d28-97a1-5de7d3500c15@github.com>
 <VQtx40lGAtvyNhM7sCAXyxNACYl_HDGI9ksHWEVtKok=.307c3726-950f-4eda-ba28-d2f79e5f8938@github.com>
Message-ID: <b1ba74d0-68e5-7f62-9ef7-3a57b15784f0@tarent.de>

There?s also still the .hgtags file.

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 phh at openjdk.org  Thu Jul 14 18:30:12 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Thu, 14 Jul 2022 18:30:12 GMT
Subject: [jdk8u-dev] RFR: 8254178: Remove .hgignore
In-Reply-To: <5TGmgU7qapZp0KVHY2bjAvqLNlX_dvfr1AXlXZ0vswM=.dee1c450-28a4-4d28-97a1-5de7d3500c15@github.com>
References: <5TGmgU7qapZp0KVHY2bjAvqLNlX_dvfr1AXlXZ0vswM=.dee1c450-28a4-4d28-97a1-5de7d3500c15@github.com>
Message-ID: <_H5stR_20J6jyarLD-ImFrLYzJI1eccq0Gt0NLD1GB0=.d634d6da-dece-4526-915b-2e51dbcd8acc@github.com>

On Mon, 11 Jul 2022 12:16:34 GMT, George Adams <duke at openjdk.org> wrote:

> backports https://bugs.openjdk.org/browse/JDK-8254178 as it's a low-risk change

That would be a backport of [JDK-8254318](https://bugs.openjdk.org/browse/JDK-8254318).

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

PR: https://git.openjdk.org/jdk8u-dev/pull/83

From duke at openjdk.org  Thu Jul 14 20:22:16 2022
From: duke at openjdk.org (George Adams)
Date: Thu, 14 Jul 2022 20:22:16 GMT
Subject: [jdk8u-dev] RFR: 8254178: Remove .hgignore
In-Reply-To: <5TGmgU7qapZp0KVHY2bjAvqLNlX_dvfr1AXlXZ0vswM=.dee1c450-28a4-4d28-97a1-5de7d3500c15@github.com>
References: <5TGmgU7qapZp0KVHY2bjAvqLNlX_dvfr1AXlXZ0vswM=.dee1c450-28a4-4d28-97a1-5de7d3500c15@github.com>
Message-ID: <2oPPeXYhs8_FINUBQybfBgz86RVOnrXv9WsjB--xnGY=.8e5b2147-3ae3-44a2-a839-ec62771c0501@github.com>

On Mon, 11 Jul 2022 12:16:34 GMT, George Adams <duke at openjdk.org> wrote:

> backports https://bugs.openjdk.org/browse/JDK-8254178 as it's a low-risk change

Yeah I'll backport that one separately

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

PR: https://git.openjdk.org/jdk8u-dev/pull/83

From duke at openjdk.org  Mon Jul 18 09:30:10 2022
From: duke at openjdk.org (lusou-zhangquan)
Date: Mon, 18 Jul 2022 09:30:10 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache [v2]
In-Reply-To: <HmjYgFB8Ydc-bC3Cw22il4G7Zw26Bjbdazfk_Y4szVg=.27508723-99eb-42fe-b603-7e89930c3ae4@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
 <MwTUmDjaouIWCEut9SJX6xTR4Yv3kMO6rScpmteaqaY=.2e1c72e9-0e2b-4eb2-879c-b9299e2d5482@github.com>
 <HmjYgFB8Ydc-bC3Cw22il4G7Zw26Bjbdazfk_Y4szVg=.27508723-99eb-42fe-b603-7e89930c3ae4@github.com>
Message-ID: <-QwbhbskPZW6KOY-oc4Mv6b7U4IFIIhUeJxzQgKDeJg=.c3c33bf5-ef0c-4848-b96b-d51211c9bb6a@github.com>

On Mon, 20 Jun 2022 19:02:03 GMT, Paul Hohensee <phh at openjdk.org> wrote:

>> lusou-zhangquan has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   8049228: Improve multithreaded scalability of InetAddress cache
>>   
>>   Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c
>
> Looks fine, but please run at least tier1 tests.

@phohensee Please take a look at this PR again, thanks a lot.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/70

From phh at openjdk.org  Mon Jul 18 18:52:11 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Mon, 18 Jul 2022 18:52:11 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache [v3]
In-Reply-To: <vcmpDcetyz5zqMt912h8ytHbsI5HJE9cWAH_L6unZ7s=.a5e5d3a0-9b89-4f52-96e7-ef50dcab99f9@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
 <vcmpDcetyz5zqMt912h8ytHbsI5HJE9cWAH_L6unZ7s=.a5e5d3a0-9b89-4f52-96e7-ef50dcab99f9@github.com>
Message-ID: <WPeXChoJHNJ8qyufWP9drKcYHvzcVln0lobzrBHeLPA=.21272415-bd42-417e-8d18-7a1840310637@github.com>

On Tue, 21 Jun 2022 02:27:18 GMT, lusou-zhangquan <duke at openjdk.org> wrote:

>> Backport JDK-8049228 to improve multithreaded scalability of InetAddress cache
>> 
>> Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c
>
> lusou-zhangquan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8049228: Improve multithreaded scalability of InetAddress cache
>   
>   Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c

Lgtm.

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

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/70

From duke at openjdk.org  Tue Jul 19 06:20:00 2022
From: duke at openjdk.org (Alexey Pavlyutkin)
Date: Tue, 19 Jul 2022 06:20:00 GMT
Subject: [jdk8u-dev] RFR: 8197859: VS2017 Complains about UINTPTR_MAX
 definition in globalDefinitions_VisCPP.hpp [v2]
In-Reply-To: <_qTWaz6VjZ7zYsqSTD7biJ9dJn74vQKC3iysr86IJJI=.9f8ea751-56f3-47d8-b169-c0ca071883ab@github.com>
References: <WCZSnJWqvZqlMsQizOTcP0iaua8g2s4Kk2Ce5mOj6a0=.0b7e5a68-af18-4784-8570-8fdbebff7bdc@github.com>
 <_qTWaz6VjZ7zYsqSTD7biJ9dJn74vQKC3iysr86IJJI=.9f8ea751-56f3-47d8-b169-c0ca071883ab@github.com>
Message-ID: <hPBS-YZwPWIhjFXlYNubg8mqOZuFO6b7UT6PvzNX6rA=.8a37d223-fa15-4b01-b7e5-3896c35cb161@github.com>

On Wed, 22 Jun 2022 08:54:19 GMT, Alexey Pavlyutkin <duke at openjdk.org> wrote:

>> Hi! Please review another backport from MSVS2019 seria. This one fixes type declarations made by globalDefinitions_VisCPP.hpp. The patch from 11u applied with the following changes:
>> 
>> - inttypes.h is included conditionally under `_MSC_VER >= 1800` because the header was introduced only in MSVS 2013 but we have to keep support of the earlier MSVS versions 
>> - the duplicates of declarations made in inttypes.h are not just removed but quoted with `_MSC_VER < 1800`
>> - common\autoconf\generated-configure.sh is regenerated to add MSVS2019 recognition (I forgot to do that in https://github.com/openjdk/jdk8u-dev/pull/33)
>> 
>> Verification: 2019 build (both 32/64) now fails with 
>> 
>> ad_x86_64_pipeline.obj : error LNK2011: precompiled object not linked in; image may not run
>> jvm.dll : fatal error LNK1120: 1 unresolved externals
>> 
>> error (to be fixed by backport of 8043492)
>> 
>> Regression: 2017/2013/2012/2010 full build - ok
>> 
>> @kimbarrett @dholmes-ora if you took a look at that it would be very much appreciated
>
> Alexey Pavlyutkin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge master
>  - fixing carriage returns
>  - Backport b8ab854bdcf625772e965a5e476e0a9db1b91f3f

ping

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

PR: https://git.openjdk.org/jdk8u-dev/pull/77

From sgehwolf at openjdk.org  Tue Jul 19 08:32:19 2022
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 19 Jul 2022 08:32:19 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache [v2]
In-Reply-To: <-QwbhbskPZW6KOY-oc4Mv6b7U4IFIIhUeJxzQgKDeJg=.c3c33bf5-ef0c-4848-b96b-d51211c9bb6a@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
 <MwTUmDjaouIWCEut9SJX6xTR4Yv3kMO6rScpmteaqaY=.2e1c72e9-0e2b-4eb2-879c-b9299e2d5482@github.com>
 <HmjYgFB8Ydc-bC3Cw22il4G7Zw26Bjbdazfk_Y4szVg=.27508723-99eb-42fe-b603-7e89930c3ae4@github.com>
 <-QwbhbskPZW6KOY-oc4Mv6b7U4IFIIhUeJxzQgKDeJg=.c3c33bf5-ef0c-4848-b96b-d51211c9bb6a@github.com>
Message-ID: <SwgbtG83mPZ7O7ucQbfdzWhrCrjn4ibwzU8yfeFAKX8=.3a360706-a41c-43d2-ac24-2e8ccb689b22@github.com>

On Mon, 18 Jul 2022 09:26:37 GMT, lusou-zhangquan <duke at openjdk.org> wrote:

>> Looks fine, but please run at least tier1 tests.
>
> @phohensee Please take a look at this PR again, thanks a lot.

@lusou-zhangquan Please only issue /integrate once you have `jdk8u-fix-yes` on the bug. See "Contributing" section in https://wiki.openjdk.org/display/jdk8u In particular steps 10 and 11.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/70

From duke at openjdk.org  Wed Jul 20 09:14:40 2022
From: duke at openjdk.org (Alexey Pavlyutkin)
Date: Wed, 20 Jul 2022 09:14:40 GMT
Subject: [jdk8u-dev] RFR: 8288865: [aarch64] LDR instructions must use
 legitimized addresses
Message-ID: <WeaIJzSBER4ylyqEWNrfw3DaS0mcXg-4VF2TLJZ9zBE=.011dbecc-9a35-452b-85f2-159a78c048ec@github.com>

Hi! Here is a backport fixing offset large offsets on memory reading by Unsafe API for Aarch64. Except 11->8 path suffling the fix applied with the only change: only LDR-related part of the test is being backported cuz 8u-dev already has got STR-related one.

Verification (Ubuntu 18.04.6 LTS (GNU/Linux 4.9.0 aarch64)): 

hotspot/test/compiler/8235385/NonVolatileMemoryAccessWithLongOffset.java

10 of 10 runs PASS (5 of 10 runs FAILED before the patch applied)

Regression: hotspot/test/compiler

@theRealAph could you take a look, it's almost clean except the fact that STR-related part of test already presents in 8u-dev

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

Commit messages:
 - updates the test to cover LDR
 - remove duplicated test
 - Backport 1f4028960a3934853104efd1d95991b137b5f520

Changes: https://git.openjdk.org/jdk8u-dev/pull/84/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=84&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288865
  Stats: 191 lines in 3 files changed: 149 ins; 2 del; 40 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/84.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/84/head:pull/84

PR: https://git.openjdk.org/jdk8u-dev/pull/84

From adinn at openjdk.org  Wed Jul 20 09:53:21 2022
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 20 Jul 2022 09:53:21 GMT
Subject: [jdk8u-dev] RFR: 8288865: [aarch64] LDR instructions must use
 legitimized addresses
In-Reply-To: <WeaIJzSBER4ylyqEWNrfw3DaS0mcXg-4VF2TLJZ9zBE=.011dbecc-9a35-452b-85f2-159a78c048ec@github.com>
References: <WeaIJzSBER4ylyqEWNrfw3DaS0mcXg-4VF2TLJZ9zBE=.011dbecc-9a35-452b-85f2-159a78c048ec@github.com>
Message-ID: <mz5wm86jjZBegZV3afhAjPC6cParZofclX7_L91kxIA=.c2c1572e-cb99-4442-b79e-ad0c51fa8061@github.com>

On Wed, 20 Jul 2022 09:06:28 GMT, Alexey Pavlyutkin <duke at openjdk.org> wrote:

> Hi! Here is a backport fixing offset large offsets on memory reading by Unsafe API for Aarch64. Except 11->8 path suffling the fix applied with the only change: only LDR-related part of the test is being backported cuz 8u-dev already has got STR-related one.
> 
> Verification (Ubuntu 18.04.6 LTS (GNU/Linux 4.9.0 aarch64)): 
> 
> hotspot/test/compiler/8235385/NonVolatileMemoryAccessWithLongOffset.java
> 
> 10 of 10 runs PASS (5 of 10 runs FAILED before the patch applied)
> 
> Regression: hotspot/test/compiler
> 
> @theRealAph could you take a look, it's almost clean except the fact that STR-related part of test already presents in 8u-dev

Looks fine to me. Even the spelling mistakes are consistent with those in jdk11u.

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

Marked as reviewed by adinn (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/84

From duke at openjdk.org  Wed Jul 20 14:47:03 2022
From: duke at openjdk.org (George Adams)
Date: Wed, 20 Jul 2022 14:47:03 GMT
Subject: [jdk8u-dev] RFR: 8139668: Generate README-build.html from markdown
In-Reply-To: <7Ld4fTYfTSoAJHHVDi6sd0YYVttRBZpz4kY9U_6N9I0=.ea3d1c92-13fc-4adc-a48a-eefe4931d716@github.com>
References: <kXrVjkOjS_vU3XL4u5JQi8mafiTz6hvYAC0gYQC5bP0=.9d17dac8-ec69-425e-8c44-22b383f6cd86@github.com>
 <7Ld4fTYfTSoAJHHVDi6sd0YYVttRBZpz4kY9U_6N9I0=.ea3d1c92-13fc-4adc-a48a-eefe4931d716@github.com>
Message-ID: <C7LbWwdrPa4FBCcj7P2Q5wmtHSboSke7wEHYz_Z6Lxg=.cf6092d1-e711-404b-9459-7e21203a290f@github.com>

On Tue, 12 Jul 2022 15:55:49 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> This updates the build documentation so it `README-builds.html` is generated from `README-builds,md`
>> 
>> This is a precursor to [JDK-8176509](https://bugs.openjdk.org/browse/JDK-8176509) which also updates the `README`, simplifying #75 
>> 
>> There are deliberately no content changes here. In fact, JDK 9 changes to the documentation prior to this change are reverted (VS2010->VS2013 bump and other build requirement changes (namely [JDK-8041593](https://bugs.openjdk.org/browse/JDK-8041593) (JDK9 update), [JDK-8062223](https://bugs.openjdk.org/browse/JDK-8062223) (ccache update), [JDK-8076531](https://bugs.openjdk.org/browse/JDK-8076531) (Windows default compiler change) and [JDK-8072023](https://bugs.openjdk.org/browse/JDK-8072023) (make version change)). We can make our own updates once these changes are in.
>> 
>> The updated `README-builds.html` was generated from the new `README-builds.md`. I fixed a bug in `common/bin/update-build-readme.sh` which checks the variable `MARKDOWN` for the location of the processor but then uses a bare `markdown` in the actual invocation.  This script is removed in JDK-8176509 anyway, being replaced with `pandoc`.
>
> I can look at when the `doc` directory was added, but, if we add this to 8u, it should be a separate change, rather than part of this backport. I would prefer backports are as close to the original issue as possible, plus there's a follow-on fix I plan to backport that also happens before the directory is added.
> 
> I'll come back to this once the July security update is out. That's taking up all my time right now.

@gnu-andrew once you've got this good to merge I'll tackle [JDK-8176509](https://bugs.openjdk.org/browse/JDK-8176509) which should tidy up the README

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

PR: https://git.openjdk.org/jdk8u-dev/pull/79

From andrew at openjdk.org  Wed Jul 20 16:41:59 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 20 Jul 2022 16:41:59 GMT
Subject: [jdk8u-dev] RFR: Merge jdk8u:master
Message-ID: <XzMSv7RBshg66dbpd-iMU3MRJ9ogz71U9YwsVnAuNAs=.5c73417b-7a57-4c58-b77b-0eb622bc42fe@github.com>

Merge of post-branch changes for 8u342 release

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

Commit messages:
 - Merge jdk8u332-b07 into jdk8u-dev
 - 8285407: Improve Xalan supports
 - 8284370: Improve zlib usage
 - 8283190: Improve MIDI processing
 - 8281866: Enhance MethodHandle invocations
 - 8281859: Improve class compilation
 - 8272243: Improve DER parsing
 - 8209771: jdk.test.lib.Utils::runAndCheckException error
 - 8272249: Better properties of loaded Properties
 - 8277608: Address IP Addressing
 - ... and 2 more: https://git.openjdk.org/jdk8u-dev/compare/40a18594...2cd1dccd

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk8u-dev/pull/85/files
  Stats: 736 lines in 24 files changed: 524 ins; 96 del; 116 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/85.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/85/head:pull/85

PR: https://git.openjdk.org/jdk8u-dev/pull/85

From bylokhov at amazon.com  Wed Jul 20 20:27:40 2022
From: bylokhov at amazon.com (Sergey Bylokhov)
Date: Wed, 20 Jul 2022 13:27:40 -0700
Subject: The implication of the JDK-8194154 fix in jdk8u342.
Message-ID: <df6be709-37e5-6059-eec9-03dd6af61b57@amazon.com>

Hello, the last release of jdk8u includes the fix for JDK-8194154[1] which disabled the possibility 
to change the "user.dir" property.

Changing the "user.dir" was not recommended from the beginning but it was not forbidden, so there 
are some old applications that rely on the old behavior. One of the app which sets the "user.dir" is 
Gradle. The Gradle has a notice in the documentation for the user:
"Never use new File(relative path) because this creates a path relative to the current working 
directory (CWD). Gradle can make no guarantees about the location of the CWD, which means builds 
that rely on it may break at any time".

But for compatibility reasons they still set the "user.dir" property, so the old plugins will work. 
Now that compatibility is broken due to the fix I mention. We found such apps immediately after the 
release.

I would like to ask what was the reason for the backport, is it critical enough to change a 
behavior? I did not find any broad discussion about that backport nor the reason why it was pushed 
but I would like to bring a compatibility concerns about that change. I think we should roll it back 
as soon as possible.

Please share your opinions?

[1] https://bugs.openjdk.org/browse/JDK-8194154

-- 
Best regards, Sergey.

From tsteele at openjdk.org  Wed Jul 20 21:09:40 2022
From: tsteele at openjdk.org (Tyler Steele)
Date: Wed, 20 Jul 2022 21:09:40 GMT
Subject: [jdk8u-dev] RFR: 8288763: Pack200 extraction failure with invalid size
Message-ID: <3q10A_9wGPJLk14Zb_2_kxWEQR09pS2j6LlRPrA6NsI=.1ceee1df-907f-4bcb-9cfa-4489c1084226@github.com>

Backports this change to jdk8 to fix the pack200 compressed size issue here as well.

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

Commit messages:
 - Backport 5e1ce54d6a11eac153a6e6487bc0b4ed89741b5b

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

PR: https://git.openjdk.org/jdk8u-dev/pull/86

From tsteele at openjdk.org  Wed Jul 20 21:24:07 2022
From: tsteele at openjdk.org (Tyler Steele)
Date: Wed, 20 Jul 2022 21:24:07 GMT
Subject: [jdk8u-dev] RFR: 8288763: Pack200 extraction failure with invalid
 size
In-Reply-To: <3q10A_9wGPJLk14Zb_2_kxWEQR09pS2j6LlRPrA6NsI=.1ceee1df-907f-4bcb-9cfa-4489c1084226@github.com>
References: <3q10A_9wGPJLk14Zb_2_kxWEQR09pS2j6LlRPrA6NsI=.1ceee1df-907f-4bcb-9cfa-4489c1084226@github.com>
Message-ID: <bUyz4kF_KzheWNl-AR8UtD-iUMiyzmqoNaBBDZxAsqs=.a78772eb-d6d5-413d-b305-ea8894ab148b@github.com>

On Wed, 20 Jul 2022 20:59:48 GMT, Tyler Steele <tsteele at openjdk.org> wrote:

> Backports this change to jdk8 to fix the pack200 compressed size issue here as well.

The bots were confused because the file path was changed. This backport is squeaky clean.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/86

From tsteele at openjdk.org  Wed Jul 20 21:29:05 2022
From: tsteele at openjdk.org (Tyler Steele)
Date: Wed, 20 Jul 2022 21:29:05 GMT
Subject: [jdk8u-dev] RFR: 8288763: Pack200 extraction failure with invalid
 size
In-Reply-To: <3q10A_9wGPJLk14Zb_2_kxWEQR09pS2j6LlRPrA6NsI=.1ceee1df-907f-4bcb-9cfa-4489c1084226@github.com>
References: <3q10A_9wGPJLk14Zb_2_kxWEQR09pS2j6LlRPrA6NsI=.1ceee1df-907f-4bcb-9cfa-4489c1084226@github.com>
Message-ID: <TazFBKM1qySv4Ctf9C9J9tpGX-WR00DqB5ohGZJhm8Y=.8d97d59e-985f-43fc-9ea7-22d13ae3587e@github.com>

On Wed, 20 Jul 2022 20:59:48 GMT, Tyler Steele <tsteele at openjdk.org> wrote:

> Backports this change to jdk8 to fix the pack200 compressed size issue here as well.

You win this round bots! I will wait for a review.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/86

From hedongbo at huawei.com  Thu Jul 21 02:01:05 2022
From: hedongbo at huawei.com (hedongbo)
Date: Thu, 21 Jul 2022 02:01:05 +0000
Subject: The implication of the JDK-8194154 fix in jdk8u342.
In-Reply-To: <df6be709-37e5-6059-eec9-03dd6af61b57@amazon.com>
References: <df6be709-37e5-6059-eec9-03dd6af61b57@amazon.com>
Message-ID: <4a368d45a5ae4b77938d9ab50eea3382@huawei.com>

The initial reason is that the customer set -Duser dir=./xxx relative path, resulting in an error: Error: Could not find or load main class xxx.
Unfortunately, we can't get the customer's code, so PR uses the tes case that comes with the original fix to illustrate this problem.

Thanks,
hedongbo

-----Original Message-----
From: jdk8u-dev <jdk8u-dev-retn at openjdk.org> On Behalf Of Sergey Bylokhov
Sent: Thursday, July 21, 2022 4:28 AM
To: jdk8u-dev at openjdk.org; Andrew Hughes <gnu.andrew at redhat.com>
Subject: The implication of the JDK-8194154 fix in jdk8u342.

Hello, the last release of jdk8u includes the fix for JDK-8194154[1] which disabled the possibility to change the "user.dir" property.

Changing the "user.dir" was not recommended from the beginning but it was not forbidden, so there are some old applications that rely on the old behavior. One of the app which sets the "user.dir" is Gradle. The Gradle has a notice in the documentation for the user:
"Never use new File(relative path) because this creates a path relative to the current working directory (CWD). Gradle can make no guarantees about the location of the CWD, which means builds that rely on it may break at any time".

But for compatibility reasons they still set the "user.dir" property, so the old plugins will work. 
Now that compatibility is broken due to the fix I mention. We found such apps immediately after the release.

I would like to ask what was the reason for the backport, is it critical enough to change a behavior? I did not find any broad discussion about that backport nor the reason why it was pushed but I would like to bring a compatibility concerns about that change. I think we should roll it back as soon as possible.

Please share your opinions?

[1] https://bugs.openjdk.org/browse/JDK-8194154

--
Best regards, Sergey.

From gnu.andrew at redhat.com  Thu Jul 21 02:20:42 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 21 Jul 2022 03:20:42 +0100
Subject: OpenJDK 8u342 Released
Message-ID: <Yti3+pqoDhSz9oEv@hex.discworld.ac.uk>

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

The source tarball is available from:

* https://openjdk-sources.osci.io/openjdk8/openjdk8u342-b07.tar.xz

The tarball is accompanied by a digital signature available at:

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

dd319dda6ad091ed432553208bb2d5ae4721624e184c3db040a648c56ec8ceb8  openjdk8u342-b07.tar.xz
94c452b360474df099e8153b2e49f4a004b7bfa59e0285e39445eb0bff36c5f7  openjdk8u342-b07.tar.xz.sig

The checksums can be downloaded from:

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

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

* Security fixes
  - JDK-8272243: Improve DER parsing
  - JDK-8272249: Better properties of loaded Properties
  - JDK-8277608: Address IP Addressing
  - JDK-8281859, CVE-2022-21540: Improve class compilation
  - JDK-8281866, CVE-2022-21541: Enhance MethodHandle invocations
  - JDK-8283190: Improve MIDI processing
  - JDK-8284370: Improve zlib usage
  - JDK-8285407, CVE-2022-34169: Improve Xalan supports
* Other changes
  - JDK-8031567: Better model for storing source revision information
  - JDK-8076190: Customizing the generation of a PKCS12 keystore
  - JDK-8129572: Cleanup usage of getResourceAsStream in jaxp
  - JDK-8132256: jaxp: Investigate removal of com/sun/org/apache/bcel/internal/util/ClassPath.java
  - JDK-8168926: C2: Bytecode escape analyzer crashes due to stack overflow
  - JDK-8170385: JDK-8031567 broke source bundles
  - JDK-8170392: JDK-8031567 broke builds from source bundles
  - JDK-8170530: bash configure output contains a typo in a suggested library name
  - JDK-8190753: (zipfs): Accessing a large entry (> 2^31 bytes) leads to a negative initial size for ByteArrayOutputStream
  - JDK-8194154: System property user.dir should not be changed
  - JDK-8202142: jfr/event/io/TestInstrumentation is unstable
  - JDK-8209771: jdk.test.lib.Utils::runAndCheckException error
  - JDK-8221988: add possibility to build with Visual Studio 2019
  - JDK-8223396: [TESTBUG] several jfr tests do not clean up files created in /tmp
  - JDK-8230865: [TESTBUG] jdk/jfr/event/io/EvilInstrument.java fails at-run shell MakeJAR.sh target
  - JDK-8235211: serviceability/attach/RemovingUnixDomainSocketTest.java fails with AttachNotSupportedException: Unable to open socket file
  - JDK-8244973: serviceability/attach/RemovingUnixDomainSocketTest.java fails "stderr was not empty"
  - JDK-8248876: LoadObject with bad base address created for exec file on linux
  - JDK-8253424: Add support for running pre-submit testing using GitHub Actions
  - JDK-8253865: Pre-submit testing using GitHub Actions does not detect failures reliably
  - JDK-8254054: Pre-submit testing using GitHub Actions should not use the deprecated set-env command
  - JDK-8254173: Add Zero, Minimal hotspot targets to submit workflow
  - JDK-8254175: Build no-pch configuration in debug mode for submit checks
  - JDK-8254282: Add Linux x86_32 builds to submit workflow
  - JDK-8255239: The timezone of the hs_err_pid log file is corrupted in Japanese locale
  - JDK-8255305: Add Linux x86_32 tier1 to submit workflow
  - JDK-8255352: Archive important test outputs in submit workflow
  - JDK-8255373: Submit workflow artifact name is always "test-results_.zip"
  - JDK-8255895: Submit workflow artifacts miss hs_errs/replays due to ZIP include mismatch
  - JDK-8256127: Add cross-compiled foreign architectures builds to submit workflow
  - JDK-8256277: Github Action build on macOS should define OS and Xcode versions
  - JDK-8256354: Github Action build on Windows should define OS and MSVC versions
  - JDK-8256393: Github Actions build on Linux should define OS and GCC versions
  - JDK-8256414: add optimized build to submit workflow
  - JDK-8256747: GitHub Actions: decouple the hotspot build-only jobs from Linux x64 testing
  - JDK-8257056: Submit workflow should apt-get update to avoid package installation errors
  - JDK-8259924: GitHub actions fail on Linux x86_32 with "Could not configure libc6:i386"
  - JDK-8260460: GitHub actions still fail on Linux x86_32 with "Could not configure libc6:i386"
  - JDK-8261107: ArrayIndexOutOfBoundsException in the ICC_Profile.getInstance(InputStream)
  - JDK-8263667: Avoid running GitHub actions on branches named pr/*
  - JDK-8266187: Memory leak in appendBootClassPath()
  - JDK-8274658: ISO 4217 Amendment 170 Update
  - JDK-8274751: Drag And Drop hangs on Windows
  - JDK-8278138: OpenJDK8 fails to start on Windows 8.1 after upgrading compiler to VS2017
  - JDK-8279669: test/jdk/com/sun/jdi/TestScaffold.java uses wrong condition
  - JDK-8281814: Debuginfo.diz contains redundant build path after backport JDK-8025936
  - JDK-8282225: GHA: Allow one concurrent run per PR only
  - JDK-8282458: Update .jcheck/conf file for 8u move to git
  - JDK-8282552: Bump update version of OpenJDK: 8u342
  - JDK-8283350: (tz) Update Timezone Data to 2022a
  - JDK-8284620: CodeBuffer may leak _overflow_arena
  - JDK-8284772: 8u GHA: Use GCC Major Version Dependencies Only
  - JDK-8285445: cannot open file "NUL:"
  - JDK-8285523: Improve test java/io/FileOutputStream/OpenNUL.java
  - JDK-8285591: [11] add signum checks in DSA.java engineVerify
  - JDK-8285727: [11u, 17u] Unify fix for JDK-8284920 with version from head
  - JDK-8286989: Build failure on macOS after 8281814
  - JDK-8287537: 8u JDK-8284620 backport broke AArch64 build

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

security-libs/java.security:

JDK-8215293: Customizing PKCS12 keystore Generation
===================================================
New system and security properties have been added to enable users to
customize the generation of PKCS #12 keystores. This includes
algorithms and parameters for key protection, certificate protection,
and MacData. The detailed explanation and possible values for these
properties can be found in the "PKCS12 KeyStore properties" section of
the `java.security` file.

Also, support for the following SHA-2 based HmacPBE algorithms has
been added to the SunJCE provider:

* HmacPBESHA224
* HmacPBESHA256
* HmacPBESHA384
* HmacPBESHA512
* HmacPBESHA512/224
* HmacPBESHA512/256

core-libs/java.io:

JDK-8285660: Enable Windows Alternate Data Streams by default
=============================================================
The Windows implementation of `java.io.File` has been changed so that
strict validity checks are **not** performed by default on file
paths. This includes allowing colons (':') in the path other than only
immediately after a single drive letter. It also allows paths that
represent NTFS Alternate Data Streams (ADS), such as
"filename:streamname". This restores the default behavior of
`java.io.File` to what it was prior to the April 2022 CPU in which
strict validity checks were not performed by default on file paths on
Windows. To re-enable strict path checking in `java.io.File`, the
system property `jdk.io.File.enableADS` should be set to `false` (case
ignored). This might be preferable, for example, if Windows special
device paths such as `NUL:` are *not* used.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/jdk8u-dev/attachments/20220721/667f9955/signature.asc>

From t.glaser at tarent.de  Thu Jul 21 02:29:29 2022
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Thu, 21 Jul 2022 04:29:29 +0200 (CEST)
Subject: OpenJDK 8u342 Released
In-Reply-To: <Yti3+pqoDhSz9oEv@hex.discworld.ac.uk>
References: <Yti3+pqoDhSz9oEv@hex.discworld.ac.uk>
Message-ID: <30bb448-f81d-b9a7-a173-4b82c1b3962@tarent.de>

On Thu, 21 Jul 2022, Andrew Hughes wrote:

> We are pleased to announce the release of OpenJDK 8u342.

OK. https://github.com/openjdk/jdk8u/tags shows only the b07 tag,
not the ga tag, is this deliberate?

Would someone please also release ? correspondingly? Thanks!
https://github.com/openjdk/aarch32-port-jdk8u/tags

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 andrew at openjdk.org  Thu Jul 21 02:37:13 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 21 Jul 2022 02:37:13 GMT
Subject: [jdk8u-dev] RFR: Merge jdk8u:master [v2]
In-Reply-To: <XzMSv7RBshg66dbpd-iMU3MRJ9ogz71U9YwsVnAuNAs=.5c73417b-7a57-4c58-b77b-0eb622bc42fe@github.com>
References: <XzMSv7RBshg66dbpd-iMU3MRJ9ogz71U9YwsVnAuNAs=.5c73417b-7a57-4c58-b77b-0eb622bc42fe@github.com>
Message-ID: <IHn1GekYUUn4VcJMo73Osu33KREDOF2d4-dXxpjGpXQ=.a5965f87-2d93-4f46-8aec-c4a272822aa3@github.com>

> Merge of post-branch changes for 8u342 release

Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:

 - Merge jdk8u332-b07 into jdk8u-dev
 - 8130895: Test javax/swing/system/6799345/TestShutdown.java fails on Solaris11 Sparcv9
   
   Backport-of: 4140fd05a447c888856c54aee22c475173030833
 - 8194873: right ALT key hotkeys no longer work in Swing components
   8155742: [Windows] robot.keyPress(KeyEvent.VK_ALT_GRAPH) throws java.lang.IllegalArgumentException in windows
   
   Reviewed-by: alitvinov, yan, serb
   Backport-of: 91f281c8d713e489ddc282f935ebd879485c4b41
 - 8282538: PKCS11 tests fail on CentOS Stream 9
   
   Backport-of: d8fd22239bafecdaaedb8985ab6d709ed846e808
 - 8256722: handle VC++:1927 VS2019 in  abstract_vm_version
   
   Backport-of: 146fe86ff68095b5eb0ce1387061699738280c06
 - 8233019: java.lang.Class.isPrimitive() (C1) returns wrong result if Klass* is aligned to 32bit
   
   Reviewed-by: phh
   Backport-of: b67ca938f37f952e53f73d2e0b8ebcaf96139fda
 - 8235218: Minimal VM is broken after JDK-8173361
   
   Reviewed-by: sgehwolf, andrew
   Backport-of: c10f731b11f314c97660df08c62f3c3d2f718f54
 - 8150669: C1 intrinsic for Class.isPrimitive
   
   Reviewed-by: phh
   Backport-of: 890f94d7e6be731ac2ebae2f1ad3cc20ec836115
 - 8283849: AsyncGetCallTrace may crash JVM on guarantee
   
   Reviewed-by: phh
   Backport-of: 19639855311a47ed532547743ea3873eb8b016d3
 - 8136354: [TEST_BUG] Test  java/awt/image/RescaleOp/RescaleAlphaTest.java with Bad action for script
   
   Backport-of: da688f57c3822e0327ad717290bed88baa73bd17
 - ... and 6 more: https://git.openjdk.org/jdk8u-dev/compare/a099a7db...2cd1dccd

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

Changes:
  - all: https://git.openjdk.org/jdk8u-dev/pull/85/files
  - new: https://git.openjdk.org/jdk8u-dev/pull/85/files/2cd1dccd..2cd1dccd

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

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/85.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/85/head:pull/85

PR: https://git.openjdk.org/jdk8u-dev/pull/85

From andrew at openjdk.org  Thu Jul 21 02:37:14 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 21 Jul 2022 02:37:14 GMT
Subject: [jdk8u-dev] Integrated: Merge jdk8u:master
In-Reply-To: <XzMSv7RBshg66dbpd-iMU3MRJ9ogz71U9YwsVnAuNAs=.5c73417b-7a57-4c58-b77b-0eb622bc42fe@github.com>
References: <XzMSv7RBshg66dbpd-iMU3MRJ9ogz71U9YwsVnAuNAs=.5c73417b-7a57-4c58-b77b-0eb622bc42fe@github.com>
Message-ID: <g5n434TZy2FYC103Sj8e02MpEMGKqTzDwqSI24_zggk=.fbdbb6d8-4ffb-432f-9f78-6b825df7cef6@github.com>

On Wed, 20 Jul 2022 16:35:39 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Merge of post-branch changes for 8u342 release

This pull request has now been integrated.

Changeset: f7f6d9d0
Author:    Andrew John Hughes <andrew at openjdk.org>
URL:       https://git.openjdk.org/jdk8u-dev/commit/f7f6d9d07fa3f166fe0155f80c61730c1c788ac5
Stats:     736 lines in 24 files changed: 524 ins; 96 del; 116 mod

Merge

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

PR: https://git.openjdk.org/jdk8u-dev/pull/85

From bylokhov at amazon.com  Thu Jul 21 05:10:11 2022
From: bylokhov at amazon.com (Sergey Bylokhov)
Date: Wed, 20 Jul 2022 22:10:11 -0700
Subject: The implication of the JDK-8194154 fix in jdk8u342.
In-Reply-To: <4a368d45a5ae4b77938d9ab50eea3382@huawei.com>
References: <df6be709-37e5-6059-eec9-03dd6af61b57@amazon.com>
 <4a368d45a5ae4b77938d9ab50eea3382@huawei.com>
Message-ID: <afe53c31-2385-59bd-187c-89b8430bf068@amazon.com>

You just confirmed that people tends to set that property for one reason or another. In your case if 
the customer application is new then it was broken from the beginning, if the application was old 
then this change just broke it in another way since all local paths which are used by the 
application will be changed. Take a look to this discussion and the number of discussions linked 
from there:
https://github.com/gradle/gradle/issues/5187

Even the checkstyle plugin is broken:
https://github.com/reposense/RepoSense/pull/530



On 7/20/22 19:01, hedongbo wrote:
> The initial reason is that the customer set -Duser dir=./xxx relative path, resulting in an error: Error: Could not find or load main class xxx.
> Unfortunately, we can't get the customer's code, so PR uses the tes case that comes with the original fix to illustrate this problem.
> 
> Thanks,
> hedongbo
> 
> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.org> On Behalf Of Sergey Bylokhov
> Sent: Thursday, July 21, 2022 4:28 AM
> To: jdk8u-dev at openjdk.org; Andrew Hughes <gnu.andrew at redhat.com>
> Subject: The implication of the JDK-8194154 fix in jdk8u342.
> 
> Hello, the last release of jdk8u includes the fix for JDK-8194154[1] which disabled the possibility to change the "user.dir" property.
> 
> Changing the "user.dir" was not recommended from the beginning but it was not forbidden, so there are some old applications that rely on the old behavior. One of the app which sets the "user.dir" is Gradle. The Gradle has a notice in the documentation for the user:
> "Never use new File(relative path) because this creates a path relative to the current working directory (CWD). Gradle can make no guarantees about the location of the CWD, which means builds that rely on it may break at any time".
> 
> But for compatibility reasons they still set the "user.dir" property, so the old plugins will work.
> Now that compatibility is broken due to the fix I mention. We found such apps immediately after the release.
> 
> I would like to ask what was the reason for the backport, is it critical enough to change a behavior? I did not find any broad discussion about that backport nor the reason why it was pushed but I would like to bring a compatibility concerns about that change. I think we should roll it back as soon as possible.
> 
> Please share your opinions?
> 
> [1] https://bugs.openjdk.org/browse/JDK-8194154
> 
> --
> Best regards, Sergey.


-- 
Best regards, Sergey.

From duke at openjdk.org  Thu Jul 21 06:46:08 2022
From: duke at openjdk.org (Poison)
Date: Thu, 21 Jul 2022 06:46:08 GMT
Subject: [jdk8u-dev] RFR: 8214427: probable bug in logic of
 ConcurrentHashMap.addCount() [v3]
In-Reply-To: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
References: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
Message-ID: <_Vq8b_znRuWWvaPywbYsmmXzhXtHHqoRmrnfODm-AJY=.0974576b-a169-4ed4-a483-9c56e3f1ef77@github.com>

> 8214427: probable bug in logic of ConcurrentHashMap.addCount()
> 
> This backport fixes the problem that the MAX_RESIZERS control does not take effect when multi-threaded expansion in ConcurrentHashMap.

Poison has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Backport 8846159987f902bb6e2b966eb4656da4b6d9469d
   
   format code
 - Merge branch 'openjdk:master' into backport-8214427
 - Merge branch 'openjdk:master' into backport-8214427
 - Backport 8846159987f902bb6e2b966eb4656da4b6d9469d

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

Changes:
  - all: https://git.openjdk.org/jdk8u-dev/pull/18/files
  - new: https://git.openjdk.org/jdk8u-dev/pull/18/files/0fbcdcaa..284b7b75

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

  Stats: 1456 lines in 58 files changed: 1180 ins; 124 del; 152 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/18.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/18/head:pull/18

PR: https://git.openjdk.org/jdk8u-dev/pull/18

From duke at openjdk.org  Thu Jul 21 06:47:22 2022
From: duke at openjdk.org (Poison)
Date: Thu, 21 Jul 2022 06:47:22 GMT
Subject: [jdk8u-dev] RFR: 8214427: probable bug in logic of
 ConcurrentHashMap.addCount() [v2]
In-Reply-To: <uEjYJCoo0-jELcORGgzEOoP37oLZoTtDi67I0LFwGcY=.a9878873-5b89-436f-9ae6-754042e42555@github.com>
References: <t5KdIesfh2dXnMyKkeuXYpgcfvaECvZ9n_Ed-HNpE2U=.6acc3c6d-6942-425b-8116-6ad64ae8a02c@github.com>
 <vtdVLByJ-U5hK3ZxqijdhQcezk43ljmSEqrkUmNbZgI=.fe061860-ba0c-4d31-a588-2596e3d41f76@github.com>
 <uEjYJCoo0-jELcORGgzEOoP37oLZoTtDi67I0LFwGcY=.a9878873-5b89-436f-9ae6-754042e42555@github.com>
Message-ID: <alwFGYLMCMRLcOu66oaGWg_gYNNNn8-0E_p_2J7zN2E=.e89da410-17e3-4769-889c-76ac225eb0f1@github.com>

On Sun, 10 Jul 2022 15:35:39 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> > I've opened a PR for the 11u backport: [openjdk/jdk11u-dev#1114](https://github.com/openjdk/jdk11u-dev/pull/1114)
> > Can you merge this with jdk8u-dev/master so that the full set of build checks run?
> > I've see some whitespace differences with the 8u version:
> > ```
> > -+                        (nt = nextTable) == null || transferIndex <= 0)
> > ++                            (nt = nextTable) == null || transferIndex <= 0)
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > ```
> > -+                    transferIndex <= 0)
> > ++                        transferIndex <= 0)
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > Do you see this locally or is it introduced by the `webrev` tool?
> > The change from `compareAndSetInt` to `compareAndSwapInt` looks correct to match the 8u version.
> 
> These whitespace issues are still not resolved in the current patch.

Already fixed

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

PR: https://git.openjdk.org/jdk8u-dev/pull/18

From duke at openjdk.org  Thu Jul 21 09:53:40 2022
From: duke at openjdk.org (George Adams)
Date: Thu, 21 Jul 2022 09:53:40 GMT
Subject: [jdk8u-dev] RFR: 8290000: Bump macOS GitHub actions to macOS 11
Message-ID: <1LfIfwSY2gXzCNJgFnAHvXVbcfx4RuG6Mo3pHhqxoaA=.fb60ceea-82c2-49c8-b218-f973c3150308@github.com>

macOS 10.15 has been deprecated for some time and will be removed completely on August 30th. See https://github.com/actions/virtual-environments#available-environments and https://github.com/actions/virtual-environments/issues/5583 for context.

This PR doesn't apply cleanly because it was added to the GitHub actions rewrite in tip. As it's unlikely that I will have a backported rewrite by August 30th my preference is to backport this way round.

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

Commit messages:
 - Backport 4e6cd67fec3d978f4c8c1aed95a1d09b544eff68

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

PR: https://git.openjdk.org/jdk8u-dev/pull/87

From duke at openjdk.org  Thu Jul 21 09:59:08 2022
From: duke at openjdk.org (George Adams)
Date: Thu, 21 Jul 2022 09:59:08 GMT
Subject: [jdk8u-dev] RFR: 8290000: Bump macOS GitHub actions to macOS 11
 [v2]
In-Reply-To: <1LfIfwSY2gXzCNJgFnAHvXVbcfx4RuG6Mo3pHhqxoaA=.fb60ceea-82c2-49c8-b218-f973c3150308@github.com>
References: <1LfIfwSY2gXzCNJgFnAHvXVbcfx4RuG6Mo3pHhqxoaA=.fb60ceea-82c2-49c8-b218-f973c3150308@github.com>
Message-ID: <nBHuEq7bqCWwlWH-n7tn-wIbpFjtw8l41Mgl-NbVT80=.c4c286fe-3ef6-44b5-856a-0503c8f07c94@github.com>

> macOS 10.15 has been deprecated for some time and will be removed completely on August 30th. See https://github.com/actions/virtual-environments#available-environments and https://github.com/actions/virtual-environments/issues/5583 for context.
> 
> This PR doesn't apply cleanly because it was added to the GitHub actions rewrite in tip. As it's unlikely that I will have a backported rewrite by August 30th my preference is to backport this way round.

George Adams has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Backport 4e6cd67fec3d978f4c8c1aed95a1d09b544eff68

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

Changes:
  - all: https://git.openjdk.org/jdk8u-dev/pull/87/files
  - new: https://git.openjdk.org/jdk8u-dev/pull/87/files/c189f8a3..08cb4aae

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

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/87.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/87/head:pull/87

PR: https://git.openjdk.org/jdk8u-dev/pull/87

From bylokhov at amazon.com  Thu Jul 21 17:44:28 2022
From: bylokhov at amazon.com (Sergey Bylokhov)
Date: Thu, 21 Jul 2022 10:44:28 -0700
Subject: The implication of the JDK-8194154 fix in jdk8u342.
In-Reply-To: <df6be709-37e5-6059-eec9-03dd6af61b57@amazon.com>
References: <df6be709-37e5-6059-eec9-03dd6af61b57@amazon.com>
Message-ID: <256c7a3f-191a-9363-d8e7-6f9c5f867961@amazon.com>

We at Amazon decided to do a respin of our JDK 8 to revert the fix for 8194154.
I have created the jbs bug to track the current issue: https://bugs.openjdk.org/browse/JDK-8290832
if the community agrees to fix it in the OpenJDK repo I can propose the PR.


On 7/20/22 13:27, Sergey Bylokhov wrote:
> Hello, the last release of jdk8u includes the fix for JDK-8194154[1] which disabled the possibility 
> to change the "user.dir" property.
> 
> Changing the "user.dir" was not recommended from the beginning but it was not forbidden, so there 
> are some old applications that rely on the old behavior. One of the app which sets the "user.dir" is 
> Gradle. The Gradle has a notice in the documentation for the user:
> "Never use new File(relative path) because this creates a path relative to the current working 
> directory (CWD). Gradle can make no guarantees about the location of the CWD, which means builds 
> that rely on it may break at any time".
> 
> But for compatibility reasons they still set the "user.dir" property, so the old plugins will work. 
> Now that compatibility is broken due to the fix I mention. We found such apps immediately after the 
> release.
> 
> I would like to ask what was the reason for the backport, is it critical enough to change a 
> behavior? I did not find any broad discussion about that backport nor the reason why it was pushed 
> but I would like to bring a compatibility concerns about that change. I think we should roll it back 
> as soon as possible.
> 
> Please share your opinions?
> 
> [1] https://bugs.openjdk.org/browse/JDK-8194154
> 


-- 
Best regards, Sergey.

From t.glaser at tarent.de  Thu Jul 21 18:23:18 2022
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Thu, 21 Jul 2022 20:23:18 +0200 (CEST)
Subject: The implication of the JDK-8194154 fix in jdk8u342.
In-Reply-To: <256c7a3f-191a-9363-d8e7-6f9c5f867961@amazon.com>
References: <df6be709-37e5-6059-eec9-03dd6af61b57@amazon.com>
 <256c7a3f-191a-9363-d8e7-6f9c5f867961@amazon.com>
Message-ID: <ea8216dc-68d4-637-d45d-9dc950c324b@tarent.de>

On Thu, 21 Jul 2022, Sergey Bylokhov wrote:

> I have created the jbs bug to track the current issue:
> https://bugs.openjdk.org/browse/JDK-8290832
> if the community agrees to fix it in the OpenJDK repo I can propose the PR.

Given OpenJDK 8 is ?legacy use only? it definitely should, IMHO,
continue running programs it used to run.

I?d rather question the proposed fix. It would be better to
normalise the paths at the places they are used.

One caveat: Martin Buchholz said that ? All APIs on Posix systems should
treat a sequence of more than one '/' equivalently to exactly one.? but
that?s untrue for one specific case: a sequence of exactly two (no less,
no more) leading slashes, in an absolute pathname, must be kept exactly
that becaude it *may* (but doesn?t have to) refer to a different filesy?
stem namespace (e.g. UNC names, for networking) instead.

So, ///foo and ////foo are /foo but //foo may or may not be /foo.

Might be useful, even, to change 11 to match.

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 serb at openjdk.org  Thu Jul 21 21:36:45 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 21 Jul 2022 21:36:45 GMT
Subject: [jdk8u-dev] RFR: JDK-8290832: It is no longer possible to change
 "user.dir" in the JDK8
Message-ID: <W0pjhP4ROmBMfS1AospdJ17URyi52s6Fdu8Z3VOWYxI=.10d8357b-4ad0-43b2-89a9-8d97491fd6c2@github.com>

This is the request to revert the fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) integrated to the [openjdk8u342](https://github.com/openjdk/jdk8u/commit/5fcfb7acbe340c8347bd47413a36dd0b1e267dc1)

The fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) disabled the possibility to change the "user.dir" property.
Changing the "user.dir" was not recommended from the beginning but it was not forbidden, so there are some old applications that rely on the old behavior. 

For compatibility reasons, it would be good to restore the old behavior.

Note that the test is simplified and saved under a different name, now it will check just the possibility to change the 'user.dir' using a simple path and name.

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

Commit messages:
 - Create ChangeDefaultUserDir.java
 - Revert "8194154: System property user.dir should not be changed"

Changes: https://git.openjdk.org/jdk8u-dev/pull/88/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=88&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290832
  Stats: 119 lines in 4 files changed: 52 ins; 65 del; 2 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/88.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/88/head:pull/88

PR: https://git.openjdk.org/jdk8u-dev/pull/88

From dsamersoff at openjdk.org  Fri Jul 22 08:50:10 2022
From: dsamersoff at openjdk.org (Dmitry Samersoff)
Date: Fri, 22 Jul 2022 08:50:10 GMT
Subject: [jdk8u-dev] RFR: JDK-8290832: It is no longer possible to change
 "user.dir" in the JDK8
In-Reply-To: <W0pjhP4ROmBMfS1AospdJ17URyi52s6Fdu8Z3VOWYxI=.10d8357b-4ad0-43b2-89a9-8d97491fd6c2@github.com>
References: <W0pjhP4ROmBMfS1AospdJ17URyi52s6Fdu8Z3VOWYxI=.10d8357b-4ad0-43b2-89a9-8d97491fd6c2@github.com>
Message-ID: <mMq45joe89Zq3dbQplQbkLLO4RjexQiLsrJE-gtVhzs=.a8226e87-25d6-45f0-80ff-fcaeb0da3b76@github.com>

On Thu, 21 Jul 2022 19:46:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the request to revert the fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) integrated to the [openjdk8u342](https://github.com/openjdk/jdk8u/commit/5fcfb7acbe340c8347bd47413a36dd0b1e267dc1)
> 
> The fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) disabled the possibility to change the "user.dir" property.
> Changing the "user.dir" was not recommended from the beginning but it was not forbidden, so there are some old applications that rely on the old behavior. 
> 
> For compatibility reasons, it would be good to restore the old behavior.
> 
> Note that the test is simplified and saved under a different name, now it will check just the possibility to change the 'user.dir' using a simple path and name.

Looks good to me.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/88

From aleksei.voitylov at bell-sw.com  Fri Jul 22 08:59:04 2022
From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov)
Date: Fri, 22 Jul 2022 11:59:04 +0300
Subject: The implication of the JDK-8194154 fix in jdk8u342.
In-Reply-To: <df6be709-37e5-6059-eec9-03dd6af61b57@amazon.com>
References: <df6be709-37e5-6059-eec9-03dd6af61b57@amazon.com>
Message-ID: <f94a943c-7ea2-4f1e-5a9f-cb9a4bd78c8f@bell-sw.com>

Hi Sergey,

JDK-8194154 is originally mislabeled as P3, it should IMO have been P2
according to ILW. That said, unfortunately the 8u backport had
unintended consequences, which have badly broken compatibility by making
it impossible to change user.dir.

I'm thus for backing out JDK-8194154, and having an 8u345(?) respin of
OpenJDK when this fix is in. Thank you for proposing JDK-8290832.

-Aleksei

On 20.07.2022 23:27, Sergey Bylokhov wrote:
> Hello, the last release of jdk8u includes the fix for JDK-8194154[1]
> which disabled the possibility to change the "user.dir" property.
>
> Changing the "user.dir" was not recommended from the beginning but it
> was not forbidden, so there are some old applications that rely on the
> old behavior. One of the app which sets the "user.dir" is Gradle. The
> Gradle has a notice in the documentation for the user:
> "Never use new File(relative path) because this creates a path
> relative to the current working directory (CWD). Gradle can make no
> guarantees about the location of the CWD, which means builds that rely
> on it may break at any time".
>
> But for compatibility reasons they still set the "user.dir" property,
> so the old plugins will work. Now that compatibility is broken due to
> the fix I mention. We found such apps immediately after the release.
>
> I would like to ask what was the reason for the backport, is it
> critical enough to change a behavior? I did not find any broad
> discussion about that backport nor the reason why it was pushed but I
> would like to bring a compatibility concerns about that change. I
> think we should roll it back as soon as possible.
>
> Please share your opinions?
>
> [1] https://bugs.openjdk.org/browse/JDK-8194154
>


From clanger at openjdk.org  Fri Jul 22 10:19:33 2022
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 22 Jul 2022 10:19:33 GMT
Subject: [jdk8u-dev] RFR: JDK-8290832: It is no longer possible to change
 "user.dir" in the JDK8
In-Reply-To: <W0pjhP4ROmBMfS1AospdJ17URyi52s6Fdu8Z3VOWYxI=.10d8357b-4ad0-43b2-89a9-8d97491fd6c2@github.com>
References: <W0pjhP4ROmBMfS1AospdJ17URyi52s6Fdu8Z3VOWYxI=.10d8357b-4ad0-43b2-89a9-8d97491fd6c2@github.com>
Message-ID: <qyUbmWjLFoaPU5yIvJiv9LTd2NL0hrN1BJvZ-7mcWGw=.414aba34-939c-4f06-8d53-432a4507cacc@github.com>

On Thu, 21 Jul 2022 19:46:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the request to revert the fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) integrated to the [openjdk8u342](https://github.com/openjdk/jdk8u/commit/5fcfb7acbe340c8347bd47413a36dd0b1e267dc1)
> 
> The fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) disabled the possibility to change the "user.dir" property.
> Changing the "user.dir" was not recommended from the beginning but it was not forbidden, so there are some old applications that rely on the old behavior. 
> 
> For compatibility reasons, it would be good to restore the old behavior.
> 
> Note that the test is simplified and saved under a different name, now it will check just the possibility to change the 'user.dir' using a simple path and name.

The change itself looks good. But wouldn't it be better to do a clean backout of [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) and then add the test that user.dir can be changed in JDK8 with a different issue?

Or would it at least be possible that the test is not shown as renamed but rather as a deletion of the old test and the addition of a new test? (Not sure whether that's something that git did automatically or whether you can change this)

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

PR: https://git.openjdk.org/jdk8u-dev/pull/88

From serb at openjdk.org  Fri Jul 22 17:41:14 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 22 Jul 2022 17:41:14 GMT
Subject: [jdk8u-dev] RFR: JDK-8290832: It is no longer possible to change
 "user.dir" in the JDK8
In-Reply-To: <qyUbmWjLFoaPU5yIvJiv9LTd2NL0hrN1BJvZ-7mcWGw=.414aba34-939c-4f06-8d53-432a4507cacc@github.com>
References: <W0pjhP4ROmBMfS1AospdJ17URyi52s6Fdu8Z3VOWYxI=.10d8357b-4ad0-43b2-89a9-8d97491fd6c2@github.com>
 <qyUbmWjLFoaPU5yIvJiv9LTd2NL0hrN1BJvZ-7mcWGw=.414aba34-939c-4f06-8d53-432a4507cacc@github.com>
Message-ID: <a5HKqILqC7JCnp-SfCZ0wgf4oJwhNlj9GBCvtBCGsNU=.5f870d0e-fe3b-4e36-872f-17ac4da203b4@github.com>

On Fri, 22 Jul 2022 10:16:11 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Or would it at least be possible that the test is not shown as renamed but rather as a deletion of the old test and the addition of a new test? (Not sure whether that's something that git did automatically or whether you can change this)

It is actually a deletion in one commit and adding a new test by another, it is how the github shows it, but I can split it by different commits.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/88

From serb at openjdk.org  Fri Jul 22 17:49:15 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 22 Jul 2022 17:49:15 GMT
Subject: [jdk8u-dev] RFR: JDK-8290832: It is no longer possible to change
 "user.dir" in the JDK8 [v2]
In-Reply-To: <W0pjhP4ROmBMfS1AospdJ17URyi52s6Fdu8Z3VOWYxI=.10d8357b-4ad0-43b2-89a9-8d97491fd6c2@github.com>
References: <W0pjhP4ROmBMfS1AospdJ17URyi52s6Fdu8Z3VOWYxI=.10d8357b-4ad0-43b2-89a9-8d97491fd6c2@github.com>
Message-ID: <9PqdruMNqbzOoPJknURZQZ5nXU3Z1wPkJ8iTr2NFWuM=.d5884bf6-055b-4273-896d-d3102217caa0@github.com>

> This is the request to revert the fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) integrated to the [openjdk8u342](https://github.com/openjdk/jdk8u/commit/5fcfb7acbe340c8347bd47413a36dd0b1e267dc1)
> 
> The fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) disabled the possibility to change the "user.dir" property.
> Changing the "user.dir" was not recommended from the beginning but it was not forbidden, so there are some old applications that rely on the old behavior. 
> 
> For compatibility reasons, it would be good to restore the old behavior.
> 
> Note that the test is simplified and saved under a different name, now it will check just the possibility to change the 'user.dir' using a simple path and name.

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

  Delete ChangeDefaultUserDir.java

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

Changes:
  - all: https://git.openjdk.org/jdk8u-dev/pull/88/files
  - new: https://git.openjdk.org/jdk8u-dev/pull/88/files/1f51111d..b2d52666

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

  Stats: 52 lines in 1 file changed: 0 ins; 52 del; 0 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/88.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/88/head:pull/88

PR: https://git.openjdk.org/jdk8u-dev/pull/88

From serb at openjdk.org  Fri Jul 22 17:49:17 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 22 Jul 2022 17:49:17 GMT
Subject: [jdk8u-dev] RFR: JDK-8290832: It is no longer possible to change
 "user.dir" in the JDK8
In-Reply-To: <W0pjhP4ROmBMfS1AospdJ17URyi52s6Fdu8Z3VOWYxI=.10d8357b-4ad0-43b2-89a9-8d97491fd6c2@github.com>
References: <W0pjhP4ROmBMfS1AospdJ17URyi52s6Fdu8Z3VOWYxI=.10d8357b-4ad0-43b2-89a9-8d97491fd6c2@github.com>
Message-ID: <6ZG9sXrypY1tpixmaWoCLKrLELmrH4CBYjL_CuDkrbE=.144e924e-91d2-4222-a731-dfd2c7cf7684@github.com>

On Thu, 21 Jul 2022 19:46:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the request to revert the fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) integrated to the [openjdk8u342](https://github.com/openjdk/jdk8u/commit/5fcfb7acbe340c8347bd47413a36dd0b1e267dc1)
> 
> The fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) disabled the possibility to change the "user.dir" property.
> Changing the "user.dir" was not recommended from the beginning but it was not forbidden, so there are some old applications that rely on the old behavior. 
> 
> For compatibility reasons, it would be good to restore the old behavior.
> 
> Note that the test is simplified and saved under a different name, now it will check just the possibility to change the 'user.dir' using a simple path and name.

The patch is updated as requested, the test will be pushed separately.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/88

From clanger at openjdk.org  Fri Jul 22 20:48:20 2022
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 22 Jul 2022 20:48:20 GMT
Subject: [jdk8u-dev] RFR: JDK-8290832: It is no longer possible to change
 "user.dir" in the JDK8 [v2]
In-Reply-To: <9PqdruMNqbzOoPJknURZQZ5nXU3Z1wPkJ8iTr2NFWuM=.d5884bf6-055b-4273-896d-d3102217caa0@github.com>
References: <W0pjhP4ROmBMfS1AospdJ17URyi52s6Fdu8Z3VOWYxI=.10d8357b-4ad0-43b2-89a9-8d97491fd6c2@github.com>
 <9PqdruMNqbzOoPJknURZQZ5nXU3Z1wPkJ8iTr2NFWuM=.d5884bf6-055b-4273-896d-d3102217caa0@github.com>
Message-ID: <FGME8oIyMmd5WTMgig-kbkbhEoESGAg_5FdOnmcWF8M=.c3ee1f6d-8b5f-4f0b-b4f6-ff6ce8a136de@github.com>

On Fri, 22 Jul 2022 17:49:15 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is the request to revert the fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) integrated to the [openjdk8u342](https://github.com/openjdk/jdk8u/commit/5fcfb7acbe340c8347bd47413a36dd0b1e267dc1)
>> 
>> The fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) disabled the possibility to change the "user.dir" property.
>> Changing the "user.dir" was not recommended from the beginning but it was not forbidden, so there are some old applications that rely on the old behavior. 
>> 
>> For compatibility reasons, it would be good to restore the old behavior.
>> 
>> Note that the test is simplified and saved under a different name, now it will check just the possibility to change the 'user.dir' using a simple path and name.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delete ChangeDefaultUserDir.java

LGTM. You might consider renaming the JBS issue to something like "Backout JDK-8194154..." But I leave that to your or the 8u maintainers.

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

Marked as reviewed by clanger (Reviewer).

PR: https://git.openjdk.org/jdk8u-dev/pull/88

From christoph.langer at sap.com  Fri Jul 22 21:33:10 2022
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 22 Jul 2022 21:33:10 +0000
Subject: The implication of the JDK-8194154 fix in jdk8u342.
In-Reply-To: <4a368d45a5ae4b77938d9ab50eea3382@huawei.com>
References: <df6be709-37e5-6059-eec9-03dd6af61b57@amazon.com>
 <4a368d45a5ae4b77938d9ab50eea3382@huawei.com>
Message-ID: <DU2PR02MB7792BD7CF36CCD7C763D21278A909@DU2PR02MB7792.eurprd02.prod.outlook.com>

Hi,

out of interest, I was playing a bit with JDK-8194154 and I agree that it should not have been backported to 8u in first place and should definitely be reverted. The effect of the fix is simply to not honor a change of System property "user.dir" within Java code any longer in nio Path handling. This is a change in behavior which should be avoided in update releases.

The patch in itself is questionable since the potential crash that should be addressed by the fix is still lurking and can be reproduced by starting the VM with a -D option, e.g. -Duser.dir="/home/a/b/c/". That is still possible with current JDK11, by the way. It must have been fixed somehow in between 11 and 17.

And furthermore, I also doubt that the problem that the backporters of this patch wanted to address, e.g. to avoid issues starting the VM when a relative path is set via -Duser.dir, would be fixed. This can still be reproduced with JDK-8194154 applied. It must have been fixed with another change between 8 and 11.

Best regards
Christoph

> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.org> On Behalf Of hedongbo
> Sent: Donnerstag, 21. Juli 2022 04:01
> To: Sergey Bylokhov <bylokhov at amazon.com>; jdk8u-dev at openjdk.org;
> Andrew Hughes <gnu.andrew at redhat.com>
> Cc: Chenshanyao <chenshanyao at huawei.com>
> Subject: RE: The implication of the JDK-8194154 fix in jdk8u342.
> 
> The initial reason is that the customer set -Duser dir=./xxx relative path,
> resulting in an error: Error: Could not find or load main class xxx.
> Unfortunately, we can't get the customer's code, so PR uses the tes case that
> comes with the original fix to illustrate this problem.
> 
> Thanks,
> hedongbo
> 
> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.org> On Behalf Of Sergey Bylokhov
> Sent: Thursday, July 21, 2022 4:28 AM
> To: jdk8u-dev at openjdk.org; Andrew Hughes <gnu.andrew at redhat.com>
> Subject: The implication of the JDK-8194154 fix in jdk8u342.
> 
> Hello, the last release of jdk8u includes the fix for JDK-8194154[1] which
> disabled the possibility to change the "user.dir" property.
> 
> Changing the "user.dir" was not recommended from the beginning but it was
> not forbidden, so there are some old applications that rely on the old behavior.
> One of the app which sets the "user.dir" is Gradle. The Gradle has a notice in
> the documentation for the user:
> "Never use new File(relative path) because this creates a path relative to the
> current working directory (CWD). Gradle can make no guarantees about the
> location of the CWD, which means builds that rely on it may break at any
> time".
> 
> But for compatibility reasons they still set the "user.dir" property, so the old
> plugins will work.
> Now that compatibility is broken due to the fix I mention. We found such apps
> immediately after the release.
> 
> I would like to ask what was the reason for the backport, is it critical enough to
> change a behavior? I did not find any broad discussion about that backport nor
> the reason why it was pushed but I would like to bring a compatibility concerns
> about that change. I think we should roll it back as soon as possible.
> 
> Please share your opinions?
> 
> [1] https://bugs.openjdk.org/browse/JDK-8194154
> 
> --
> Best regards, Sergey.

From duke at openjdk.org  Sun Jul 24 20:14:02 2022
From: duke at openjdk.org (George Adams)
Date: Sun, 24 Jul 2022 20:14:02 GMT
Subject: [jdk8u-dev] RFR: 8251551: Use .md filename extension for README
In-Reply-To: <W0JyblcUvnhtSdOZ1yThJd1jrYRTAx0-HHG7Q3tWHxo=.18161227-3dbc-4bcf-968d-65f576c4281f@github.com>
References: <R-sF5coJgFH-Vhx1TexI_HokiwRiwvWvPFukJbdU3xs=.8d8ba90b-a684-4871-aa5b-00b5918e1a36@github.com>
 <W0JyblcUvnhtSdOZ1yThJd1jrYRTAx0-HHG7Q3tWHxo=.18161227-3dbc-4bcf-968d-65f576c4281f@github.com>
Message-ID: <TZtQ9wBHGeGIJjQ8JwiGLed_fz8MNJct-odLj1JGrfM=.229ab39b-11bd-4c27-8555-ae2710907eaa@github.com>

On Fri, 24 Jun 2022 17:35:04 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> Backports https://bugs.openjdk.org/browse/JDK-8251551 as it's a low-risk change and generally improves the readability/usability in GitHub.
>> 
>> Currently, I've just converted the README to markdown format and added a little syntax highlighting. I'm not sure if people would like me to go one step further and rip out the mercurial/nested repo references?
>
> I've opened #79 for the first of these. Once both are in, you should be able to just do this change cleanly.

Adding a comment to prevent this from closing. @gnu-andrew is your other patch ready yet?

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

PR: https://git.openjdk.org/jdk8u-dev/pull/75

From hedongbo at huawei.com  Mon Jul 25 01:15:40 2022
From: hedongbo at huawei.com (hedongbo)
Date: Mon, 25 Jul 2022 01:15:40 +0000
Subject: The implication of the JDK-8194154 fix in jdk8u342.
In-Reply-To: <DU2PR02MB7792BD7CF36CCD7C763D21278A909@DU2PR02MB7792.eurprd02.prod.outlook.com>
References: <df6be709-37e5-6059-eec9-03dd6af61b57@amazon.com>
 <4a368d45a5ae4b77938d9ab50eea3382@huawei.com>
 <DU2PR02MB7792BD7CF36CCD7C763D21278A909@DU2PR02MB7792.eurprd02.prod.outlook.com>
Message-ID: <b97c78bcdf0a455cae505131e1d2e803@huawei.com>

Hi,
 
After in-depth communication with customers, we found that when customers upgraded JDK to 8u232,
`java.lang.RuntimeException: default directory must be absolute` exception was thrown, which causes the product to fail to
start(introduced by JDK-8213429[1], CVE-2019-2933). The following is a simple case:

$ cat Foo.java
public class Foo {
    public static void main(String[] args) {
        System.out.println("foo");
    }
}
$ openjdk-8u222-b10/bin/java -Duser.dir=. Foo foo $ openjdk-8u232-b09/bin/java -Duser.dir=. Foo
Error: A JNI error has occurred, please check your installation and try again Exception in thread "main" java.lang.ExceptionInInitializerError
            at sun.net.www.protocol.file.FileURLConnection.getPermission(FileURLConnection.java:225)
            at java.net.URLClassLoader.getPermissions(URLClassLoader.java:666)
            at sun.misc.Launcher$AppClassLoader.getPermissions(Launcher.java:360)
            at java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:206)
            at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
            at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
            at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
            at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
            at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
            at java.security.AccessController.doPrivileged(Native Method)
            at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
            at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
            at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
            at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
            at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495)
Caused by: java.lang.RuntimeException: default directory must be absolute
            at sun.nio.fs.UnixFileSystem.<init>(UnixFileSystem.java:54)
            at sun.nio.fs.LinuxFileSystem.<init>(LinuxFileSystem.java:39)
            at sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:46)
            at sun.nio.fs.LinuxFileSystemProvider.newFileSystem(LinuxFileSystemProvider.java:39)
            at sun.nio.fs.UnixFileSystemProvider.<init>(UnixFileSystemProvider.java:56)
            at sun.nio.fs.LinuxFileSystemProvider.<init>(LinuxFileSystemProvider.java:41)
            at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
            at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
            at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
            at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
            at java.lang.Class.newInstance(Class.java:442)
            at sun.nio.fs.DefaultFileSystemProvider.createProvider(DefaultFileSystemProvider.java:48)
            at sun.nio.fs.DefaultFileSystemProvider.create(DefaultFileSystemProvider.java:63)
            at java.io.FilePermission.<clinit>(FilePermission.java:187)
            ... 15 more
$ openjdk-8u232-b09/bin/java -Duser.dir=$PWD Foo
foo

Our customer changed to use absolute path in -Duser.dir as a workaround, so in fact this patch doesn't help the customer's problem.

But we found that customers should not change the value of user.dir, believing that JDK-8194154 is a JDK bug and should be backported to jdk8u.
Unfortunately, we didn't realize that this would bring us compatibility issues. I apologize for this.
 
I agree to revert this patch in JDK8 to maintain backward compatibility, apologize again.

[1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/b148d99d5cc3
 
Thanks,
hedongbo

-----Original Message-----
From: Langer, Christoph <christoph.langer at sap.com> 
Sent: Saturday, July 23, 2022 5:33 AM
To: hedongbo <hedongbo at huawei.com>; Sergey Bylokhov <bylokhov at amazon.com>; jdk8u-dev at openjdk.org; Andrew Hughes <gnu.andrew at redhat.com>
Cc: Chenshanyao <chenshanyao at huawei.com>
Subject: RE: The implication of the JDK-8194154 fix in jdk8u342.

Hi,

out of interest, I was playing a bit with JDK-8194154 and I agree that it should not have been backported to 8u in first place and should definitely be reverted. The effect of the fix is simply to not honor a change of System property "user.dir" within Java code any longer in nio Path handling. This is a change in behavior which should be avoided in update releases.

The patch in itself is questionable since the potential crash that should be addressed by the fix is still lurking and can be reproduced by starting the VM with a -D option, e.g. -Duser.dir="/home/a/b/c/". That is still possible with current JDK11, by the way. It must have been fixed somehow in between 11 and 17.

And furthermore, I also doubt that the problem that the backporters of this patch wanted to address, e.g. to avoid issues starting the VM when a relative path is set via -Duser.dir, would be fixed. This can still be reproduced with JDK-8194154 applied. It must have been fixed with another change between 8 and 11.

Best regards
Christoph

> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.org> On Behalf Of hedongbo
> Sent: Donnerstag, 21. Juli 2022 04:01
> To: Sergey Bylokhov <bylokhov at amazon.com>; jdk8u-dev at openjdk.org; 
> Andrew Hughes <gnu.andrew at redhat.com>
> Cc: Chenshanyao <chenshanyao at huawei.com>
> Subject: RE: The implication of the JDK-8194154 fix in jdk8u342.
> 
> The initial reason is that the customer set -Duser dir=./xxx relative 
> path, resulting in an error: Error: Could not find or load main class xxx.
> Unfortunately, we can't get the customer's code, so PR uses the tes 
> case that comes with the original fix to illustrate this problem.
> 
> Thanks,
> hedongbo
> 
> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-retn at openjdk.org> On Behalf Of Sergey 
> Bylokhov
> Sent: Thursday, July 21, 2022 4:28 AM
> To: jdk8u-dev at openjdk.org; Andrew Hughes <gnu.andrew at redhat.com>
> Subject: The implication of the JDK-8194154 fix in jdk8u342.
> 
> Hello, the last release of jdk8u includes the fix for JDK-8194154[1] 
> which disabled the possibility to change the "user.dir" property.
> 
> Changing the "user.dir" was not recommended from the beginning but it 
> was not forbidden, so there are some old applications that rely on the old behavior.
> One of the app which sets the "user.dir" is Gradle. The Gradle has a 
> notice in the documentation for the user:
> "Never use new File(relative path) because this creates a path 
> relative to the current working directory (CWD). Gradle can make no 
> guarantees about the location of the CWD, which means builds that rely 
> on it may break at any time".
> 
> But for compatibility reasons they still set the "user.dir" property, 
> so the old plugins will work.
> Now that compatibility is broken due to the fix I mention. We found 
> such apps immediately after the release.
> 
> I would like to ask what was the reason for the backport, is it 
> critical enough to change a behavior? I did not find any broad 
> discussion about that backport nor the reason why it was pushed but I 
> would like to bring a compatibility concerns about that change. I think we should roll it back as soon as possible.
> 
> Please share your opinions?
> 
> [1] https://bugs.openjdk.org/browse/JDK-8194154
> 
> --
> Best regards, Sergey.

From ebaron at openjdk.org  Mon Jul 25 21:04:59 2022
From: ebaron at openjdk.org (Elliott Baron)
Date: Mon, 25 Jul 2022 21:04:59 GMT
Subject: [jdk8u-dev] RFR: 8035467: Xerces Update: Move to Xalan based DOM L3
 serializer. Deprecate Xerces' native serializer.
Message-ID: <Lx7dn5rK4UFSvKjhh9iv8DbQDcGnxGZ3Ct28bAcVl_k=.851d6cbb-526f-4635-9564-ef7722d31e3c@github.com>

This backport is part of the effort to update Xerces in 8u to 2.12 ([JDK-8238164](https://bugs.openjdk.org/browse/JDK-8238164).

The JDK 9 commit does not apply cleanly, but only required cosmetic changes. These are due to differences in some copyright headers, and not having a `@version` Javadoc tag in the 8u version of these files.

I am concerned over deprecating the Xerces serializer. As noted in [JDK-8219692](https://bugs.openjdk.org/browse/JDK-8219692), there are behavioural changes caused by this new serializer.

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

Commit messages:
 - Backport 16cbc58194d5256dcbca6fc6567f44057494b6f1

Changes: https://git.openjdk.org/jdk8u-dev/pull/89/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=89&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8035467
  Stats: 6315 lines in 50 files changed: 6205 ins; 2 del; 108 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/89.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/89/head:pull/89

PR: https://git.openjdk.org/jdk8u-dev/pull/89

From andrew at openjdk.org  Tue Jul 26 19:26:33 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 26 Jul 2022 19:26:33 GMT
Subject: [jdk8u-dev] RFR: 8139668: Generate README-build.html from markdown
In-Reply-To: <kXrVjkOjS_vU3XL4u5JQi8mafiTz6hvYAC0gYQC5bP0=.9d17dac8-ec69-425e-8c44-22b383f6cd86@github.com>
References: <kXrVjkOjS_vU3XL4u5JQi8mafiTz6hvYAC0gYQC5bP0=.9d17dac8-ec69-425e-8c44-22b383f6cd86@github.com>
Message-ID: <RtJqHA1AFSK0ZfmS_xoEHHNqyP3DqFKbEbfmzlAii_0=.a6f330f3-73cc-4a6a-84d4-8fd379dc163a@github.com>

On Fri, 24 Jun 2022 17:34:34 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> This updates the build documentation so it `README-builds.html` is generated from `README-builds,md`
> 
> This is a precursor to [JDK-8176509](https://bugs.openjdk.org/browse/JDK-8176509) which also updates the `README`, simplifying #75 
> 
> There are deliberately no content changes here. In fact, JDK 9 changes to the documentation prior to this change are reverted (VS2010->VS2013 bump and other build requirement changes (namely [JDK-8041593](https://bugs.openjdk.org/browse/JDK-8041593) (JDK9 update), [JDK-8062223](https://bugs.openjdk.org/browse/JDK-8062223) (ccache update), [JDK-8076531](https://bugs.openjdk.org/browse/JDK-8076531) (Windows default compiler change) and [JDK-8072023](https://bugs.openjdk.org/browse/JDK-8072023) (make version change)). We can make our own updates once these changes are in.
> 
> The updated `README-builds.html` was generated from the new `README-builds.md`. I fixed a bug in `common/bin/update-build-readme.sh` which checks the variable `MARKDOWN` for the location of the processor but then uses a bare `markdown` in the actual invocation.  This script is removed in JDK-8176509 anyway, being replaced with `pandoc`.

This is good to go from my side. Waiting on a review.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/79

From andrew at openjdk.org  Tue Jul 26 19:26:34 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 26 Jul 2022 19:26:34 GMT
Subject: [jdk8u-dev] RFR: 8139668: Generate README-build.html from markdown
In-Reply-To: <QP0oUNxdxjq42KRy8C7YQ8r1G_JGcs2lLdi-j8WULww=.7629b303-7ab6-4c5c-95f3-29cc15d695ad@github.com>
References: <kXrVjkOjS_vU3XL4u5JQi8mafiTz6hvYAC0gYQC5bP0=.9d17dac8-ec69-425e-8c44-22b383f6cd86@github.com>
 <86I2-vbk6aoBUlr6Y8A8XNrz_9QnhM2ecBXFIjPCm7U=.0d28efc4-f443-49b3-bb20-07730ac6d8eb@github.com>
 <QP0oUNxdxjq42KRy8C7YQ8r1G_JGcs2lLdi-j8WULww=.7629b303-7ab6-4c5c-95f3-29cc15d695ad@github.com>
Message-ID: <cGU6bh0edfWL2VXyXAMVvw51w3YFeB0MFsu3i_cCQGA=.9ce3d7cf-19df-4f73-a20a-3116ca4b346e@github.com>

On Thu, 30 Jun 2022 08:55:39 GMT, George Adams <duke at openjdk.org> wrote:

> Probably we should move this document to the new doc folder? Do we have a plans to align Readme/BuildDoc to the jdk/jdk version, simple readme with a few links and other docs in "doc" folder?: https://github.com/openjdk/jdk

That sounds a sensible approach. I'd prefer to do that via backports where possible, but it sounds like the doc change is buried in the mono transition so it might not be possible with that one. This is the first step. [JDK-8176509](https://bugs.openjdk.org/browse/JDK-8176509) would be the second.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/79

From iris.clark at oracle.com  Tue Jul 26 21:09:38 2022
From: iris.clark at oracle.com (Iris Clark)
Date: Tue, 26 Jul 2022 21:09:38 +0000
Subject: Java SE 8 Maintenance Release 4 (JSR 337) posted to jcp.org
Message-ID: <SJ0PR10MB54404AE1D04417552765977BFB949@SJ0PR10MB5440.namprd10.prod.outlook.com>

Maintenance Release 4 of JSR 337 which includes updates to the specification,
RI, and TCK exclude list is available here:

https://jcp.org/aboutJava/communityprocess/mrel/jsr337/index4.html

Thanks to everyone who contributed to this effort!

Iris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk8u-dev/attachments/20220726/b8fc3a24/attachment.htm>

From duke at openjdk.org  Wed Jul 27 02:43:14 2022
From: duke at openjdk.org (lusou-zhangquan)
Date: Wed, 27 Jul 2022 02:43:14 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache [v2]
In-Reply-To: <-QwbhbskPZW6KOY-oc4Mv6b7U4IFIIhUeJxzQgKDeJg=.c3c33bf5-ef0c-4848-b96b-d51211c9bb6a@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
 <MwTUmDjaouIWCEut9SJX6xTR4Yv3kMO6rScpmteaqaY=.2e1c72e9-0e2b-4eb2-879c-b9299e2d5482@github.com>
 <HmjYgFB8Ydc-bC3Cw22il4G7Zw26Bjbdazfk_Y4szVg=.27508723-99eb-42fe-b603-7e89930c3ae4@github.com>
 <-QwbhbskPZW6KOY-oc4Mv6b7U4IFIIhUeJxzQgKDeJg=.c3c33bf5-ef0c-4848-b96b-d51211c9bb6a@github.com>
Message-ID: <1NF_3g5Tk2hZSEHaFfKO-I6zdDnV1kHcWYUC226r-Ts=.ce77443d-208e-4442-8711-508bf2284a36@github.com>

On Mon, 18 Jul 2022 09:26:37 GMT, lusou-zhangquan <duke at openjdk.org> wrote:

>> Looks fine, but please run at least tier1 tests.
>
> @phohensee Please take a look at this PR again, thanks a lot.

> @lusou-zhangquan Please only issue /integrate once you have `jdk8u-fix-yes` on the bug. See "Contributing" section in https://wiki.openjdk.org/display/jdk8u In particular steps 10 and 11.

Sorry for not following the contributing rules. The latest comment of this bug mentions this PR but no `jdk8u-fix-yes` label attached. Should I keep waiting or request for maintainer's review to let it move on? Will appreciate if you could give any advice.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/70

From phh at openjdk.org  Wed Jul 27 15:38:54 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 27 Jul 2022 15:38:54 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache [v3]
In-Reply-To: <vcmpDcetyz5zqMt912h8ytHbsI5HJE9cWAH_L6unZ7s=.a5e5d3a0-9b89-4f52-96e7-ef50dcab99f9@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
 <vcmpDcetyz5zqMt912h8ytHbsI5HJE9cWAH_L6unZ7s=.a5e5d3a0-9b89-4f52-96e7-ef50dcab99f9@github.com>
Message-ID: <-M8dDvXM9KRzmOErpAGrNqs8oW2jHzrVlGxOHEnvdlQ=.195b6e62-8eb3-4329-b084-1a58ff7ff2d6@github.com>

On Tue, 21 Jun 2022 02:27:18 GMT, lusou-zhangquan <duke at openjdk.org> wrote:

>> Backport JDK-8049228 to improve multithreaded scalability of InetAddress cache
>> 
>> Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c
>
> lusou-zhangquan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8049228: Improve multithreaded scalability of InetAddress cache
>   
>   Backport-of 250fbb065a789a303d692d698c9b69117bf6cd2c

lusou-zhangquan, I've tagged both issues with jdk8u-fix-request on your behalf. If you post here any additional justification you may have, I'll add it to the fix request comment.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/70

From dholmes at openjdk.org  Wed Jul 27 21:54:03 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 27 Jul 2022 21:54:03 GMT
Subject: [jdk8u] RFR: 8287132: Retire Runtime.runFinalizersOnExit so that it
 always throws UOE
Message-ID: <1qsfSrYGZqYw3qDHwDPRT8v0aAsbM8VWXMREyMTxaQ4=.7ab82dd7-a972-4ffb-8a4c-109a49e4eff1@github.com>

Forward port of the changes for SE 8 Maintenance release 4, as applied to jdk8u-ri, for:

[JDK-8287132](https://bugs.openjdk.org/browse/JDK-8287132): Retire Runtime.runFinalizersOnExit so that it always throws UOE

The changes applied "unclean" only with regard to trivial things like copyright year updates.

Thanks.

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

Commit messages:
 - Backport 0d4cfc090c651786535529acfe5acb0209cb1d3d

Changes: https://git.openjdk.org/jdk8u/pull/13/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u&pr=13&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287132
  Stats: 575 lines in 25 files changed: 98 ins; 366 del; 111 mod
  Patch: https://git.openjdk.org/jdk8u/pull/13.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u pull/13/head:pull/13

PR: https://git.openjdk.org/jdk8u/pull/13

From duke at openjdk.org  Wed Jul 27 23:12:39 2022
From: duke at openjdk.org (Rui Li)
Date: Wed, 27 Jul 2022 23:12:39 GMT
Subject: [jdk8u-dev] RFR: 8071530: Update OS detection code to reflect Windows
 10 version change
Message-ID: <9-bsPn0zQrI8aMTYbwVUcNr9qIz8VtawAsUqgoTPf2A=.b15e830b-4bbe-44e9-9ac5-cffc7ceeb3e9@github.com>

jdk commit: https://github.com/openjdk/jdk/commit/fa47cc3e215fe4bb7531ff1a78f3965e2e84ac9f

Clean backport.

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

Commit messages:
 - Backport fa47cc3e215fe4bb7531ff1a78f3965e2e84ac9f

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

PR: https://git.openjdk.org/jdk8u-dev/pull/91

From duke at openjdk.org  Thu Jul 28 02:26:51 2022
From: duke at openjdk.org (lusou-zhangquan)
Date: Thu, 28 Jul 2022 02:26:51 GMT
Subject: [jdk8u-dev] RFR: 8049228: Improve multithreaded scalability of
 InetAddress cache [v3]
In-Reply-To: <-M8dDvXM9KRzmOErpAGrNqs8oW2jHzrVlGxOHEnvdlQ=.195b6e62-8eb3-4329-b084-1a58ff7ff2d6@github.com>
References: <HbSRA1llWmyonPm6aOUeZNIAWu23Jvxgb2q8zsg0w5Q=.72da7639-1f95-42a3-8879-5a8d99bf2456@github.com>
 <vcmpDcetyz5zqMt912h8ytHbsI5HJE9cWAH_L6unZ7s=.a5e5d3a0-9b89-4f52-96e7-ef50dcab99f9@github.com>
 <-M8dDvXM9KRzmOErpAGrNqs8oW2jHzrVlGxOHEnvdlQ=.195b6e62-8eb3-4329-b084-1a58ff7ff2d6@github.com>
Message-ID: <X1EeocnpvvnzRrFNU11XpEbaWfIwDo1uUNcLV90O3T8=.a0febf47-dfdb-4856-93f0-18a50b02cedf@github.com>

On Wed, 27 Jul 2022 15:36:49 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> lusou-zhangquan, I've tagged both issues with jdk8u-fix-request on your behalf. If you post here any additional justification you may have, I'll add it to the fix request comment.

Thanks a lot for your help.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/70

From duke at openjdk.org  Thu Jul 28 05:22:46 2022
From: duke at openjdk.org (duke)
Date: Thu, 28 Jul 2022 05:22:46 GMT
Subject: [jdk8u-dev] Withdrawn: 8173339: AArch64: Fix minimum stack size
 computations
In-Reply-To: <bEg39Q0fA25U3eHCwj0V3y-7ECL56wrHnisD63mfLfo=.c1e4e2cb-bc9c-4d35-b5c9-a14f0cf56d96@github.com>
References: <bEg39Q0fA25U3eHCwj0V3y-7ECL56wrHnisD63mfLfo=.c1e4e2cb-bc9c-4d35-b5c9-a14f0cf56d96@github.com>
Message-ID: <5EMYbc-jL-FV9OVJIACfjt8MMDD3wfBdZs_OeEcsdLw=.e76b081e-c9c9-49db-b69c-48d30cfacdc6@github.com>

On Mon, 30 May 2022 03:22:04 GMT, Dongbo He <dongbohe at openjdk.org> wrote:

> Hi,
> 
> I would like to backport this patch to fix minimum stack size computations on AArch64.
> I updated the value directly on `define_pd_global` because [JDK-8078556](https://bugs.openjdk.java.net/browse/JDK-8078556) is not in 8u.
> 
> Testing: Performed full jtreg test aarch64-linux-gnu platforms with 4k page size.
> Following test case worked correctly after patch.
> Before patch:
> $ java TLSStackOverflow
> [1]    35476 segmentation fault (core dumped) java TLSStackOverflow
> After patch:
> $ java TLSStackOverflow
> got expected stackoverflow, passed
> 
> $ keytool -genkey -keyalg RSA -keystore localhost-rsa.jks -storepass changeit -storetype pkcs12
> $ cat TLSStackOverflow.java
> 
> import javax.net.ServerSocketFactory;
> import javax.net.SocketFactory;
> import javax.net.ssl.*;
> import java.io.*;
> import java.net.InetAddress;
> import java.net.InetSocketAddress;
> import java.net.Socket;
> import java.security.KeyStore;
> import java.security.KeyStoreException;
> import java.security.NoSuchAlgorithmException;
> import java.security.SecureRandom;
> import java.security.cert.CertificateException;
> import java.security.cert.X509Certificate;
> 
> public class TLSStackOverflow
> {
> 
>     private static final String keystore = "/home/hedongbo/myprojects/study/stackoverflow/new/localhost-rsa.jks";
>     private static final char[] passphrase = "changeit".toCharArray();
>     private static final int port = 8447;
> 
>     private static KeyStore pfx = null;
> 
>     public static void doWrite(OutputStream out) throws Exception {
>         out.write("hello".getBytes(), 0, 3);
>         out.flush();
>         doWrite(out);
>     }
> 
>     public TLSStackOverflow()
>     {}
> 
>     public static void main(String[] args) throws Exception
>     {
>         new Thread(() -> {
>             try {
>                 pfx = KeyStore.getInstance("PKCS12");
>                 pfx.load(new FileInputStream(keystore), passphrase);
>                 SSLContext ctx = SSLContext.getInstance("TLS");
>                 KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
>                 kmf.init(pfx, passphrase);
>                 KeyManager[] kms = kmf.getKeyManagers();
>                 ctx.init(kms, null, null);
>                 ServerSocketFactory fact = ctx.getServerSocketFactory();
>                 SSLServerSocket serversocket = (SSLServerSocket) fact.createServerSocket(port);
>                 while (true)
>                 {
>                     Socket socket = null;
>                     try
>                     {
>                         socket = serversocket.accept();
> 
>                         DataInputStream in = new DataInputStream(socket.getInputStream());
>                         DataOutputStream out = new DataOutputStream(socket.getOutputStream());
> 
>                         byte[] buf = new byte[8192];
>                         int len = in.read(buf);
>                     }
>                     catch (Exception e)
>                     {
>                         e.printStackTrace();
>                     }
>                     finally
>                     {
> //                        try
> //                        {
> //                            socket.close();
> //                        }
> //                        catch (Exception e) {
> //                            e.printStackTrace();
> //                        }
>                     }
>                 }
>             } catch (Exception e) {
>                 e.printStackTrace();
>             }
>         }).start();
> 
>         Thread.sleep(2000);
> 
>         new Thread(() -> {
>             SSLSocket socket = null;
>             try {
>                 pfx = KeyStore.getInstance("PKCS12");
>                 pfx.load(new FileInputStream(keystore), passphrase);
>                 SSLContext ctx = SSLContext.getInstance("TLS");
>                 KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
>                 kmf.init(pfx, passphrase);
>                 TrustAllManager[] trust = { new TrustAllManager() };
>                 ctx.init(null, trust, null);
>                 SocketFactory fact = ctx.getSocketFactory();
>                 socket = (SSLSocket) fact.createSocket();
>                 socket.connect(new InetSocketAddress(InetAddress.getLoopbackAddress(), port), 2000);
>                 socket.setTcpNoDelay(true);
>                 socket.startHandshake();
> 
>                 DataInputStream in = new DataInputStream(socket.getInputStream());
>                 DataOutputStream out = new DataOutputStream(socket.getOutputStream());
> 
>                 String s = "GET " + " HTTP/1.1\r\n";
>                 s+= "Accept: */*\r\n";
>                 s+= "User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)\r\n";
>                 s+= "Connection: Close\r\n";
>                 s+= "\r\n";
>                 try {
>                     doWrite(out);
>                 } catch (StackOverflowError e) {
>                     System.out.println("got expected stackoverflow, passed");
>                     System.exit(0);
>                 }
> 
>                 byte[] buf = new byte[8192];
>                 int len = in.read(buf);
>                 if (len == -1)
>                 {
>                     System.out.println("eof");
>                     return;
>                 }
>                 System.out.println(new String(buf, 0, len));
>             }
>             catch (Exception e)
>             {
>                 e.printStackTrace();
>             }
>             finally
>             {
>                 try
>                 {
>                     socket.close();
>                 }
>                 catch (Exception e)
>                 {}
>             }
> 
>         }).start();
> 
>     }
> 
> }
> 
> 
> class TrustAllManager implements X509TrustManager
> {
>     private X509Certificate[] issuers;
> 
>     public TrustAllManager()
>     {
>         this.issuers = new X509Certificate[0];
>     }
> 
>     public X509Certificate[] getAcceptedIssuers()
>     {
>         return issuers ;
>     }
> 
>     public void checkClientTrusted(X509Certificate[] chain, String authType)
>     {}
> 
>     public void checkServerTrusted(X509Certificate[] chain, String authType)
>     {}
> }

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/66

From duke at openjdk.org  Thu Jul 28 05:25:52 2022
From: duke at openjdk.org (duke)
Date: Thu, 28 Jul 2022 05:25:52 GMT
Subject: [jdk8u-dev] Withdrawn: 8166140: C1: Possible integer overflow in
 LIRGenerator::generate_address on several platforms
In-Reply-To: <bewq2-9tRiBHq9XBksQrrPdbPxmvODqIXWOC1ae9jfg=.38d18744-9790-404a-b5ae-cfd346309d92@github.com>
References: <bewq2-9tRiBHq9XBksQrrPdbPxmvODqIXWOC1ae9jfg=.38d18744-9790-404a-b5ae-cfd346309d92@github.com>
Message-ID: <el-0cn80O_KcHjpR6piavM3Y6eDY3kCfpCFSRDnG84k=.61398d09-88ec-4c2c-a67d-0d5486d6b336@github.com>

On Fri, 22 Apr 2022 12:00:12 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> 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

This pull request has been closed without being integrated.

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

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

From iris at openjdk.org  Thu Jul 28 18:54:10 2022
From: iris at openjdk.org (Iris Clark)
Date: Thu, 28 Jul 2022 18:54:10 GMT
Subject: [jdk8u] RFR: 8287132: Retire Runtime.runFinalizersOnExit so that
 it always throws UOE
In-Reply-To: <1qsfSrYGZqYw3qDHwDPRT8v0aAsbM8VWXMREyMTxaQ4=.7ab82dd7-a972-4ffb-8a4c-109a49e4eff1@github.com>
References: <1qsfSrYGZqYw3qDHwDPRT8v0aAsbM8VWXMREyMTxaQ4=.7ab82dd7-a972-4ffb-8a4c-109a49e4eff1@github.com>
Message-ID: <Uf2LOnVF50fiM6BTbqw6NRaVUnbcTEGc_yOmvsgp71Y=.8f36bd9c-4bb2-42d6-8df4-509aec2d5681@github.com>

On Wed, 27 Jul 2022 02:32:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Forward port of the changes for SE 8 Maintenance release 4, as applied to jdk8u-ri, for:
> 
> [JDK-8287132](https://bugs.openjdk.org/browse/JDK-8287132): Retire Runtime.runFinalizersOnExit so that it always throws UOE
> 
> The changes applied "unclean" only with regard to trivial things like copyright year updates.
> 
> Thanks.

Spec change match JSR 337 MR 4, as expected.

I leave it to the 8u Maintainers to comment on whether these changes should be applied to the jdk8u repo or the jdk8u-dev repo.

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

Marked as reviewed by iris (Author).

PR: https://git.openjdk.org/jdk8u/pull/13

From dholmes at openjdk.org  Thu Jul 28 23:05:59 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 28 Jul 2022 23:05:59 GMT
Subject: [jdk8u] RFR: 8287132: Retire Runtime.runFinalizersOnExit so that
 it always throws UOE
In-Reply-To: <1qsfSrYGZqYw3qDHwDPRT8v0aAsbM8VWXMREyMTxaQ4=.7ab82dd7-a972-4ffb-8a4c-109a49e4eff1@github.com>
References: <1qsfSrYGZqYw3qDHwDPRT8v0aAsbM8VWXMREyMTxaQ4=.7ab82dd7-a972-4ffb-8a4c-109a49e4eff1@github.com>
Message-ID: <_8kdcUZanSR_yodPR9qPrjhCsD5zaa9UdqvYgJZ5ihE=.2f7d1e06-4b56-498b-9133-37439429ed5f@github.com>

On Wed, 27 Jul 2022 02:32:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Forward port of the changes for SE 8 Maintenance release 4, as applied to jdk8u-ri, for:
> 
> [JDK-8287132](https://bugs.openjdk.org/browse/JDK-8287132): Retire Runtime.runFinalizersOnExit so that it always throws UOE
> 
> The changes applied "unclean" only with regard to trivial things like copyright year updates.
> 
> Thanks.

This is the wrong repo so I will close and re-submit.

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

PR: https://git.openjdk.org/jdk8u/pull/13

From dholmes at openjdk.org  Thu Jul 28 23:05:59 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 28 Jul 2022 23:05:59 GMT
Subject: [jdk8u] Withdrawn: 8287132: Retire Runtime.runFinalizersOnExit so that
 it always throws UOE
In-Reply-To: <1qsfSrYGZqYw3qDHwDPRT8v0aAsbM8VWXMREyMTxaQ4=.7ab82dd7-a972-4ffb-8a4c-109a49e4eff1@github.com>
References: <1qsfSrYGZqYw3qDHwDPRT8v0aAsbM8VWXMREyMTxaQ4=.7ab82dd7-a972-4ffb-8a4c-109a49e4eff1@github.com>
Message-ID: <wXrr3XbuvGGitLZjM8p8LhXMw1hgWPhHujDxNUJEZ7U=.a563ae76-6ecd-44b9-977d-d9a82a4b191f@github.com>

On Wed, 27 Jul 2022 02:32:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Forward port of the changes for SE 8 Maintenance release 4, as applied to jdk8u-ri, for:
> 
> [JDK-8287132](https://bugs.openjdk.org/browse/JDK-8287132): Retire Runtime.runFinalizersOnExit so that it always throws UOE
> 
> The changes applied "unclean" only with regard to trivial things like copyright year updates.
> 
> Thanks.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk8u/pull/13

From dholmes at openjdk.org  Fri Jul 29 00:26:22 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 29 Jul 2022 00:26:22 GMT
Subject: [jdk8u-dev] RFR: 8287132: Retire Runtime.runFinalizersOnExit so that
 it always throws UOE
Message-ID: <yC_fFLRfaFdzgXH3L6dzsTNxW4sMGN1bMh4jRIUEYGE=.4ba038a7-4a62-4de1-b181-cc66f079ad99@github.com>

Forward port of the changes for SE 8 Maintenance release 4, as applied to jdk8u-ri, for:

[JDK-8287132](https://bugs.openjdk.org/browse/JDK-8287132): Retire Runtime.runFinalizersOnExit so that it always throws UOE

The changes applied "unclean" only with regard to trivial things like copyright year updates.

Thanks.

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

Commit messages:
 - Backport 0d4cfc090c651786535529acfe5acb0209cb1d3d

Changes: https://git.openjdk.org/jdk8u-dev/pull/92/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=92&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287132
  Stats: 575 lines in 25 files changed: 98 ins; 365 del; 112 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/92.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/92/head:pull/92

PR: https://git.openjdk.org/jdk8u-dev/pull/92

From t.glaser at tarent.de  Fri Jul 29 00:44:19 2022
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Fri, 29 Jul 2022 02:44:19 +0200 (CEST)
Subject: [jdk8u-dev] RFR: 8287132: Retire Runtime.runFinalizersOnExit so
 that it always throws UOE
In-Reply-To: <yC_fFLRfaFdzgXH3L6dzsTNxW4sMGN1bMh4jRIUEYGE=.4ba038a7-4a62-4de1-b181-cc66f079ad99@github.com>
References: <yC_fFLRfaFdzgXH3L6dzsTNxW4sMGN1bMh4jRIUEYGE=.4ba038a7-4a62-4de1-b181-cc66f079ad99@github.com>
Message-ID: <ba758c43-1e4a-644e-93f6-1ff022b7325b@tarent.de>

On Fri, 29 Jul 2022, David Holmes wrote:

>   Patch: https://git.openjdk.org/jdk8u-dev/pull/92.diff

From a distro maintainer PoV I do have a complaint about this.

Currently, JVM_Exit is an exported symbol of the shlib:

$ nm -D /usr/lib/jvm/java-1.8.0-openjdk-i386/jre/lib/i386/server/libjvm.so | fgrep Exit 
005cc5c0 T JVM_Exit
[?]

This patch will remove that, IIUC. This is an ABI break.

ABI breaks need the shlib major version to increase.
This shlib is unversioned, so this cannot be done.

Therefore this cannot be done in OpenJDK 8 at all, or in any
released version really.

To make this possible, add a dummy JVM_Exit() call, instead of
removing it altogether. Perhaps like this?

JVM_ENTRY_NO_ENV(void, JVM_Exit(jint code))
  before_exit(thread);
  vm_exit(code);
JVM_END

I understand this is the same as JVM_Halt(), but this duplication
is necessary, mandatory even to avoid breaking existing applications.

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 andrew at openjdk.org  Fri Jul 29 01:08:48 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 29 Jul 2022 01:08:48 GMT
Subject: [jdk8u-dev] RFR: 8290832: It is no longer possible to change
 "user.dir" in the JDK8
In-Reply-To: <6ZG9sXrypY1tpixmaWoCLKrLELmrH4CBYjL_CuDkrbE=.144e924e-91d2-4222-a731-dfd2c7cf7684@github.com>
References: <W0pjhP4ROmBMfS1AospdJ17URyi52s6Fdu8Z3VOWYxI=.10d8357b-4ad0-43b2-89a9-8d97491fd6c2@github.com>
 <6ZG9sXrypY1tpixmaWoCLKrLELmrH4CBYjL_CuDkrbE=.144e924e-91d2-4222-a731-dfd2c7cf7684@github.com>
Message-ID: <hBque7D-of6S_ycuoCncGJ_ukpeudH8Cg7zhgQnKtdY=.c7adc015-ed8c-4988-8281-b0746eed0e18@github.com>

On Fri, 22 Jul 2022 17:45:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This is the request to revert the fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) integrated to the [openjdk8u342](https://github.com/openjdk/jdk8u/commit/5fcfb7acbe340c8347bd47413a36dd0b1e267dc1)
>> 
>> The fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) disabled the possibility to change the "user.dir" property.
>> Changing the "user.dir" was not recommended from the beginning but it was not forbidden, so there are some old applications that rely on the old behavior. 
>> 
>> For compatibility reasons, it would be good to restore the old behavior.
>> 
>> Note that the test is simplified and saved under a different name, now it will check just the possibility to change the 'user.dir' using a simple path and name.
>
> The patch is updated as requested, the test will be pushed separately.

Thanks for catching this @mrserb and the patch itself looks like a clean backout to me.

However, I suggest we do this on https://github.com/openjdk/jdk8u for an interim 8u345 release.  I've just requested that version from ops and will update the jcheck rules on 8u when that is created.

Presumably we'll do the test under a different bug?

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

PR: https://git.openjdk.org/jdk8u-dev/pull/88

From gnu.andrew at redhat.com  Fri Jul 29 01:09:23 2022
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 29 Jul 2022 02:09:23 +0100
Subject: The implication of the JDK-8194154 fix in jdk8u342.
In-Reply-To: <df6be709-37e5-6059-eec9-03dd6af61b57@amazon.com>
References: <df6be709-37e5-6059-eec9-03dd6af61b57@amazon.com>
Message-ID: <YuMzQ0TmmHUpT/IU@hex.discworld.ac.uk>

On 13:27 Wed 20 Jul     , Sergey Bylokhov wrote:
> Hello, the last release of jdk8u includes the fix for JDK-8194154[1] which disabled the possibility 
> to change the "user.dir" property.
> 
> Changing the "user.dir" was not recommended from the beginning but it was not forbidden, so there 
> are some old applications that rely on the old behavior. One of the app which sets the "user.dir" is 
> Gradle. The Gradle has a notice in the documentation for the user:
> "Never use new File(relative path) because this creates a path relative to the current working 
> directory (CWD). Gradle can make no guarantees about the location of the CWD, which means builds 
> that rely on it may break at any time".
> 
> But for compatibility reasons they still set the "user.dir" property, so the old plugins will work. 
> Now that compatibility is broken due to the fix I mention. We found such apps immediately after the 
> release.
> 
> I would like to ask what was the reason for the backport, is it critical enough to change a 
> behavior? I did not find any broad discussion about that backport nor the reason why it was pushed 
> but I would like to bring a compatibility concerns about that change. I think we should roll it back 
> as soon as possible.
> 
> Please share your opinions?
> 
> [1] https://bugs.openjdk.org/browse/JDK-8194154
> 
> -- 
> Best regards, Sergey.
> 

This is the first I've heard of this patch and I'm not sure why this
was ever backported to 8u. I don't see any reasoning on the original
PR or approval request and I didn't approve this one myself. I don't
believe I would have on the basis of what I'm seeing now.

Thanks for raising the issue.  From the discussion on here, it seems
reverting this is unanimous and the original submitter agrees it was a
mistake.  I have hence asked for openjdk8u345 to be created in JBS and
we'll proceed with an interim release to revert this as soon as
possible.

How was the Gradle issue found? Only after release? It appears this
patch was integrated in March, so I'm concerned that we didn't catch
something like this earlier e.g. in rampdown.

Best regards,
-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/jdk8u-dev/attachments/20220729/97bbc523/signature.asc>

From dholmes at openjdk.org  Fri Jul 29 01:15:51 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 29 Jul 2022 01:15:51 GMT
Subject: [jdk8u] RFR: 8287132: Retire Runtime.runFinalizersOnExit so that
 it always throws UOE
In-Reply-To: <1qsfSrYGZqYw3qDHwDPRT8v0aAsbM8VWXMREyMTxaQ4=.7ab82dd7-a972-4ffb-8a4c-109a49e4eff1@github.com>
References: <1qsfSrYGZqYw3qDHwDPRT8v0aAsbM8VWXMREyMTxaQ4=.7ab82dd7-a972-4ffb-8a4c-109a49e4eff1@github.com>
Message-ID: <YCWRkB4Y-0l9VqfZZFpNaZbDWExaWcEPbEcunK3EAfM=.962459b3-4d09-4a4c-9595-ae9010bf9662@github.com>

On Wed, 27 Jul 2022 02:32:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Forward port of the changes for SE 8 Maintenance release 4, as applied to jdk8u-ri, for:
> 
> [JDK-8287132](https://bugs.openjdk.org/browse/JDK-8287132): Retire Runtime.runFinalizersOnExit so that it always throws UOE
> 
> The changes applied "unclean" only with regard to trivial things like copyright year updates.
> 
> Thanks.

Resubmitted as https://github.com/openjdk/jdk8u-dev/pull/92

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

PR: https://git.openjdk.org/jdk8u/pull/13

From ecki at zusammenkunft.net  Fri Jul 29 01:22:50 2022
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Fri, 29 Jul 2022 01:22:50 +0000
Subject: [jdk8u-dev] RFR: 8287132: Retire Runtime.runFinalizersOnExit so
 that it always throws UOE
In-Reply-To: <ba758c43-1e4a-644e-93f6-1ff022b7325b@tarent.de>
References: <yC_fFLRfaFdzgXH3L6dzsTNxW4sMGN1bMh4jRIUEYGE=.4ba038a7-4a62-4de1-b181-cc66f079ad99@github.com>
 <ba758c43-1e4a-644e-93f6-1ff022b7325b@tarent.de>
Message-ID: <AM9P193MB1142E1FAA5ABCD19507E3978FF999@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>

Agreed, In addition to that, I also think (as already mentioned, sorry
,) the runFinalizerOnExit() should be a NOP or allow a system property to turn it into a nop.

The risk of code (yeah I know you did not find any) calling that setter (and not liking the exception for example in startup thread) is real, there is no reason to add more incompatibility risk to 8u. Just remove it for new releases.

Making this a Nop is perfectly within its original spec. (And less code than the throw)

(Mood: I just spent two days in Code I never wanted to touch again for fixing the issues from a 11u backport, before I could ship the eagerly july security update. It would be worse with the 8 generation systems. I hope this is not a theme for the MR?)

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: jdk8u-dev <jdk8u-dev-retn at openjdk.org> im Auftrag von Thorsten Glaser <t.glaser at tarent.de>
Gesendet: Friday, July 29, 2022 2:44:19 AM
An: David Holmes <dholmes at openjdk.org>
Cc: jdk8u-dev at openjdk.org <jdk8u-dev at openjdk.org>
Betreff: Re: [jdk8u-dev] RFR: 8287132: Retire Runtime.runFinalizersOnExit so that it always throws UOE

On Fri, 29 Jul 2022, David Holmes wrote:

>   Patch: https://git.openjdk.org/jdk8u-dev/pull/92.diff

From a distro maintainer PoV I do have a complaint about this.

Currently, JVM_Exit is an exported symbol of the shlib:

$ nm -D /usr/lib/jvm/java-1.8.0-openjdk-i386/jre/lib/i386/server/libjvm.so | fgrep Exit
005cc5c0 T JVM_Exit
[?]

This patch will remove that, IIUC. This is an ABI break.

ABI breaks need the shlib major version to increase.
This shlib is unversioned, so this cannot be done.

Therefore this cannot be done in OpenJDK 8 at all, or in any
released version really.

To make this possible, add a dummy JVM_Exit() call, instead of
removing it altogether. Perhaps like this?

JVM_ENTRY_NO_ENV(void, JVM_Exit(jint code))
  before_exit(thread);
  vm_exit(code);
JVM_END

I understand this is the same as JVM_Halt(), but this duplication
is necessary, mandatory even to avoid breaking existing applications.

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!
                        ****************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk8u-dev/attachments/20220729/af46c961/attachment.htm>

From t.glaser at tarent.de  Fri Jul 29 01:40:51 2022
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Fri, 29 Jul 2022 03:40:51 +0200 (CEST)
Subject: [jdk8u-dev] RFR: 8287132: Retire Runtime.runFinalizersOnExit so
 that it always throws UOE
In-Reply-To: <AM9P193MB1142E1FAA5ABCD19507E3978FF999@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
References: <yC_fFLRfaFdzgXH3L6dzsTNxW4sMGN1bMh4jRIUEYGE=.4ba038a7-4a62-4de1-b181-cc66f079ad99@github.com>
 <ba758c43-1e4a-644e-93f6-1ff022b7325b@tarent.de>
 <AM9P193MB1142E1FAA5ABCD19507E3978FF999@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
Message-ID: <0142754-c355-34b5-a05e-b3a1c57f3c9@tarent.de>

On Fri, 29 Jul 2022, Bernd Eckenfels wrote:

> The risk of code (yeah I know you did not find any) calling that
> setter (and not liking the exception for example in startup thread) is
> real, there is no reason to add more incompatibility risk to 8u. Just
> remove it for new releases.

Good point! Same applies for Debian old*stable, where 8u enters as a
security update and therefore is supposed to not break things.

> Making this a Nop is perfectly within its original spec. (And less
> code than the throw)

All the better ;)

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 serb at openjdk.org  Fri Jul 29 01:51:43 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 29 Jul 2022 01:51:43 GMT
Subject: [jdk8u-dev] RFR: 8290832: It is no longer possible to change
 "user.dir" in the JDK8
In-Reply-To: <hBque7D-of6S_ycuoCncGJ_ukpeudH8Cg7zhgQnKtdY=.c7adc015-ed8c-4988-8281-b0746eed0e18@github.com>
References: <W0pjhP4ROmBMfS1AospdJ17URyi52s6Fdu8Z3VOWYxI=.10d8357b-4ad0-43b2-89a9-8d97491fd6c2@github.com>
 <6ZG9sXrypY1tpixmaWoCLKrLELmrH4CBYjL_CuDkrbE=.144e924e-91d2-4222-a731-dfd2c7cf7684@github.com>
 <hBque7D-of6S_ycuoCncGJ_ukpeudH8Cg7zhgQnKtdY=.c7adc015-ed8c-4988-8281-b0746eed0e18@github.com>
Message-ID: <1LsuVmHcBXtVCrDeuudtFel4j0VXiqdUEMjR3l0aka0=.66ef85e2-95ce-4a7a-ad95-a060112960c3@github.com>

On Fri, 29 Jul 2022 01:04:53 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> However, I suggest we do this on https://github.com/openjdk/jdk8u for an interim 8u345 release. I've just requested that version from ops and will update the jcheck rules on 8u when that is created.

Ok, I'll prepare the patch for that repo.

> Presumably we'll do the test under a different bug?

Yes, I'll add the test in a separate CR, so this patch will be as simple as "git revert"..

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

PR: https://git.openjdk.org/jdk8u-dev/pull/88

From serb at openjdk.org  Fri Jul 29 04:15:16 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 29 Jul 2022 04:15:16 GMT
Subject: [jdk8u] RFR: 8290832: It is no longer possible to change "user.dir" in
 the JDK8
Message-ID: <XsKY7sABdFo_VWW5NgOE7-wFNI_gyDjy5LuC6pq3wLw=.fd227a6d-271d-485e-8a7c-6b75cf807c3e@github.com>

This is the request to revert the fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) integrated to the [openjdk8u342](https://github.com/openjdk/jdk8u/commit/5fcfb7acbe340c8347bd47413a36dd0b1e267dc1)

The fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) disabled the possibility to change the "user.dir" property.
Changing the "user.dir" was not recommended from the beginning but it was not forbidden, so there are some old applications that rely on the old behavior. 

For compatibility reasons, it would be good to restore the old behavior.

This PR reverts this commit: https://github.com/openjdk/jdk8u/commit/5fcfb7acbe340c8347bd47413a36dd0b1e267dc1

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

Commit messages:
 - Revert "8194154: System property user.dir should not be changed"

Changes: https://git.openjdk.org/jdk8u/pull/14/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u&pr=14&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290832
  Stats: 67 lines in 3 files changed: 0 ins; 65 del; 2 mod
  Patch: https://git.openjdk.org/jdk8u/pull/14.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u pull/14/head:pull/14

PR: https://git.openjdk.org/jdk8u/pull/14

From david.holmes at oracle.com  Fri Jul 29 12:25:04 2022
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 29 Jul 2022 22:25:04 +1000
Subject: [jdk8u-dev] RFR: 8287132: Retire Runtime.runFinalizersOnExit so
 that it always throws UOE
In-Reply-To: <ba758c43-1e4a-644e-93f6-1ff022b7325b@tarent.de>
References: <yC_fFLRfaFdzgXH3L6dzsTNxW4sMGN1bMh4jRIUEYGE=.4ba038a7-4a62-4de1-b181-cc66f079ad99@github.com>
 <ba758c43-1e4a-644e-93f6-1ff022b7325b@tarent.de>
Message-ID: <869180c3-72e3-2541-7a60-4ec104f13780@oracle.com>

Hi Thorsten,

On 29/07/2022 10:44 am, Thorsten Glaser wrote:
> On Fri, 29 Jul 2022, David Holmes wrote:
> 
>>    Patch: https://git.openjdk.org/jdk8u-dev/pull/92.diff
> 
>  From a distro maintainer PoV I do have a complaint about this.
> 
> Currently, JVM_Exit is an exported symbol of the shlib:
> 
> $ nm -D /usr/lib/jvm/java-1.8.0-openjdk-i386/jre/lib/i386/server/libjvm.so | fgrep Exit
> 005cc5c0 T JVM_Exit
> [?]
> 
> This patch will remove that, IIUC. This is an ABI break.
> 
> ABI breaks need the shlib major version to increase.
> This shlib is unversioned, so this cannot be done.
> 
> Therefore this cannot be done in OpenJDK 8 at all, or in any
> released version really.

JVM_Exit is never called by any Java code so this is dead code that has 
been removed. The JVM_* API is not supported for any use other than the 
JDK library so no external uses of this symbol should exist.

David
-----


> To make this possible, add a dummy JVM_Exit() call, instead of
> removing it altogether. Perhaps like this?
> 
> JVM_ENTRY_NO_ENV(void, JVM_Exit(jint code))
>    before_exit(thread);
>    vm_exit(code);
> JVM_END
> 
> I understand this is the same as JVM_Halt(), but this duplication
> is necessary, mandatory even to avoid breaking existing applications.
> 
> bye,
> //mirabilos

From david.holmes at oracle.com  Fri Jul 29 12:27:15 2022
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 29 Jul 2022 22:27:15 +1000
Subject: [jdk8u-dev] RFR: 8287132: Retire Runtime.runFinalizersOnExit so
 that it always throws UOE
In-Reply-To: <AM9P193MB1142E1FAA5ABCD19507E3978FF999@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
References: <yC_fFLRfaFdzgXH3L6dzsTNxW4sMGN1bMh4jRIUEYGE=.4ba038a7-4a62-4de1-b181-cc66f079ad99@github.com>
 <ba758c43-1e4a-644e-93f6-1ff022b7325b@tarent.de>
 <AM9P193MB1142E1FAA5ABCD19507E3978FF999@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
Message-ID: <15608de8-3463-f829-523d-3369a98e0070@oracle.com>

On 29/07/2022 11:22 am, Bernd Eckenfels wrote:
> Agreed, In addition to that, I also think (as already mentioned, sorry
> ,) the runFinalizerOnExit() should be a NOP or allow a system property 
> to turn it into a nop.

This change has already been proposed and accepted by the JCP as part of 
SE 8 Maintenance Release 4:

https://jcp.org/en/jsr/detail?id=337

Regards,
David
-----

> The risk of code (yeah I know you did not find any) calling that setter 
> (and not liking the exception for example in startup thread) is real, 
> there is no reason to add more incompatibility risk to 8u. Just remove 
> it for new releases.
> 
> Making this a Nop is perfectly within its original spec. (And less code 
> than the throw)
> 
> (Mood: I just spent two days in Code I never wanted to touch again for 
> fixing the issues from a 11u backport, before I could ship the eagerly 
> july security update. It would be worse with the 8 generation systems. I 
> hope this is not a theme for the MR?)
> 
> Gruss
> Bernd
> -- 
> http://bernd.eckenfels.net
> ------------------------------------------------------------------------
> *Von:* jdk8u-dev <jdk8u-dev-retn at openjdk.org> im Auftrag von Thorsten 
> Glaser <t.glaser at tarent.de>
> *Gesendet:* Friday, July 29, 2022 2:44:19 AM
> *An:* David Holmes <dholmes at openjdk.org>
> *Cc:* jdk8u-dev at openjdk.org <jdk8u-dev at openjdk.org>
> *Betreff:* Re: [jdk8u-dev] RFR: 8287132: Retire 
> Runtime.runFinalizersOnExit so that it always throws UOE
> On Fri, 29 Jul 2022, David Holmes wrote:
> 
>>?? Patch: https://git.openjdk.org/jdk8u-dev/pull/92.diff 
> <https://git.openjdk.org/jdk8u-dev/pull/92.diff>
> 
>  From a distro maintainer PoV I do have a complaint about this.
> 
> Currently, JVM_Exit is an exported symbol of the shlib:
> 
> $ nm -D 
> /usr/lib/jvm/java-1.8.0-openjdk-i386/jre/lib/i386/server/libjvm.so | 
> fgrep Exit
> 005cc5c0 T JVM_Exit
> [?]
> 
> This patch will remove that, IIUC. This is an ABI break.
> 
> ABI breaks need the shlib major version to increase.
> This shlib is unversioned, so this cannot be done.
> 
> Therefore this cannot be done in OpenJDK 8 at all, or in any
> released version really.
> 
> To make this possible, add a dummy JVM_Exit() call, instead of
> removing it altogether. Perhaps like this?
> 
> JVM_ENTRY_NO_ENV(void, JVM_Exit(jint code))
>  ? before_exit(thread);
>  ? vm_exit(code);
> JVM_END
> 
> I understand this is the same as JVM_Halt(), but this duplication
> is necessary, mandatory even to avoid breaking existing applications.
> 
> bye,
> //mirabilos
> -- 
> Infrastrukturexperte ? tarent solutions GmbH
> Am Dickobskreuz 10, D-53121 Bonn ? http://www.tarent.de/ 
> <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 
> <https://www.tarent.de/newsletter>
> ??? header encryption!
>                          
> ****************************************************

From phh at openjdk.org  Fri Jul 29 14:38:11 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 29 Jul 2022 14:38:11 GMT
Subject: [jdk8u] RFR: 8290832: It is no longer possible to change
 "user.dir" in the JDK8
In-Reply-To: <XsKY7sABdFo_VWW5NgOE7-wFNI_gyDjy5LuC6pq3wLw=.fd227a6d-271d-485e-8a7c-6b75cf807c3e@github.com>
References: <XsKY7sABdFo_VWW5NgOE7-wFNI_gyDjy5LuC6pq3wLw=.fd227a6d-271d-485e-8a7c-6b75cf807c3e@github.com>
Message-ID: <hPgH3sjhPVvrghATBPyOBuWy2_mtM9U1AMBkqG3NOyg=.d7f69afc-5e72-4791-93b0-e4443d27e54e@github.com>

On Fri, 29 Jul 2022 03:46:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the request to revert the fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) integrated to the [openjdk8u342](https://github.com/openjdk/jdk8u/commit/5fcfb7acbe340c8347bd47413a36dd0b1e267dc1)
> 
> The fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) disabled the possibility to change the "user.dir" property.
> Changing the "user.dir" was not recommended from the beginning but it was not forbidden, so there are some old applications that rely on the old behavior. 
> 
> For compatibility reasons, it would be good to restore the old behavior.
> 
> This PR reverts this commit: https://github.com/openjdk/jdk8u/commit/5fcfb7acbe340c8347bd47413a36dd0b1e267dc1

Copyright dates need to be reverted in UnixFileSystem.java and WinNTFileSystem.java. Other than that, lgtm.

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

Changes requested by phh (Reviewer).

PR: https://git.openjdk.org/jdk8u/pull/14

From hseigel at openjdk.org  Fri Jul 29 15:17:00 2022
From: hseigel at openjdk.org (Harold Seigel)
Date: Fri, 29 Jul 2022 15:17:00 GMT
Subject: [jdk8u-dev] RFR: 8287132: Retire Runtime.runFinalizersOnExit so
 that it always throws UOE
In-Reply-To: <yC_fFLRfaFdzgXH3L6dzsTNxW4sMGN1bMh4jRIUEYGE=.4ba038a7-4a62-4de1-b181-cc66f079ad99@github.com>
References: <yC_fFLRfaFdzgXH3L6dzsTNxW4sMGN1bMh4jRIUEYGE=.4ba038a7-4a62-4de1-b181-cc66f079ad99@github.com>
Message-ID: <Uoeg69AXD_ef8RFqhP8BQh9seOgx9ZJsJKD_MLpByqc=.7bd06f33-e357-4b21-aeab-e23c2a0d39df@github.com>

On Fri, 29 Jul 2022 00:18:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Forward port of the changes for SE 8 Maintenance release 4, as applied to jdk8u-ri, for:
> 
> [JDK-8287132](https://bugs.openjdk.org/browse/JDK-8287132): Retire Runtime.runFinalizersOnExit so that it always throws UOE
> 
> The changes applied "unclean" only with regard to trivial things like copyright year updates.
> 
> Thanks.

The changes look good.  Thanks for doing this.
Harold

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

Marked as reviewed by hseigel (Committer).

PR: https://git.openjdk.org/jdk8u-dev/pull/92

From iris at openjdk.org  Fri Jul 29 16:03:54 2022
From: iris at openjdk.org (Iris Clark)
Date: Fri, 29 Jul 2022 16:03:54 GMT
Subject: [jdk8u-dev] RFR: 8287132: Retire Runtime.runFinalizersOnExit so
 that it always throws UOE
In-Reply-To: <yC_fFLRfaFdzgXH3L6dzsTNxW4sMGN1bMh4jRIUEYGE=.4ba038a7-4a62-4de1-b181-cc66f079ad99@github.com>
References: <yC_fFLRfaFdzgXH3L6dzsTNxW4sMGN1bMh4jRIUEYGE=.4ba038a7-4a62-4de1-b181-cc66f079ad99@github.com>
Message-ID: <nHXeqRqIxrVZgyZTFw98cEEukMx7Xzqej5xccBNpFrg=.ee1138b0-392b-43f4-b380-337c1b02a1ad@github.com>

On Fri, 29 Jul 2022 00:18:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Forward port of the changes for SE 8 Maintenance release 4, as applied to jdk8u-ri, for:
> 
> [JDK-8287132](https://bugs.openjdk.org/browse/JDK-8287132): Retire Runtime.runFinalizersOnExit so that it always throws UOE
> 
> The changes applied "unclean" only with regard to trivial things like copyright year updates.
> 
> Thanks.

Spec changes as expected in JSR 337 MR 4.

Thanks!

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

Marked as reviewed by iris (Author).

PR: https://git.openjdk.org/jdk8u-dev/pull/92

From t.glaser at tarent.de  Fri Jul 29 19:07:04 2022
From: t.glaser at tarent.de (Thorsten Glaser)
Date: Fri, 29 Jul 2022 21:07:04 +0200 (CEST)
Subject: [jdk8u-dev] RFR: 8287132: Retire Runtime.runFinalizersOnExit so
 that it always throws UOE
In-Reply-To: <15608de8-3463-f829-523d-3369a98e0070@oracle.com>
References: <yC_fFLRfaFdzgXH3L6dzsTNxW4sMGN1bMh4jRIUEYGE=.4ba038a7-4a62-4de1-b181-cc66f079ad99@github.com>
 <ba758c43-1e4a-644e-93f6-1ff022b7325b@tarent.de>
 <AM9P193MB1142E1FAA5ABCD19507E3978FF999@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
 <15608de8-3463-f829-523d-3369a98e0070@oracle.com>
Message-ID: <a1d8e2fe-91d3-5ee2-d04b-328433ef49c9@tarent.de>

On Fri, 29 Jul 2022, David Holmes wrote:

> On 29/07/2022 11:22 am, Bernd Eckenfels wrote:
> > Agreed, In addition to that, I also think (as already mentioned, sorry
> > ,) the runFinalizerOnExit() should be a NOP or allow a system property to
> > turn it into a nop.
> 
> This change has already been proposed and accepted by the JCP as part of SE 8
> Maintenance Release 4:

And that?s fine for the reference implementation.

However, *this*, here, is about the real-world real-existing OpenJDK
which real applications use, and which is in security/bugfixes only
mode and therefore needs to not break existing applications. It?s not
only perfectly fine but even, to some point, expected that different
decisions are taken, for compatibility reasons mostly.

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 andrew at openjdk.org  Fri Jul 29 20:38:39 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 29 Jul 2022 20:38:39 GMT
Subject: [jdk8u] RFR: 8290832: It is no longer possible to change
 "user.dir" in the JDK8
In-Reply-To: <XsKY7sABdFo_VWW5NgOE7-wFNI_gyDjy5LuC6pq3wLw=.fd227a6d-271d-485e-8a7c-6b75cf807c3e@github.com>
References: <XsKY7sABdFo_VWW5NgOE7-wFNI_gyDjy5LuC6pq3wLw=.fd227a6d-271d-485e-8a7c-6b75cf807c3e@github.com>
Message-ID: <Ok8AdswErhqbiO8w7670NREub10132dZy4QQg0Q1NV0=.1e3bf1a6-a23a-4e98-aa5f-f4f7db3c22a9@github.com>

On Fri, 29 Jul 2022 03:46:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the request to revert the fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) integrated to the [openjdk8u342](https://github.com/openjdk/jdk8u/commit/5fcfb7acbe340c8347bd47413a36dd0b1e267dc1)
> 
> The fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) disabled the possibility to change the "user.dir" property.
> Changing the "user.dir" was not recommended from the beginning but it was not forbidden, so there are some old applications that rely on the old behavior. 
> 
> For compatibility reasons, it would be good to restore the old behavior.
> 
> This PR reverts this commit: https://github.com/openjdk/jdk8u/commit/5fcfb7acbe340c8347bd47413a36dd0b1e267dc1

@mrserb can you turn on Actions for this repo? I know we already tested this on 8u-dev but it would be good to get those enabled for any future critical fixes that need to go direct to 8u.

If one of you could review #15 that will need to go in before this so it resolves against the right release.

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

PR: https://git.openjdk.org/jdk8u/pull/14

From andrew at openjdk.org  Fri Jul 29 20:38:38 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 29 Jul 2022 20:38:38 GMT
Subject: [jdk8u] RFR: 8290832: It is no longer possible to change
 "user.dir" in the JDK8
In-Reply-To: <hPgH3sjhPVvrghATBPyOBuWy2_mtM9U1AMBkqG3NOyg=.d7f69afc-5e72-4791-93b0-e4443d27e54e@github.com>
References: <XsKY7sABdFo_VWW5NgOE7-wFNI_gyDjy5LuC6pq3wLw=.fd227a6d-271d-485e-8a7c-6b75cf807c3e@github.com>
 <hPgH3sjhPVvrghATBPyOBuWy2_mtM9U1AMBkqG3NOyg=.d7f69afc-5e72-4791-93b0-e4443d27e54e@github.com>
Message-ID: <uS1F7iBOiaOiJpMxruWMrPSmYPiF_BsJG06sCMUxQPs=.2705827a-5ef3-4dd8-977e-f95d7362e738@github.com>

On Fri, 29 Jul 2022 14:35:58 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> Copyright dates need to be reverted in UnixFileSystem.java and WinNTFileSystem.java. Other than that, lgtm.

Yes, I did wonder why those were omitted myself. It should just be a simple `git revert <id>`, no?

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

PR: https://git.openjdk.org/jdk8u/pull/14

From andrew at openjdk.org  Fri Jul 29 20:41:31 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 29 Jul 2022 20:41:31 GMT
Subject: [jdk8u] RFR: 8291568: Bump update version of OpenJDK: 8u345
Message-ID: <_KGtZFYxfnYheCuVlJfrToTlF8e1LPhfawOmVTq1D8U=.38ea1a5b-55eb-4cd6-9b2e-b766d501936b@github.com>

Needed bump for the interim release to revert [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) ; see #14

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

Commit messages:
 - 8291568: Bump update version of OpenJDK: 8u345

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

PR: https://git.openjdk.org/jdk8u/pull/15

From duke at openjdk.org  Fri Jul 29 21:18:59 2022
From: duke at openjdk.org (duke)
Date: Fri, 29 Jul 2022 21:18:59 GMT
Subject: [jdk8u-dev] Withdrawn: 8287537: 8u JDK-8284620 backport broke AArch64
 build
In-Reply-To: <DwsCoHwGLh8SYMBHNxOXI0EQCJDo7Q41eGwCmHJvrN8=.0dcf23f0-f24f-48d5-8cf5-e1c403cb743d@github.com>
References: <DwsCoHwGLh8SYMBHNxOXI0EQCJDo7Q41eGwCmHJvrN8=.0dcf23f0-f24f-48d5-8cf5-e1c403cb743d@github.com>
Message-ID: <tpo6WpdsQXXWVL1bf_ECHFlriu0rB0QHD7Rwkbz-Hbw=.ded72e25-2c90-43ee-ad4d-0dd15e89fdb6@github.com>

On Tue, 31 May 2022 13:53:37 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> The original backport is bad, sorry.
> 
> Test:
> 
> - [x] built on Linux x86_64
> - [x] build on AArch64 (Raspberry Pi) w/o patch.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/69

From serb at openjdk.org  Fri Jul 29 22:33:13 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 29 Jul 2022 22:33:13 GMT
Subject: [jdk8u] RFR: 8291568: Bump update version of OpenJDK: 8u345
In-Reply-To: <_KGtZFYxfnYheCuVlJfrToTlF8e1LPhfawOmVTq1D8U=.38ea1a5b-55eb-4cd6-9b2e-b766d501936b@github.com>
References: <_KGtZFYxfnYheCuVlJfrToTlF8e1LPhfawOmVTq1D8U=.38ea1a5b-55eb-4cd6-9b2e-b766d501936b@github.com>
Message-ID: <QZ0z-Kc6y04r144UvCVao6LLxTVCL2qw2atFK8heAao=.910e28f9-ee0d-4639-9208-0e5df27e497a@github.com>

On Fri, 29 Jul 2022 20:33:47 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Needed bump for the interim release to revert [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) ; see #14

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.org/jdk8u/pull/15

From phh at openjdk.org  Fri Jul 29 22:33:13 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 29 Jul 2022 22:33:13 GMT
Subject: [jdk8u] RFR: 8291568: Bump update version of OpenJDK: 8u345
In-Reply-To: <_KGtZFYxfnYheCuVlJfrToTlF8e1LPhfawOmVTq1D8U=.38ea1a5b-55eb-4cd6-9b2e-b766d501936b@github.com>
References: <_KGtZFYxfnYheCuVlJfrToTlF8e1LPhfawOmVTq1D8U=.38ea1a5b-55eb-4cd6-9b2e-b766d501936b@github.com>
Message-ID: <7z8F-i2OGTGs7gRcgmjtEQdIWggbhQ7JhLl-JWmH8PM=.857dd25a-447a-42ea-995b-652b1af79302@github.com>

On Fri, 29 Jul 2022 20:33:47 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Needed bump for the interim release to revert [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) ; see #14

Lgtm.

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

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.org/jdk8u/pull/15

From phh at openjdk.org  Fri Jul 29 22:36:56 2022
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 29 Jul 2022 22:36:56 GMT
Subject: [jdk8u] RFR: 8290832: It is no longer possible to change
 "user.dir" in the JDK8
In-Reply-To: <XsKY7sABdFo_VWW5NgOE7-wFNI_gyDjy5LuC6pq3wLw=.fd227a6d-271d-485e-8a7c-6b75cf807c3e@github.com>
References: <XsKY7sABdFo_VWW5NgOE7-wFNI_gyDjy5LuC6pq3wLw=.fd227a6d-271d-485e-8a7c-6b75cf807c3e@github.com>
Message-ID: <DubB9_aFvSZATBLJzLvdO7rbsdo38WVc9D46L20XQ38=.800d3ce0-c4b3-4208-857f-308e8cf48ed9@github.com>

On Fri, 29 Jul 2022 03:46:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the request to revert the fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) integrated to the [openjdk8u342](https://github.com/openjdk/jdk8u/commit/5fcfb7acbe340c8347bd47413a36dd0b1e267dc1)
> 
> The fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) disabled the possibility to change the "user.dir" property.
> Changing the "user.dir" was not recommended from the beginning but it was not forbidden, so there are some old applications that rely on the old behavior. 
> 
> For compatibility reasons, it would be good to restore the old behavior.
> 
> This PR reverts this commit: https://github.com/openjdk/jdk8u/commit/5fcfb7acbe340c8347bd47413a36dd0b1e267dc1

In that case, lgtm.

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

Marked as reviewed by phh (Reviewer).

PR: https://git.openjdk.org/jdk8u/pull/14

From serb at openjdk.org  Fri Jul 29 22:36:57 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 29 Jul 2022 22:36:57 GMT
Subject: [jdk8u] RFR: 8290832: It is no longer possible to change
 "user.dir" in the JDK8
In-Reply-To: <uS1F7iBOiaOiJpMxruWMrPSmYPiF_BsJG06sCMUxQPs=.2705827a-5ef3-4dd8-977e-f95d7362e738@github.com>
References: <XsKY7sABdFo_VWW5NgOE7-wFNI_gyDjy5LuC6pq3wLw=.fd227a6d-271d-485e-8a7c-6b75cf807c3e@github.com>
 <hPgH3sjhPVvrghATBPyOBuWy2_mtM9U1AMBkqG3NOyg=.d7f69afc-5e72-4791-93b0-e4443d27e54e@github.com>
 <uS1F7iBOiaOiJpMxruWMrPSmYPiF_BsJG06sCMUxQPs=.2705827a-5ef3-4dd8-977e-f95d7362e738@github.com>
Message-ID: <IyOVrJ9AXL4xHg070_y0YO5gBMr7E5THmZGdwqb6j9Y=.a73e3281-e8f9-44ba-bb26-91100d5c3170@github.com>

On Fri, 29 Jul 2022 20:34:34 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> > Copyright dates need to be reverted in UnixFileSystem.java and WinNTFileSystem.java. Other than that, lgtm.
> 
> Yes, I did wonder why those were omitted myself. It should just be a simple `git revert <id>`, no?

That dates were changed later, the fix in question changed them to 2018, but now they are 2022 due to other fixes.

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

PR: https://git.openjdk.org/jdk8u/pull/14

From serb at openjdk.org  Fri Jul 29 22:36:58 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 29 Jul 2022 22:36:58 GMT
Subject: [jdk8u] RFR: 8290832: It is no longer possible to change
 "user.dir" in the JDK8
In-Reply-To: <IyOVrJ9AXL4xHg070_y0YO5gBMr7E5THmZGdwqb6j9Y=.a73e3281-e8f9-44ba-bb26-91100d5c3170@github.com>
References: <XsKY7sABdFo_VWW5NgOE7-wFNI_gyDjy5LuC6pq3wLw=.fd227a6d-271d-485e-8a7c-6b75cf807c3e@github.com>
 <hPgH3sjhPVvrghATBPyOBuWy2_mtM9U1AMBkqG3NOyg=.d7f69afc-5e72-4791-93b0-e4443d27e54e@github.com>
 <uS1F7iBOiaOiJpMxruWMrPSmYPiF_BsJG06sCMUxQPs=.2705827a-5ef3-4dd8-977e-f95d7362e738@github.com>
 <IyOVrJ9AXL4xHg070_y0YO5gBMr7E5THmZGdwqb6j9Y=.a73e3281-e8f9-44ba-bb26-91100d5c3170@github.com>
Message-ID: <Dc8GxjMKSdD2n37nDzC8MgrAQHb51XSlnwr9w6YLsFU=.c915b21f-eb65-4582-93e1-f8fa2f2ce78b@github.com>

On Fri, 29 Jul 2022 22:30:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> Copyright dates need to be reverted in UnixFileSystem.java and WinNTFileSystem.java. Other than that, lgtm.
>> 
>> Yes, I did wonder why those were omitted myself. It should just be a simple `git revert <id>`, no?
>
>> > Copyright dates need to be reverted in UnixFileSystem.java and WinNTFileSystem.java. Other than that, lgtm.
>> 
>> Yes, I did wonder why those were omitted myself. It should just be a simple `git revert <id>`, no?
> 
> That dates were changed later, the fix in question changed them to 2018, but now they are 2022 due to other fixes.

> @mrserb can you turn on Actions for this repo? I know we already tested this on 8u-dev but it would be good to get those enabled for any future critical fixes that need to go direct to 8u.

I think Github disabled those actions since the changes in this repo rarely happen.

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

PR: https://git.openjdk.org/jdk8u/pull/14

From david.holmes at oracle.com  Fri Jul 29 23:06:23 2022
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 30 Jul 2022 09:06:23 +1000
Subject: [jdk8u-dev] RFR: 8287132: Retire Runtime.runFinalizersOnExit so
 that it always throws UOE
In-Reply-To: <a1d8e2fe-91d3-5ee2-d04b-328433ef49c9@tarent.de>
References: <yC_fFLRfaFdzgXH3L6dzsTNxW4sMGN1bMh4jRIUEYGE=.4ba038a7-4a62-4de1-b181-cc66f079ad99@github.com>
 <ba758c43-1e4a-644e-93f6-1ff022b7325b@tarent.de>
 <AM9P193MB1142E1FAA5ABCD19507E3978FF999@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>
 <15608de8-3463-f829-523d-3369a98e0070@oracle.com>
 <a1d8e2fe-91d3-5ee2-d04b-328433ef49c9@tarent.de>
Message-ID: <c34ded5d-495e-2924-0c0b-211b363c96df@oracle.com>

On 30/07/2022 5:07 am, Thorsten Glaser wrote:
> On Fri, 29 Jul 2022, David Holmes wrote:
> 
>> On 29/07/2022 11:22 am, Bernd Eckenfels wrote:
>>> Agreed, In addition to that, I also think (as already mentioned, sorry
>>> ,) the runFinalizerOnExit() should be a NOP or allow a system property to
>>> turn it into a nop.
>>
>> This change has already been proposed and accepted by the JCP as part of SE 8
>> Maintenance Release 4:
> 
> And that?s fine for the reference implementation.
> 
> However, *this*, here, is about the real-world real-existing OpenJDK
> which real applications use, and which is in security/bugfixes only
> mode and therefore needs to not break existing applications. It?s not
> only perfectly fine but even, to some point, expected that different
> decisions are taken, for compatibility reasons mostly.

It is my understanding that compliance with the Java SE 8 platform 
specification, including MR4, is a requirement for the OpenJDK as well.

With regards to turning the method into a nop instead of throwing UOE, 
that was considered (of course) and rejected as too risky. Any code (if 
it exists) that actually relies on finalizers running at exit could be 
broken in non-obvious ways if we simply silently stopped running those 
finalizers. It was considered far better to fail-fast(er) at the time 
RFOE was called.

David
-----

> bye,
> //mirabilos

From dholmes at openjdk.org  Fri Jul 29 23:11:52 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 29 Jul 2022 23:11:52 GMT
Subject: [jdk8u-dev] RFR: 8287132: Retire Runtime.runFinalizersOnExit so
 that it always throws UOE
In-Reply-To: <Uoeg69AXD_ef8RFqhP8BQh9seOgx9ZJsJKD_MLpByqc=.7bd06f33-e357-4b21-aeab-e23c2a0d39df@github.com>
References: <yC_fFLRfaFdzgXH3L6dzsTNxW4sMGN1bMh4jRIUEYGE=.4ba038a7-4a62-4de1-b181-cc66f079ad99@github.com>
 <Uoeg69AXD_ef8RFqhP8BQh9seOgx9ZJsJKD_MLpByqc=.7bd06f33-e357-4b21-aeab-e23c2a0d39df@github.com>
Message-ID: <s_q-IExmphP2pCnsQ8o1Jrh9VFlD3SVgfgN_Xyop_Qs=.369b60fc-bf31-4bb0-9f42-8b6a789baac7@github.com>

On Fri, 29 Jul 2022 15:13:13 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Forward port of the changes for SE 8 Maintenance release 4, as applied to jdk8u-ri, for:
>> 
>> [JDK-8287132](https://bugs.openjdk.org/browse/JDK-8287132): Retire Runtime.runFinalizersOnExit so that it always throws UOE
>> 
>> The changes applied "unclean" only with regard to trivial things like copyright year updates.
>> 
>> Thanks.
>
> The changes look good.  Thanks for doing this.
> Harold

Thanks for the reviews @hseigel  and @irisclark .

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

PR: https://git.openjdk.org/jdk8u-dev/pull/92

From duke at openjdk.org  Fri Jul 29 23:37:39 2022
From: duke at openjdk.org (Rui Li)
Date: Fri, 29 Jul 2022 23:37:39 GMT
Subject: [jdk8u-dev] RFR: 8274840: Update OS detection code to recognize
 Windows 11
Message-ID: <SKUNM86w1ykZK7xFY1YKSXYi8Hou9JNf7GjYWCCVt3E=.c46b0383-6f51-4281-af45-630732381473@github.com>

This pull request contains a backport of commit https://github.com/openjdk/jdk/commit/97ea9dd2f24f9f1fb9b9345a4202a825ee28e014

The original author is Matthias Baesken and co-authored by Arno Zeller. It was reviewed by clanger, dholmes.

The backport was clean after updating filepath.


Verified on win11: when doing `java -XshowSettings:properties -version`, can see `os.name = Windows 11`

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

Depends on: https://git.openjdk.org/jdk8u-dev/pull/91

Commit messages:
 - Backport 97ea9dd2f24f9f1fb9b9345a4202a825ee28e014

Changes: https://git.openjdk.org/jdk8u-dev/pull/93/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk8u-dev&pr=93&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8274840
  Stats: 15 lines in 2 files changed: 13 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk8u-dev/pull/93.diff
  Fetch: git fetch https://git.openjdk.org/jdk8u-dev pull/93/head:pull/93

PR: https://git.openjdk.org/jdk8u-dev/pull/93

From serb at openjdk.org  Sat Jul 30 00:10:56 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 30 Jul 2022 00:10:56 GMT
Subject: [jdk8u] RFR: 8290832: It is no longer possible to change
 "user.dir" in the JDK8
In-Reply-To: <XsKY7sABdFo_VWW5NgOE7-wFNI_gyDjy5LuC6pq3wLw=.fd227a6d-271d-485e-8a7c-6b75cf807c3e@github.com>
References: <XsKY7sABdFo_VWW5NgOE7-wFNI_gyDjy5LuC6pq3wLw=.fd227a6d-271d-485e-8a7c-6b75cf807c3e@github.com>
Message-ID: <69_vZJYkWVhKK6lHHxgrPSMAHYhM_Q-oQZaFFzSW8zo=.94bfb7b1-717d-4f52-b692-11a5eb443ec4@github.com>

On Fri, 29 Jul 2022 03:46:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the request to revert the fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) integrated to the [openjdk8u342](https://github.com/openjdk/jdk8u/commit/5fcfb7acbe340c8347bd47413a36dd0b1e267dc1)
> 
> The fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) disabled the possibility to change the "user.dir" property.
> Changing the "user.dir" was not recommended from the beginning but it was not forbidden, so there are some old applications that rely on the old behavior. 
> 
> For compatibility reasons, it would be good to restore the old behavior.
> 
> This PR reverts this commit: https://github.com/openjdk/jdk8u/commit/5fcfb7acbe340c8347bd47413a36dd0b1e267dc1

actions executed.

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

PR: https://git.openjdk.org/jdk8u/pull/14

From andrew at openjdk.org  Sat Jul 30 16:53:06 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 30 Jul 2022 16:53:06 GMT
Subject: [jdk8u] RFR: 8290832: It is no longer possible to change
 "user.dir" in the JDK8
In-Reply-To: <XsKY7sABdFo_VWW5NgOE7-wFNI_gyDjy5LuC6pq3wLw=.fd227a6d-271d-485e-8a7c-6b75cf807c3e@github.com>
References: <XsKY7sABdFo_VWW5NgOE7-wFNI_gyDjy5LuC6pq3wLw=.fd227a6d-271d-485e-8a7c-6b75cf807c3e@github.com>
Message-ID: <1HEdb8YeSYXQgZRcPKMmtH-6HvOOo4bh0IMl0NkbNTY=.1ec8dced-3887-45e0-8ba1-47da41ddb2ac@github.com>

On Fri, 29 Jul 2022 03:46:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the request to revert the fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) integrated to the [openjdk8u342](https://github.com/openjdk/jdk8u/commit/5fcfb7acbe340c8347bd47413a36dd0b1e267dc1)
> 
> The fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) disabled the possibility to change the "user.dir" property.
> Changing the "user.dir" was not recommended from the beginning but it was not forbidden, so there are some old applications that rely on the old behavior. 
> 
> For compatibility reasons, it would be good to restore the old behavior.
> 
> This PR reverts this commit: https://github.com/openjdk/jdk8u/commit/5fcfb7acbe340c8347bd47413a36dd0b1e267dc1

Ah, right, sorry I should have checked the current state of the files. Both were updated by the security fix JDK-8278356.

I've approved the bug (flipped it to a `jdk8u-critical-fix/yes` to reflect it going direct to 8u, not 8u-dev) and the release bump is in now, so this is good to go.

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

Marked as reviewed by andrew (Reviewer).

PR: https://git.openjdk.org/jdk8u/pull/14

From andrew at openjdk.org  Sat Jul 30 16:53:13 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 30 Jul 2022 16:53:13 GMT
Subject: [jdk8u] RFR: 8290832: It is no longer possible to change
 "user.dir" in the JDK8
In-Reply-To: <69_vZJYkWVhKK6lHHxgrPSMAHYhM_Q-oQZaFFzSW8zo=.94bfb7b1-717d-4f52-b692-11a5eb443ec4@github.com>
References: <XsKY7sABdFo_VWW5NgOE7-wFNI_gyDjy5LuC6pq3wLw=.fd227a6d-271d-485e-8a7c-6b75cf807c3e@github.com>
 <69_vZJYkWVhKK6lHHxgrPSMAHYhM_Q-oQZaFFzSW8zo=.94bfb7b1-717d-4f52-b692-11a5eb443ec4@github.com>
Message-ID: <SZ93TTwUGVabxZFmYP-bSkV_1gI2tYriVWlfXgfa_U8=.f4e77a69-88d7-46fb-ac30-9bca74b5e58a@github.com>

On Sat, 30 Jul 2022 00:08:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> actions executed.

Thanks. Strange that it would disable them, I've not heard of that before.

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

PR: https://git.openjdk.org/jdk8u/pull/14

From andrew at openjdk.org  Sat Jul 30 16:56:33 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 30 Jul 2022 16:56:33 GMT
Subject: [jdk8u] RFR: 8291568: Bump update version of OpenJDK: 8u345
In-Reply-To: <_KGtZFYxfnYheCuVlJfrToTlF8e1LPhfawOmVTq1D8U=.38ea1a5b-55eb-4cd6-9b2e-b766d501936b@github.com>
References: <_KGtZFYxfnYheCuVlJfrToTlF8e1LPhfawOmVTq1D8U=.38ea1a5b-55eb-4cd6-9b2e-b766d501936b@github.com>
Message-ID: <pPDjVgJE4BNZR7R_tH-4RK9PB2rL48YV7CfuApXhvA8=.d4dfceda-719a-4fba-8bf4-315a272a7434@github.com>

On Fri, 29 Jul 2022 20:33:47 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Needed bump for the interim release to revert [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) ; see #14

Thanks both. I've self-approved this piece of trivial admin so we can get the release underway.

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

PR: https://git.openjdk.org/jdk8u/pull/15

From andrew at openjdk.org  Sat Jul 30 16:56:34 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sat, 30 Jul 2022 16:56:34 GMT
Subject: [jdk8u] Integrated: 8291568: Bump update version of OpenJDK: 8u345
In-Reply-To: <_KGtZFYxfnYheCuVlJfrToTlF8e1LPhfawOmVTq1D8U=.38ea1a5b-55eb-4cd6-9b2e-b766d501936b@github.com>
References: <_KGtZFYxfnYheCuVlJfrToTlF8e1LPhfawOmVTq1D8U=.38ea1a5b-55eb-4cd6-9b2e-b766d501936b@github.com>
Message-ID: <AkR8ANhJGXv4CMhIXXk4oBrnEcnHWOi5qvnhyoHh7Ws=.2eaff672-3f5a-493b-a492-fb1cad8636c3@github.com>

On Fri, 29 Jul 2022 20:33:47 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Needed bump for the interim release to revert [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) ; see #14

This pull request has now been integrated.

Changeset: 244f98e4
Author:    Andrew John Hughes <andrew at openjdk.org>
URL:       https://git.openjdk.org/jdk8u/commit/244f98e4eb5cd16d2b8ff11b6aa98787ed7c2a10
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8291568: Bump update version of OpenJDK: 8u345

Reviewed-by: phh, serb

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

PR: https://git.openjdk.org/jdk8u/pull/15

From serb at openjdk.org  Sun Jul 31 04:04:36 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 31 Jul 2022 04:04:36 GMT
Subject: [jdk8u] Integrated: 8290832: It is no longer possible to change
 "user.dir" in the JDK8
In-Reply-To: <XsKY7sABdFo_VWW5NgOE7-wFNI_gyDjy5LuC6pq3wLw=.fd227a6d-271d-485e-8a7c-6b75cf807c3e@github.com>
References: <XsKY7sABdFo_VWW5NgOE7-wFNI_gyDjy5LuC6pq3wLw=.fd227a6d-271d-485e-8a7c-6b75cf807c3e@github.com>
Message-ID: <BDhivyA9M_nc2ZGUY-LLKcezI9NQnjdUc2vSrzhfaEw=.e863d8fd-3898-4fff-8b90-75b785a8a01f@github.com>

On Fri, 29 Jul 2022 03:46:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the request to revert the fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) integrated to the [openjdk8u342](https://github.com/openjdk/jdk8u/commit/5fcfb7acbe340c8347bd47413a36dd0b1e267dc1)
> 
> The fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) disabled the possibility to change the "user.dir" property.
> Changing the "user.dir" was not recommended from the beginning but it was not forbidden, so there are some old applications that rely on the old behavior. 
> 
> For compatibility reasons, it would be good to restore the old behavior.
> 
> This PR reverts this commit: https://github.com/openjdk/jdk8u/commit/5fcfb7acbe340c8347bd47413a36dd0b1e267dc1

This pull request has now been integrated.

Changeset: 2dadc2bf
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk8u/commit/2dadc2bf312d5f947e0735d5ec13c285824db31d
Stats:     67 lines in 3 files changed: 0 ins; 65 del; 2 mod

8290832: It is no longer possible to change "user.dir" in the JDK8

Reviewed-by: phh, andrew

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

PR: https://git.openjdk.org/jdk8u/pull/14

From serb at openjdk.org  Sun Jul 31 04:53:33 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 31 Jul 2022 04:53:33 GMT
Subject: [jdk8u-dev] Withdrawn: 8290832: It is no longer possible to change
 "user.dir" in the JDK8
In-Reply-To: <W0pjhP4ROmBMfS1AospdJ17URyi52s6Fdu8Z3VOWYxI=.10d8357b-4ad0-43b2-89a9-8d97491fd6c2@github.com>
References: <W0pjhP4ROmBMfS1AospdJ17URyi52s6Fdu8Z3VOWYxI=.10d8357b-4ad0-43b2-89a9-8d97491fd6c2@github.com>
Message-ID: <zO96KFFaFntHqAiQ5tE0UiA8I3Qv8txt737aJNkuln4=.d30db600-4449-4f74-b2f6-5d1258e0454c@github.com>

On Thu, 21 Jul 2022 19:46:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the request to revert the fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) integrated to the [openjdk8u342](https://github.com/openjdk/jdk8u/commit/5fcfb7acbe340c8347bd47413a36dd0b1e267dc1)
> 
> The fix for [JDK-8194154](https://bugs.openjdk.org/browse/JDK-8194154) disabled the possibility to change the "user.dir" property.
> Changing the "user.dir" was not recommended from the beginning but it was not forbidden, so there are some old applications that rely on the old behavior. 
> 
> For compatibility reasons, it would be good to restore the old behavior.
> 
> Note that the test is simplified and saved under a different name, now it will check just the possibility to change the 'user.dir' using a simple path and name.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk8u-dev/pull/88