From duke at openjdk.org  Fri Jul  1 08:16:20 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 1 Jul 2022 08:16:20 GMT
Subject: RFR: 8289572: InputStream wrapping with BufferedInputStream is
 redundant in HttpTimestamper
Message-ID: <P9jIj_8YZm3wshGxV9ox_-38G9UfMWbKLy0z9u7Gfug=.adc2f80c-086c-4b9e-a70b-129b7ba746ff@github.com>

In case we read all bytes from an `InputStream` we don't need wrapping with `BufferedInputStream` as the bytes are not written into internal buffer. With removal of redundant buffer we save 8 kB of allocated memory.

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

Commit messages:
 - 8289572: InputStream wrapping with BufferedInputStream is redundant in HttpTimestamper

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

PR: https://git.openjdk.org/jdk/pull/9343

From dfuchs at openjdk.org  Fri Jul  1 08:16:33 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 1 Jul 2022 08:16:33 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10]
In-Reply-To: <iHdGR-wS_iXFAw4KrXdpIT6Y5d1CLM7ZHZiYGyGrzqc=.6994b6c0-195e-4b94-92fe-b1111f2986c3@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com>
 <Ix_ksEm4xi4dzECO_5gNZtTe6TsQB3Rw1DL-PfxyKkQ=.49d35b76-0beb-476e-8640-640657458832@github.com>
 <70yQ-BIsnyWNrP3w5tc2-392ICgUkF8LpweOUtcFkLQ=.2313ff23-7b8e-4653-9136-ee4bf8d800ec@github.com>
 <iHdGR-wS_iXFAw4KrXdpIT6Y5d1CLM7ZHZiYGyGrzqc=.6994b6c0-195e-4b94-92fe-b1111f2986c3@github.com>
Message-ID: <ctNcTWJEDZF6dlYxcgkJwvSV7-4eIZPnKmRuyL6Hj-8=.67307530-abb4-4871-8bf8-5b5f754ba2b2@github.com>

On Thu, 30 Jun 2022 20:36:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I'm not sure if all unused object will be collected in one GC call always.  The gc() specification says "When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all unused objects. ... There is also no guarantee that this effort will determine the change of reachability in any particular number of objects, or that any particular number of {@link java.lang.ref.Reference Reference} objects will be cleared and enqueued."  But from the spec, I did not get a clear answer for the question.
>> 
>> If the `booleanSupplier` object could be cleared in a collection other than the `ref` collection, the current code may be safer.
>
> True, knowing when GC is 'done' is not deterministic except for a specify Reference to a specific object.
> System.gc is just a request, the checking for an object can more quickly exit the loop.
> The code is as is, and already commented, might wait an extra cycle, but only in the case of a race between the requested predicate and the object being reclaimed.  Ok as it.

Maybe not for this PR - but it could be useful to have a version of ForceGC that takes as parameter a ReferenceQueue<T> and a Reference<T>. That would be more efficient than creating a new object and waiting for a different cleaner thread to cleanup that object.

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

PR: https://git.openjdk.org/jdk/pull/8979

From xuelei at openjdk.org  Fri Jul  1 08:29:39 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 1 Jul 2022 08:29:39 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10]
In-Reply-To: <ctNcTWJEDZF6dlYxcgkJwvSV7-4eIZPnKmRuyL6Hj-8=.67307530-abb4-4871-8bf8-5b5f754ba2b2@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com>
 <Ix_ksEm4xi4dzECO_5gNZtTe6TsQB3Rw1DL-PfxyKkQ=.49d35b76-0beb-476e-8640-640657458832@github.com>
 <70yQ-BIsnyWNrP3w5tc2-392ICgUkF8LpweOUtcFkLQ=.2313ff23-7b8e-4653-9136-ee4bf8d800ec@github.com>
 <iHdGR-wS_iXFAw4KrXdpIT6Y5d1CLM7ZHZiYGyGrzqc=.6994b6c0-195e-4b94-92fe-b1111f2986c3@github.com>
 <ctNcTWJEDZF6dlYxcgkJwvSV7-4eIZPnKmRuyL6Hj-8=.67307530-abb4-4871-8bf8-5b5f754ba2b2@github.com>
Message-ID: <9IGgWUHMMTrHU89TkAr8IRjlplc01pUc3gAljFNDYYs=.c4c91870-b1da-45eb-b8ab-24bfb26a1558@github.com>

On Fri, 1 Jul 2022 08:12:59 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> True, knowing when GC is 'done' is not deterministic except for a specify Reference to a specific object.
>> System.gc is just a request, the checking for an object can more quickly exit the loop.
>> The code is as is, and already commented, might wait an extra cycle, but only in the case of a race between the requested predicate and the object being reclaimed.  Ok as it.
>
> Maybe not for this PR - but it could be useful to have a version of ForceGC that takes as parameter a ReferenceQueue<T> and a Reference<T>. That would be more efficient than creating a new object and waiting for a different cleaner thread to cleanup that object.

@dfuch  Taking a reference as parameter could simplify the use of ForceGC.  I though about this idea as well, when I had to check lambada expressions in each call.  I would like to do it in the future so that this PR could focus on less things.

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

PR: https://git.openjdk.org/jdk/pull/8979

From xuelei at openjdk.org  Fri Jul  1 08:35:37 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 1 Jul 2022 08:35:37 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v12]
In-Reply-To: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
Message-ID: <C4WxQo62GwvZzNa0fb4nlVxi081-H7b_jB4XRIeitLg=.3fdeec94-f7a8-43b6-88a2-29250b4dcd29@github.com>

> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge
 - update per feedback
 - Master
 - use Reference.refersTo
 - remove trailing whitespaces
 - use timeout factor
 - Merge
 - Merge master
 - Merge
 - add timeout parameter
 - ... and 5 more: https://git.openjdk.org/jdk/compare/d260a4e7...82b660af

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

Changes: https://git.openjdk.org/jdk/pull/8979/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8979&range=11
  Stats: 92 lines in 10 files changed: 13 ins; 38 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/8979.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/8979/head:pull/8979

PR: https://git.openjdk.org/jdk/pull/8979

From xuelei at openjdk.org  Fri Jul  1 08:35:39 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 1 Jul 2022 08:35:39 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v11]
In-Reply-To: <i8iz_AGI5N5zHYkYWkq9LEiZN03z4QyfS4HmAJdR7C4=.ce63ef8d-dbf2-4754-bccf-333ffd1fb008@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <i8iz_AGI5N5zHYkYWkq9LEiZN03z4QyfS4HmAJdR7C4=.ce63ef8d-dbf2-4754-bccf-333ffd1fb008@github.com>
Message-ID: <qLfq3u7MgXlWco-vHohFvk1dbTqA7FnbukVK7IBfxLo=.81494f0b-8ba4-4367-9c9e-f62fef0ebe64@github.com>

On Thu, 30 Jun 2022 18:44:30 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update per feedback

Could someone in Oracle help me run Mach 5 testing?

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

PR: https://git.openjdk.org/jdk/pull/8979

From dfuchs at openjdk.org  Fri Jul  1 08:43:33 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 1 Jul 2022 08:43:33 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10]
In-Reply-To: <9IGgWUHMMTrHU89TkAr8IRjlplc01pUc3gAljFNDYYs=.c4c91870-b1da-45eb-b8ab-24bfb26a1558@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com>
 <Ix_ksEm4xi4dzECO_5gNZtTe6TsQB3Rw1DL-PfxyKkQ=.49d35b76-0beb-476e-8640-640657458832@github.com>
 <70yQ-BIsnyWNrP3w5tc2-392ICgUkF8LpweOUtcFkLQ=.2313ff23-7b8e-4653-9136-ee4bf8d800ec@github.com>
 <iHdGR-wS_iXFAw4KrXdpIT6Y5d1CLM7ZHZiYGyGrzqc=.6994b6c0-195e-4b94-92fe-b1111f2986c3@github.com>
 <ctNcTWJEDZF6dlYxcgkJwvSV7-4eIZPnKmRuyL6Hj-8=.67307530-abb4-4871-8bf8-5b5f754ba2b2@github.com>
 <9IGgWUHMMTrHU89TkAr8IRjlplc01pUc3gAljFNDYYs=.c4c91870-b1da-45eb-b8ab-24bfb26a1558@github.com>
Message-ID: <PaQuKeE74RkeylHVZ_fZrs-ly1Ry2y_M_n2KTeQbniQ=.60a9a64d-80de-46d8-a798-c78dd45ec20e@github.com>

On Fri, 1 Jul 2022 08:26:30 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Maybe not for this PR - but it could be useful to have a version of ForceGC that takes as parameter a `ReferenceQueue<T>` and a `Reference<T>`. That would be more efficient than creating a new object and waiting for a different cleaner thread to cleanup that object.
>
> @dfuch  Taking a reference as parameter could simplify the use of ForceGC.  I though about this idea as well, when I had to check lambada expressions in each call.  I would like to do it in the future so that this PR could focus on less things.

Thanks @XueleiFan, that's fine by me!

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

PR: https://git.openjdk.org/jdk/pull/8979

From dfuchs at openjdk.org  Fri Jul  1 09:17:39 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 1 Jul 2022 09:17:39 GMT
Subject: RFR: 8289572: InputStream wrapping with BufferedInputStream is
 redundant in HttpTimestamper
In-Reply-To: <P9jIj_8YZm3wshGxV9ox_-38G9UfMWbKLy0z9u7Gfug=.adc2f80c-086c-4b9e-a70b-129b7ba746ff@github.com>
References: <P9jIj_8YZm3wshGxV9ox_-38G9UfMWbKLy0z9u7Gfug=.adc2f80c-086c-4b9e-a70b-129b7ba746ff@github.com>
Message-ID: <8yMmc4A6IYKHqFsDyzxyT5esuwsxNohZZrGq0zroT0E=.10b65a93-de25-449b-82b4-655eddab09d2@github.com>

On Fri, 1 Jul 2022 08:06:10 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> In case we read all bytes from an InputStream we don't need wrapping with BufferedInputStream as the bytes are not written into internal buffer. With removal of redundant buffer we save 8 kB of allocated memory.

I believe that in that case the bytes might get double buffered, depending on whether the buffer used by `readAllBytes` is bigger than the buffer used by  `BufferedInputStream`, since IIAMNM `readAllBytes()` will call `read(byte[], off, len)` - but I otherwise agree that regardless of that wrapping in a `BufferedInputStream` is always wasteful in this case. Good find!

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

PR: https://git.openjdk.org/jdk/pull/9343

From duke at openjdk.org  Fri Jul  1 09:33:25 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 1 Jul 2022 09:33:25 GMT
Subject: RFR: 8289572: InputStream wrapping with BufferedInputStream is
 redundant in HttpTimestamper
In-Reply-To: <8yMmc4A6IYKHqFsDyzxyT5esuwsxNohZZrGq0zroT0E=.10b65a93-de25-449b-82b4-655eddab09d2@github.com>
References: <P9jIj_8YZm3wshGxV9ox_-38G9UfMWbKLy0z9u7Gfug=.adc2f80c-086c-4b9e-a70b-129b7ba746ff@github.com>
 <8yMmc4A6IYKHqFsDyzxyT5esuwsxNohZZrGq0zroT0E=.10b65a93-de25-449b-82b4-655eddab09d2@github.com>
Message-ID: <MXp1kfTHOQ0tVBovqtwLHWBFyuOLaT6Asq7l3MNmGfQ=.bad20e73-b1de-4e4d-be12-914b45ff133f@github.com>

On Fri, 1 Jul 2022 09:13:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> In case we read all bytes from an `InputStream` we don't need wrapping with `BufferedInputStream` as the bytes are not written into internal buffer. With removal of redundant buffer we save 8 kB of allocated memory.
>
>> In case we read all bytes from an InputStream we don't need wrapping with BufferedInputStream as the bytes are not written into internal buffer. With removal of redundant buffer we save 8 kB of allocated memory.
> 
> I believe that in that case the bytes might get double buffered, depending on whether the buffer used by `readAllBytes` is bigger than the buffer used by  `BufferedInputStream`, since IIAMNM `readAllBytes()` will call `read(byte[], off, len)` - but I otherwise agree that regardless of that wrapping in a `BufferedInputStream` is always wasteful in this case. Good find!

@dfuch as of current implementation of `InputStream.readNBytes()` it relies on `InputStream.DEFAULT_BUFFER_SIZE` which is 8192 and equals to `DEFAULT_BUFFER_SIZE` in `BufferedInputStream`.

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

PR: https://git.openjdk.org/jdk/pull/9343

From rriggs at openjdk.org  Fri Jul  1 14:29:33 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 1 Jul 2022 14:29:33 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10]
In-Reply-To: <PaQuKeE74RkeylHVZ_fZrs-ly1Ry2y_M_n2KTeQbniQ=.60a9a64d-80de-46d8-a798-c78dd45ec20e@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com>
 <Ix_ksEm4xi4dzECO_5gNZtTe6TsQB3Rw1DL-PfxyKkQ=.49d35b76-0beb-476e-8640-640657458832@github.com>
 <70yQ-BIsnyWNrP3w5tc2-392ICgUkF8LpweOUtcFkLQ=.2313ff23-7b8e-4653-9136-ee4bf8d800ec@github.com>
 <iHdGR-wS_iXFAw4KrXdpIT6Y5d1CLM7ZHZiYGyGrzqc=.6994b6c0-195e-4b94-92fe-b1111f2986c3@github.com>
 <ctNcTWJEDZF6dlYxcgkJwvSV7-4eIZPnKmRuyL6Hj-8=.67307530-abb4-4871-8bf8-5b5f754ba2b2@github.com>
 <9IGgWUHMMTrHU89TkAr8IRjlplc01pUc3gAljFNDYYs=.c4c91870-b1da-45eb-b8ab-24bfb26a1558@github.com>
 <PaQuKeE74RkeylHVZ_fZrs-ly1Ry2y_M_n2KTeQbniQ=.60a9a64d-80de-46d8-a798-c78dd45ec20e@github.com>
Message-ID: <QAQjdyMAduE2KO4NXEugdMh-JxIg2HHX56LqfWz3JB4=.462ad0ab-f73c-49bc-a0e7-127581cef75e@github.com>

On Fri, 1 Jul 2022 08:40:06 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> @dfuch  Taking a reference as parameter could simplify the use of ForceGC.  I though about this idea as well, when I had to check lambada expressions in each call.  I would like to do it in the future so that this PR could focus on less things.
>
> Thanks @XueleiFan, that's fine by me!

When using Reference/ReferenceQueue there is no Cleaner, only normal reference processing (via GC).

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

PR: https://git.openjdk.org/jdk/pull/8979

From alanb at openjdk.org  Fri Jul  1 14:50:43 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 1 Jul 2022 14:50:43 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v12]
In-Reply-To: <C4WxQo62GwvZzNa0fb4nlVxi081-H7b_jB4XRIeitLg=.3fdeec94-f7a8-43b6-88a2-29250b4dcd29@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <C4WxQo62GwvZzNa0fb4nlVxi081-H7b_jB4XRIeitLg=.3fdeec94-f7a8-43b6-88a2-29250b4dcd29@github.com>
Message-ID: <b4TKicu5_3MfmCROD1LXua5Rc4_ruqQ5jDtsjcipjrQ=.08522aaa-9f17-4be7-81ef-af6d9162ef4b@github.com>

On Fri, 1 Jul 2022 08:35:37 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.
>
> Xue-Lei Andrew Fan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge
>  - update per feedback
>  - Master
>  - use Reference.refersTo
>  - remove trailing whitespaces
>  - use timeout factor
>  - Merge
>  - Merge master
>  - Merge
>  - add timeout parameter
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/d260a4e7...82b660af

Does this address JDK-8288286 and allow ReflectionCallerCacheTest.java  to be removed from ProblemList-Xcomp.txt?

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

PR: https://git.openjdk.org/jdk/pull/8979

From dfuchs at openjdk.org  Fri Jul  1 14:50:45 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 1 Jul 2022 14:50:45 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v10]
In-Reply-To: <QAQjdyMAduE2KO4NXEugdMh-JxIg2HHX56LqfWz3JB4=.462ad0ab-f73c-49bc-a0e7-127581cef75e@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <9f0CtAs87t5ee-KIK14QaBswkLB2_KuCpdloR6AMpQg=.4c1aecc5-cd1c-4447-869f-76d648a0fa73@github.com>
 <Ix_ksEm4xi4dzECO_5gNZtTe6TsQB3Rw1DL-PfxyKkQ=.49d35b76-0beb-476e-8640-640657458832@github.com>
 <70yQ-BIsnyWNrP3w5tc2-392ICgUkF8LpweOUtcFkLQ=.2313ff23-7b8e-4653-9136-ee4bf8d800ec@github.com>
 <iHdGR-wS_iXFAw4KrXdpIT6Y5d1CLM7ZHZiYGyGrzqc=.6994b6c0-195e-4b94-92fe-b1111f2986c3@github.com>
 <ctNcTWJEDZF6dlYxcgkJwvSV7-4eIZPnKmRuyL6Hj-8=.67307530-abb4-4871-8bf8-5b5f754ba2b2@github.com>
 <9IGgWUHMMTrHU89TkAr8IRjlplc01pUc3gAljFNDYYs=.c4c91870-b1da-45eb-b8ab-24bfb26a1558@github.com>
 <PaQuKeE74RkeylHVZ_fZrs-ly1Ry2y_M_n2KTeQbniQ=.60a9a64d-80de-46d8-a798-c78dd45ec20e@github.com>
 <QAQjdyMAduE2KO4NXEugdMh-JxIg2HHX56LqfWz3JB4=.462ad0ab-f73c-49bc-a0e7-127581cef75e@github.com>
Message-ID: <64g5q52rXNZV6xMdrDBYCGlJn74vbKhY7ymN0LoTKF4=.ce4314be-f717-4c5f-96df-5eff4aae4865@github.com>

On Fri, 1 Jul 2022 14:26:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Thanks @XueleiFan, that's fine by me!
>
> When using Reference/ReferenceQueue there is no Cleaner, only normal reference processing (via GC).

I have tests that use Reference/ReferenceQueue to check that an object that uses a Cleaner has been garbage collected. I don't use ForceGC in those tests because it's much more efficient to wait on my ReferenceQueue rather than having ForceGC  wait on something else.

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

PR: https://git.openjdk.org/jdk/pull/8979

From rriggs at openjdk.org  Fri Jul  1 15:30:41 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 1 Jul 2022 15:30:41 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v11]
In-Reply-To: <qLfq3u7MgXlWco-vHohFvk1dbTqA7FnbukVK7IBfxLo=.81494f0b-8ba4-4367-9c9e-f62fef0ebe64@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <i8iz_AGI5N5zHYkYWkq9LEiZN03z4QyfS4HmAJdR7C4=.ce63ef8d-dbf2-4754-bccf-333ffd1fb008@github.com>
 <qLfq3u7MgXlWco-vHohFvk1dbTqA7FnbukVK7IBfxLo=.81494f0b-8ba4-4367-9c9e-f62fef0ebe64@github.com>
Message-ID: <I2wyp7vBpo-rpNwC9g1kjfc7tvc4QlAX6OecsPqP9vw=.4c86b116-f035-424a-a036-5bbd0867a3c1@github.com>

On Fri, 1 Jul 2022 08:31:28 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Could someone in Oracle help me run Mach 5 testing?
The CI Passed for Tiers 1-3.

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

PR: https://git.openjdk.org/jdk/pull/8979

From xuelei at openjdk.org  Fri Jul  1 18:40:06 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 1 Jul 2022 18:40:06 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v11]
In-Reply-To: <I2wyp7vBpo-rpNwC9g1kjfc7tvc4QlAX6OecsPqP9vw=.4c86b116-f035-424a-a036-5bbd0867a3c1@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <i8iz_AGI5N5zHYkYWkq9LEiZN03z4QyfS4HmAJdR7C4=.ce63ef8d-dbf2-4754-bccf-333ffd1fb008@github.com>
 <qLfq3u7MgXlWco-vHohFvk1dbTqA7FnbukVK7IBfxLo=.81494f0b-8ba4-4367-9c9e-f62fef0ebe64@github.com>
 <I2wyp7vBpo-rpNwC9g1kjfc7tvc4QlAX6OecsPqP9vw=.4c86b116-f035-424a-a036-5bbd0867a3c1@github.com>
Message-ID: <EN9OKqd3QzxNNM8HBm96KlbDhAGuUevA6UlAyOvK9-8=.43760239-2356-4b67-8a33-23e5c6e8a222@github.com>

On Fri, 1 Jul 2022 15:28:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> >  Could someone in Oracle help me run Mach 5 testing?
>
> The CI Passed for Tiers 1-3.

Thanks a lot!

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

PR: https://git.openjdk.org/jdk/pull/8979

From duke at openjdk.org  Fri Jul  1 19:27:16 2022
From: duke at openjdk.org (Kevin Driver)
Date: Fri, 1 Jul 2022 19:27:16 GMT
Subject: RFR: 8170762: Remove randomness from ISO10126Padding
Message-ID: <dPKTNX-lsIvodW1hMjVLpbQi23gAEIoQJi-7BkBV6eA=.492057c4-c77f-4bcf-a81b-9a22baad02ae@github.com>

JDK-8170762 - update Javadoc to indicate ISO10126Padding pads with random bytes, though the spec does not require random bytes

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

Commit messages:
 - update javadoc according to JDK-8170762

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

PR: https://git.openjdk.org/jdk/pull/9350

From duke at openjdk.org  Fri Jul  1 19:55:27 2022
From: duke at openjdk.org (Mark Powers)
Date: Fri, 1 Jul 2022 19:55:27 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <MOaYWQkCI1aQWZf8-X6hc2HqbKDnB1MkFzCk7JeGBUM=.502f8687-efe2-49b1-b461-76571d67bebc@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
 <MOaYWQkCI1aQWZf8-X6hc2HqbKDnB1MkFzCk7JeGBUM=.502f8687-efe2-49b1-b461-76571d67bebc@github.com>
Message-ID: <D_92dd8EslODxZ0XLu3Yi5sRrcdzJYQuISAqbwo0v_Q=.fb26cbb7-1fdf-4401-9dd9-6c9f3eabf309@github.com>

On Tue, 28 Jun 2022 20:19:29 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Valerie fix
>
> src/java.base/share/classes/java/security/AlgorithmParameterGenerator.java line 249:
> 
>> 247:      * <p> A new {@code AlgorithmParameterGenerator} object encapsulating the
>> 248:      * {@code AlgorithmParameterGeneratorSpi} implementation from the Provider
>> 249:      * object is returned.  Note that the specified Provider object
> 
> Code-ify two "Provider" here.

This conflicts with the previous recommendation. I ultimately changed "Provider object" to just "provider". The sentence flows much better.

> src/java.base/share/classes/java/security/AlgorithmParameters.java line 225:
> 
>> 223:      * <p> A new {@code AlgorithmParameters} object encapsulating the
>> 224:      * {@code AlgorithmParametersSpi} implementation from the specified
>> 225:      * Provider object is returned.  Note that the specified Provider object
> 
> `{@code Provider}`.

Changed "Provider object" to just "provider". The sentence flows much better.

> src/java.base/share/classes/java/security/AllPermission.java line 73:
> 
>> 71:      * Creates a new {@code AllPermission} object. This
>> 72:      * constructor exists for use by the {@code Policy} object
>> 73:      * to instantiate new Permission objects.
> 
> `{@code Permission}`.

Fixed.

> src/java.base/share/classes/java/security/AllPermission.java line 139:
> 
>> 137: /**
>> 138:  * An {@code AllPermissionCollection} stores a collection
>> 139:  * of AllPermission permissions. {@code AllPermission} objects
> 
> `{@code AllPermission}`.

Fixed.

> src/java.base/share/classes/java/security/AllPermission.java line 177:
> 
>> 175: 
>> 176:     /**
>> 177:      * Adds a permission to the {@code AllPermissions} object.
> 
> There is no such a thing named "AllPermissions". Update it into "AllPermissionCollection". There are several such names in this file.

Fixed.

> src/java.base/share/classes/java/security/AllPermission.java line 178:
> 
>> 176:     /**
>> 177:      * Adds a permission to the {@code AllPermissions} object.
>> 178:      * The key for the hash is {@code permission.path}.
> 
> No idea what key means? Could possibly be describing an old implementation. File a separate bug please.

JDK-8289581 Unintelligible comment in AllPermission add() method

> src/java.base/share/classes/java/security/AllPermission.java line 201:
> 
>> 199:     /**
>> 200:      * Check and see if this set of permissions implies the permissions
>> 201:      * expressed in "permission".
> 
> "this set of permissions" is not used anywhere. You can copy from the same method from the parent class.

What is the JavaDoc change? Is this a code change?

> src/java.base/share/classes/java/security/BasicPermission.java line 246:
> 
>> 244:     /**
>> 245:      * Returns a new {@code PermissionCollection} object for storing
>> 246:      * BasicPermissions.
> 
> Maybe the original wording is better. I found it strange to write `{@code BasicPermission}s`. There are several other occurrences in this file.

Changed to `{@code BasicPermission}` objects.

> src/java.base/share/classes/java/security/BasicPermission.java line 250:
> 
>> 248:      * <p>{@code BasicPermission} objects must be stored in a manner
>> 249:      * that allows them to be inserted in any order, but that also enables the
>> 250:      * {@code PermissionCollection} {@code implies} method
> 
> Two code in a row. Maybe make it a link?

made it a link

> src/java.base/share/classes/java/security/BasicPermission.java line 360:
> 
>> 358:      *                                       {@code BasicPermission}, or if
>> 359:      *                                       the permission is not of the
>> 360:      *                                       same Class as the other
> 
> "Class" to "class" or "type".

using "class"

> src/java.base/share/classes/java/security/GeneralSecurityException.java line 52:
> 
>> 50:      * Constructs a {@code GeneralSecurityException} with the specified detail
>> 51:      * message.
>> 52:      * A detail message is a String that describes this particular
> 
> "String" to "string".

using `{@code String}`

> src/java.base/share/classes/java/security/IdentityScope.java line 38:
> 
>> 36:  *
>> 37:  * <p>An {@code IdentityScope} can contain {@code Identity} objects of all
>> 38:  * kinds, including Signers. All types of {@code Identity} objects can be
> 
> "Signers" -> "signers".

Fixed.

> src/java.base/share/classes/java/security/IdentityScope.java line 190:
> 
>> 188:     /**
>> 189:      * Retrieves the {@code Identity} whose name is the same as that of the
>> 190:      * specified principal. (Note: Identity implements Principal.)
> 
> Code-ify both Identity and Principal.

Fixed.

> src/java.base/share/classes/java/security/KeyStore.java line 1728:
> 
>> 1726:      * A new {@code KeyStore} object is returned that encapsulates the
>> 1727:      * {@code KeyStoreSpi}
>> 1728:      * implementation from the first Provider that supports the specified file.
> 
> "Provider" -> "provider".

Fixed.

> src/java.base/share/classes/java/security/KeyStore.java line 1889:
> 
>> 1887:          * @throws KeyStoreException if an error occurred during the
>> 1888:          *   operation
>> 1889:          * @throws IllegalStateException if the getKeyStore method has
> 
> Code-ify getKeyStore.

Fixed.

> src/java.base/share/classes/java/security/KeyStore.java line 1903:
> 
>> 1901:          *
>> 1902:          * <p> This is useful if an existing {@code KeyStore} object needs to be
>> 1903:          * used with Builder-based APIs.
> 
> "Builder" -> "builder".

Fixed.

> src/java.base/share/classes/java/security/KeyStore.java line 1913:
> 
>> 1911:          * @throws IllegalArgumentException if the keyStore has not been
>> 1912:          *   initialized
>> 1913:          */
> 
> A bunch of names need to be in code above: Builder, KeyStore, ProtectionParameter, keyStore, protectionParameters. Same for the methods below.

Fixed.

> src/java.base/share/classes/java/security/MessageDigest.java line 266:
> 
>> 264:      * <p> A new {@code MessageDigest} object encapsulating the
>> 265:      * {@code MessageDigestSpi} implementation from the specified Provider
>> 266:      * object is returned.  Note that the specified Provider object
> 
> "Provider" -> "provider".

Fixed.

> src/java.base/share/classes/java/security/MessageDigest.java line 562:
> 
>> 560:      * The following class allows providers to extend from
>> 561:      * {@code MessageDigestSpi} rather than from {@code MessageDigest}.
>> 562:      * It represents a MessageDigest with an
> 
> Maybe "message digest"?

Yes.

> src/java.base/share/classes/java/security/MessageDigest.java line 565:
> 
>> 563:      * encapsulated, provider-supplied SPI object (of type MessageDigestSpi).
>> 564:      * If the provider implementation is an instance of
>> 565:      * {@code MessageDigestSpi}, the getInstance() methods above return an
> 
> Wrap getInstance in code.

Fixed.

> src/java.base/share/classes/java/security/MessageDigest.java line 569:
> 
>> 567:      *
>> 568:      * Note: All SPI methods from the original MessageDigest class have been
>> 569:      * moved up the hierarchy into a new class (MessageDigestSpi), which has
> 
> Both MessageDigest and MessageDigestSpi here.

Fixed.

> src/java.base/share/classes/java/security/NoSuchProviderException.java line 43:
> 
>> 41:     /**
>> 42:      * Constructs a {@code NoSuchProviderException} with no detail message. A
>> 43:      * detail message is a String that describes this particular
> 
> "String" to "string".

using `{@code String}`

> src/java.base/share/classes/java/security/Permission.java line 52:
> 
>> 50:  * subset test.
>> 51:  *
>> 52:  * <P> {@code Permission} objects are similar to String objects in that they
> 
> `{@code String}`.

Fixed.

> src/java.base/share/classes/java/security/PermissionCollection.java line 80:
> 
>> 78:  * it desires (one using a Hashtable, one using a Vector, etc.). For example,
>> 79:  * the Permissions object uses a default {@code PermissionCollection}
>> 80:  * implementation that stores the permission objects in a Hashtable.
> 
> Several names need to be wrapped in code in the two paragraphs above.

Fixed.

> src/java.base/share/classes/java/security/PermissionCollection.java line 130:
> 
>> 128:     /**
>> 129:      * Checks to see if the specified permission is implied by
>> 130:      * the collection of Permission objects held in this
> 
> Permission.

Fixed.

> src/java.base/share/classes/java/security/PermissionCollection.java line 175:
> 
>> 173:      * Marks this {@code PermissionCollection} object as "readonly". After
>> 174:      * a {@code PermissionCollection} object
>> 175:      * is marked as readonly, no new Permission objects can be added to it
> 
> Permission.

Fixed.

> src/java.base/share/classes/java/security/PermissionCollection.java line 184:
> 
>> 182:     /**
>> 183:      * Returns true if this {@code PermissionCollection} object is marked
>> 184:      * as readonly. If it is readonly, no new Permission objects can be added
> 
> Permission.

Fixed.

> src/java.base/share/classes/java/security/PermissionCollection.java line 211:
> 
>> 209:      * method of this
>> 210:      * object's superclass, which is Object. The result is
>> 211:      * this PermissionCollection's type name followed by this object's
> 
> Object, PermissionCollection.

Changed Object to `{@code Object}`  but changed "PermissionCollection's" to just "collection's".

> src/java.base/share/classes/java/security/Permissions.java line 64:
> 
>> 62:  * PermissionCollection that uses a hashtable will be created and used. Each
>> 63:  * hashtable entry stores a Permission object as both the key and the value.
>> 64:  *
> 
> Multiple Permission and PermissionCollection.

Fixed.

> src/java.base/share/classes/java/security/Permissions.java line 100:
> 
>> 98:     /**
>> 99:      * Creates a new {@code Permissions} object containing no
>> 100:      * PermissionCollections.
> 
> PermissionCollections.

changed to `{@code PermissionCollection}` objects

> src/java.base/share/classes/java/security/Permissions.java line 117:
> 
>> 115:      * if an appropriate collection does not yet exist.
>> 116:      *
>> 117:      * @param permission the Permission object to add.
> 
> Permission on L117, PermissionCollection on L108 and L114. FilePermission and FilePermissionCollection on Line 110.

Fixed.

> src/java.base/share/classes/java/security/Permissions.java line 154:
> 
>> 152:      * specifies "read" access for  all files in all subdirectories of the
>> 153:      * "/tmp" directory, and another FilePermission that specifies "write"
>> 154:      * access for all files in the "/tmp/scratch/foo" directory.
> 
> FilePermissionCollection and FIlePermission (twice) above.

Fixed.

> src/java.base/share/classes/java/security/Permissions.java line 188:
> 
>> 186:     /**
>> 187:      * Returns an enumeration of all the Permission objects in all the
>> 188:      * PermissionCollections in this {@code Permissions} object.
> 
> Permission and PermissionCollection.

Fixed.

> src/java.base/share/classes/java/security/Permissions.java line 190:
> 
>> 188:      * PermissionCollections in this {@code Permissions} object.
>> 189:      *
>> 190:      * @return an enumeration of all the Permissions.
> 
> Permissions. This one need to be taken care of because it's about permission objects inside, not Permissions as in this class name.

@return an enumeration of all the `{@code Permission}` objects.

> src/java.base/share/classes/java/security/Permissions.java line 205:
> 
>> 203:      * For example, if <i>p</i> is a FilePermission,
>> 204:      * the FilePermissionCollection
>> 205:      * stored in this {@code Permissions} object will be returned.
> 
> PermissionCollection, FilePermission, FilePermissionCollection.

Fixed.

> src/java.base/share/classes/java/security/Permissions.java line 208:
> 
>> 206:      *
>> 207:      * If createEmpty is true,
>> 208:      * this method creates a new PermissionCollection object for the specified
> 
> createEmpty and PermissionCollection.

Fixed.

> src/java.base/share/classes/java/security/Permissions.java line 220:
> 
>> 218:      * createEmpty is true, then
>> 219:      * this method instantiates and stores a default PermissionCollection
>> 220:      * that uses a hashtable to store its permission objects.
> 
> PermissionCollection on L216 and 219.

Fixed.

> src/java.base/share/classes/java/security/Policy.java line 50:
> 
>> 48:  * {@code getPolicy} installs an instance of the default Policy
>> 49:  * implementation (a default subclass implementation of this abstract class).
>> 50:  * The default Policy implementation can be changed by setting the value
> 
> Policy.

Fixed.

> src/java.base/share/classes/java/security/Policy.java line 371:
> 
>> 369:      * A new {@code Policy} object encapsulating the
>> 370:      * {@code PolicySpi} implementation from the first
>> 371:      * Provider that supports the specified type is returned.
> 
> "Provider" to "provider", L368 and L371.

Fixed.

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

PR: https://git.openjdk.org/jdk/pull/9282

From weijun at openjdk.org  Fri Jul  1 20:15:46 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 1 Jul 2022 20:15:46 GMT
Subject: RFR: 8170762: Remove randomness from ISO10126Padding
In-Reply-To: <dPKTNX-lsIvodW1hMjVLpbQi23gAEIoQJi-7BkBV6eA=.492057c4-c77f-4bcf-a81b-9a22baad02ae@github.com>
References: <dPKTNX-lsIvodW1hMjVLpbQi23gAEIoQJi-7BkBV6eA=.492057c4-c77f-4bcf-a81b-9a22baad02ae@github.com>
Message-ID: <vwE2SXmybP4E2wb9oXgzzYlLBHRFW_3z6uHCrYPO8aI=.ae58442a-725b-4e10-ad85-a60798c9e4a6@github.com>

On Fri, 1 Jul 2022 19:17:34 GMT, Kevin Driver <duke at openjdk.org> wrote:

> JDK-8170762 - update Javadoc to indicate ISO10126Padding pads with random bytes, though the spec does not require random bytes

Bug reporter says "document it in the SunJCE documentation". I am not sure what "SunJCE documentation" is, but the file updated here is an internal class and not a part of any documentation. The best suggestion I can make is adding a footnote to the padding name in Table 4-16 in https://docs.oracle.com/en/java/javase/18/security/oracle-providers.html.

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

PR: https://git.openjdk.org/jdk/pull/9350

From weijun at openjdk.org  Fri Jul  1 20:19:39 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 1 Jul 2022 20:19:39 GMT
Subject: RFR: 8170762: Remove randomness from ISO10126Padding
In-Reply-To: <dPKTNX-lsIvodW1hMjVLpbQi23gAEIoQJi-7BkBV6eA=.492057c4-c77f-4bcf-a81b-9a22baad02ae@github.com>
References: <dPKTNX-lsIvodW1hMjVLpbQi23gAEIoQJi-7BkBV6eA=.492057c4-c77f-4bcf-a81b-9a22baad02ae@github.com>
Message-ID: <owmEUFu7ODXGqze1dGYF8BaQ4zHmoBj5yrEW6uIrzdw=.742f84c2-0639-4593-b2a3-f048be26b2fc@github.com>

On Fri, 1 Jul 2022 19:17:34 GMT, Kevin Driver <duke at openjdk.org> wrote:

> JDK-8170762 - update Javadoc to indicate ISO10126Padding pads with random bytes, though the spec does not require random bytes

Also, the bug title does not match code change. Randomness is not removed, it's documented.

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

PR: https://git.openjdk.org/jdk/pull/9350

From duke at openjdk.org  Fri Jul  1 20:50:37 2022
From: duke at openjdk.org (Kevin Driver)
Date: Fri, 1 Jul 2022 20:50:37 GMT
Subject: RFR: 8170762: Remove randomness from ISO10126Padding
In-Reply-To: <owmEUFu7ODXGqze1dGYF8BaQ4zHmoBj5yrEW6uIrzdw=.742f84c2-0639-4593-b2a3-f048be26b2fc@github.com>
References: <dPKTNX-lsIvodW1hMjVLpbQi23gAEIoQJi-7BkBV6eA=.492057c4-c77f-4bcf-a81b-9a22baad02ae@github.com>
 <owmEUFu7ODXGqze1dGYF8BaQ4zHmoBj5yrEW6uIrzdw=.742f84c2-0639-4593-b2a3-f048be26b2fc@github.com>
Message-ID: <9gQeKGTcV6CRYiL7IiO9pobkbIycdBYDIAlCoER2_-Q=.f6462326-c220-42a9-a687-04403a40c0e0@github.com>

On Fri, 1 Jul 2022 20:15:57 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> JDK-8170762 - update Javadoc to indicate ISO10126Padding pads with random bytes, though the spec does not require random bytes
>
> Also, the bug title does not match code change. Randomness is not removed, it's documented.

@wangweij - thanks for clarifying! I was wondering about both of these items.

Maybe you can point me in the right direction for updating the documentation link you provided? Is it available in the open? 

WRT the bug, should I just change the title of the bug, or what do you suggest?

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

PR: https://git.openjdk.org/jdk/pull/9350

From weijun at openjdk.org  Fri Jul  1 21:12:29 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 1 Jul 2022 21:12:29 GMT
Subject: RFR: 8170762: Document that ISO10126Padding pads with random bytes
In-Reply-To: <dPKTNX-lsIvodW1hMjVLpbQi23gAEIoQJi-7BkBV6eA=.492057c4-c77f-4bcf-a81b-9a22baad02ae@github.com>
References: <dPKTNX-lsIvodW1hMjVLpbQi23gAEIoQJi-7BkBV6eA=.492057c4-c77f-4bcf-a81b-9a22baad02ae@github.com>
Message-ID: <GpF8IFTPNdwWckIJm39o4fKV6QdJk536rT3wnTf6jt4=.bc350fe3-8941-4f54-995b-5892f7f305fc@github.com>

On Fri, 1 Jul 2022 19:17:34 GMT, Kevin Driver <duke at openjdk.org> wrote:

> JDK-8170762 - update Javadoc to indicate ISO10126Padding pads with random bytes, though the spec does not require random bytes

Approved. File another docs bug to update the doc.

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

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9350

From duke at openjdk.org  Fri Jul  1 21:18:38 2022
From: duke at openjdk.org (Kevin Driver)
Date: Fri, 1 Jul 2022 21:18:38 GMT
Subject: RFR: 8170762: Document that ISO10126Padding pads with random bytes
In-Reply-To: <dPKTNX-lsIvodW1hMjVLpbQi23gAEIoQJi-7BkBV6eA=.492057c4-c77f-4bcf-a81b-9a22baad02ae@github.com>
References: <dPKTNX-lsIvodW1hMjVLpbQi23gAEIoQJi-7BkBV6eA=.492057c4-c77f-4bcf-a81b-9a22baad02ae@github.com>
Message-ID: <CReSFv1mrf3ZTaG9Wm9CPjPMkTtdj0tHoL7RsZ0aobs=.f028bef2-c8b7-4b00-8ffe-620ffe3eb1e4@github.com>

On Fri, 1 Jul 2022 19:17:34 GMT, Kevin Driver <duke at openjdk.org> wrote:

> JDK-8170762 - update Javadoc to indicate ISO10126Padding pads with random bytes, though the spec does not require random bytes

Filed: https://bugs.openjdk.org/browse/JDK-8289602

> Approved. File another docs bug to update the doc.

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

PR: https://git.openjdk.org/jdk/pull/9350

From xuelei at openjdk.org  Fri Jul  1 21:26:55 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 1 Jul 2022 21:26:55 GMT
Subject: RFR: 8287596: Reorg jdk.test.lib.util.ForceGC [v12]
In-Reply-To: <b4TKicu5_3MfmCROD1LXua5Rc4_ruqQ5jDtsjcipjrQ=.08522aaa-9f17-4be7-81ef-af6d9162ef4b@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
 <C4WxQo62GwvZzNa0fb4nlVxi081-H7b_jB4XRIeitLg=.3fdeec94-f7a8-43b6-88a2-29250b4dcd29@github.com>
 <b4TKicu5_3MfmCROD1LXua5Rc4_ruqQ5jDtsjcipjrQ=.08522aaa-9f17-4be7-81ef-af6d9162ef4b@github.com>
Message-ID: <Jp-RdSJhW-NUI1fpj-xCbwW42ObiSgDkX03J-ZRZYEs=.9a8e6926-e49b-4319-85ed-af1a143afe3d@github.com>

On Fri, 1 Jul 2022 14:45:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Does this address JDK-8288286 and allow ReflectionCallerCacheTest.java to be removed from ProblemList-Xcomp.txt?

I think JDK-8288286 should be addressed, but I would like to have it further evaluated via more Mach5 testing before remove the case from problem list.

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

PR: https://git.openjdk.org/jdk/pull/8979

From duke at openjdk.org  Fri Jul  1 21:32:30 2022
From: duke at openjdk.org (Kevin Driver)
Date: Fri, 1 Jul 2022 21:32:30 GMT
Subject: Integrated: 8170762: Document that ISO10126Padding pads with random
 bytes
In-Reply-To: <dPKTNX-lsIvodW1hMjVLpbQi23gAEIoQJi-7BkBV6eA=.492057c4-c77f-4bcf-a81b-9a22baad02ae@github.com>
References: <dPKTNX-lsIvodW1hMjVLpbQi23gAEIoQJi-7BkBV6eA=.492057c4-c77f-4bcf-a81b-9a22baad02ae@github.com>
Message-ID: <xYXYE10gw7iT7Q0NDSr7cxDLg_X-WajEW3D2nFiWQ18=.89be4ddc-d300-44c1-8007-abf14a662c0d@github.com>

On Fri, 1 Jul 2022 19:17:34 GMT, Kevin Driver <duke at openjdk.org> wrote:

> JDK-8170762 - update Javadoc to indicate ISO10126Padding pads with random bytes, though the spec does not require random bytes

This pull request has now been integrated.

Changeset: 2dd00f58
Author:    Kevin Driver <kevin.driver at oracle.com>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2dd00f580c1c5999a4905ade09bc50a5cb37ca57
Stats:     6 lines in 1 file changed: 3 ins; 2 del; 1 mod

8170762: Document that ISO10126Padding pads with random bytes

Reviewed-by: weijun

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

PR: https://git.openjdk.org/jdk/pull/9350

From duke at openjdk.org  Fri Jul  1 22:08:13 2022
From: duke at openjdk.org (Kevin Driver)
Date: Fri, 1 Jul 2022 22:08:13 GMT
Subject: Integrated: 8289603: Code change for JDK-8170762 breaks all build
Message-ID: <sRuw5PwbByP3hy1EfCOBB4kcM0tsv25rSf9iYWvv6L8=.d4f538fe-a4ba-422b-a9a4-3d21a48c8772@github.com>

Fix build break from JDK-8170762

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

Commit messages:
 - change copyright dates

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

PR: https://git.openjdk.org/jdk/pull/9352

From weijun at openjdk.org  Fri Jul  1 22:08:13 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 1 Jul 2022 22:08:13 GMT
Subject: Integrated: 8289603: Code change for JDK-8170762 breaks all build
In-Reply-To: <sRuw5PwbByP3hy1EfCOBB4kcM0tsv25rSf9iYWvv6L8=.d4f538fe-a4ba-422b-a9a4-3d21a48c8772@github.com>
References: <sRuw5PwbByP3hy1EfCOBB4kcM0tsv25rSf9iYWvv6L8=.d4f538fe-a4ba-422b-a9a4-3d21a48c8772@github.com>
Message-ID: <7x55ffr2tBz9ho385ySZERdS7PzZmV007_hTdGHARHw=.8347b50c-54b4-4f33-a6bf-41c6a8d08890@github.com>

On Fri, 1 Jul 2022 21:47:37 GMT, Kevin Driver <duke at openjdk.org> wrote:

> Fix build break from JDK-8170762

LGTM.

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

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9352

From duke at openjdk.org  Fri Jul  1 22:08:13 2022
From: duke at openjdk.org (Kevin Driver)
Date: Fri, 1 Jul 2022 22:08:13 GMT
Subject: Integrated: 8289603: Code change for JDK-8170762 breaks all build
In-Reply-To: <sRuw5PwbByP3hy1EfCOBB4kcM0tsv25rSf9iYWvv6L8=.d4f538fe-a4ba-422b-a9a4-3d21a48c8772@github.com>
References: <sRuw5PwbByP3hy1EfCOBB4kcM0tsv25rSf9iYWvv6L8=.d4f538fe-a4ba-422b-a9a4-3d21a48c8772@github.com>
Message-ID: <ucSmImNfBZ4UevYCbe27rGdB05qS7MLDkvGULzmhIiU=.ee6a32d0-e81e-4611-bf6d-9fbb8beaf087@github.com>

On Fri, 1 Jul 2022 21:47:37 GMT, Kevin Driver <duke at openjdk.org> wrote:

> Fix build break from JDK-8170762

This pull request has now been integrated.

Changeset: 44e8c462
Author:    Kevin Driver <kevin.driver at oracle.com>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/44e8c462b459a7db530dbc23c5ba923439c419b4
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8289603: Code change for JDK-8170762 breaks all build

Reviewed-by: weijun

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

PR: https://git.openjdk.org/jdk/pull/9352

From wetmore at openjdk.org  Fri Jul  1 23:43:40 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 1 Jul 2022 23:43:40 GMT
Subject: RFR: 8170762: Document that ISO10126Padding pads with random bytes
In-Reply-To: <dPKTNX-lsIvodW1hMjVLpbQi23gAEIoQJi-7BkBV6eA=.492057c4-c77f-4bcf-a81b-9a22baad02ae@github.com>
References: <dPKTNX-lsIvodW1hMjVLpbQi23gAEIoQJi-7BkBV6eA=.492057c4-c77f-4bcf-a81b-9a22baad02ae@github.com>
Message-ID: <BTN39FByxvwC1IfUSEEJLkJs7g83-1FeLwtgkfCZx9E=.c5c13eb6-04ca-4880-bd05-457695e0a22a@github.com>

On Fri, 1 Jul 2022 19:17:34 GMT, Kevin Driver <duke at openjdk.org> wrote:

> JDK-8170762 - update Javadoc to indicate ISO10126Padding pads with random bytes, though the spec does not require random bytes

Just a comment, I believe both approaches are ok.  The ISO 10126 spec says:

> When padding with octets...the first subfield (pad fill) shall consist
> of 0 to 7 octets with arbitrary contents. 

Adam's original comment was that because the spec says "arbitrary data," we could potentially just optimize the code a small bit by not having to fill with random data, and rather just leave as an uninitialized field.  But using random data to get some arbitrary data it is possibly a little safer since it will perturb the output a bit vs. an all zero padding.

So, fine to leave has been fixed.  However, I do have further comments on the doc bug.

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

PR: https://git.openjdk.org/jdk/pull/9350

From duke at openjdk.org  Fri Jul  1 23:46:24 2022
From: duke at openjdk.org (Mark Powers)
Date: Fri, 1 Jul 2022 23:46:24 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <MOaYWQkCI1aQWZf8-X6hc2HqbKDnB1MkFzCk7JeGBUM=.502f8687-efe2-49b1-b461-76571d67bebc@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
 <MOaYWQkCI1aQWZf8-X6hc2HqbKDnB1MkFzCk7JeGBUM=.502f8687-efe2-49b1-b461-76571d67bebc@github.com>
Message-ID: <CW8HfYTz-EQKj6XyClYjHbnD2eC5o2GmsuvMD_6nljc=.256ccec8-c63e-4651-b922-e5090c22120e@github.com>

On Tue, 28 Jun 2022 20:58:17 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Valerie fix
>
> src/java.base/share/classes/java/security/Policy.java line 505:
> 
>> 503:      * <p> A new {@code Policy} object encapsulating the
>> 504:      * {@code PolicySpi} implementation from the specified Provider
>> 505:      * object is returned.  Note that the specified Provider object
> 
> Provider, twice.

Changed to "provider".

> src/java.base/share/classes/java/security/Policy.java line 517:
> 
>> 515:      * {@code null}.
>> 516:      *
>> 517:      * @param provider the Provider.
> 
> Provider.

used `{@code Provider}`

> src/java.base/share/classes/java/security/Policy.java line 581:
> 
>> 579:      * Otherwise this method returns {@code null}.
>> 580:      *
>> 581:      * @return the Provider of this Policy, or {@code null}.
> 
> Provider, L575/577/581. Maybe "provider". Or wrap in code.

Fixed.

> src/java.base/share/classes/java/security/Policy.java line 596:
> 
>> 594:      * Otherwise this method returns {@code null}.
>> 595:      *
>> 596:      * @return the type of this Policy, or {@code null}.
> 
> Policy, L590/596.

Fixed.

> src/java.base/share/classes/java/security/Policy.java line 611:
> 
>> 609:      * Otherwise this method returns {@code null}.
>> 610:      *
>> 611:      * @return Policy parameters, or {@code null}.
> 
> Policy, L605/611.

used `{@code Policy}`

> src/java.base/share/classes/java/security/ProtectionDomain.java line 53:
> 
>> 51:  * policies, a {@code ProtectionDomain} can also be constructed such that it
>> 52:  * is dynamically mapped to a set of permissions by the current Policy whenever
>> 53:  * a permission is checked.
> 
> Policy, L50/52.

used "policy"

> src/java.base/share/classes/java/security/ProtectionDomain.java line 166:
> 
>> 164:      * Permissions object.
>> 165:      * <p>
>> 166:      * The permissions granted to this domain are static, i.e.
> 
> CodeSource, Permissions. Note it's PermissionCollection here. So maybe use "permissions".

used "permissions"

> src/java.base/share/classes/java/security/ProtectionDomain.java line 192:
> 
>> 190:     /**
>> 191:      * Creates a new {@code ProtectionDomain} qualified by the given CodeSource,
>> 192:      * Permissions, ClassLoader and array of Principals. If the
> 
> Same as above, plus ClassLoader and Principal.

Fixed.

> src/java.base/share/classes/java/security/ProtectionDomain.java line 241:
> 
>> 239:     /**
>> 240:      * Returns the CodeSource of this domain.
>> 241:      * @return the CodeSource of this domain which may be {@code null}.
> 
> CodeSource.

used `{@code Codesource}`

> src/java.base/share/classes/java/security/ProtectionDomain.java line 251:
> 
>> 249:     /**
>> 250:      * Returns the ClassLoader of this domain.
>> 251:      * @return the ClassLoader of this domain which may be {@code null}.
> 
> ClassLoader.

used `{@code ClassLoader}`

> src/java.base/share/classes/java/security/ProtectionDomain.java line 298:
> 
>> 296:     /**
>> 297:      * Check and see if this {@code ProtectionDomain} implies the permissions
>> 298:      * expressed in the Permission object.
> 
> Permission.

used `{@code Permission}`

> src/java.base/share/classes/java/security/ProtectionDomain.java line 458:
> 
>> 456:      *          debug is {@code null},
>> 457:      *          caller has Policy.getPolicy permission
>> 458:      */
> 
> Maybe it's not necessary to fix these non-public API cases.

IntelliJ will certainly generate javadoc for non-public cases.

> src/java.base/share/classes/java/security/ProviderException.java line 52:
> 
>> 50: 
>> 51:     /**
>> 52:      * Constructs a {@code ProviderException} with the specified detail
> 
> String, L43/53. I'm now wondering if we need to describe what detail message means at all.

I'm going to keep `{@code String} `since I don't want to go back and change all occurrences in all files. Documentation changes are too subjective and destroy the brain.

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

PR: https://git.openjdk.org/jdk/pull/9282

From duke at openjdk.org  Fri Jul  1 23:59:02 2022
From: duke at openjdk.org (Mark Powers)
Date: Fri, 1 Jul 2022 23:59:02 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v5]
In-Reply-To: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
Message-ID: <NwYQb6RnPv89OZAAR7vfy0Ttw-UDLyVICatQ56RBet8=.9e81691c-2d77-4a66-a773-1c4ae0b0f636@github.com>

> https://bugs.openjdk.org/browse/JDK-8284851

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

  Max comments continued

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9282/files
  - new: https://git.openjdk.org/jdk/pull/9282/files/e21432f5..cd71b62b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9282&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9282&range=03-04

  Stats: 299 lines in 15 files changed: 20 ins; 2 del; 277 mod
  Patch: https://git.openjdk.org/jdk/pull/9282.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9282/head:pull/9282

PR: https://git.openjdk.org/jdk/pull/9282

From iveresov at openjdk.org  Sat Jul  2 01:13:01 2022
From: iveresov at openjdk.org (Igor Veresov)
Date: Sat, 2 Jul 2022 01:13:01 GMT
Subject: [jdk19] RFR: 8245268: -Xcomp is missing from java launcher
 documentation
Message-ID: <FVqMF2apRSRhYmOkhnI2ut8b6iz1BXA1meOfNzU5HQY=.f21b7123-395b-467d-9da0-154102f04398@github.com>

Updated man pages from markdown sources.

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

Commit messages:
 - Update man pages

Changes: https://git.openjdk.org/jdk19/pull/103/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=103&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8245268
  Stats: 495 lines in 8 files changed: 437 ins; 16 del; 42 mod
  Patch: https://git.openjdk.org/jdk19/pull/103.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/103/head:pull/103

PR: https://git.openjdk.org/jdk19/pull/103

From jwaters at openjdk.org  Sat Jul  2 02:14:30 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 2 Jul 2022 02:14:30 GMT
Subject: Withdrawn: 8289275: Remove incorrect __declspec(dllimport) attributes
 from pointers in jdk.crypto.cryptoki
In-Reply-To: <x3k19aEcTApm1U-SKpcROrzW0qN0xTLIlY-r31jrV8c=.875dc878-323f-433b-ba91-7bbcd83f317b@github.com>
References: <x3k19aEcTApm1U-SKpcROrzW0qN0xTLIlY-r31jrV8c=.875dc878-323f-433b-ba91-7bbcd83f317b@github.com>
Message-ID: <H2GEVTA3tNX_txn_73bxKTpGnRG2HbJ9Qu54bSB6wyY=.5799356b-6912-4e71-9a45-2b1d82e6e832@github.com>

On Tue, 28 Jun 2022 07:12:07 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Several instances of function pointers in jdk.crypto.cryptoki are marked with the dllimport attribute, which should only be applied to symbol declarations, of which a typedef'd function pointer is not. This would only be useful if a function pointer defined in the linked dll is desired to be imported, not if the pointer itself is created locally and used to store a function address. In addition to being incorrect, at least on the versions of Visual C++ the JDK supports today, it is also redundant; Typically they are used to avoid an indirect stub that jumps to the proper entry in the import address table, but usage of these typedefs involves loading the address of a function and directly (Usually through GetProcAddress, even in other cases it would simply be set to the address of a function anyway) assigning it to the pointer before immediately dispatching when called, which bypasses this procedure entirely and makes the attribute pointless.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/9304

From kvn at openjdk.org  Sat Jul  2 02:15:46 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 2 Jul 2022 02:15:46 GMT
Subject: [jdk19] RFR: 8245268: -Xcomp is missing from java launcher
 documentation
In-Reply-To: <FVqMF2apRSRhYmOkhnI2ut8b6iz1BXA1meOfNzU5HQY=.f21b7123-395b-467d-9da0-154102f04398@github.com>
References: <FVqMF2apRSRhYmOkhnI2ut8b6iz1BXA1meOfNzU5HQY=.f21b7123-395b-467d-9da0-154102f04398@github.com>
Message-ID: <GTDdFln5SLvJgul7efyPR3N21byQWhR7frfN4T0J6sY=.5718188f-cf95-40cf-9675-786342527de5@github.com>

On Sat, 2 Jul 2022 01:04:19 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> Updated man pages from markdown sources.

I am not sure some words changes are correct?

May be we should cleanup and update all these man pages as separate issue. And apply only `-Xcomp` changes.

@iklam
 you recently pushed changes https://github.com/openjdk/jdk/pull/9024 which included only CDS related update.
Did you discuss this issue during your changes review?

src/java.base/share/man/java.1 line 3682:

> 3680: .RS
> 3681: .PP
> 3682: The following examples show how to set the mimimum size of allocated

`mimimum`?

src/java.base/share/man/java.1 line 5367:

> 5365: \f[CB];\f[R]
> 5366: .PP
> 5367: (The names "static" and "dyanmic" are used for historical reasons.

`dyanmic` ?

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

PR: https://git.openjdk.org/jdk19/pull/103

From jwaters at openjdk.org  Sat Jul  2 02:21:09 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 2 Jul 2022 02:21:09 GMT
Subject: RFR: 8289275: Remove incorrect __declspec(dllimport) attributes from
 pointers in jdk.crypto.cryptoki
Message-ID: <yM6fqtQfhPvlMnxnqJbc1H-A3SJ0f6n4ee2zgGCmD7M=.d388accc-1210-40e7-8ae6-11118cec5156@github.com>

Several instances of function pointers in jdk.crypto.cryptoki are marked with the dllimport attribute, which should only be applied to symbol declarations, of which a typedef'd function pointer is not. This would only be useful if a function pointer defined in the linked dll is desired to be imported, not if the pointer itself is created locally and used to store a function address. In addition to being incorrect, at least on the versions of Visual C++ the JDK supports today, it is also redundant; Typically they are used to avoid an indirect stub that jumps to the proper entry in the import address table, but usage of these typedefs involves loading the address of a function and directly (Usually through GetProcAddress, even in other cases it would simply be set to the address of a function anyway) assigning it to the pointer before immediately dispatching when called, which bypasses this procedure entirely and makes the attribute pointless.

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

Commit messages:
 - Remove __declspec(dllimport) from pointers

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

PR: https://git.openjdk.org/jdk/pull/9353

From iveresov at openjdk.org  Sat Jul  2 02:48:48 2022
From: iveresov at openjdk.org (Igor Veresov)
Date: Sat, 2 Jul 2022 02:48:48 GMT
Subject: [jdk19] RFR: 8245268: -Xcomp is missing from java launcher
 documentation
In-Reply-To: <FVqMF2apRSRhYmOkhnI2ut8b6iz1BXA1meOfNzU5HQY=.f21b7123-395b-467d-9da0-154102f04398@github.com>
References: <FVqMF2apRSRhYmOkhnI2ut8b6iz1BXA1meOfNzU5HQY=.f21b7123-395b-467d-9da0-154102f04398@github.com>
Message-ID: <3n97bQQ4ib9ogDH_nIP-ivvywhufhTnQR49_SjlHmF4=.f0e23271-724e-404f-80fa-304ba27258a9@github.com>

On Sat, 2 Jul 2022 01:04:19 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> Updated man pages from markdown sources.

There is also a question of which version is actually correct. Yeah, may be I should manually craft a patch just for the Xcomp part.

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

PR: https://git.openjdk.org/jdk19/pull/103

From iveresov at openjdk.org  Sat Jul  2 02:48:47 2022
From: iveresov at openjdk.org (Igor Veresov)
Date: Sat, 2 Jul 2022 02:48:47 GMT
Subject: [jdk19] RFR: 8245268: -Xcomp is missing from java launcher
 documentation
In-Reply-To: <GTDdFln5SLvJgul7efyPR3N21byQWhR7frfN4T0J6sY=.5718188f-cf95-40cf-9675-786342527de5@github.com>
References: <FVqMF2apRSRhYmOkhnI2ut8b6iz1BXA1meOfNzU5HQY=.f21b7123-395b-467d-9da0-154102f04398@github.com>
 <GTDdFln5SLvJgul7efyPR3N21byQWhR7frfN4T0J6sY=.5718188f-cf95-40cf-9675-786342527de5@github.com>
Message-ID: <V-SVt46nBKakekIk5Csju-hajRpTKc0QkpgN_iDuk9g=.cb88ce06-3ade-4f03-8c98-35a3712778a7@github.com>

On Sat, 2 Jul 2022 02:12:43 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I am not sure some words changes are correct?
> 
> May be we should cleanup and update all these man pages as separate issue. And apply only `-Xcomp` changes.
> 

Then I'd have to manually craft a patch instead of actually generating them. It seems like it's all been out of sync for a long time.

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

PR: https://git.openjdk.org/jdk19/pull/103

From iklam at openjdk.org  Sat Jul  2 03:32:26 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 2 Jul 2022 03:32:26 GMT
Subject: [jdk19] RFR: 8245268: -Xcomp is missing from java launcher
 documentation
In-Reply-To: <3n97bQQ4ib9ogDH_nIP-ivvywhufhTnQR49_SjlHmF4=.f0e23271-724e-404f-80fa-304ba27258a9@github.com>
References: <FVqMF2apRSRhYmOkhnI2ut8b6iz1BXA1meOfNzU5HQY=.f21b7123-395b-467d-9da0-154102f04398@github.com>
 <3n97bQQ4ib9ogDH_nIP-ivvywhufhTnQR49_SjlHmF4=.f0e23271-724e-404f-80fa-304ba27258a9@github.com>
Message-ID: <WweobGTMI6puAW9cxCBHPbieCg3haM9wLj8SWOQfCJQ=.5aa6943f-f5cf-481c-989c-84d9ae2a85a7@github.com>

On Sat, 2 Jul 2022 02:45:43 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> There is also a question of which version is actually correct. Yeah, may be I should manually craft a patch just for the Xcomp part.

@veresov  please see the closed issue https://bugs.openjdk.org/browse/JDK-8287821

@vnkozlov when I did https://github.com/openjdk/jdk/pull/9024, I generated `java.1` from the `java.md` file. I then use the `meld` program on Linux to revert all changes in the `java.1` file that were unrelated to my changes in `java.md`. Yes, it was a pain.

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

PR: https://git.openjdk.org/jdk19/pull/103

From iveresov at openjdk.org  Sat Jul  2 03:48:27 2022
From: iveresov at openjdk.org (Igor Veresov)
Date: Sat, 2 Jul 2022 03:48:27 GMT
Subject: [jdk19] RFR: 8245268: -Xcomp is missing from java launcher
 documentation [v2]
In-Reply-To: <FVqMF2apRSRhYmOkhnI2ut8b6iz1BXA1meOfNzU5HQY=.f21b7123-395b-467d-9da0-154102f04398@github.com>
References: <FVqMF2apRSRhYmOkhnI2ut8b6iz1BXA1meOfNzU5HQY=.f21b7123-395b-467d-9da0-154102f04398@github.com>
Message-ID: <NCiOFzyET1RX2BY45y_L87Q5JLBwK16Asd9PVw71y2Y=.901afc8c-3c37-4565-9df8-1df67e679e91@github.com>

> Updated man pages from markdown sources.

Igor Veresov 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:

  Update java manpage

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/103/files
  - new: https://git.openjdk.org/jdk19/pull/103/files/37da94df..f3526e7b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk19&pr=103&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=103&range=00-01

  Stats: 485 lines in 8 files changed: 12 ins; 427 del; 46 mod
  Patch: https://git.openjdk.org/jdk19/pull/103.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/103/head:pull/103

PR: https://git.openjdk.org/jdk19/pull/103

From iveresov at openjdk.org  Sat Jul  2 03:48:27 2022
From: iveresov at openjdk.org (Igor Veresov)
Date: Sat, 2 Jul 2022 03:48:27 GMT
Subject: [jdk19] RFR: 8245268: -Xcomp is missing from java launcher
 documentation
In-Reply-To: <FVqMF2apRSRhYmOkhnI2ut8b6iz1BXA1meOfNzU5HQY=.f21b7123-395b-467d-9da0-154102f04398@github.com>
References: <FVqMF2apRSRhYmOkhnI2ut8b6iz1BXA1meOfNzU5HQY=.f21b7123-395b-467d-9da0-154102f04398@github.com>
Message-ID: <Fp5RB0VOEqsq8oNwxkvU-glRi49RN5Cv3muYPCExG9o=.8470a733-d97e-4db2-8457-26732abdefdf@github.com>

On Sat, 2 Jul 2022 01:04:19 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> Updated man pages from markdown sources.

Ok, I just hacked a patch file.

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

PR: https://git.openjdk.org/jdk19/pull/103

From weijun at openjdk.org  Sat Jul  2 17:03:07 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 2 Jul 2022 17:03:07 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <D_92dd8EslODxZ0XLu3Yi5sRrcdzJYQuISAqbwo0v_Q=.fb26cbb7-1fdf-4401-9dd9-6c9f3eabf309@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
 <MOaYWQkCI1aQWZf8-X6hc2HqbKDnB1MkFzCk7JeGBUM=.502f8687-efe2-49b1-b461-76571d67bebc@github.com>
 <D_92dd8EslODxZ0XLu3Yi5sRrcdzJYQuISAqbwo0v_Q=.fb26cbb7-1fdf-4401-9dd9-6c9f3eabf309@github.com>
Message-ID: <_MukuTUTdI8xmnE8WqZVgqdAwBgXCwShZu_WJNHRatA=.44ca52b0-bf28-4fa7-a675-7fd45e9c099d@github.com>

On Fri, 1 Jul 2022 19:48:59 GMT, Mark Powers <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/AllPermission.java line 201:
>> 
>>> 199:     /**
>>> 200:      * Check and see if this set of permissions implies the permissions
>>> 201:      * expressed in "permission".
>> 
>> "this set of permissions" is not used anywhere. You can copy from the same method from the parent class.
>
> What is the JavaDoc change? Is this a code change?

Ignore it then.

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

PR: https://git.openjdk.org/jdk/pull/9282

From duke at openjdk.org  Sat Jul  2 18:41:59 2022
From: duke at openjdk.org (kristylee88)
Date: Sat, 2 Jul 2022 18:41:59 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v5]
In-Reply-To: <NwYQb6RnPv89OZAAR7vfy0Ttw-UDLyVICatQ56RBet8=.9e81691c-2d77-4a66-a773-1c4ae0b0f636@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <NwYQb6RnPv89OZAAR7vfy0Ttw-UDLyVICatQ56RBet8=.9e81691c-2d77-4a66-a773-1c4ae0b0f636@github.com>
Message-ID: <b0FKLow8pWlX_OVNhCYb60rfSczpGUkZGIF1jQY1h0s=.0d39d5db-6ab8-47bc-aa9f-5e0ac4ee7e84@github.com>

On Fri, 1 Jul 2022 23:59:02 GMT, Mark Powers <duke at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8284851
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Max comments continued

Marked as reviewed by kristylee88 at github.com (no known OpenJDK username).

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

PR: https://git.openjdk.org/jdk/pull/9282

From duke at openjdk.org  Sat Jul  2 18:48:05 2022
From: duke at openjdk.org (kristylee88)
Date: Sat, 2 Jul 2022 18:48:05 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v5]
In-Reply-To: <NwYQb6RnPv89OZAAR7vfy0Ttw-UDLyVICatQ56RBet8=.9e81691c-2d77-4a66-a773-1c4ae0b0f636@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <NwYQb6RnPv89OZAAR7vfy0Ttw-UDLyVICatQ56RBet8=.9e81691c-2d77-4a66-a773-1c4ae0b0f636@github.com>
Message-ID: <uordOZwfXpztQvO9nmrLBnrmiTnfGlJfpavfjBF72Xc=.3cd85ba4-219b-4668-9dd0-8a9e353e2864@github.com>

On Fri, 1 Jul 2022 23:59:02 GMT, Mark Powers <duke at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8284851
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Max comments continued

Marked as reviewed by kristylee88 at github.com (no known OpenJDK username).

Marked as reviewed by kristylee88 at github.com (no known OpenJDK username).

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

PR: https://git.openjdk.org/jdk/pull/9282

From attila at openjdk.org  Sun Jul  3 20:22:29 2022
From: attila at openjdk.org (Attila Szegedi)
Date: Sun, 3 Jul 2022 20:22:29 GMT
Subject: RFR: 8289274: Cleanup unnecessary null comparison before
 instanceof check in security modules
In-Reply-To: <qd5Ewuyi5C8hOlMKMyjD6Ofpyn-B7pGljsDqG8iBRIE=.71fb0398-960e-4681-a184-9eb133e20022@github.com>
References: <qd5Ewuyi5C8hOlMKMyjD6Ofpyn-B7pGljsDqG8iBRIE=.71fb0398-960e-4681-a184-9eb133e20022@github.com>
Message-ID: <r5gI-Ovpso4jY_FtvlkGbyF7V2KQhbADyxMHCycXfpI=.bdeaad7e-dfe8-4e62-a0be-dbc46c45c074@github.com>

On Fri, 24 Jun 2022 18:27:05 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Update code checks both non-null and instance of a class in security classes.
> The checks and explicit casts could also be replaced with pattern matching for the instanceof operator.
> 
> See similar cleanup in java.base - [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422)

Changes requested by attila (Reviewer).

src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1143:

> 1141:         Entry entry = entries.get(alias.toLowerCase(Locale.ENGLISH));
> 1142:         if (entryClass == KeyStore.PrivateKeyEntry.class) {
> 1143:             return (entry instanceof PrivateKeyEntry);

Suggestion:

            return entry instanceof PrivateKeyEntry;

src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1146:

> 1144:         }
> 1145:         if (entryClass == KeyStore.SecretKeyEntry.class) {
> 1146:             return (entry instanceof SecretKeyEntry);

Suggestion:

            return entry instanceof SecretKeyEntry;

src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 491:

> 489:                 break;
> 490:             case "SSLServer":
> 491:                 result = (t instanceof IOException);

Suggestion:

                result = t instanceof IOException;

src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 494:

> 492:                 break;
> 493:             case "URI":
> 494:                 result = (t instanceof IOException);

Suggestion:

                result = t instanceof IOException;

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

PR: https://git.openjdk.org/jdk/pull/9284

From aturbanov at openjdk.org  Mon Jul  4 07:18:05 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 4 Jul 2022 07:18:05 GMT
Subject: RFR: 8289659: Refactor I/O stream copying to use
 InputStream.readAllBytes in X509CertPath
Message-ID: <wj4QPVNRRYV0CDdbtG9UN7H-iFvtDd7Og9araPbw4YY=.b575524d-215c-4026-bdac-57b6e7f4ecdd@github.com>

Use `InputStream.readAllBytes` instead of manually written method.

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

Commit messages:
 - [PATCH] Refactor I/O stream copying to use InputStream.readAllBytes in X509CertPath

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

PR: https://git.openjdk.org/jdk/pull/9263

From attila at openjdk.org  Mon Jul  4 07:18:06 2022
From: attila at openjdk.org (Attila Szegedi)
Date: Mon, 4 Jul 2022 07:18:06 GMT
Subject: RFR: 8289659: Refactor I/O stream copying to use
 InputStream.readAllBytes in X509CertPath
In-Reply-To: <wj4QPVNRRYV0CDdbtG9UN7H-iFvtDd7Og9araPbw4YY=.b575524d-215c-4026-bdac-57b6e7f4ecdd@github.com>
References: <wj4QPVNRRYV0CDdbtG9UN7H-iFvtDd7Og9araPbw4YY=.b575524d-215c-4026-bdac-57b6e7f4ecdd@github.com>
Message-ID: <9lDUy6CUq1lyHGPuXktPOIWwnpZnQS30gxRaythqT7E=.ce8bdc0f-30fb-464c-b5b3-61584e8a9760@github.com>

On Thu, 23 Jun 2022 19:32:44 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Use `InputStream.readAllBytes` instead of manually written method.

Marked as reviewed by attila (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9263

From matthias.baesken at sap.com  Mon Jul  4 07:57:09 2022
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 4 Jul 2022 07:57:09 +0000
Subject: security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java
 failure in jdk20
Message-ID: <AM9PR02MB67709A31F6BFFBD11C81312D93BE9@AM9PR02MB6770.eurprd02.prod.outlook.com>

Hello, after https://bugs.openjdk.org/browse/JDK-8224768   removed the ActalisCA test from the problem list, we see the test failing on all platforms
 when running with JDK20 .

Can someone who runs those tests regularly confirm this ?

Thanks, Matthias

Failure is :
=====================================================
CONFIGURATION
=====================================================
http.proxyHost :null
http.proxyPort :null
https.proxyHost :null
https.proxyPort :null
https.socksProxyHost :null
https.socksProxyPort :null
jdk.certpath.disabledAlgorithms :MD2, MD5, SHA1 jdkCA & usage TLSServer, RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224, SHA1 usage SignedJAR & denyAfter 2019-01-01
Revocation options :[NO_FALLBACK]
OCSP responder set :null
Trusted root set: false
Expected EE Status:GOOD
=====================================================
Successful CertPath validation
Expected Certificate status: GOOD
Certificate status after validation: GOOD

=====================================================
CONFIGURATION
=====================================================
http.proxyHost :null
http.proxyPort :null
https.proxyHost :null
https.proxyPort :null
https.socksProxyHost :null
https.socksProxyPort :null
jdk.certpath.disabledAlgorithms :MD2, MD5, SHA1 jdkCA & usage TLSServer, RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224, SHA1 usage SignedJAR & denyAfter 2019-01-01
Revocation options :[NO_FALLBACK]
OCSP responder set :null
Trusted root set: false
Validation Date:Wed Jun 01 00:00:00 CEST 2022
Expected EE Status:REVOKED
Expected EE Revocation Date:Mon Mar 07 15:11:11 CET 2022
=====================================================
Received exception: java.security.cert.CertPathValidatorException: Certificate has been revoked, reason: CESSATION_OF_OPERATION, revocation date: Mon Mar 07 15:11:11 CET 2022, authority: CN=Actalis Organization Validated Server CA G3 - OCSP Responder, O=Actalis S.p.A., L=Ponte San Pietro, ST=Bergamo, C=IT, extension OIDs: []
Expected Certificate status: REVOKED
Certificate status after validation: REVOKED
Certificate revocation date:Mon Mar 07 15:11:11 CET 2022
Expected revocation date:Mon Mar 07 15:11:11 CET 2022
--------------------------------

=====================================================
CONFIGURATION
=====================================================
http.proxyHost :null
http.proxyPort :null
https.proxyHost :null
https.proxyPort :null
https.socksProxyHost :null
https.socksProxyPort :null
jdk.certpath.disabledAlgorithms :MD2, MD5, SHA1 jdkCA & usage TLSServer, RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224, SHA1 usage SignedJAR & denyAfter 2019-01-01
Revocation options :[NO_FALLBACK, PREFER_CRLS]
OCSP responder set :null
Trusted root set: false
Expected EE Status:GOOD
=====================================================
Received exception: java.security.cert.CertPathValidatorException: sun.security.provider.certpath.PKIX$CertStoreTypeException: Invalid name: cn=Actalis Authentication Root CA,o=Actalis S.p.A./03358520967,c=IT
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220704/6780702f/attachment-0001.htm>

From duke at openjdk.org  Mon Jul  4 14:22:42 2022
From: duke at openjdk.org (zzambers)
Date: Mon, 4 Jul 2022 14:22:42 GMT
Subject: RFR: 8289301: P11Cipher should not throw out of bounds exception
 during padding [v3]
In-Reply-To: <3JHTrgtISq3EoVHE0JI_5ZHT-8TaLC8GB9bTyXGaPEI=.09128ed2-6b77-4aa4-bd4e-ca1594ec4371@github.com>
References: <3JHTrgtISq3EoVHE0JI_5ZHT-8TaLC8GB9bTyXGaPEI=.09128ed2-6b77-4aa4-bd4e-ca1594ec4371@github.com>
Message-ID: <59vZZzDpqvTVmUvBL0PH4075kou0rKX2rqZE26aRcds=.738f5f6d-8cbf-4496-bbdd-9226396251c2@github.com>

> SunPkcs11 provider throws out of bounds exception during encryption when specific conditions are met.
> 
> Exception:
> 
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 32
> 	at java.base/java.util.Arrays.rangeCheck(Arrays.java:725)
> 	at java.base/java.util.Arrays.fill(Arrays.java:3308)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher$PKCS5Padding.setPaddingBytes(P11Cipher.java:96)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.implDoFinal(P11Cipher.java:813)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.engineDoFinal(P11Cipher.java:585)
> 	at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2417)
> ...
> 
> 
> Details:
> This problems happens when reqBlockUpdates is true and implUpdate, which does not end on block boundary, is performed followed by final implUpdate, which ends exactly on block boundary. In that case final implUpdate fills padBuffer and then just returns. [1] Following implDoFinal then tries to add padding and throws OOB exception. Problem is, that in this case (input is multiple of block size) whole padding block should be added, but there is no space for it in padBuffer causing OOB exception.
> 
> Solution:
> Solution is to detect this case (implDoFinal is called with full padBuffer) and to perform additional C_EncryptUpdate to free up padBuffer so that padBuffer can than be used to add whole new padding block.
> 
> [1] https://github.com/openjdk/jdk/blob/d4eeeb82cb2288973a6a247c54513f7e1c6b58f0/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L622

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

  fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9310/files
  - new: https://git.openjdk.org/jdk/pull/9310/files/a2ecbb1d..85d6ff89

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9310&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9310&range=01-02

  Stats: 15 lines in 2 files changed: 0 ins; 4 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/9310.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9310/head:pull/9310

PR: https://git.openjdk.org/jdk/pull/9310

From duke at openjdk.org  Mon Jul  4 14:22:44 2022
From: duke at openjdk.org (zzambers)
Date: Mon, 4 Jul 2022 14:22:44 GMT
Subject: RFR: 8289301: P11Cipher should not throw out of bounds exception
 during padding [v2]
In-Reply-To: <gp5_Qv_lWCZZYkg-9WMs6B6AKi4P4cecZ4i5SJ7nqgM=.2ed63e64-179c-4405-b6d4-ad91b553b4ba@github.com>
References: <3JHTrgtISq3EoVHE0JI_5ZHT-8TaLC8GB9bTyXGaPEI=.09128ed2-6b77-4aa4-bd4e-ca1594ec4371@github.com>
 <gp5_Qv_lWCZZYkg-9WMs6B6AKi4P4cecZ4i5SJ7nqgM=.2ed63e64-179c-4405-b6d4-ad91b553b4ba@github.com>
Message-ID: <ehV4_by9CwnUhpA1Ql6xiY-WdpE_rQ3902KlhCobXuY=.c1f53ab0-4bee-472d-a5ab-d4ff1c36ef58@github.com>

On Tue, 28 Jun 2022 13:20:53 GMT, zzambers <duke at openjdk.org> wrote:

>> SunPkcs11 provider throws out of bounds exception during encryption when specific conditions are met.
>> 
>> Exception:
>> 
>> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 32
>> 	at java.base/java.util.Arrays.rangeCheck(Arrays.java:725)
>> 	at java.base/java.util.Arrays.fill(Arrays.java:3308)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher$PKCS5Padding.setPaddingBytes(P11Cipher.java:96)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.implDoFinal(P11Cipher.java:813)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.engineDoFinal(P11Cipher.java:585)
>> 	at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2417)
>> ...
>> 
>> 
>> Details:
>> This problems happens when reqBlockUpdates is true and implUpdate, which does not end on block boundary, is performed followed by final implUpdate, which ends exactly on block boundary. In that case final implUpdate fills padBuffer and then just returns. [1] Following implDoFinal then tries to add padding and throws OOB exception. Problem is, that in this case (input is multiple of block size) whole padding block should be added, but there is no space for it in padBuffer causing OOB exception.
>> 
>> Solution:
>> Solution is to detect this case (implDoFinal is called with full padBuffer) and to perform additional C_EncryptUpdate to free up padBuffer so that padBuffer can than be used to add whole new padding block.
>> 
>> [1] https://github.com/openjdk/jdk/blob/d4eeeb82cb2288973a6a247c54513f7e1c6b58f0/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L622
>
> zzambers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bug number and copyright date

I have fixed all the issues, jdk_security tests passed for me (with these changes). Thanks

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

PR: https://git.openjdk.org/jdk/pull/9310

From jpai at openjdk.org  Tue Jul  5 06:20:25 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 5 Jul 2022 06:20:25 GMT
Subject: RFR: 8289572: InputStream wrapping with BufferedInputStream is
 redundant in HttpTimestamper
In-Reply-To: <P9jIj_8YZm3wshGxV9ox_-38G9UfMWbKLy0z9u7Gfug=.adc2f80c-086c-4b9e-a70b-129b7ba746ff@github.com>
References: <P9jIj_8YZm3wshGxV9ox_-38G9UfMWbKLy0z9u7Gfug=.adc2f80c-086c-4b9e-a70b-129b7ba746ff@github.com>
Message-ID: <cc53_WMXdw77sdpAWDPIzP9rsn0s08TIgOSpbn5g05Y=.9d40dd8c-5223-49d9-b5bf-7b09168563fb@github.com>

On Fri, 1 Jul 2022 08:06:10 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> In case we read all bytes from an `InputStream` we don't need wrapping with `BufferedInputStream` as the bytes are not written into internal buffer. With removal of redundant buffer we save 8 kB of allocated memory.

Looks fine to me, but please wait for someone from the security team to review this, before merging.

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

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9343

From duke at openjdk.org  Tue Jul  5 12:29:43 2022
From: duke at openjdk.org (Kevin Driver)
Date: Tue, 5 Jul 2022 12:29:43 GMT
Subject: RFR: 8170762: Document that ISO10126Padding pads with random bytes
In-Reply-To: <BTN39FByxvwC1IfUSEEJLkJs7g83-1FeLwtgkfCZx9E=.c5c13eb6-04ca-4880-bd05-457695e0a22a@github.com>
References: <dPKTNX-lsIvodW1hMjVLpbQi23gAEIoQJi-7BkBV6eA=.492057c4-c77f-4bcf-a81b-9a22baad02ae@github.com>
 <BTN39FByxvwC1IfUSEEJLkJs7g83-1FeLwtgkfCZx9E=.c5c13eb6-04ca-4880-bd05-457695e0a22a@github.com>
Message-ID: <NOdehChZZe-z4azI5-pymsUUvAbQ8VDyXee8Ua3d-O0=.2d438836-f3ab-4f26-9941-7ba627aeeaab@github.com>

On Fri, 1 Jul 2022 23:38:51 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> JDK-8170762 - update Javadoc to indicate ISO10126Padding pads with random bytes, though the spec does not require random bytes
>
> Just a comment, I believe both approaches are ok.  The ISO 10126 spec says:
> 
>> When padding with octets...the first subfield (pad fill) shall consist
>> of 0 to 7 octets with arbitrary contents. 
> 
> Adam's original comment was that because the spec says "arbitrary data," we could potentially just optimize the code a small bit by not having to fill with random data, and rather just leave as an uninitialized field.  But using random data to get some arbitrary data it is possibly a little safer since it will perturb the output a little vs. using an all zero padding.
> 
> So, fine to leave has been fixed.  However, I do have further comments on the doc bug.

Yes, @bradfordwetmore. Agreed. Both approaches are valid; hence just taking the "document the choice" approach.

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

PR: https://git.openjdk.org/jdk/pull/9350

From duke at openjdk.org  Tue Jul  5 15:37:55 2022
From: duke at openjdk.org (Mark Powers)
Date: Tue, 5 Jul 2022 15:37:55 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v6]
In-Reply-To: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
Message-ID: <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>

> https://bugs.openjdk.org/browse/JDK-8284851

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

  aw shucks - another one

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9282/files
  - new: https://git.openjdk.org/jdk/pull/9282/files/cd71b62b..2f494fcb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9282&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9282&range=04-05

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

PR: https://git.openjdk.org/jdk/pull/9282

From duke at openjdk.org  Tue Jul  5 15:40:42 2022
From: duke at openjdk.org (Mark Powers)
Date: Tue, 5 Jul 2022 15:40:42 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v5]
In-Reply-To: <NwYQb6RnPv89OZAAR7vfy0Ttw-UDLyVICatQ56RBet8=.9e81691c-2d77-4a66-a773-1c4ae0b0f636@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <NwYQb6RnPv89OZAAR7vfy0Ttw-UDLyVICatQ56RBet8=.9e81691c-2d77-4a66-a773-1c4ae0b0f636@github.com>
Message-ID: <ASagPSrC7FLnSXOgLBYz82rLcuZAwJsCvxYadjdEvKE=.7acd65cf-44d2-4167-a069-421e9ebefb64@github.com>

On Fri, 1 Jul 2022 23:59:02 GMT, Mark Powers <duke at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8284851
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Max comments continued

Found and fixed a `{@code }` missing the `}`.

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

PR: https://git.openjdk.org/jdk/pull/9282

From duke at openjdk.org  Tue Jul  5 19:55:05 2022
From: duke at openjdk.org (Mark Powers)
Date: Tue, 5 Jul 2022 19:55:05 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <MOaYWQkCI1aQWZf8-X6hc2HqbKDnB1MkFzCk7JeGBUM=.502f8687-efe2-49b1-b461-76571d67bebc@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
 <MOaYWQkCI1aQWZf8-X6hc2HqbKDnB1MkFzCk7JeGBUM=.502f8687-efe2-49b1-b461-76571d67bebc@github.com>
Message-ID: <DQFrwAk71965WVXlfUxzonKIXJtAndzif9BXGRV2G90=.1b09d2d3-9588-417b-93be-8c2b97900ba0@github.com>

On Tue, 28 Jun 2022 20:44:04 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Valerie fix
>
> src/java.base/share/classes/java/security/KeyStoreException.java line 44:
> 
>> 42:     /**
>> 43:      * Constructs a {@code KeyStoreException} with no detail message.  (A
>> 44:      * detail message is a String that describes this particular
> 
> "String" -> "string". Same below.

using `{@code String}`

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

PR: https://git.openjdk.org/jdk/pull/9282

From duke at openjdk.org  Tue Jul  5 20:06:00 2022
From: duke at openjdk.org (Mark Powers)
Date: Tue, 5 Jul 2022 20:06:00 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v6]
In-Reply-To: <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
Message-ID: <ik_cd3X7Z7hXToFTQO1gcPn3UXiODgDsB2SMH1bCwjM=.2d673c53-17c5-469c-9d53-60d31a0ba568@github.com>

On Tue, 5 Jul 2022 15:37:55 GMT, Mark Powers <duke at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8284851
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   aw shucks - another one

The pre-submit that fails doesn't appear to have anything to do with my changes.

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

PR: https://git.openjdk.org/jdk/pull/9282

From djelinski at openjdk.org  Tue Jul  5 21:06:58 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 5 Jul 2022 21:06:58 GMT
Subject: RFR: 8289768: Clean up unused code
Message-ID: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>

This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 

The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.

I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.

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

Commit messages:
 - Remove unused variables (windows)
 - Remove unused variables (macos)
 - Remove unused variables (linux)

Changes: https://git.openjdk.org/jdk/pull/9383/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9383&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289768
  Stats: 69 lines in 45 files changed: 0 ins; 65 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9383.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9383/head:pull/9383

PR: https://git.openjdk.org/jdk/pull/9383

From valeriep at openjdk.org  Wed Jul  6 00:11:43 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 6 Jul 2022 00:11:43 GMT
Subject: RFR: 8289301: P11Cipher should not throw out of bounds exception
 during padding [v2]
In-Reply-To: <ehV4_by9CwnUhpA1Ql6xiY-WdpE_rQ3902KlhCobXuY=.c1f53ab0-4bee-472d-a5ab-d4ff1c36ef58@github.com>
References: <3JHTrgtISq3EoVHE0JI_5ZHT-8TaLC8GB9bTyXGaPEI=.09128ed2-6b77-4aa4-bd4e-ca1594ec4371@github.com>
 <gp5_Qv_lWCZZYkg-9WMs6B6AKi4P4cecZ4i5SJ7nqgM=.2ed63e64-179c-4405-b6d4-ad91b553b4ba@github.com>
 <ehV4_by9CwnUhpA1Ql6xiY-WdpE_rQ3902KlhCobXuY=.c1f53ab0-4bee-472d-a5ab-d4ff1c36ef58@github.com>
Message-ID: <AByRE-tMOU-EoxMOy8wZGX3RlCkCsVotFIEpxmq7TzE=.9eaba02e-9992-4dde-8142-1a2cf29ef27e@github.com>

On Mon, 4 Jul 2022 14:19:38 GMT, zzambers <duke at openjdk.org> wrote:

> I have fixed all the issues, jdk_security tests passed for me (with these changes). Thanks

Looks good, I will approve after the test job complete successfully. Thanks!

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

PR: https://git.openjdk.org/jdk/pull/9310

From aturbanov at openjdk.org  Wed Jul  6 15:15:41 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 6 Jul 2022 15:15:41 GMT
Subject: RFR: 8289274: Cleanup unnecessary null comparison before
 instanceof check in security modules
In-Reply-To: <r5gI-Ovpso4jY_FtvlkGbyF7V2KQhbADyxMHCycXfpI=.bdeaad7e-dfe8-4e62-a0be-dbc46c45c074@github.com>
References: <qd5Ewuyi5C8hOlMKMyjD6Ofpyn-B7pGljsDqG8iBRIE=.71fb0398-960e-4681-a184-9eb133e20022@github.com>
 <r5gI-Ovpso4jY_FtvlkGbyF7V2KQhbADyxMHCycXfpI=.bdeaad7e-dfe8-4e62-a0be-dbc46c45c074@github.com>
Message-ID: <QFdBx2y7E7oBGcqJ5Cg9v4ZG9yHs1BsuFWCCiNLxJjo=.4d1eaae2-9687-48f3-b667-b4ac57d55258@github.com>

On Sun, 3 Jul 2022 20:17:07 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> Update code checks both non-null and instance of a class in security classes.
>> The checks and explicit casts could also be replaced with pattern matching for the instanceof operator.
>> 
>> See similar cleanup in java.base - [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422)
>
> src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 491:
> 
>> 489:                 break;
>> 490:             case "SSLServer":
>> 491:                 result = (t instanceof IOException);
> 
> Suggestion:
> 
>                 result = t instanceof IOException;

I like current approach with parentheses when `instanceof` is involved. Especially with assignment. In this case you can clearly see start and end of expression which would be assigned to variable.
@seanjmullan what do you think?

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

PR: https://git.openjdk.org/jdk/pull/9284

From xueleifan at tencent.com  Wed Jul  6 14:36:31 2022
From: xueleifan at tencent.com (xueleifan(XueleiFan))
Date: Wed, 6 Jul 2022 14:36:31 +0000
Subject: [Internet]Re: Re: JEP Review Request: TLS Certificate Compression
In-Reply-To: <A6C22B73-9CE9-43AE-A668-37A9265DF2D0@Tencent.Com>
References: <B8548635-21F2-47D5-B304-920121967D23@Tencent.Com>
 <CAMrH03JWtz_AjaK45Aa-1AJzJ9HnuM1a=GZxDNJSqNbQr_cseQ@mail.gmail.com>
 <A6C22B73-9CE9-43AE-A668-37A9265DF2D0@Tencent.Com>
Message-ID: <F6858DE1-A8C3-4796-993A-F7DA75FC999F@Tencent.Com>


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

Could I get the JEP reviewed by adding his/her name to the ?Reviewed By? filed in JBS so that we can move forward?  Please let me know if you have concerns.


Thanks,
Xuelei

> On Apr 13, 2022, at 2:47 PM, xueleifan(XueleiFan) <xueleifan at tencent.com> wrote:
> 
> Hi Daniel,
> 
> Actually, I?m considering the improvement, by using cached compressed certificates, for the implementation.  The solution is not straightforward yet to me.  But it is a direction I will consider seriously.
> 
> Thanks,
> Xuelei
> 
>> On Apr 13, 2022, at 1:01 PM, Daniel Jeli?ski <djelinski1 at gmail.com> wrote:
>> 
>> I like the idea of implementing certificate compression. Only one
>> concern: TLS handshakes are generally a CPU-intensive operation, and
>> certificate compression / decompression will only make it worse. Will
>> it be possible to compress a certificate once and use it across
>> multiple handshakes? Decompression has to be performed every time,
>> obviously.
>> 
>> Regards,
>> Daniel
>> 
>> pon., 21 mar 2022 o 16:49 xueleifan(XueleiFan) <xueleifan at tencent.com>
>> napisa?(a):
>>> 
>>> Hi,
>>> 
>>> 
>>> The JDK Enhancement Proposal, TLS Certificate Compression, has been opened for community review.  Detailed, please refer to the draft:
>>> 
>>>   https://bugs.openjdk.java.net/browse/JDK-8281710
>>> 
>>> and the discussion of this potential feature at security-dev:
>>> 
>>>   https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029242.html
>>> 
>>> 
>>> Please feel free to make comments and review the JEP.
>>> 
>>> Thanks,
>>> Xuelei
>> 
> 


From djelinski at openjdk.org  Wed Jul  6 08:57:23 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 6 Jul 2022 08:57:23 GMT
Subject: RFR: 8289768: Clean up unused code [v2]
In-Reply-To: <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
 <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>
Message-ID: <cSxCo06RRmSKNsQWRjAe2_lf5fpbm9R_c-crab--ac8=.3cc175af-0bf3-43b2-a345-a16314862e88@github.com>

On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
>> 
>> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
>> 
>> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.
>
> Daniel Jeli?ski 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 remote-tracking branch 'origin' into unused-variables
>  - Remove unused variables (windows)
>  - Remove unused variables (macos)
>  - Remove unused variables (linux)

test failure is unrelated, caused by [JDK-8289619](https://bugs.openjdk.org/browse/JDK-8289619)

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

PR: https://git.openjdk.org/jdk/pull/9383

From xuelei at openjdk.org  Wed Jul  6 14:28:36 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 6 Jul 2022 14:28:36 GMT
Subject: Integrated: 8287596: Reorg jdk.test.lib.util.ForceGC
In-Reply-To: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
References: <FLKRxAMKM7VJ4Rbs9jyg_O5Db_Bu7AqHpMn03mP2Ljg=.e6dd4021-27c5-4216-aa74-a148d99fb68a@github.com>
Message-ID: <qApGsW-PNjuL4Q0mxOHCa_EwWIoJ9_Uc0HyG8xqQDLA=.34d1a4bc-aed8-4130-abfc-0f2d6ca687f8@github.com>

On Wed, 1 Jun 2022 19:08:03 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> This is a follow up update per comments in [JDK-8287384 PR](https://github.com/openjdk/jdk/pull/8907).  The tier1 and tier2 test in open part looks good to me.  Please help to run Mach5 just case the closed test cases are impacted.

This pull request has now been integrated.

Changeset: 82a8bd7e
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/82a8bd7e92a1867b0c82f051361938be8610428d
Stats:     92 lines in 10 files changed: 13 ins; 38 del; 41 mod

8287596: Reorg jdk.test.lib.util.ForceGC

Reviewed-by: rriggs

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

PR: https://git.openjdk.org/jdk/pull/8979

From mullan at openjdk.org  Wed Jul  6 15:09:49 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 6 Jul 2022 15:09:49 GMT
Subject: RFR: 8289274: Cleanup unnecessary null comparison before
 instanceof check in security modules
In-Reply-To: <qd5Ewuyi5C8hOlMKMyjD6Ofpyn-B7pGljsDqG8iBRIE=.71fb0398-960e-4681-a184-9eb133e20022@github.com>
References: <qd5Ewuyi5C8hOlMKMyjD6Ofpyn-B7pGljsDqG8iBRIE=.71fb0398-960e-4681-a184-9eb133e20022@github.com>
Message-ID: <NVyTYOd7-vrqwVIJW7vPb4en1sWq6C0j6jF55C-Gwo4=.3b88e1f8-7384-4344-8b85-c87e05b8c8d8@github.com>

On Fri, 24 Jun 2022 18:27:05 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Update code checks both non-null and instance of a class in security classes.
> The checks and explicit casts could also be replaced with pattern matching for the instanceof operator.
> 
> See similar cleanup in java.base - [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422)

Marked as reviewed by mullan (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9284

From dfuchs at openjdk.org  Wed Jul  6 09:39:28 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 6 Jul 2022 09:39:28 GMT
Subject: RFR: 8289768: Clean up unused code [v2]
In-Reply-To: <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
 <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>
Message-ID: <KaJHebp-ApC21FZYke6AekCJZYJR09p-0dNQfAkLKkU=.a187d507-ab37-4086-86bc-e1f03e52a067@github.com>

On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
>> 
>> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
>> 
>> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.
>
> Daniel Jeli?ski 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 remote-tracking branch 'origin' into unused-variables
>  - Remove unused variables (windows)
>  - Remove unused variables (macos)
>  - Remove unused variables (linux)

Changes to libnet look good. Please wait until you have obtained approvals from maintainers of the other areas to integrate,

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9383

From lancea at openjdk.org  Wed Jul  6 15:35:39 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 6 Jul 2022 15:35:39 GMT
Subject: RFR: 8289768: Clean up unused code [v2]
In-Reply-To: <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
 <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>
Message-ID: <LoVNDWlc51SJQBDzXcw8BTrvooN3L3-unDnIRLCHgek=.53cef1f1-2273-4da5-9d64-b3346f19814e@github.com>

On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
>> 
>> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
>> 
>> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.
>
> Daniel Jeli?ski 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 remote-tracking branch 'origin' into unused-variables
>  - Remove unused variables (windows)
>  - Remove unused variables (macos)
>  - Remove unused variables (linux)

zlib looks fine given it is openjdk and not an upstream needed change

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

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9383

From mullan at openjdk.org  Wed Jul  6 15:21:28 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 6 Jul 2022 15:21:28 GMT
Subject: RFR: 8289274: Cleanup unnecessary null comparison before
 instanceof check in security modules
In-Reply-To: <QFdBx2y7E7oBGcqJ5Cg9v4ZG9yHs1BsuFWCCiNLxJjo=.4d1eaae2-9687-48f3-b667-b4ac57d55258@github.com>
References: <qd5Ewuyi5C8hOlMKMyjD6Ofpyn-B7pGljsDqG8iBRIE=.71fb0398-960e-4681-a184-9eb133e20022@github.com>
 <r5gI-Ovpso4jY_FtvlkGbyF7V2KQhbADyxMHCycXfpI=.bdeaad7e-dfe8-4e62-a0be-dbc46c45c074@github.com>
 <QFdBx2y7E7oBGcqJ5Cg9v4ZG9yHs1BsuFWCCiNLxJjo=.4d1eaae2-9687-48f3-b667-b4ac57d55258@github.com>
Message-ID: <NjMwBu97wgf3mkVIJvBqVt7MW-hoMbcxFUzInS0obVo=.72930134-82fa-4ee0-902d-90021f7e507e@github.com>

On Wed, 6 Jul 2022 15:12:06 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 491:
>> 
>>> 489:                 break;
>>> 490:             case "SSLServer":
>>> 491:                 result = (t instanceof IOException);
>> 
>> Suggestion:
>> 
>>                 result = t instanceof IOException;
>
> I like current approach with parentheses when `instanceof` is involved. Especially with assignment. In this case you can clearly see start and end of expression which would be assigned to variable.
> @seanjmullan what do you think?

I agree. It helps with the readability of the code.

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

PR: https://git.openjdk.org/jdk/pull/9284

From weijun at openjdk.org  Wed Jul  6 14:30:52 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 6 Jul 2022 14:30:52 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v6]
In-Reply-To: <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
Message-ID: <SYCGP60U5RL45tBog_yqgveKbD5XW6DXMjdGXIHMVcA=.40c2c853-f4e9-41fa-938d-6fa8786fb98b@github.com>

On Tue, 5 Jul 2022 15:37:55 GMT, Mark Powers <duke at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8284851
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   aw shucks - another one

Last comments.

src/java.base/share/classes/java/security/AllPermission.java line 183:

> 181:      *
> 182:      * @throws    IllegalArgumentException   if the permission is not an
> 183:      *                                       {@crypto AllPermission}

Typo, `s/crypto/code/`.

src/java.base/share/classes/java/security/CodeSource.java line 307:

> 305:      * and {@code null} certificates all imply
> 306:      * the codesource with the location "http://www.example.com/classes/foo.jar"
> 307:      * and {@code null} certificates:

Should the URL in the line above be wrapped in `{@code}`?

src/java.base/share/classes/javax/crypto/CryptoPermissions.java line 135:

> 133:      * object is marked as readonly.
> 134:      *
> 135:      * @see isReadOnly

Should be `PermissionCollection#isReadOnly`.

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

PR: https://git.openjdk.org/jdk/pull/9282

From djelinski at openjdk.org  Wed Jul  6 05:32:29 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 6 Jul 2022 05:32:29 GMT
Subject: RFR: 8289768: Clean up unused code [v2]
In-Reply-To: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
Message-ID: <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>

> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
> 
> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
> 
> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.

Daniel Jeli?ski 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 remote-tracking branch 'origin' into unused-variables
 - Remove unused variables (windows)
 - Remove unused variables (macos)
 - Remove unused variables (linux)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9383/files
  - new: https://git.openjdk.org/jdk/pull/9383/files/915680c0..b4cd5374

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9383&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9383&range=00-01

  Stats: 491 lines in 22 files changed: 458 ins; 5 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/9383.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9383/head:pull/9383

PR: https://git.openjdk.org/jdk/pull/9383

From weijun at openjdk.org  Wed Jul  6 16:44:53 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 6 Jul 2022 16:44:53 GMT
Subject: RFR: 8289768: Clean up unused code [v2]
In-Reply-To: <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
 <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>
Message-ID: <ZMpyNEU8PTGXpzZCkL5qkbpRdthjX3UpghdXRPILoeI=.9fd9bfdb-5f33-4537-8155-d1d3624f2236@github.com>

On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
>> 
>> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
>> 
>> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.
>
> Daniel Jeli?ski 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 remote-tracking branch 'origin' into unused-variables
>  - Remove unused variables (windows)
>  - Remove unused variables (macos)
>  - Remove unused variables (linux)

Changes in security (`java.security.jgss`, `jdk.crypto.cryptoki`, `jdk.crypto.mscapi`) look fine to me.

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

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9383

From sean.mullan at oracle.com  Wed Jul  6 16:58:24 2022
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 6 Jul 2022 12:58:24 -0400
Subject: security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java
 failure in jdk20
In-Reply-To: <AM9PR02MB67709A31F6BFFBD11C81312D93BE9@AM9PR02MB6770.eurprd02.prod.outlook.com>
References: <AM9PR02MB67709A31F6BFFBD11C81312D93BE9@AM9PR02MB6770.eurprd02.prod.outlook.com>
Message-ID: <7eb3cd11-fc66-b273-4342-589f2880a089@oracle.com>

Yes, I see the same issue. Please file a bug. It is trying to retrieve a 
CRL from the CA's LDAP repository and not finding an entry. Use of LDAP 
URLs for fetching CRLs is somewhat rare in my experience (usually it 
uses HTTP). It could be an issue with the CA's configuration, or it 
could possibly be a bug in the JDK, or it could be something with the 
test configuration. More evaluation is needed.

--Sean

On 7/4/22 3:57 AM, Baesken, Matthias wrote:
> Hello, after https://bugs.openjdk.org/browse/JDK-8224768 
> <https://bugs.openjdk.org/browse/JDK-8224768>?? removed the ActalisCA 
> test from the problem list, we see the test failing on all platforms
> 
>  ?when running with JDK20 .
> 
> Can someone who runs those tests regularly confirm this ?
> 
> Thanks, Matthias
> 
> Failure is :
> 
> =====================================================
> 
> CONFIGURATION
> 
> =====================================================
> 
> http.proxyHost :null
> 
> http.proxyPort :null
> 
> https.proxyHost :null
> 
> https.proxyPort :null
> 
> https.socksProxyHost :null
> 
> https.socksProxyPort :null
> 
> jdk.certpath.disabledAlgorithms :MD2, MD5, SHA1 jdkCA & usage TLSServer, 
> RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224, SHA1 usage 
> SignedJAR & denyAfter 2019-01-01
> 
> Revocation options :[NO_FALLBACK]
> 
> OCSP responder set :null
> 
> Trusted root set: false
> 
> Expected EE Status:GOOD
> 
> =====================================================
> 
> Successful CertPath validation
> 
> Expected Certificate status: GOOD
> 
> Certificate status after validation: GOOD
> 
> =====================================================
> 
> CONFIGURATION
> 
> =====================================================
> 
> http.proxyHost :null
> 
> http.proxyPort :null
> 
> https.proxyHost :null
> 
> https.proxyPort :null
> 
> https.socksProxyHost :null
> 
> https.socksProxyPort :null
> 
> jdk.certpath.disabledAlgorithms :MD2, MD5, SHA1 jdkCA & usage TLSServer, 
> RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224, SHA1 usage 
> SignedJAR & denyAfter 2019-01-01
> 
> Revocation options :[NO_FALLBACK]
> 
> OCSP responder set :null
> 
> Trusted root set: false
> 
> Validation Date:Wed Jun 01 00:00:00 CEST 2022
> 
> Expected EE Status:REVOKED
> 
> Expected EE Revocation Date:Mon Mar 07 15:11:11 CET 2022
> 
> =====================================================
> 
> Received exception: java.security.cert.CertPathValidatorException: 
> Certificate has been revoked, reason: CESSATION_OF_OPERATION, revocation 
> date: Mon Mar 07 15:11:11 CET 2022, authority: CN=Actalis Organization 
> Validated Server CA G3 - OCSP Responder, O=Actalis S.p.A., L=Ponte San 
> Pietro, ST=Bergamo, C=IT, extension OIDs: []
> 
> Expected Certificate status: REVOKED
> 
> Certificate status after validation: REVOKED
> 
> Certificate revocation date:Mon Mar 07 15:11:11 CET 2022
> 
> Expected revocation date:Mon Mar 07 15:11:11 CET 2022
> 
> --------------------------------
> 
> =====================================================
> 
> CONFIGURATION
> 
> =====================================================
> 
> http.proxyHost :null
> 
> http.proxyPort :null
> 
> https.proxyHost :null
> 
> https.proxyPort :null
> 
> https.socksProxyHost :null
> 
> https.socksProxyPort :null
> 
> jdk.certpath.disabledAlgorithms :MD2, MD5, SHA1 jdkCA & usage TLSServer, 
> RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224, SHA1 usage 
> SignedJAR & denyAfter 2019-01-01
> 
> Revocation options :[NO_FALLBACK, PREFER_CRLS]
> 
> OCSP responder set :null
> 
> Trusted root set: false
> 
> Expected EE Status:GOOD
> 
> =====================================================
> 
> Received exception: java.security.cert.CertPathValidatorException: 
> sun.security.provider.certpath.PKIX$CertStoreTypeException: Invalid 
> name: cn=Actalis Authentication Root CA,o=Actalis S.p.A./03358520967,c=IT
> 

From mcimadamore at openjdk.org  Wed Jul  6 18:01:28 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 6 Jul 2022 18:01:28 GMT
Subject: [jdk19] RFR: 8287809: Revisit implementation of memory session
 [v5]
In-Reply-To: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
Message-ID: <BKPU7A7NVDkRKWKe7Z0AscxT0LDRV8lhMBHsFKsUb2k=.d0bc0898-8a48-4d18-bd1d-a2635de31279@github.com>

> This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Merge branch 'master' into memory_session_cleanup
 - Fix ambiguity between session vs. base session
 - Revert implicit vs. heap session changes
 - Unify heap vs. implicit scopes
 - Merge branch 'master' into memory_session_cleanup
 - Fix issue in Direct-X-Buffer template
 - Simplify and drop the state class
 - Add missing files
 - Initial push

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

Changes: https://git.openjdk.org/jdk19/pull/22/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=22&range=04
  Stats: 484 lines in 24 files changed: 56 ins; 107 del; 321 mod
  Patch: https://git.openjdk.org/jdk19/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/22/head:pull/22

PR: https://git.openjdk.org/jdk19/pull/22

From jvernee at openjdk.org  Wed Jul  6 17:00:47 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 6 Jul 2022 17:00:47 GMT
Subject: [jdk19] RFR: 8287809: Revisit implementation of memory session
 [v4]
In-Reply-To: <hZrORsCyL-X6TdxTEI6X3jnfSQkUWOXEVPAKclNpQoA=.7b16aefa-0d58-431e-b7c7-51ffa3a6444c@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
 <hZrORsCyL-X6TdxTEI6X3jnfSQkUWOXEVPAKclNpQoA=.7b16aefa-0d58-431e-b7c7-51ffa3a6444c@github.com>
Message-ID: <9ZEADSzSlDzVxEDuF3KT1bgynXFLLtLmXZi1XszM0D0=.ff3a84ef-d38b-4daa-920e-acee3ee97e6c@github.com>

On Fri, 17 Jun 2022 18:39:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert implicit vs. heap session changes

Am I understanding correctly that, before calling `checkValidState` we also need to always call `baseSession()`? `checkValidState()` just calls `checkValidStateRaw` in a try/catch, and for non-closeable views this always throws.

There seem to be many cases where `baseSession()` is not called...

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

PR: https://git.openjdk.org/jdk19/pull/22

From jvernee at openjdk.org  Wed Jul  6 17:11:55 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 6 Jul 2022 17:11:55 GMT
Subject: [jdk19] RFR: 8287809: Revisit implementation of memory session
 [v4]
In-Reply-To: <PwZArHsIfTBaBDqG0_cE8z6i2C5TwvcP-bLz3vyt98U=.d39bbcc0-6a63-40ea-a9f0-0dc47d31b8c0@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
 <hZrORsCyL-X6TdxTEI6X3jnfSQkUWOXEVPAKclNpQoA=.7b16aefa-0d58-431e-b7c7-51ffa3a6444c@github.com>
 <PwZArHsIfTBaBDqG0_cE8z6i2C5TwvcP-bLz3vyt98U=.d39bbcc0-6a63-40ea-a9f0-0dc47d31b8c0@github.com>
Message-ID: <37B_wovfu8uoaM0hq4X1PG3xccVavpwYiZcJ9uNpqTM=.e417015c-9cef-4125-88cb-346b0a80471e@github.com>

On Wed, 6 Jul 2022 17:05:51 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert implicit vs. heap session changes
>
> src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 131:
> 
>> 129:         AbstractMemorySegmentImpl bb = checkAddress(obb, base, handle.length, true);
>> 130: #if[floatingPoint]
>> 131:         $rawType$ rawValue = SCOPED_MEMORY_ACCESS.get$RawType$Unaligned(bb.session(),
> 
> For instance, it's not clear to me why `baseSession()` is not called here.

It seems that, if `get$RawType$Unaligned` calls `checkValidStateRaw()` this will end up throwing an exception

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

PR: https://git.openjdk.org/jdk19/pull/22

From valeriep at openjdk.org  Wed Jul  6 17:01:45 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 6 Jul 2022 17:01:45 GMT
Subject: RFR: 8289301: P11Cipher should not throw out of bounds exception
 during padding [v3]
In-Reply-To: <59vZZzDpqvTVmUvBL0PH4075kou0rKX2rqZE26aRcds=.738f5f6d-8cbf-4496-bbdd-9226396251c2@github.com>
References: <3JHTrgtISq3EoVHE0JI_5ZHT-8TaLC8GB9bTyXGaPEI=.09128ed2-6b77-4aa4-bd4e-ca1594ec4371@github.com>
 <59vZZzDpqvTVmUvBL0PH4075kou0rKX2rqZE26aRcds=.738f5f6d-8cbf-4496-bbdd-9226396251c2@github.com>
Message-ID: <FemQQ-R42jjWw3JbFKnCr8kOyf64j8V_h1Fz4f0Wew4=.36460f22-5546-4e9a-aa15-291dd5586eea@github.com>

On Mon, 4 Jul 2022 14:22:42 GMT, zzambers <duke at openjdk.org> wrote:

>> SunPkcs11 provider throws out of bounds exception during encryption when specific conditions are met.
>> 
>> Exception:
>> 
>> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 32
>> 	at java.base/java.util.Arrays.rangeCheck(Arrays.java:725)
>> 	at java.base/java.util.Arrays.fill(Arrays.java:3308)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher$PKCS5Padding.setPaddingBytes(P11Cipher.java:96)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.implDoFinal(P11Cipher.java:813)
>> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.engineDoFinal(P11Cipher.java:585)
>> 	at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2417)
>> ...
>> 
>> 
>> Details:
>> This problems happens when reqBlockUpdates is true and implUpdate, which does not end on block boundary, is performed followed by final implUpdate, which ends exactly on block boundary. In that case final implUpdate fills padBuffer and then just returns. [1] Following implDoFinal then tries to add padding and throws OOB exception. Problem is, that in this case (input is multiple of block size) whole padding block should be added, but there is no space for it in padBuffer causing OOB exception.
>> 
>> Solution:
>> Solution is to detect this case (implDoFinal is called with full padBuffer) and to perform additional C_EncryptUpdate to free up padBuffer so that padBuffer can than be used to add whole new padding block.
>> 
>> [1] https://github.com/openjdk/jdk/blob/d4eeeb82cb2288973a6a247c54513f7e1c6b58f0/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L622
>
> zzambers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixes

Marked as reviewed by valeriep (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9310

From mcimadamore at openjdk.org  Wed Jul  6 17:16:56 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 6 Jul 2022 17:16:56 GMT
Subject: [jdk19] RFR: 8287809: Revisit implementation of memory session
 [v4]
In-Reply-To: <PwZArHsIfTBaBDqG0_cE8z6i2C5TwvcP-bLz3vyt98U=.d39bbcc0-6a63-40ea-a9f0-0dc47d31b8c0@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
 <hZrORsCyL-X6TdxTEI6X3jnfSQkUWOXEVPAKclNpQoA=.7b16aefa-0d58-431e-b7c7-51ffa3a6444c@github.com>
 <PwZArHsIfTBaBDqG0_cE8z6i2C5TwvcP-bLz3vyt98U=.d39bbcc0-6a63-40ea-a9f0-0dc47d31b8c0@github.com>
Message-ID: <nr-VbIeTMBs059cV__axZJhk1ZMVwDhkpWdnx2wKwVY=.60da6028-7c96-4dec-9bb1-7443e771b62d@github.com>

On Wed, 6 Jul 2022 17:07:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert implicit vs. heap session changes
>
> src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64VaList.java line 172:
> 
>> 170: 
>> 171:         public Builder(MemorySession session) {
>> 172:             ((MemorySessionImpl)session).checkValidState();
> 
> Or here, if the memory session is a non-closeable view.

I believe there was a wrong renaming with the IDE here, I will fix this

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

PR: https://git.openjdk.org/jdk19/pull/22

From mcimadamore at openjdk.org  Wed Jul  6 21:50:36 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 6 Jul 2022 21:50:36 GMT
Subject: [jdk19] RFR: 8287809: Revisit implementation of memory session
 [v6]
In-Reply-To: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
Message-ID: <eR3Wu-bSjrIgEjrFw3tqt3P38BIWgYSNQNF8pYcS_Dw=.bb171234-043b-446b-8760-79e2e00a2f46@github.com>

> This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017

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

  Turn non-closeable view back into MemorySession impl

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/22/files
  - new: https://git.openjdk.org/jdk19/pull/22/files/09bb7cf3..809a0a2e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk19&pr=22&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=22&range=04-05

  Stats: 79 lines in 14 files changed: 7 ins; 11 del; 61 mod
  Patch: https://git.openjdk.org/jdk19/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/22/head:pull/22

PR: https://git.openjdk.org/jdk19/pull/22

From duke at openjdk.org  Wed Jul  6 22:39:21 2022
From: duke at openjdk.org (Mark Powers)
Date: Wed, 6 Jul 2022 22:39:21 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v6]
In-Reply-To: <oeBQTs3Y72i3jqdiPq31liaFR11Ll2Z1m3ub49Sgea0=.dcc54891-37e0-499a-b925-1b9eba632416@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
 <SYCGP60U5RL45tBog_yqgveKbD5XW6DXMjdGXIHMVcA=.40c2c853-f4e9-41fa-938d-6fa8786fb98b@github.com>
 <oeBQTs3Y72i3jqdiPq31liaFR11Ll2Z1m3ub49Sgea0=.dcc54891-37e0-499a-b925-1b9eba632416@github.com>
Message-ID: <wYXfSiGj95WBOp_Ca4wLbSBSgvdrjxD5_k8XNeGP8PY=.7a2aaac9-87da-4d15-a390-95afd7685b6e@github.com>

On Wed, 6 Jul 2022 19:54:57 GMT, Mark Powers <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/CodeSource.java line 307:
>> 
>>> 305:      * and {@code null} certificates all imply
>>> 306:      * the codesource with the location "http://www.example.com/classes/foo.jar"
>>> 307:      * and {@code null} certificates:
>> 
>> Should the URL in the line above be wrapped in `{@code}`?
>
> JarURLConnection.java has a wrapped URL, but BigInteger.java does not.
> 
> I don't know the right answer although I could ask on #javadoc-team.

Max pointed out that BigInteger.java doesn't count because it's non-public method.
Using `{@code}`.

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

PR: https://git.openjdk.org/jdk/pull/9282

From valeriep at openjdk.org  Wed Jul  6 20:48:59 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 6 Jul 2022 20:48:59 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v6]
In-Reply-To: <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
Message-ID: <SNFAHAj_tYXSqxKOnSdvtKJbDRdtIw16uauZy8PPw5U=.0265a120-036c-4939-9f31-d2f824cf8fa4@github.com>

On Tue, 5 Jul 2022 15:37:55 GMT, Mark Powers <duke at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8284851
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   aw shucks - another one

src/java.base/share/classes/javax/crypto/Cipher.java line 144:

> 142:  * <p>
> 143:  * Every implementation of the Java platform is required to support
> 144:  * the following standard {@code Cipher} objecttransformations with the keysizes

typo: objecttransformations -> transformations

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

PR: https://git.openjdk.org/jdk/pull/9282

From duke at openjdk.org  Thu Jul  7 00:52:50 2022
From: duke at openjdk.org (Mark Powers)
Date: Thu, 7 Jul 2022 00:52:50 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v6]
In-Reply-To: <SY_FJDfhoY_hkNdjf57ljtzL3mr0dUL42w50_3bJD_c=.75d93fde-379b-4b4c-af39-c0cdb69c9281@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
 <SY_FJDfhoY_hkNdjf57ljtzL3mr0dUL42w50_3bJD_c=.75d93fde-379b-4b4c-af39-c0cdb69c9281@github.com>
Message-ID: <SOGGo3Pa2vmQX8BGN_aoGwsxYSEdZE8yvRvZuNh42t4=.f20ed8de-f17c-4ff1-b133-3d5ae2b2b088@github.com>

On Wed, 6 Jul 2022 23:11:15 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   aw shucks - another one
>
> src/java.base/share/classes/javax/crypto/CryptoPermission.java line 359:
> 
>> 357: 
>> 358:     /**
>> 359:      * Returns a string describing this {@code CryptoPermission}.
> 
> add object here.

Fixed.

> src/java.base/share/classes/javax/crypto/CryptoPermission.java line 365:
> 
>> 363:      * format: '("ClassName" "algorithm" "keysize" "exemption_mechanism")'.
>> 364:      *
>> 365:      * @return information about this {@code CryptoPermission}.
> 
> add object here.

Fixed.

> src/java.base/share/classes/javax/crypto/CryptoPermission.java line 451:
> 
>> 449: 
>> 450: /**
>> 451:  * A {@code CryptoPermissionCollection} stores a set of
> 
> add object here.

Fixed.

> src/java.base/share/classes/javax/crypto/CryptoPermission.java line 452:
> 
>> 450: /**
>> 451:  * A {@code CryptoPermissionCollection} stores a set of
>> 452:  * {@code CryptoPermission} permissions.
> 
> Use `objects` instead of `permissions` for consistency's sake?

Fixed.

> src/java.base/share/classes/javax/crypto/CryptoPermission.java line 477:
> 
>> 475: 
>> 476:     /**
>> 477:      * Adds a permission to the {@code CryptoPermissionCollection}.
> 
> add object here.

Fixed.

> src/java.base/share/classes/javax/crypto/CryptoPermission.java line 502:
> 
>> 500:      * @param permission the {@code Permission} object to compare
>> 501:      *
>> 502:      * @return {@code true} if the given permission  is implied by this
> 
> redundant space between `permission` and `is`?

Fixed.

> src/java.base/share/classes/javax/crypto/CryptoPermissions.java line 47:
> 
>> 45: /**
>> 46:  * This class contains {@code CryptoPermission} objects, organized into
>> 47:  * PermissionCollections according to algorithm names.
> 
> There is no PermissionCollections class. So, this should probably be changed to "{@code PermissionCollection} objects.

Fixed.

> src/java.base/share/classes/javax/crypto/CryptoPermissions.java line 94:
> 
>> 92:     /**
>> 93:      * Populates the crypto policy from the specified
>> 94:      * InputStream into this {@code CryptoPermissions} object.
> 
> add {@code } to InputStream?

Fixed.

> src/java.base/share/classes/javax/crypto/CryptoPermissions.java line 164:
> 
>> 162:      * @param permission the {@code Permission} object to check.
>> 163:      *
>> 164:      * @return true if "permission" is implied by the permissions
> 
> should be {@code permission} instead of "permission". Also, add {@code } to true.

Fixed.

> src/java.base/share/classes/javax/crypto/CryptoPermissions.java line 165:
> 
>> 163:      *
>> 164:      * @return true if "permission" is implied by the permissions
>> 165:      * in the {@code PermissionCollection} it belongs to, false if not.
> 
> add {@code } to false.

Fixed.

> src/java.base/share/classes/javax/crypto/CryptoPermissions.java line 187:
> 
>> 185:     /**
>> 186:      * Returns an enumeration of all the {@code Permission} objects
>> 187:      * in all the PermissionCollections in this
> 
> There is no PermissionCollections class. So, this should probably be changed to {@code PermissionCollection} objects. However, the sentence seems long and a bit hard to parse. Do you think we really need the middle part, i.e. "in all the PermissionCollection objects"?

I don't think we need the middle part. Nothing is lost by removing it.

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

PR: https://git.openjdk.org/jdk/pull/9282

From mcimadamore at openjdk.org  Wed Jul  6 21:50:39 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 6 Jul 2022 21:50:39 GMT
Subject: [jdk19] RFR: 8287809: Revisit implementation of memory session
 [v5]
In-Reply-To: <BKPU7A7NVDkRKWKe7Z0AscxT0LDRV8lhMBHsFKsUb2k=.d0bc0898-8a48-4d18-bd1d-a2635de31279@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
 <BKPU7A7NVDkRKWKe7Z0AscxT0LDRV8lhMBHsFKsUb2k=.d0bc0898-8a48-4d18-bd1d-a2635de31279@github.com>
Message-ID: <skTDctOYdpNK9Ztc6VtfF-JX9YxsL3vDEktF8vzrNTQ=.1dd02333-0e5b-4b9e-b7a3-f6e5e959d19c@github.com>

On Wed, 6 Jul 2022 18:01:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge branch 'master' into memory_session_cleanup
>  - Fix ambiguity between session vs. base session
>  - Revert implicit vs. heap session changes
>  - Unify heap vs. implicit scopes
>  - Merge branch 'master' into memory_session_cleanup
>  - Fix issue in Direct-X-Buffer template
>  - Simplify and drop the state class
>  - Add missing files
>  - Initial push

I've fixed the issues in the review comments, and further reduced the differences between the contents of this patch and mainline (while retaining the improvements).

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

PR: https://git.openjdk.org/jdk19/pull/22

From smarks at openjdk.org  Thu Jul  7 00:34:45 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 7 Jul 2022 00:34:45 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v17]
In-Reply-To: <oPgxqmLOciqOKyyiyXij5NljzGJ9bvo1SJWczC4V5ls=.1cd484f7-78d4-4f5e-9563-6d5d5af802ac@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
 <oPgxqmLOciqOKyyiyXij5NljzGJ9bvo1SJWczC4V5ls=.1cd484f7-78d4-4f5e-9563-6d5d5af802ac@github.com>
Message-ID: <cV45AQenpAzwJOJLADWjF5Pzb4kLfU277Ix58W6i0G0=.e4e6571a-7216-4495-9947-5d9bf28d10cf@github.com>

On Wed, 1 Jun 2022 16:45:35 GMT, liach <duke at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   do it as naotoj said
>
> 'the new' fix should be applied to newHashMap etc. too.

@liach 

> 'the new' fix should be applied to newHashMap etc. too.

I've filed [JDK-8289872](https://bugs.openjdk.org/browse/JDK-8289872) for this. It's a small thing but best to fix it before we forget about it.

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

PR: https://git.openjdk.org/jdk/pull/8302

From valeriep at openjdk.org  Wed Jul  6 22:47:21 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 6 Jul 2022 22:47:21 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v6]
In-Reply-To: <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
Message-ID: <eyXXDqgP6Y9R9_V3LhlJBgW80peZWDMF2ZTaFqntD9U=.151f4514-d628-42d8-b18d-a7aea6d1d2fa@github.com>

On Tue, 5 Jul 2022 15:37:55 GMT, Mark Powers <duke at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8284851
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   aw shucks - another one

src/java.base/share/classes/javax/crypto/CipherSpi.java line 444:

> 442:      * {@code Cipher} object and initializing it.
> 443:      *
> 444:      * @param opmode the operation mode of this {@code Cipher} (this is one of

add object here.

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

PR: https://git.openjdk.org/jdk/pull/9282

From naoto at openjdk.org  Wed Jul  6 19:46:33 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 6 Jul 2022 19:46:33 GMT
Subject: RFR: 8289768: Clean up unused code [v2]
In-Reply-To: <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
 <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>
Message-ID: <sHbNPpkAlwc9slRcjKYbXCWOgpKXN-XEunqXoXX1644=.76ae69fd-5911-4090-923f-f7c47c8ca088@github.com>

On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
>> 
>> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
>> 
>> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.
>
> Daniel Jeli?ski 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 remote-tracking branch 'origin' into unused-variables
>  - Remove unused variables (windows)
>  - Remove unused variables (macos)
>  - Remove unused variables (linux)

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9383

From duke at openjdk.org  Wed Jul  6 19:57:11 2022
From: duke at openjdk.org (Mark Powers)
Date: Wed, 6 Jul 2022 19:57:11 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v6]
In-Reply-To: <SYCGP60U5RL45tBog_yqgveKbD5XW6DXMjdGXIHMVcA=.40c2c853-f4e9-41fa-938d-6fa8786fb98b@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
 <SYCGP60U5RL45tBog_yqgveKbD5XW6DXMjdGXIHMVcA=.40c2c853-f4e9-41fa-938d-6fa8786fb98b@github.com>
Message-ID: <oeBQTs3Y72i3jqdiPq31liaFR11Ll2Z1m3ub49Sgea0=.dcc54891-37e0-499a-b925-1b9eba632416@github.com>

On Wed, 6 Jul 2022 14:04:10 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   aw shucks - another one
>
> src/java.base/share/classes/java/security/AllPermission.java line 183:
> 
>> 181:      *
>> 182:      * @throws    IllegalArgumentException   if the permission is not an
>> 183:      *                                       {@crypto AllPermission}
> 
> Typo, `s/crypto/code/`.

That's what happens when you don't watch your fingers. Fixed.

> src/java.base/share/classes/java/security/CodeSource.java line 307:
> 
>> 305:      * and {@code null} certificates all imply
>> 306:      * the codesource with the location "http://www.example.com/classes/foo.jar"
>> 307:      * and {@code null} certificates:
> 
> Should the URL in the line above be wrapped in `{@code}`?

JarURLConnection.java has a wrapped URL, but BigInteger.java does not.

I don't know the right answer although I could ask on #javadoc-team.

> src/java.base/share/classes/javax/crypto/CryptoPermissions.java line 135:
> 
>> 133:      * object is marked as readonly.
>> 134:      *
>> 135:      * @see isReadOnly
> 
> Should be `PermissionCollection#isReadOnly`.

@see `{@link PermissionCollection#isReadOnly}`

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

PR: https://git.openjdk.org/jdk/pull/9282

From valeriep at openjdk.org  Wed Jul  6 20:56:09 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 6 Jul 2022 20:56:09 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v6]
In-Reply-To: <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
Message-ID: <r1laGKSBGiVplSbYZJ9hsZLeYXisoUbt1m_rCoQRqG8=.8df0ec37-e64b-4f81-835d-1c5ca5d4ee50@github.com>

On Tue, 5 Jul 2022 15:37:55 GMT, Mark Powers <duke at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8284851
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   aw shucks - another one

src/java.base/share/classes/javax/crypto/Cipher.java line 1069:

> 1067: 
> 1068:     /**
> 1069:      * Returns the exemption mechanism object used with this {@code Cipher}.

Add object at the end.

src/java.base/share/classes/javax/crypto/Cipher.java line 1071:

> 1069:      * Returns the exemption mechanism object used with this {@code Cipher}.
> 1070:      *
> 1071:      * @return the exemption mechanism object used with this {@code Cipher}, or

add object to {@code Cipher} here.

src/java.base/share/classes/javax/crypto/Cipher.java line 1223:

> 1221:      * <p>Note that when a {@code Cipher} object is initialized, it loses all
> 1222:      * previously-acquired state. In other words, initializing a {@code Cipher}
> 1223:      * object is equivalent to creating a new instance of that {@code Cipher}

add object to {@code Cipher} here?

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

PR: https://git.openjdk.org/jdk/pull/9282

From weijun at openjdk.org  Wed Jul  6 20:10:05 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 6 Jul 2022 20:10:05 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v6]
In-Reply-To: <oeBQTs3Y72i3jqdiPq31liaFR11Ll2Z1m3ub49Sgea0=.dcc54891-37e0-499a-b925-1b9eba632416@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
 <SYCGP60U5RL45tBog_yqgveKbD5XW6DXMjdGXIHMVcA=.40c2c853-f4e9-41fa-938d-6fa8786fb98b@github.com>
 <oeBQTs3Y72i3jqdiPq31liaFR11Ll2Z1m3ub49Sgea0=.dcc54891-37e0-499a-b925-1b9eba632416@github.com>
Message-ID: <P9aBxQPAsQew1HvY078_Bb2bwWn0oZ1Z5cPxsEt-lRo=.22fdf2b5-aafd-4138-9f55-d3477db2357e@github.com>

On Wed, 6 Jul 2022 19:55:04 GMT, Mark Powers <duke at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/CryptoPermissions.java line 135:
>> 
>>> 133:      * object is marked as readonly.
>>> 134:      *
>>> 135:      * @see isReadOnly
>> 
>> Should be `PermissionCollection#isReadOnly`.
>
> @see `{@link PermissionCollection#isReadOnly}`

I think `@see PermissionCollection#isReadOnly` is enough.

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

PR: https://git.openjdk.org/jdk/pull/9282

From duke at openjdk.org  Thu Jul  7 10:32:17 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 7 Jul 2022 10:32:17 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is constructed
 from entirely used byte[]
Message-ID: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>

We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null.

Benchmark results:

before

Benchmark                                                  Mode  Cnt  Score   Error  Units
StringConstructor.newStringFromArray                       avgt   50  4,815 ? 0,154  ns/op
StringConstructor.newStringFromArrayWithCharset            avgt   50  4,462 ? 0,068  ns/op
StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,653 ? 0,040  ns/op
StringConstructor.newStringFromRangedArray                 avgt   50  5,090 ? 0,066  ns/op
StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,550 ? 0,041  ns/op
StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  8,080 ? 0,055  ns/op

after

Benchmark                                                  Mode  Cnt  Score   Error  Units
StringConstructor.newStringFromArray                       avgt   50  4,595 ? 0,053  ns/op
StringConstructor.newStringFromArrayWithCharset            avgt   50  4,038 ? 0,062  ns/op
StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,035 ? 0,031  ns/op
StringConstructor.newStringFromRangedArray                 avgt   50  4,084 ? 0,007  ns/op
StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,014 ? 0,008  ns/op
StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,466 ? 0,071  ns/op

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

Commit messages:
 - 8289908: Skip bounds check for cases when String is constructed from entirely used byte[]

Changes: https://git.openjdk.org/jdk/pull/9407/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9407&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289908
  Stats: 90 lines in 5 files changed: 77 ins; 1 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/9407.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9407/head:pull/9407

PR: https://git.openjdk.org/jdk/pull/9407

From coffeys at openjdk.org  Thu Jul  7 08:43:42 2022
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 7 Jul 2022 08:43:42 GMT
Subject: RFR: 6522064: Aliases from Microsoft CryptoAPI has bad character
 encoding
In-Reply-To: <qBrTitaiup671MjRvJo8F3BnAvwzwOXYobE6eQLqWuA=.fae8fa8a-a38d-48dd-b4fc-3509a6616aee@github.com>
References: <qBrTitaiup671MjRvJo8F3BnAvwzwOXYobE6eQLqWuA=.fae8fa8a-a38d-48dd-b4fc-3509a6616aee@github.com>
Message-ID: <fbW8xw0v6rSEin7YtmMsl0-NU68n6oD4UUjvGsFCRUw=.ffc32dab-386d-4286-96f6-53b16534e38d@github.com>

On Wed, 8 Jun 2022 13:42:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Switch to wide char version of `CertGetNameString` to get the non-ASCII name.

LGTM

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

Marked as reviewed by coffeys (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9085

From valeriep at openjdk.org  Wed Jul  6 21:09:03 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 6 Jul 2022 21:09:03 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v6]
In-Reply-To: <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
Message-ID: <GXF81cba4dvn256F3qUYYlNEHy2Al8CVnSc_EbZc52U=.be8b12fc-9009-448b-88a4-ecaecf2174ae@github.com>

On Tue, 5 Jul 2022 15:37:55 GMT, Mark Powers <duke at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8284851
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   aw shucks - another one

src/java.base/share/classes/javax/crypto/Cipher.java line 2707:

> 2705:      * Calls to this method provide AAD to the {@code Cipher} object
> 2706:      * when operating in modes such as AEAD (GCM/CCM).  If this
> 2707:      * {@code Cipher} is operating in either GCM or CCM mode, all AAD

add object to {@code Cipher} here.

src/java.base/share/classes/javax/crypto/Cipher.java line 2786:

> 2784:      * Calls to this method provide AAD to the {@code Cipher} object
> 2785:      *  when operating in modes such as AEAD (GCM/CCM).  If this
> 2786:      * {@code Cipher} is operating in either GCM or CCM mode, all AAD

add object to {@code Cipher} here.

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

PR: https://git.openjdk.org/jdk/pull/9282

From valeriep at openjdk.org  Wed Jul  6 22:39:25 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 6 Jul 2022 22:39:25 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v6]
In-Reply-To: <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
Message-ID: <Fc7OEQ-c-0tCS8LGFzXWT-Eoigx4B2eElg-ymkqEvho=.d0171fbe-206d-4bb4-aeb7-fdfd67c9eae6@github.com>

On Tue, 5 Jul 2022 15:37:55 GMT, Mark Powers <duke at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8284851
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   aw shucks - another one

src/java.base/share/classes/javax/crypto/CipherSpi.java line 385:

> 383:      * previously-acquired state. In other words, initializing a {@code Cipher}
> 384:      * object is equivalent to creating a new instance of that
> 385:      * {@code Cipher} and initializing it.

add object to {@code Cipher} here.

src/java.base/share/classes/javax/crypto/CipherSpi.java line 445:

> 443:      *
> 444:      * @param opmode the operation mode of this {@code Cipher} (this is one of
> 445:      * the following:

add object to {@code Cipher} here.

src/java.base/share/classes/javax/crypto/CipherSpi.java line 597:

> 595:      * decryption mode, and (un)padding has been requested, but the decrypted
> 596:      * data is not bounded by the appropriate padding bytes
> 597:      * @throws AEADBadTagException if this {@code Cipher} is decrypting in an

add object to {@code Cipher} here.

src/java.base/share/classes/javax/crypto/CipherSpi.java line 608:

> 606:      * Encrypts or decrypts data in a single-part operation,
> 607:      * or finishes a multiple-part operation.
> 608:      * The data is encrypted or decrypted, depending on how this {@code Cipher}

add object to {@code Cipher} here.

src/java.base/share/classes/javax/crypto/CipherSpi.java line 624:

> 622:      * a {@code ShortBufferException} is thrown.
> 623:      *
> 624:      * <p>Upon finishing, this method resets this {@code Cipher} to the state

add object to {@code Cipher} here.

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

PR: https://git.openjdk.org/jdk/pull/9282

From valeriep at openjdk.org  Wed Jul  6 22:50:22 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 6 Jul 2022 22:50:22 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v6]
In-Reply-To: <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
Message-ID: <V0yzU9xpmtxxYrsImqDuVMJ3nr5N6l1IrVv_l77jGUo=.d4f28554-bec1-496d-bbfa-8ffb89b070cd@github.com>

On Tue, 5 Jul 2022 15:37:55 GMT, Mark Powers <duke at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8284851
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   aw shucks - another one

src/java.base/share/classes/javax/crypto/CipherSpi.java line 631:

> 629:      * {@code engineInit}) more data.
> 630:      *
> 631:      * <p>Note: if any exception is thrown, this {@code Cipher} may need to

add object here.

src/java.base/share/classes/javax/crypto/CipherSpi.java line 651:

> 649:      * @throws ShortBufferException if the given output buffer is too small
> 650:      * to hold the result
> 651:      * @throws BadPaddingException if this {@code Cipher} is in decryption mode,

add object here.

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

PR: https://git.openjdk.org/jdk/pull/9282

From duke at openjdk.org  Wed Jul  6 22:39:26 2022
From: duke at openjdk.org (Mark Powers)
Date: Wed, 6 Jul 2022 22:39:26 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v6]
In-Reply-To: <P9aBxQPAsQew1HvY078_Bb2bwWn0oZ1Z5cPxsEt-lRo=.22fdf2b5-aafd-4138-9f55-d3477db2357e@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
 <SYCGP60U5RL45tBog_yqgveKbD5XW6DXMjdGXIHMVcA=.40c2c853-f4e9-41fa-938d-6fa8786fb98b@github.com>
 <oeBQTs3Y72i3jqdiPq31liaFR11Ll2Z1m3ub49Sgea0=.dcc54891-37e0-499a-b925-1b9eba632416@github.com>
 <P9aBxQPAsQew1HvY078_Bb2bwWn0oZ1Z5cPxsEt-lRo=.22fdf2b5-aafd-4138-9f55-d3477db2357e@github.com>
Message-ID: <u_B5XSfoAjWe-9Z3s0CIJm6sqDS1RBAL-wdb4QCHaC0=.7448ec3f-b352-4f67-a8e7-a83ab76b985a@github.com>

On Wed, 6 Jul 2022 20:06:02 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> @see `{@link PermissionCollection#isReadOnly}`
>
> I think `@see PermissionCollection#isReadOnly` is enough.

Fixed.

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

PR: https://git.openjdk.org/jdk/pull/9282

From valeriep at openjdk.org  Wed Jul  6 22:44:58 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 6 Jul 2022 22:44:58 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v6]
In-Reply-To: <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
Message-ID: <phO2m9IOJYKqvBk2XpZNOlMhS11szeNgQkIDvCAaQYM=.92b196f6-0f7e-4f39-aaec-c094b0637213@github.com>

On Tue, 5 Jul 2022 15:37:55 GMT, Mark Powers <duke at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8284851
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   aw shucks - another one

src/java.base/share/classes/javax/crypto/CipherSpi.java line 301:

> 299: 
> 300:     /**
> 301:      * Initializes this {@code Cipher} object with a key and a source

Hmm, with this {@code } change, I think the class name should be `CipherSpi` instead of `Cipher`.
This comment applies to the rest of this file.

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

PR: https://git.openjdk.org/jdk/pull/9282

From valeriep at openjdk.org  Wed Jul  6 23:39:58 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 6 Jul 2022 23:39:58 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v6]
In-Reply-To: <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
Message-ID: <SY_FJDfhoY_hkNdjf57ljtzL3mr0dUL42w50_3bJD_c=.75d93fde-379b-4b4c-af39-c0cdb69c9281@github.com>

On Tue, 5 Jul 2022 15:37:55 GMT, Mark Powers <duke at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8284851
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   aw shucks - another one

src/java.base/share/classes/javax/crypto/CryptoPermission.java line 359:

> 357: 
> 358:     /**
> 359:      * Returns a string describing this {@code CryptoPermission}.

add object here.

src/java.base/share/classes/javax/crypto/CryptoPermission.java line 365:

> 363:      * format: '("ClassName" "algorithm" "keysize" "exemption_mechanism")'.
> 364:      *
> 365:      * @return information about this {@code CryptoPermission}.

add object here.

src/java.base/share/classes/javax/crypto/CryptoPermission.java line 451:

> 449: 
> 450: /**
> 451:  * A {@code CryptoPermissionCollection} stores a set of

add object here.

src/java.base/share/classes/javax/crypto/CryptoPermission.java line 452:

> 450: /**
> 451:  * A {@code CryptoPermissionCollection} stores a set of
> 452:  * {@code CryptoPermission} permissions.

Use `objects` instead of `permissions` for consistency's sake?

src/java.base/share/classes/javax/crypto/CryptoPermission.java line 477:

> 475: 
> 476:     /**
> 477:      * Adds a permission to the {@code CryptoPermissionCollection}.

add object here.

src/java.base/share/classes/javax/crypto/CryptoPermission.java line 502:

> 500:      * @param permission the {@code Permission} object to compare
> 501:      *
> 502:      * @return {@code true} if the given permission  is implied by this

redundant space between `permission` and `is`?

src/java.base/share/classes/javax/crypto/CryptoPermissions.java line 47:

> 45: /**
> 46:  * This class contains {@code CryptoPermission} objects, organized into
> 47:  * PermissionCollections according to algorithm names.

There is no PermissionCollections class. So, this should probably be changed to "{@code PermissionCollection} objects.

src/java.base/share/classes/javax/crypto/CryptoPermissions.java line 94:

> 92:     /**
> 93:      * Populates the crypto policy from the specified
> 94:      * InputStream into this {@code CryptoPermissions} object.

add {@code } to InputStream?

src/java.base/share/classes/javax/crypto/CryptoPermissions.java line 164:

> 162:      * @param permission the {@code Permission} object to check.
> 163:      *
> 164:      * @return true if "permission" is implied by the permissions

should be {@code permission} instead of "permission". Also, add {@code } to true.

src/java.base/share/classes/javax/crypto/CryptoPermissions.java line 165:

> 163:      *
> 164:      * @return true if "permission" is implied by the permissions
> 165:      * in the {@code PermissionCollection} it belongs to, false if not.

add {@code } to false.

src/java.base/share/classes/javax/crypto/CryptoPermissions.java line 187:

> 185:     /**
> 186:      * Returns an enumeration of all the {@code Permission} objects
> 187:      * in all the PermissionCollections in this

There is no PermissionCollections class. So, this should probably be changed to {@code PermissionCollection} objects. However, the sentence seems long and a bit hard to parse. Do you think we really need the middle part, i.e. "in all the PermissionCollection objects"?

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

PR: https://git.openjdk.org/jdk/pull/9282

From valeriep at openjdk.org  Wed Jul  6 21:03:06 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 6 Jul 2022 21:03:06 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v6]
In-Reply-To: <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
Message-ID: <zV6s4a_pA6BCy3a6jOPuJDyt8yZJHTj94seIQNVosDs=.7efa842a-563a-4a6a-9d4f-8d5260e48853@github.com>

On Tue, 5 Jul 2022 15:37:55 GMT, Mark Powers <duke at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8284851
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   aw shucks - another one

src/java.base/share/classes/javax/crypto/Cipher.java line 1801:

> 1799:      * doFinal() calls - should be initialized and in ENCRYPT_MODE or
> 1800:      * DECRYPT_MODE.
> 1801:      * @throws IllegalStateException if this {@code Cipher} objectis not in

typo: objectis -> object is

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

PR: https://git.openjdk.org/jdk/pull/9282

From valeriep at openjdk.org  Wed Jul  6 22:28:06 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 6 Jul 2022 22:28:06 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v6]
In-Reply-To: <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
Message-ID: <r-ARs2ZzP3FNCVONJhUGAz-Fb2enQS6eqpTD-YEJnlw=.fbffcfd6-a502-4a09-8c50-5d4dc10a21d1@github.com>

On Tue, 5 Jul 2022 15:37:55 GMT, Mark Powers <duke at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8284851
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   aw shucks - another one

src/java.base/share/classes/javax/crypto/CipherOutputStream.java line 106:

> 104:      *
> 105:      * Constructs a {@code CipherOutputStream} from an
> 106:      * {@code OutputStream} and a {@code Cipher}.

add object to {@code Cipher} here.

src/java.base/share/classes/javax/crypto/CipherOutputStream.java line 206:

> 204:      * <p>Any bytes buffered by the encapsulated {@code Cipher} object
> 205:      * and waiting to be processed by it will not be written out. For example,
> 206:      * if the encapsulated {@code Cipher} is a block cipher, and the

add object to {@code Cipher} here.

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

PR: https://git.openjdk.org/jdk/pull/9282

From valeriep at openjdk.org  Wed Jul  6 22:59:29 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 6 Jul 2022 22:59:29 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v6]
In-Reply-To: <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
Message-ID: <-MDSAKTMXpmNUm11q7lL2RoaSKEmjexT_vevuMTDzDI=.f3b87778-fdfb-42f3-afb7-c07d345ffe7c@github.com>

On Tue, 5 Jul 2022 15:37:55 GMT, Mark Powers <duke at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8284851
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   aw shucks - another one

src/java.base/share/classes/javax/crypto/CryptoAllPermission.java line 107:

> 105: /**
> 106:  * A {@code CryptoAllPermissionCollection} stores a collection
> 107:  * of {@code CryptoAllPermission} permissions.

maybe change "permissions" to "objects" to be consistent with the rest of this file?

src/java.base/share/classes/javax/crypto/CryptoAllPermission.java line 158:

> 156:      *
> 157:      * @return {@code true} if the given permission is implied by this
> 158:      * CryptoAllPermissionCollection.

Add {@code }?

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

PR: https://git.openjdk.org/jdk/pull/9282

From weijun at openjdk.org  Wed Jul  6 23:06:05 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 6 Jul 2022 23:06:05 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v6]
In-Reply-To: <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
Message-ID: <gn0HedweKGsIwg_65BLdeFtgv5CmetsGojxpewLikEw=.3d2c1414-60af-412e-876f-3d670b2348af@github.com>

On Tue, 5 Jul 2022 15:37:55 GMT, Mark Powers <duke at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8284851
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   aw shucks - another one

I don't have more comments on the `java.security` package.

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

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9282

From duke at openjdk.org  Thu Jul  7 02:45:42 2022
From: duke at openjdk.org (Mark Powers)
Date: Thu, 7 Jul 2022 02:45:42 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v7]
In-Reply-To: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
Message-ID: <vx7uWo4UNOJ_GJ6ndEtZgT4_ajkF6rUtEjJSv_uaItI=.e5b10bcb-040d-4d5e-bfd2-dc74f35b03d2@github.com>

> https://bugs.openjdk.org/browse/JDK-8284851

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

 - Merge
 - comments from Valerie and Max
 - aw shucks - another one
 - Max comments continued
 - Max comments
 - Valerie fix continued
 - Valerie fix
 - mo polish
 - polish
 - Merge
 - ... and 3 more: https://git.openjdk.org/jdk/compare/6cefee01...54310a1a

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9282/files
  - new: https://git.openjdk.org/jdk/pull/9282/files/2f494fcb..54310a1a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9282&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9282&range=05-06

  Stats: 37604 lines in 625 files changed: 31356 ins; 3309 del; 2939 mod
  Patch: https://git.openjdk.org/jdk/pull/9282.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9282/head:pull/9282

PR: https://git.openjdk.org/jdk/pull/9282

From duke at openjdk.org  Thu Jul  7 00:10:20 2022
From: duke at openjdk.org (Mark Powers)
Date: Thu, 7 Jul 2022 00:10:20 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v6]
In-Reply-To: <SNFAHAj_tYXSqxKOnSdvtKJbDRdtIw16uauZy8PPw5U=.0265a120-036c-4939-9f31-d2f824cf8fa4@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
 <SNFAHAj_tYXSqxKOnSdvtKJbDRdtIw16uauZy8PPw5U=.0265a120-036c-4939-9f31-d2f824cf8fa4@github.com>
Message-ID: <Jg_CQuI6g56nPfF_h7kVGjEku4gburMqve8LGXpDsGs=.9721851a-35cd-4a2f-bf6b-65316039580b@github.com>

On Wed, 6 Jul 2022 20:46:44 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   aw shucks - another one
>
> src/java.base/share/classes/javax/crypto/Cipher.java line 144:
> 
>> 142:  * <p>
>> 143:  * Every implementation of the Java platform is required to support
>> 144:  * the following standard {@code Cipher} objecttransformations with the keysizes
> 
> typo: objecttransformations -> transformations

How did that happen? Fixed.

> src/java.base/share/classes/javax/crypto/Cipher.java line 1069:
> 
>> 1067: 
>> 1068:     /**
>> 1069:      * Returns the exemption mechanism object used with this {@code Cipher}.
> 
> Add object at the end.

Added.

> src/java.base/share/classes/javax/crypto/Cipher.java line 1223:
> 
>> 1221:      * <p>Note that when a {@code Cipher} object is initialized, it loses all
>> 1222:      * previously-acquired state. In other words, initializing a {@code Cipher}
>> 1223:      * object is equivalent to creating a new instance of that {@code Cipher}
> 
> add object to {@code Cipher} here?

Fixed.

> src/java.base/share/classes/javax/crypto/Cipher.java line 1801:
> 
>> 1799:      * doFinal() calls - should be initialized and in ENCRYPT_MODE or
>> 1800:      * DECRYPT_MODE.
>> 1801:      * @throws IllegalStateException if this {@code Cipher} objectis not in
> 
> typo: objectis -> object is

Fixed.

> src/java.base/share/classes/javax/crypto/Cipher.java line 2707:
> 
>> 2705:      * Calls to this method provide AAD to the {@code Cipher} object
>> 2706:      * when operating in modes such as AEAD (GCM/CCM).  If this
>> 2707:      * {@code Cipher} is operating in either GCM or CCM mode, all AAD
> 
> add object to {@code Cipher} here.

Fixed.

> src/java.base/share/classes/javax/crypto/Cipher.java line 2786:
> 
>> 2784:      * Calls to this method provide AAD to the {@code Cipher} object
>> 2785:      *  when operating in modes such as AEAD (GCM/CCM).  If this
>> 2786:      * {@code Cipher} is operating in either GCM or CCM mode, all AAD
> 
> add object to {@code Cipher} here.

Fixed.

> src/java.base/share/classes/javax/crypto/CipherOutputStream.java line 106:
> 
>> 104:      *
>> 105:      * Constructs a {@code CipherOutputStream} from an
>> 106:      * {@code OutputStream} and a {@code Cipher}.
> 
> add object to {@code Cipher} here.

Fixed.

> src/java.base/share/classes/javax/crypto/CipherOutputStream.java line 206:
> 
>> 204:      * <p>Any bytes buffered by the encapsulated {@code Cipher} object
>> 205:      * and waiting to be processed by it will not be written out. For example,
>> 206:      * if the encapsulated {@code Cipher} is a block cipher, and the
> 
> add object to {@code Cipher} here.

Fixed.

> src/java.base/share/classes/javax/crypto/CipherSpi.java line 301:
> 
>> 299: 
>> 300:     /**
>> 301:      * Initializes this {@code Cipher} object with a key and a source
> 
> Hmm, with this {@code } change, I think the class name should be `CipherSpi` instead of `Cipher`.
> This comment applies to the rest of this file.

Fixed. That's a lot of changes.

> src/java.base/share/classes/javax/crypto/CipherSpi.java line 385:
> 
>> 383:      * previously-acquired state. In other words, initializing a {@code Cipher}
>> 384:      * object is equivalent to creating a new instance of that
>> 385:      * {@code Cipher} and initializing it.
> 
> add object here.

Fixed.

> src/java.base/share/classes/javax/crypto/CipherSpi.java line 444:
> 
>> 442:      * {@code Cipher} object and initializing it.
>> 443:      *
>> 444:      * @param opmode the operation mode of this {@code Cipher} (this is one of
> 
> add object here.

Same comment appeared earlier. Odd. It's fixed.

> src/java.base/share/classes/javax/crypto/CipherSpi.java line 597:
> 
>> 595:      * decryption mode, and (un)padding has been requested, but the decrypted
>> 596:      * data is not bounded by the appropriate padding bytes
>> 597:      * @throws AEADBadTagException if this {@code Cipher} is decrypting in an
> 
> add object here.

Fixed.

> src/java.base/share/classes/javax/crypto/CipherSpi.java line 608:
> 
>> 606:      * Encrypts or decrypts data in a single-part operation,
>> 607:      * or finishes a multiple-part operation.
>> 608:      * The data is encrypted or decrypted, depending on how this {@code Cipher}
> 
> add object here.

Fixed.

> src/java.base/share/classes/javax/crypto/CipherSpi.java line 624:
> 
>> 622:      * a {@code ShortBufferException} is thrown.
>> 623:      *
>> 624:      * <p>Upon finishing, this method resets this {@code Cipher} to the state
> 
> add object here.

Fixed.

> src/java.base/share/classes/javax/crypto/CipherSpi.java line 631:
> 
>> 629:      * {@code engineInit}) more data.
>> 630:      *
>> 631:      * <p>Note: if any exception is thrown, this {@code Cipher} may need to
> 
> add object here.

Fixed.

> src/java.base/share/classes/javax/crypto/CipherSpi.java line 651:
> 
>> 649:      * @throws ShortBufferException if the given output buffer is too small
>> 650:      * to hold the result
>> 651:      * @throws BadPaddingException if this {@code Cipher} is in decryption mode,
> 
> add object here.

Fixed.

> src/java.base/share/classes/javax/crypto/CryptoAllPermission.java line 107:
> 
>> 105: /**
>> 106:  * A {@code CryptoAllPermissionCollection} stores a collection
>> 107:  * of {@code CryptoAllPermission} permissions.
> 
> maybe change "permissions" to "objects" to be consistent with the rest of this file?

Fixed.

> src/java.base/share/classes/javax/crypto/CryptoAllPermission.java line 158:
> 
>> 156:      *
>> 157:      * @return {@code true} if the given permission is implied by this
>> 158:      * CryptoAllPermissionCollection.
> 
> Add {@code }?

`{@code CryptoAllPermissionCollection}` object

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

PR: https://git.openjdk.org/jdk/pull/9282

From sean.mullan at oracle.com  Wed Jul  6 18:40:33 2022
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 6 Jul 2022 14:40:33 -0400
Subject: [Internet]Re: Re: JEP Review Request: TLS Certificate Compression
In-Reply-To: <F6858DE1-A8C3-4796-993A-F7DA75FC999F@Tencent.Com>
References: <B8548635-21F2-47D5-B304-920121967D23@Tencent.Com>
 <CAMrH03JWtz_AjaK45Aa-1AJzJ9HnuM1a=GZxDNJSqNbQr_cseQ@mail.gmail.com>
 <A6C22B73-9CE9-43AE-A668-37A9265DF2D0@Tencent.Com>
 <F6858DE1-A8C3-4796-993A-F7DA75FC999F@Tencent.Com>
Message-ID: <2b0e381c-d41d-2b03-238e-cf2d4af4201c@oracle.com>

I haven't had time to look at this in detail yet. I would like a couple 
more weeks to review the draft.

Thanks,
Sean

On 7/6/22 10:36 AM, xueleifan(XueleiFan) wrote:
> 
>>>>    https://bugs.openjdk.java.net/browse/JDK-8281710
> 
> Could I get the JEP reviewed by adding his/her name to the ?Reviewed By? filed in JBS so that we can move forward?  Please let me know if you have concerns.
> 
> 
> Thanks,
> Xuelei
> 
>> On Apr 13, 2022, at 2:47 PM, xueleifan(XueleiFan) <xueleifan at tencent.com> wrote:
>>
>> Hi Daniel,
>>
>> Actually, I?m considering the improvement, by using cached compressed certificates, for the implementation.  The solution is not straightforward yet to me.  But it is a direction I will consider seriously.
>>
>> Thanks,
>> Xuelei
>>
>>> On Apr 13, 2022, at 1:01 PM, Daniel Jeli?ski <djelinski1 at gmail.com> wrote:
>>>
>>> I like the idea of implementing certificate compression. Only one
>>> concern: TLS handshakes are generally a CPU-intensive operation, and
>>> certificate compression / decompression will only make it worse. Will
>>> it be possible to compress a certificate once and use it across
>>> multiple handshakes? Decompression has to be performed every time,
>>> obviously.
>>>
>>> Regards,
>>> Daniel
>>>
>>> pon., 21 mar 2022 o 16:49 xueleifan(XueleiFan) <xueleifan at tencent.com>
>>> napisa?(a):
>>>>
>>>> Hi,
>>>>
>>>>
>>>> The JDK Enhancement Proposal, TLS Certificate Compression, has been opened for community review.  Detailed, please refer to the draft:
>>>>
>>>>    https://bugs.openjdk.java.net/browse/JDK-8281710
>>>>
>>>> and the discussion of this potential feature at security-dev:
>>>>
>>>>    https://mail.openjdk.java.net/pipermail/security-dev/2022-March/029242.html
>>>>
>>>>
>>>> Please feel free to make comments and review the JEP.
>>>>
>>>> Thanks,
>>>> Xuelei
>>>
>>
> 

From jvernee at openjdk.org  Wed Jul  6 17:11:54 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 6 Jul 2022 17:11:54 GMT
Subject: [jdk19] RFR: 8287809: Revisit implementation of memory session
 [v4]
In-Reply-To: <hZrORsCyL-X6TdxTEI6X3jnfSQkUWOXEVPAKclNpQoA=.7b16aefa-0d58-431e-b7c7-51ffa3a6444c@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
 <hZrORsCyL-X6TdxTEI6X3jnfSQkUWOXEVPAKclNpQoA=.7b16aefa-0d58-431e-b7c7-51ffa3a6444c@github.com>
Message-ID: <PwZArHsIfTBaBDqG0_cE8z6i2C5TwvcP-bLz3vyt98U=.d39bbcc0-6a63-40ea-a9f0-0dc47d31b8c0@github.com>

On Fri, 17 Jun 2022 18:39:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert implicit vs. heap session changes

src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template line 131:

> 129:         AbstractMemorySegmentImpl bb = checkAddress(obb, base, handle.length, true);
> 130: #if[floatingPoint]
> 131:         $rawType$ rawValue = SCOPED_MEMORY_ACCESS.get$RawType$Unaligned(bb.session(),

For instance, it's not clear to me why `baseSession()` is not called here.

src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64VaList.java line 172:

> 170: 
> 171:         public Builder(MemorySession session) {
> 172:             ((MemorySessionImpl)session).checkValidState();

Or here, if the memory session is a non-closeable view.

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

PR: https://git.openjdk.org/jdk19/pull/22

From matthias.baesken at sap.com  Thu Jul  7 06:35:32 2022
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 7 Jul 2022 06:35:32 +0000
Subject: security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java
 failure in jdk20
In-Reply-To: <7eb3cd11-fc66-b273-4342-589f2880a089@oracle.com>
References: <AM9PR02MB67709A31F6BFFBD11C81312D93BE9@AM9PR02MB6770.eurprd02.prod.outlook.com>
 <7eb3cd11-fc66-b273-4342-589f2880a089@oracle.com>
Message-ID: <AM9PR02MB6770DD0BBEBFC78995A47BFE93839@AM9PR02MB6770.eurprd02.prod.outlook.com>

Hi Sean,  thanks for confirming.
I created 

https://bugs.openjdk.org/browse/JDK-8289884
8289884: security/infra/java/security/cert/CertPathValidator/certification/ActalisCA.java fails after 8224768

Best regards, Matthias


>Yes, I see the same issue. Please file a bug. It is trying to retrieve a 
>CRL from the CA's LDAP repository and not finding an entry. Use of LDAP 
>URLs for fetching CRLs is somewhat rare in my experience (usually it 
>uses HTTP). It could be an issue with the CA's configuration, or it 
>could possibly be a bug in the JDK, or it could be something with the 
>test configuration. More evaluation is needed.

 

From duke at openjdk.org  Wed Jul  6 22:59:28 2022
From: duke at openjdk.org (Mark Powers)
Date: Wed, 6 Jul 2022 22:59:28 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v6]
In-Reply-To: <r1laGKSBGiVplSbYZJ9hsZLeYXisoUbt1m_rCoQRqG8=.8df0ec37-e64b-4f81-835d-1c5ca5d4ee50@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <3I9CpSVb6G655WqFLfYZhOVzKFdd0WeeachQ7O2gQJI=.02182a4c-4348-4a24-b4d7-d306a90a7003@github.com>
 <r1laGKSBGiVplSbYZJ9hsZLeYXisoUbt1m_rCoQRqG8=.8df0ec37-e64b-4f81-835d-1c5ca5d4ee50@github.com>
Message-ID: <e1LjerGrQ3Dofh-89-mjmVIPR41zu9B2VdSOMSy-f3k=.85b2db9c-1cb7-4ab2-b61f-208fdf4142d8@github.com>

On Wed, 6 Jul 2022 20:50:19 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   aw shucks - another one
>
> src/java.base/share/classes/javax/crypto/Cipher.java line 1071:
> 
>> 1069:      * Returns the exemption mechanism object used with this {@code Cipher}.
>> 1070:      *
>> 1071:      * @return the exemption mechanism object used with this {@code Cipher}, or
> 
> add object to {@code Cipher} here.

Added.

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

PR: https://git.openjdk.org/jdk/pull/9282

From duke at openjdk.org  Thu Jul  7 10:20:43 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Thu, 7 Jul 2022 10:20:43 GMT
Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule
 is not logged
In-Reply-To: <R0zl8UunTV29IF1LgFlH2Xns12lg9ni2gTAEyHOtNI4=.9ea5aa0d-f7dd-4ac1-9b3f-b5f84b2f4a99@github.com>
References: <R0zl8UunTV29IF1LgFlH2Xns12lg9ni2gTAEyHOtNI4=.9ea5aa0d-f7dd-4ac1-9b3f-b5f84b2f4a99@github.com>
Message-ID: <0La342aRxm-EuFOtXVOeDPpqZAXlKiodEFZ0zlI8IXY=.461bbe91-8d56-44a0-a65e-57651e14a6de@github.com>

On Tue, 14 Jun 2022 19:07:24 GMT, Jayashree Huttanagoudar <duke at openjdk.org> wrote:

> Could you please review the changes?
> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug

I verified the changes with sample example here: https://web.mit.edu/java_v1.5.0_22/distrib/share/docs/guide/security/jaas/tutorials/GeneralAcnOnly.html , before and after the patch.

Results are below:
Before Patch:

# ./build/linux-x86_64-server-release/images/jdk/bin/javac sample/SampleAcn.java sample/module/SampleLoginModule.java sample/principal/SamplePrincipal.java
# ./build/linux-x86_64-server-release/images/jdk/bin/java -Djava.security.auth.login.config==sample_jaas.config -Djava.security.debug=logincontext sample.SampleAcn
	[LoginContext]: Build ServiceProviders cache for ClassLoader: app
	[LoginContext]: Discovered ServiceProviders for ClassLoader: app
java.util.ServiceLoader$ProviderImpl at d5ed6ed
java.util.ServiceLoader$ProviderImpl at 15a76bb1
java.util.ServiceLoader$ProviderImpl at 307eace9
java.util.ServiceLoader$ProviderImpl at f50ec023
java.util.ServiceLoader$ProviderImpl at fdf98634
java.util.ServiceLoader$ProviderImpl at c2632fde
java.util.ServiceLoader$ProviderImpl at 994f9a60
	[LoginContext]: sample.module.SampleLoginModule loaded via reflection
user name: testUser
password: test
		[SampleLoginModule] user entered user name: testUser
		[SampleLoginModule] user entered password: test
		[SampleLoginModule] authentication failed
	[LoginContext]: login OPTIONAL failure
	[LoginContext]: abort ignored
Authentication failed:
  Password Incorrect
user name: test
password: testPassword
		[SampleLoginModule] user entered user name: test
		[SampleLoginModule] user entered password: testPassword
		[SampleLoginModule] authentication failed
	[LoginContext]: login OPTIONAL failure
	[LoginContext]: abort ignored
Authentication failed:
  User Name Incorrect
user name: testUser
password: test
		[SampleLoginModule] user entered user name: testUser
		[SampleLoginModule] user entered password: test
		[SampleLoginModule] authentication failed
	[LoginContext]: login OPTIONAL failure
	[LoginContext]: abort ignored
Authentication failed:
  Password Incorrect

Sorry


After Patch:

# ./build/linux-x86_64-server-release/images/jdk/bin/javac sample/SampleAcn.java sample/module/SampleLoginModule.java sample/principal/SamplePrincipal.java
# ./build/linux-x86_64-server-release/images/jdk/bin/java -Djava.security.auth.login.config==sample_jaas.config -Djava.security.debug=logincontext sample.SampleAcn
	[LoginContext]: Build ServiceProviders cache for ClassLoader: app
	[LoginContext]: Discovered ServiceProviders for ClassLoader: app
java.util.ServiceLoader$ProviderImpl at 8533fe57
java.util.ServiceLoader$ProviderImpl at 1718814c
java.util.ServiceLoader$ProviderImpl at 49c41191
java.util.ServiceLoader$ProviderImpl at 55608305
java.util.ServiceLoader$ProviderImpl at ee04ebce
java.util.ServiceLoader$ProviderImpl at 52aed7a2
java.util.ServiceLoader$ProviderImpl at 6214285b
	[LoginContext]: sample.module.SampleLoginModule loaded via reflection
user name: test
password: testPassword
		[SampleLoginModule] user entered user name: test
		[SampleLoginModule] user entered password: testPassword
		[SampleLoginModule] authentication failed
	[LoginContext]: login OPTIONAL failure
	[LoginContext]: abort ignored
Authentication failed:
  javax.security.auth.login.FailedLoginException: User Name Incorrect
	at sample.module.SampleLoginModule.login(SampleLoginModule.java:214)
	at java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
	at java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:679)
	at java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:677)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
	at java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:677)
	at java.base/javax.security.auth.login.LoginContext.login(LoginContext.java:587)
	at sample.SampleAcn.main(SampleAcn.java:87)

user name: testUser
password: test
		[SampleLoginModule] user entered user name: testUser
		[SampleLoginModule] user entered password: test
		[SampleLoginModule] authentication failed
	[LoginContext]: login OPTIONAL failure
	[LoginContext]: abort ignored
Authentication failed:
  javax.security.auth.login.FailedLoginException: Password Incorrect
	at sample.module.SampleLoginModule.login(SampleLoginModule.java:216)
	at java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
	at java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:679)
	at java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:677)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
	at java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:677)
	at java.base/javax.security.auth.login.LoginContext.login(LoginContext.java:587)
	at sample.SampleAcn.main(SampleAcn.java:87)

user name: test
password: test
		[SampleLoginModule] user entered user name: test
		[SampleLoginModule] user entered password: test
		[SampleLoginModule] authentication failed
	[LoginContext]: login OPTIONAL failure
	[LoginContext]: abort ignored
Authentication failed:
  javax.security.auth.login.FailedLoginException: User Name Incorrect
	at sample.module.SampleLoginModule.login(SampleLoginModule.java:214)
	at java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
	at java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:679)
	at java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:677)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
	at java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:677)
	at java.base/javax.security.auth.login.LoginContext.login(LoginContext.java:587)
	at sample.SampleAcn.main(SampleAcn.java:87)

Sorry


After the patch it is printing the stack trace.

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

PR: https://git.openjdk.org/jdk/pull/9159

From duke at openjdk.org  Thu Jul  7 10:47:43 2022
From: duke at openjdk.org (zzambers)
Date: Thu, 7 Jul 2022 10:47:43 GMT
Subject: RFR: 8289301: P11Cipher should not throw out of bounds exception
 during padding [v2]
In-Reply-To: <AByRE-tMOU-EoxMOy8wZGX3RlCkCsVotFIEpxmq7TzE=.9eaba02e-9992-4dde-8142-1a2cf29ef27e@github.com>
References: <3JHTrgtISq3EoVHE0JI_5ZHT-8TaLC8GB9bTyXGaPEI=.09128ed2-6b77-4aa4-bd4e-ca1594ec4371@github.com>
 <gp5_Qv_lWCZZYkg-9WMs6B6AKi4P4cecZ4i5SJ7nqgM=.2ed63e64-179c-4405-b6d4-ad91b553b4ba@github.com>
 <ehV4_by9CwnUhpA1Ql6xiY-WdpE_rQ3902KlhCobXuY=.c1f53ab0-4bee-472d-a5ab-d4ff1c36ef58@github.com>
 <AByRE-tMOU-EoxMOy8wZGX3RlCkCsVotFIEpxmq7TzE=.9eaba02e-9992-4dde-8142-1a2cf29ef27e@github.com>
Message-ID: <K8agR6nWoiBAaprIZHcT7IFVfWQHgcqxdi5YAbJ4sFM=.5e00c00d-6b24-4923-a1dc-bb2b510e037e@github.com>

On Wed, 6 Jul 2022 00:07:50 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> I have fixed all the issues, jdk_security tests passed for me (with these changes). Thanks
>
>> I have fixed all the issues, jdk_security tests passed for me (with these changes). Thanks
> 
> Looks good, I will approve after the test job complete successfully. Thanks!

@valeriepeng Thank you for the review

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

PR: https://git.openjdk.org/jdk/pull/9310

From duke at openjdk.org  Thu Jul  7 10:25:41 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Thu, 7 Jul 2022 10:25:41 GMT
Subject: RFR: 8283082:
 sun.security.x509.X509CertImpl.delete("x509.info.validity") nulls out info
 field [v3]
In-Reply-To: <Zxft7h2QnF1SMXLmvwAGCxARqYCFg28mGghxQqZs9jY=.72635478-69dd-433d-b8d6-a8d8ede67dc3@github.com>
References: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
 <Zxft7h2QnF1SMXLmvwAGCxARqYCFg28mGghxQqZs9jY=.72635478-69dd-433d-b8d6-a8d8ede67dc3@github.com>
Message-ID: <RzqoogAEtNlKQIVdeKd0u9aWFUYmTKLMjMv0knC8PVE=.1ace2d46-c75d-4289-914d-b7439cba1819@github.com>

On Wed, 29 Jun 2022 16:08:01 GMT, Jayashree Huttanagoudar <duke at openjdk.org> wrote:

>> Could you please review the changes?
>> This is to address the issue: https://bugs.openjdk.org/browse/JDK-8283082?jql=labels%20%3D%20starter-bug
>
> Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments. Add regression test for the change

I tried to look at what is cause for the failure and not able to locate the detail !!
I navigated till here: https://github.com/jhuttana/jdk/runs/7116877356?check_suite_focus=true but nothing was useful to find the details.
Could you please guide me where I should look at the details?

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

PR: https://git.openjdk.org/jdk/pull/9306

From weijun at openjdk.org  Thu Jul  7 14:22:47 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 7 Jul 2022 14:22:47 GMT
Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule
 is not logged
In-Reply-To: <R0zl8UunTV29IF1LgFlH2Xns12lg9ni2gTAEyHOtNI4=.9ea5aa0d-f7dd-4ac1-9b3f-b5f84b2f4a99@github.com>
References: <R0zl8UunTV29IF1LgFlH2Xns12lg9ni2gTAEyHOtNI4=.9ea5aa0d-f7dd-4ac1-9b3f-b5f84b2f4a99@github.com>
Message-ID: <l8KZsV_Esl3D5c4V5sEVCTw1YBWxM9BuEqYn2EAJpFg=.62d59bc7-7cbb-4d54-a68b-2ad5bf61b9f2@github.com>

On Tue, 14 Jun 2022 19:07:24 GMT, Jayashree Huttanagoudar <duke at openjdk.org> wrote:

> Could you please review the changes?
> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug

It will be nice if the test itself can confirm the correctness since this is not a manual test (and we definitely want to avoid manual test as much as possible). Also, tests in OpenJDK are meant to be launched by the `jtreg` command instead of `javac/java` it. Read https://openjdk.org/jtreg/ for more details.

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

PR: https://git.openjdk.org/jdk/pull/9159

From weijun at openjdk.org  Thu Jul  7 14:05:46 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 7 Jul 2022 14:05:46 GMT
Subject: RFR: 8283082:
 sun.security.x509.X509CertImpl.delete("x509.info.validity") nulls out info
 field [v2]
In-Reply-To: <lkRfon7i8kkzHkqDB-427qxmhgv95Opu9P1FJ4DSz3A=.a8b4c470-f871-43a5-8d42-2b42dce8e443@github.com>
References: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
 <5xpsI8QNjiQl0Byp3HKwgnQ5dZH7RUiX0OwdO6rbNF4=.ba3bc008-f086-40d9-90a0-a05bdcc82e7e@github.com>
 <9eTwVSU1M262dL4z3vJX2jv8uTDH9IRR_M_-gdzynrk=.af93307c-f9bc-42b0-9e53-388171ab6083@github.com>
 <lkRfon7i8kkzHkqDB-427qxmhgv95Opu9P1FJ4DSz3A=.a8b4c470-f871-43a5-8d42-2b42dce8e443@github.com>
Message-ID: <e5ASBwCiMjJawr8hAEenZN1ozwSsrQBhmNhWvYKYPBU=.78e9415a-ae24-46a6-9896-bec46892bd20@github.com>

On Wed, 29 Jun 2022 16:13:15 GMT, Jayashree Huttanagoudar <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/x509/X509CertImpl.java line 742:
>> 
>>> 740: 
>>> 741:         if (id.equalsIgnoreCase(INFO)) {
>>> 742:             if ((attr.getSuffix() == null)) {
>> 
>> You can remove the parentheses that were added last time.
>
> @wangweij I have added the test case under: test/jdk/sun/security/x509/X509CertImpl/JDK8283082.java 
> As this is the first I am adding regression test so I am not sure whether the naming convention for the test case is right or not.

Thanks for adding the test. It looks fine.

Please add a copyright header and a block of `@test` comment to the test. You can find a nearby existing test file and see what they looks like. Since it references internal classes, a `@modules java.base/sun.security.x509` is necessary. Please run the test with the `jtreg` command to ensure everything is correct. Before your fix, the test should fail; and after it, it should succeed.

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

PR: https://git.openjdk.org/jdk/pull/9306

From rriggs at openjdk.org  Thu Jul  7 18:48:40 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 7 Jul 2022 18:48:40 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[]
In-Reply-To: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
Message-ID: <Xg9s8Vevl5-T8n4HJ8iQuIwxbU3ny9nLpD_5X_H7Yes=.1d9d7d50-f37c-4e33-8ca0-0b89af3f0a7b@github.com>

On Thu, 7 Jul 2022 10:21:06 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null.
> 
> Benchmark results:
> 
> before
> 
> Benchmark                                                  Mode  Cnt  Score   Error  Units
> StringConstructor.newStringFromArray                       avgt   50  4,815 ? 0,154  ns/op
> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,462 ? 0,068  ns/op
> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,653 ? 0,040  ns/op
> StringConstructor.newStringFromRangedArray                 avgt   50  5,090 ? 0,066  ns/op
> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,550 ? 0,041  ns/op
> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  8,080 ? 0,055  ns/op
> 
> after
> 
> Benchmark                                                  Mode  Cnt  Score   Error  Units
> StringConstructor.newStringFromArray                       avgt   50  4,595 ? 0,053  ns/op
> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,038 ? 0,062  ns/op
> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,035 ? 0,031  ns/op
> StringConstructor.newStringFromRangedArray                 avgt   50  4,084 ? 0,007  ns/op
> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,014 ? 0,008  ns/op
> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,466 ? 0,071  ns/op

src/java.base/share/classes/java/lang/String.java line 1429:

> 1427:      */
> 1428:     public String(byte[] bytes, int offset, int length) {
> 1429:         this(bytes, offset, length, Charset.defaultCharset(), checkBoundsOffCount(offset, length, bytes.length));

Can you avoid the extra constructor by applying `checkBoundOffCount` to the offset argument; it returns the offset.

this(bytes, checkBoundsOffCount(offset, length, bytes.length), length, Charset.defaultCharset());

or call `Preconditions.checkFromIndexSize` directly.

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

PR: https://git.openjdk.org/jdk/pull/9407

From duke at openjdk.org  Thu Jul  7 15:40:44 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Thu, 7 Jul 2022 15:40:44 GMT
Subject: RFR: 8283082:
 sun.security.x509.X509CertImpl.delete("x509.info.validity") nulls out info
 field [v3]
In-Reply-To: <wS7ogc5VtTP3jOa2iBblofPxDxdbl_LUEQ-KQKhOEKw=.0d4ef8c1-1e82-4606-acc9-3cf39822103c@github.com>
References: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
 <Zxft7h2QnF1SMXLmvwAGCxARqYCFg28mGghxQqZs9jY=.72635478-69dd-433d-b8d6-a8d8ede67dc3@github.com>
 <wS7ogc5VtTP3jOa2iBblofPxDxdbl_LUEQ-KQKhOEKw=.0d4ef8c1-1e82-4606-acc9-3cf39822103c@github.com>
Message-ID: <A-xvRceav5XG4kcfkW8fFLujEIbw0siL9SbrJP1PGn8=.0cb80a61-bc7f-47f3-9686-d4565c8b3ab2@github.com>

On Thu, 7 Jul 2022 13:58:53 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> You can expand the "Run Tests" task and see the failed one (it's very long). It's a linux-x86 test and it mentions "thread". I've heard that thread-related tests could fail on linux-x86 because loom support was only added to linux-x64. Unless you heard from someone else that it's a real issue, I think you can ignore it.

Sure I will check and confirm that. Thank you!

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

PR: https://git.openjdk.org/jdk/pull/9306

From valeriep at openjdk.org  Thu Jul  7 17:38:48 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 7 Jul 2022 17:38:48 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v7]
In-Reply-To: <vx7uWo4UNOJ_GJ6ndEtZgT4_ajkF6rUtEjJSv_uaItI=.e5b10bcb-040d-4d5e-bfd2-dc74f35b03d2@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <vx7uWo4UNOJ_GJ6ndEtZgT4_ajkF6rUtEjJSv_uaItI=.e5b10bcb-040d-4d5e-bfd2-dc74f35b03d2@github.com>
Message-ID: <NhqLH2H5WLnlfeFlUtH-Jv4z-OUtZbJGqZ3AK95tLAY=.b93937e9-a80c-41b2-a3d7-5b3c45731415@github.com>

On Thu, 7 Jul 2022 02:45:42 GMT, Mark Powers <duke at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8284851
>
> Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Merge
>  - comments from Valerie and Max
>  - aw shucks - another one
>  - Max comments continued
>  - Max comments
>  - Valerie fix continued
>  - Valerie fix
>  - mo polish
>  - polish
>  - Merge
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/d1ea0be1...54310a1a

src/java.base/share/classes/javax/crypto/CryptoAllPermission.java line 98:

> 96:      *
> 97:      * @return a new {@code PermissionCollection} object suitable for
> 98:      * storing {@code CryptoAllPermissions} objects.

typo: CryptoAllPermissions -> CryptoAllPermission?

src/java.base/share/classes/javax/crypto/CryptoAllPermission.java line 126:

> 124: 
> 125:     /**
> 126:      * Create an empty {@code CryptoAllPermission} object.

typo: CryptoAllPermissions -> CryptoAllPermission?

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

PR: https://git.openjdk.org/jdk/pull/9282

From duke at openjdk.org  Thu Jul  7 15:38:42 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Thu, 7 Jul 2022 15:38:42 GMT
Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule
 is not logged
In-Reply-To: <R0zl8UunTV29IF1LgFlH2Xns12lg9ni2gTAEyHOtNI4=.9ea5aa0d-f7dd-4ac1-9b3f-b5f84b2f4a99@github.com>
References: <R0zl8UunTV29IF1LgFlH2Xns12lg9ni2gTAEyHOtNI4=.9ea5aa0d-f7dd-4ac1-9b3f-b5f84b2f4a99@github.com>
Message-ID: <xPYXbaoIM6ZQx7S1Bt82NsHGi44PaImImLoIDxexTa4=.8288af24-bf4b-485a-9d06-2e9d5509c46c@github.com>

On Tue, 14 Jun 2022 19:07:24 GMT, Jayashree Huttanagoudar <duke at openjdk.org> wrote:

> Could you please review the changes?
> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug

Ok. So the steps what I followed to confirm the patch can be converted to test case?

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

PR: https://git.openjdk.org/jdk/pull/9159

From kdriver at openjdk.org  Thu Jul  7 19:31:09 2022
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 7 Jul 2022 19:31:09 GMT
Subject: RFR: 8289939: Add flag to restrict public exponent as described in SP
 800-56B
Message-ID: <EscA4XUvqqsANjaJecqb3sBqU9TGIWhD1vhEoyju2_g=.92cbd78f-acb6-42eb-af78-a92e93633a6a@github.com>

[SP 800-56B](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Br2.pdf) stipulates that the publicExponent e "shall" be 65,537 ? e < 2^256

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

Commit messages:
 - initial commit for JDK-8289939

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

PR: https://git.openjdk.org/jdk/pull/9413

From cjplummer at openjdk.org  Thu Jul  7 19:16:48 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 7 Jul 2022 19:16:48 GMT
Subject: RFR: 8289768: Clean up unused code [v2]
In-Reply-To: <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
 <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>
Message-ID: <7Cpve0LsselBf8cHCfT_4qs3j1XeaNFmxP62RFSMW8A=.8d642396-9421-4099-bfad-21aeeffaaa35@github.com>

On Wed, 6 Jul 2022 05:32:29 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
>> 
>> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
>> 
>> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.
>
> Daniel Jeli?ski 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 remote-tracking branch 'origin' into unused-variables
>  - Remove unused variables (windows)
>  - Remove unused variables (macos)
>  - Remove unused variables (linux)

Are you going to update copyrights?

I reviewed src/jdk.hotspot.agent, src/jdk.jdi/, src/jdk.jdwp.agent, and src/jdk.management. Looks good other than copyrights and the suggestion I made for additional cleanup in symtab.c.

src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c line 308:

> 306:   ELF_SHDR* shbuf = NULL;
> 307:   ELF_SHDR* cursct = NULL;
> 308:   ELF_PHDR* phbuf = NULL;

phbuf is also essentially unused. The only reference is to free it if non-null, but it's always NULL, so that code can be removed too.

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

Changes requested by cjplummer (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9383

From valeriep at openjdk.org  Thu Jul  7 17:18:29 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 7 Jul 2022 17:18:29 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v2]
In-Reply-To: <bz8vrsVAzSmlFQJFpM8cH9LxpkYa41QAyOmbaNv1jcM=.6414412a-df47-4d70-878d-34e98643e0f5@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <cbBU6Io87Hy3zGYcPT6Eeymm5lvTIBnYtPLRDMtEac4=.94bf50d4-f6d6-4408-aff4-49676ecbc8c9@github.com>
 <qrl1PL4Xjwex0DDEN4oiLt7SXhtyzDfT0axLlo1KWsA=.82615098-8dfd-407e-9d6a-2cf26e65fa7c@github.com>
 <bz8vrsVAzSmlFQJFpM8cH9LxpkYa41QAyOmbaNv1jcM=.6414412a-df47-4d70-878d-34e98643e0f5@github.com>
Message-ID: <KcldRukAs0hWi9SDC3C3EqGVN2jBIo8972E3t1VXsWs=.b6e5b855-e7da-448d-bd01-37237c7bf5a7@github.com>

On Thu, 30 Jun 2022 16:19:17 GMT, Mark Powers <duke at openjdk.org> wrote:

>> src/java.base/share/classes/javax/crypto/SealedObject.java line 195:
>> 
>>> 193:     /**
>>> 194:      * Constructs a <code>SealedObject</code> object from the passed-in
>>> 195:      * SealedObject.
>> 
>> Add `{@code }` to SealedObject?
>
> using `{@code }`

I mean the SealedObject on line 195.

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

PR: https://git.openjdk.org/jdk/pull/9282

From duke at openjdk.org  Thu Jul  7 15:40:45 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Thu, 7 Jul 2022 15:40:45 GMT
Subject: RFR: 8283082:
 sun.security.x509.X509CertImpl.delete("x509.info.validity") nulls out info
 field [v2]
In-Reply-To: <e5ASBwCiMjJawr8hAEenZN1ozwSsrQBhmNhWvYKYPBU=.78e9415a-ae24-46a6-9896-bec46892bd20@github.com>
References: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
 <5xpsI8QNjiQl0Byp3HKwgnQ5dZH7RUiX0OwdO6rbNF4=.ba3bc008-f086-40d9-90a0-a05bdcc82e7e@github.com>
 <9eTwVSU1M262dL4z3vJX2jv8uTDH9IRR_M_-gdzynrk=.af93307c-f9bc-42b0-9e53-388171ab6083@github.com>
 <lkRfon7i8kkzHkqDB-427qxmhgv95Opu9P1FJ4DSz3A=.a8b4c470-f871-43a5-8d42-2b42dce8e443@github.com>
 <e5ASBwCiMjJawr8hAEenZN1ozwSsrQBhmNhWvYKYPBU=.78e9415a-ae24-46a6-9896-bec46892bd20@github.com>
Message-ID: <3znsBRXPvnI_FGD2IHUUgtZtx2GTK-LfwU8wKqPh0P4=.29e69dc0-f2f7-4c3b-9ca7-129e633266d2@github.com>

On Thu, 7 Jul 2022 14:03:42 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Thanks for adding the test. It looks fine. The name is good.
> 
> Please add a copyright header and a `@test` block comment. You can find a nearby existing test file and see what they look like. Since the new test references internal classes, a `@modules java.base/sun.security.x509` is necessary. Please run the test with the `jtreg` command to ensure everything is correct. Before your fix, the test should fail; and after it, it should succeed.

Ok Sure :) Thanks for suggesting this.

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

PR: https://git.openjdk.org/jdk/pull/9306

From hchao at openjdk.org  Thu Jul  7 18:37:52 2022
From: hchao at openjdk.org (Hai-May Chao)
Date: Thu, 7 Jul 2022 18:37:52 GMT
Subject: RFR: 6522064: Aliases from Microsoft CryptoAPI has bad character
 encoding
In-Reply-To: <qBrTitaiup671MjRvJo8F3BnAvwzwOXYobE6eQLqWuA=.fae8fa8a-a38d-48dd-b4fc-3509a6616aee@github.com>
References: <qBrTitaiup671MjRvJo8F3BnAvwzwOXYobE6eQLqWuA=.fae8fa8a-a38d-48dd-b4fc-3509a6616aee@github.com>
Message-ID: <HpSb893tJvE9NF0N9arqxuntVK0Vr3cAg6YDmbtLf6Y=.3984db42-2913-428d-b0ed-46b725ee1582@github.com>

On Wed, 8 Jun 2022 13:42:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Switch to wide char version of `CertGetNameString` to get the non-ASCII name.

Marked as reviewed by hchao (Committer).

Test case looks good.

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

PR: https://git.openjdk.org/jdk/pull/9085

From duke at openjdk.org  Thu Jul  7 18:48:59 2022
From: duke at openjdk.org (Mark Powers)
Date: Thu, 7 Jul 2022 18:48:59 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v8]
In-Reply-To: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
Message-ID: <WDgtnIc8tvMkv_iAF8_l18USmn5iQbCxDFF0grsoBFc=.a923b1cb-5b94-404c-bc35-e69656f02297@github.com>

> https://bugs.openjdk.org/browse/JDK-8284851

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

  final comments from Valerie

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9282/files
  - new: https://git.openjdk.org/jdk/pull/9282/files/54310a1a..cd390f9b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9282&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9282&range=06-07

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

PR: https://git.openjdk.org/jdk/pull/9282

From weijun at openjdk.org  Thu Jul  7 14:02:47 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 7 Jul 2022 14:02:47 GMT
Subject: RFR: 8283082:
 sun.security.x509.X509CertImpl.delete("x509.info.validity") nulls out info
 field [v3]
In-Reply-To: <Zxft7h2QnF1SMXLmvwAGCxARqYCFg28mGghxQqZs9jY=.72635478-69dd-433d-b8d6-a8d8ede67dc3@github.com>
References: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
 <Zxft7h2QnF1SMXLmvwAGCxARqYCFg28mGghxQqZs9jY=.72635478-69dd-433d-b8d6-a8d8ede67dc3@github.com>
Message-ID: <wS7ogc5VtTP3jOa2iBblofPxDxdbl_LUEQ-KQKhOEKw=.0d4ef8c1-1e82-4606-acc9-3cf39822103c@github.com>

On Wed, 29 Jun 2022 16:08:01 GMT, Jayashree Huttanagoudar <duke at openjdk.org> wrote:

>> Could you please review the changes?
>> This is to address the issue: https://bugs.openjdk.org/browse/JDK-8283082?jql=labels%20%3D%20starter-bug
>
> Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments. Add regression test for the change

You can expand the "Run Tests" task and see the failed one (it's very long). It's a linux-x86 test and it mentions "thread". I've heard that thread-related tests could fail on linux-x86 because loom support was only added to linux-x64. Unless you heard from someone else that it's a real issue, I think you can ignore it.

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

PR: https://git.openjdk.org/jdk/pull/9306

From valeriep at openjdk.org  Thu Jul  7 20:01:19 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 7 Jul 2022 20:01:19 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v8]
In-Reply-To: <WDgtnIc8tvMkv_iAF8_l18USmn5iQbCxDFF0grsoBFc=.a923b1cb-5b94-404c-bc35-e69656f02297@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <WDgtnIc8tvMkv_iAF8_l18USmn5iQbCxDFF0grsoBFc=.a923b1cb-5b94-404c-bc35-e69656f02297@github.com>
Message-ID: <qXyFGYnKuuxH321wqvm0FI4I2S4Q5DK6JnVl9GxGCAU=.ed6b317e-f243-41f8-86d3-83c564d648a9@github.com>

On Thu, 7 Jul 2022 18:48:59 GMT, Mark Powers <duke at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8284851
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   final comments from Valerie

Ok with the changes under javax.crypto package.

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

Marked as reviewed by valeriep (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9282

From kdriver at openjdk.org  Thu Jul  7 20:14:24 2022
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 7 Jul 2022 20:14:24 GMT
Subject: RFR: 8289939: Add flag to restrict public exponent as described in
 SP 800-56B [v2]
In-Reply-To: <EscA4XUvqqsANjaJecqb3sBqU9TGIWhD1vhEoyju2_g=.92cbd78f-acb6-42eb-af78-a92e93633a6a@github.com>
References: <EscA4XUvqqsANjaJecqb3sBqU9TGIWhD1vhEoyju2_g=.92cbd78f-acb6-42eb-af78-a92e93633a6a@github.com>
Message-ID: <N8MYAw9aklYsQbqjzwu95VT8OBMEeeJgFb-l-rcrNsI=.8662d03e-75ba-4d76-95b0-053d22d0bb55@github.com>

> [SP 800-56B](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Br2.pdf) stipulates that the publicExponent e "shall" be 65,537 ? e < 2^256

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

  update copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9413/files
  - new: https://git.openjdk.org/jdk/pull/9413/files/102caf7d..104436b7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9413&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9413&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/9413

From valeriep at openjdk.org  Thu Jul  7 17:18:27 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 7 Jul 2022 17:18:27 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v7]
In-Reply-To: <vx7uWo4UNOJ_GJ6ndEtZgT4_ajkF6rUtEjJSv_uaItI=.e5b10bcb-040d-4d5e-bfd2-dc74f35b03d2@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <vx7uWo4UNOJ_GJ6ndEtZgT4_ajkF6rUtEjJSv_uaItI=.e5b10bcb-040d-4d5e-bfd2-dc74f35b03d2@github.com>
Message-ID: <51XNA0pF0NzVfncX6OPorE-xeugDfatSVuMzeW_3WGM=.30cf9b8a-6a17-4cd5-9a16-7b5bed423090@github.com>

On Thu, 7 Jul 2022 02:45:42 GMT, Mark Powers <duke at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8284851
>
> Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Merge
>  - comments from Valerie and Max
>  - aw shucks - another one
>  - Max comments continued
>  - Max comments
>  - Valerie fix continued
>  - Valerie fix
>  - mo polish
>  - polish
>  - Merge
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/88dd9d95...54310a1a

src/java.base/share/classes/javax/crypto/MacSpi.java line 96:

> 94:     /**
> 95:      * Processes {@code input.remaining()} bytes in the ByteBuffer
> 96:      * {@code input}, starting at {@code input.position()}.

Hmm, should these be {@code input}.remaining() and {@code input}.position()?

src/java.base/share/classes/javax/crypto/SealedObject.java line 43:

> 41:  * confidentiality with a cryptographic algorithm.
> 42:  *
> 43:  * <p> Given any Serializable object, one can create a {@code SealedObject}

add {@code } to Serializable?

src/java.base/share/classes/javax/crypto/SealedObject.java line 125:

> 123:      * encoded in the default format.
> 124:      * <p>
> 125:      * That is, {@code cipher.getParameters().getEncoded()}.

cipher -> Cipher?

src/java.base/share/classes/javax/crypto/SealedObject.java line 132:

> 130: 
> 131:     /**
> 132:      * Constructs a {@code SealedObject} from any Serializable object.

add {@code } to Serializable?

src/java.base/share/classes/javax/crypto/SealedObject.java line 227:

> 225:      * the sealing operation.
> 226:      * If the default provider package provides an implementation of that
> 227:      * algorithm, an instance of {@code Cipher} object containing that

"an instance of" seems redundant now that you added "object"

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

PR: https://git.openjdk.org/jdk/pull/9282

From weijun at openjdk.org  Thu Jul  7 18:56:41 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 7 Jul 2022 18:56:41 GMT
Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule
 is not logged
In-Reply-To: <R0zl8UunTV29IF1LgFlH2Xns12lg9ni2gTAEyHOtNI4=.9ea5aa0d-f7dd-4ac1-9b3f-b5f84b2f4a99@github.com>
References: <R0zl8UunTV29IF1LgFlH2Xns12lg9ni2gTAEyHOtNI4=.9ea5aa0d-f7dd-4ac1-9b3f-b5f84b2f4a99@github.com>
Message-ID: <b19RJ6Ok7iroXcIRts3MTA4myKgGN2OdjQpb5Bybpg0=.24059f23-fe35-4ce4-91f5-e0926ebee16c@github.com>

On Tue, 14 Jun 2022 19:07:24 GMT, Jayashree Huttanagoudar <duke at openjdk.org> wrote:

> Could you please review the changes?
> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug

Yes, or you can write an individual test.

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

PR: https://git.openjdk.org/jdk/pull/9159

From duke at openjdk.org  Thu Jul  7 18:21:01 2022
From: duke at openjdk.org (zzambers)
Date: Thu, 7 Jul 2022 18:21:01 GMT
Subject: Integrated: 8289301: P11Cipher should not throw out of bounds
 exception during padding
In-Reply-To: <3JHTrgtISq3EoVHE0JI_5ZHT-8TaLC8GB9bTyXGaPEI=.09128ed2-6b77-4aa4-bd4e-ca1594ec4371@github.com>
References: <3JHTrgtISq3EoVHE0JI_5ZHT-8TaLC8GB9bTyXGaPEI=.09128ed2-6b77-4aa4-bd4e-ca1594ec4371@github.com>
Message-ID: <KAEqMT_U5Thl_xMxaYzFxakaVgWYf-thmyouYDiDJLE=.4197d7ad-3d2d-45e7-b80b-e74f94eb8f4d@github.com>

On Tue, 28 Jun 2022 12:57:21 GMT, zzambers <duke at openjdk.org> wrote:

> SunPkcs11 provider throws out of bounds exception during encryption when specific conditions are met.
> 
> Exception:
> 
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 32
> 	at java.base/java.util.Arrays.rangeCheck(Arrays.java:725)
> 	at java.base/java.util.Arrays.fill(Arrays.java:3308)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher$PKCS5Padding.setPaddingBytes(P11Cipher.java:96)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.implDoFinal(P11Cipher.java:813)
> 	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Cipher.engineDoFinal(P11Cipher.java:585)
> 	at java.base/javax.crypto.Cipher.doFinal(Cipher.java:2417)
> ...
> 
> 
> Details:
> This problems happens when reqBlockUpdates is true and implUpdate, which does not end on block boundary, is performed followed by final implUpdate, which ends exactly on block boundary. In that case final implUpdate fills padBuffer and then just returns. [1] Following implDoFinal then tries to add padding and throws OOB exception. Problem is, that in this case (input is multiple of block size) whole padding block should be added, but there is no space for it in padBuffer causing OOB exception.
> 
> Solution:
> Solution is to detect this case (implDoFinal is called with full padBuffer) and to perform additional C_EncryptUpdate to free up padBuffer so that padBuffer can than be used to add whole new padding block.
> 
> [1] https://github.com/openjdk/jdk/blob/d4eeeb82cb2288973a6a247c54513f7e1c6b58f0/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java#L622

This pull request has now been integrated.

Changeset: 3e60e828
Author:    Zdenek Zambersky <zzambers at redhat.com>
Committer: Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3e60e828148a0490a4422d0724d15f3eccec17f0
Stats:     124 lines in 2 files changed: 117 ins; 0 del; 7 mod

8289301: P11Cipher should not throw out of bounds exception during padding

Reviewed-by: valeriep

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

PR: https://git.openjdk.org/jdk/pull/9310

From duke at openjdk.org  Thu Jul  7 18:44:25 2022
From: duke at openjdk.org (Mark Powers)
Date: Thu, 7 Jul 2022 18:44:25 GMT
Subject: RFR: JDK-8284851 Update javax.crypto files to use proper javadoc
 for mentioned classes [v7]
In-Reply-To: <NhqLH2H5WLnlfeFlUtH-Jv4z-OUtZbJGqZ3AK95tLAY=.b93937e9-a80c-41b2-a3d7-5b3c45731415@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
 <vx7uWo4UNOJ_GJ6ndEtZgT4_ajkF6rUtEjJSv_uaItI=.e5b10bcb-040d-4d5e-bfd2-dc74f35b03d2@github.com>
 <NhqLH2H5WLnlfeFlUtH-Jv4z-OUtZbJGqZ3AK95tLAY=.b93937e9-a80c-41b2-a3d7-5b3c45731415@github.com>
Message-ID: <YaUojs9vj71AkCad8iu8IiOoV6BfWfzZT_uS9veKDyo=.b1edfe5c-15fe-4305-95f9-dc1d74f1d579@github.com>

On Thu, 7 Jul 2022 17:35:08 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Mark Powers has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
>> 
>>  - Merge
>>  - comments from Valerie and Max
>>  - aw shucks - another one
>>  - Max comments continued
>>  - Max comments
>>  - Valerie fix continued
>>  - Valerie fix
>>  - mo polish
>>  - polish
>>  - Merge
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/ca0ee471...54310a1a
>
> src/java.base/share/classes/javax/crypto/CryptoAllPermission.java line 98:
> 
>> 96:      *
>> 97:      * @return a new {@code PermissionCollection} object suitable for
>> 98:      * storing {@code CryptoAllPermissions} objects.
> 
> typo: CryptoAllPermissions -> CryptoAllPermission?

Fixed.

> src/java.base/share/classes/javax/crypto/CryptoAllPermission.java line 126:
> 
>> 124: 
>> 125:     /**
>> 126:      * Create an empty {@code CryptoAllPermission} object.
> 
> typo: CryptoAllPermissions -> CryptoAllPermission?

It's already fixed.

> src/java.base/share/classes/javax/crypto/MacSpi.java line 96:
> 
>> 94:     /**
>> 95:      * Processes {@code input.remaining()} bytes in the ByteBuffer
>> 96:      * {@code input}, starting at {@code input.position()}.
> 
> Hmm, should these be {@code input}.remaining() and {@code input}.position()?

No.

> src/java.base/share/classes/javax/crypto/SealedObject.java line 43:
> 
>> 41:  * confidentiality with a cryptographic algorithm.
>> 42:  *
>> 43:  * <p> Given any Serializable object, one can create a {@code SealedObject}
> 
> add {@code } to Serializable?

Fixed.

> src/java.base/share/classes/javax/crypto/SealedObject.java line 125:
> 
>> 123:      * encoded in the default format.
>> 124:      * <p>
>> 125:      * That is, {@code cipher.getParameters().getEncoded()}.
> 
> cipher -> Cipher?

Fixed.

> src/java.base/share/classes/javax/crypto/SealedObject.java line 132:
> 
>> 130: 
>> 131:     /**
>> 132:      * Constructs a {@code SealedObject} from any Serializable object.
> 
> add {@code } to Serializable?

Fixed.

> src/java.base/share/classes/javax/crypto/SealedObject.java line 227:
> 
>> 225:      * the sealing operation.
>> 226:      * If the default provider package provides an implementation of that
>> 227:      * algorithm, an instance of {@code Cipher} object containing that
> 
> "an instance of" seems redundant now that you added "object"

Fixed.

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

PR: https://git.openjdk.org/jdk/pull/9282

From duke at openjdk.org  Thu Jul  7 23:24:40 2022
From: duke at openjdk.org (Mark Powers)
Date: Thu, 7 Jul 2022 23:24:40 GMT
Subject: Integrated: JDK-8284851 Update javax.crypto files to use proper
 javadoc for mentioned classes
In-Reply-To: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
References: <BZKYXg-d1eULnuqZcrLG8-32hPsku1IKe2YlA9im734=.2858d7f2-ecb6-44d3-be7a-e0522e7f0c66@github.com>
Message-ID: <r-9pzY4qy8z7g8kgw3ZCpHsf342wnI9nFqce24qwDC8=.03928344-e032-491a-ad00-6d6eee9a042b@github.com>

On Fri, 24 Jun 2022 16:48:46 GMT, Mark Powers <duke at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8284851

This pull request has now been integrated.

Changeset: f804f2ce
Author:    Mark Powers <mark.powers at oracle.com>
Committer: Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f804f2ce8ef7a859aae021b20cbdcd9e34f9fb94
Stats:     2149 lines in 92 files changed: 138 ins; 6 del; 2005 mod

8284851: Update javax.crypto files to use proper javadoc for mentioned classes

Reviewed-by: weijun, valeriep

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

PR: https://git.openjdk.org/jdk/pull/9282

From weijun at openjdk.org  Fri Jul  8 04:06:37 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 8 Jul 2022 04:06:37 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after login
 failure
Message-ID: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>

Add null-checks in all `LoginModule` implementations. It's possible that an application calls `logout` after a login failure, where most internal variables for principals and credentials are null and removing a null from the `Subject`'s principals and credentials sets will trigger a `NullPointerException`.

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

Commit messages:
 - more null check inside collections
 - implSpec, some javadoc cstyle change
 - the fix

Changes: https://git.openjdk.org/jdk/pull/9348/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9348&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8282730
  Stats: 199 lines in 9 files changed: 148 ins; 2 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/9348.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9348/head:pull/9348

PR: https://git.openjdk.org/jdk/pull/9348

From coleenp at openjdk.org  Thu Jul  7 23:30:25 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 7 Jul 2022 23:30:25 GMT
Subject: RFR: 8271707: migrate tests to use jdk.test.whitebox.WhiteBox
Message-ID: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>

This change uses sed to change sun.hotspot.WhiteBox to jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly.  Due to indirect inclusions of some of the test libraries, changing a few wasn't a reliable option, and I need the new one for a different change I was looking at.
The non-sed changes are for jdk/test/whitebox/WhiteBox to add some code for GC that was only added to the sun version.
Also, the ClassFileInstaller has a label for sun.hotspot.Whitebox so that didn't change with the edit.
Tested with tiers1-6.

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

Commit messages:
 - 8271707: migrate tests to use jdk.test.whitebox.WhiteBox

Changes: https://git.openjdk.org/jdk/pull/9417/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9417&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8271707
  Stats: 2995 lines in 984 files changed: 6 ins; 0 del; 2989 mod
  Patch: https://git.openjdk.org/jdk/pull/9417.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9417/head:pull/9417

PR: https://git.openjdk.org/jdk/pull/9417

From valeriep at openjdk.org  Thu Jul  7 22:01:40 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 7 Jul 2022 22:01:40 GMT
Subject: RFR: 8289275: Remove incorrect __declspec(dllimport) attributes
 from pointers in jdk.crypto.cryptoki
In-Reply-To: <yM6fqtQfhPvlMnxnqJbc1H-A3SJ0f6n4ee2zgGCmD7M=.d388accc-1210-40e7-8ae6-11118cec5156@github.com>
References: <yM6fqtQfhPvlMnxnqJbc1H-A3SJ0f6n4ee2zgGCmD7M=.d388accc-1210-40e7-8ae6-11118cec5156@github.com>
Message-ID: <RAmmcj30-EkE6RgXo7rTp4M8RyaNAt5wBOcBpvxiLn0=.76b2d61e-4dc6-4958-8a2d-3ada3cfc4c98@github.com>

On Sat, 2 Jul 2022 02:12:15 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Several instances of function pointers in jdk.crypto.cryptoki are marked with the dllimport attribute, which should only be applied to symbol declarations, of which a typedef'd function pointer is not. This would only be useful if a function pointer defined in the linked dll is desired to be imported, not if the pointer itself is created locally and used to store a function address. In addition to being incorrect, at least on the versions of Visual C++ the JDK supports today, it is also redundant; Typically they are used to avoid an indirect stub that jumps to the proper entry in the import address table, but usage of these typedefs involves loading the address of a function and directly (Usually through GetProcAddress, even in other cases it would simply be set to the address of a function anyway) assigning it to the pointer before immediately dispatching when called, which bypasses this procedure entirely and makes the attribute pointless.

pkcs11.h is a standard header file from OASIS. Best to leave it alone. Just my .02.

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

PR: https://git.openjdk.org/jdk/pull/9353

From weijun at openjdk.org  Fri Jul  8 04:06:39 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 8 Jul 2022 04:06:39 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after
 login failure
In-Reply-To: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
References: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
Message-ID: <Tng9jgPX0V5AL7yrsmF95-uIGl9T6XYeFy11QVoOjBs=.f4a6876b-1ffa-4c28-a241-e1c1310d033f@github.com>

On Fri, 1 Jul 2022 17:31:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add null-checks in all `LoginModule` implementations. It's possible that an application calls `logout` after a login failure, where most internal variables for principals and credentials are null and removing a null from the `Subject`'s principals and credentials sets will trigger a `NullPointerException`.

src/jdk.security.auth/share/classes/com/sun/security/auth/module/JndiLoginModule.java line 485:

> 483:         if (supplementaryGroups != null) {
> 484:             for (int i = 0; i < supplementaryGroups.size(); i++) {
> 485:                 subject.getPrincipals().remove(supplementaryGroups.get(i));

To be safest, I can check if `supplementaryGroups.get(i)` is null too. Same in `NTLoginModule` and `UnixLoginModule`.

src/jdk.security.auth/share/classes/com/sun/security/auth/module/NTLoginModule.java line 368:

> 366:         }
> 367:         if (groups != null) {
> 368:             for (int i = 0; groups != null && i < groups.length; i++) {

Oops, `groups != null` is already checked here. Will revert.

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

PR: https://git.openjdk.org/jdk/pull/9348

From lmesnik at openjdk.org  Fri Jul  8 00:53:43 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 8 Jul 2022 00:53:43 GMT
Subject: RFR: 8271707: migrate tests to use jdk.test.whitebox.WhiteBox
In-Reply-To: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>
References: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>
Message-ID: <dGq1uotyXJlQ3HTcsiMP6dG6n-5Q3lzNG-b8kG29OUU=.523bd006-466d-40e4-8845-51f2768cd226@github.com>

On Thu, 7 Jul 2022 20:43:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change uses sed to change sun.hotspot.WhiteBox to jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly.  Due to indirect inclusions of some of the test libraries, changing a few wasn't a reliable option, and I need the new one for a different change I was looking at.
> The non-sed changes are for jdk/test/whitebox/WhiteBox to add some code for GC that was only added to the sun version.
> Also, the ClassFileInstaller has a label for sun.hotspot.Whitebox so that didn't change with the edit.
> Tested with tiers1-6.

Marked as reviewed by lmesnik (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9417

From duke at openjdk.org  Fri Jul  8 07:39:46 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 8 Jul 2022 07:39:46 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[]
In-Reply-To: <Xg9s8Vevl5-T8n4HJ8iQuIwxbU3ny9nLpD_5X_H7Yes=.1d9d7d50-f37c-4e33-8ca0-0b89af3f0a7b@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
 <Xg9s8Vevl5-T8n4HJ8iQuIwxbU3ny9nLpD_5X_H7Yes=.1d9d7d50-f37c-4e33-8ca0-0b89af3f0a7b@github.com>
Message-ID: <nKquvMxiD3EKvHHXEffLjQPfv0boqHtD8rZQ03UVkkQ=.5f86c56b-b5a5-4fe5-a7cc-4fb041828ca1@github.com>

On Thu, 7 Jul 2022 18:45:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null.
>> 
>> Benchmark results:
>> 
>> before
>> 
>> Benchmark                                                  Mode  Cnt  Score   Error  Units
>> StringConstructor.newStringFromArray                       avgt   50  4,815 ? 0,154  ns/op
>> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,462 ? 0,068  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,653 ? 0,040  ns/op
>> StringConstructor.newStringFromRangedArray                 avgt   50  5,090 ? 0,066  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,550 ? 0,041  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  8,080 ? 0,055  ns/op
>> 
>> after
>> 
>> Benchmark                                                  Mode  Cnt  Score   Error  Units
>> StringConstructor.newStringFromArray                       avgt   50  4,595 ? 0,053  ns/op
>> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,038 ? 0,062  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,035 ? 0,031  ns/op
>> StringConstructor.newStringFromRangedArray                 avgt   50  4,084 ? 0,007  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,014 ? 0,008  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,466 ? 0,071  ns/op
>
> src/java.base/share/classes/java/lang/String.java line 1429:
> 
>> 1427:      */
>> 1428:     public String(byte[] bytes, int offset, int length) {
>> 1429:         this(bytes, offset, length, Charset.defaultCharset(), checkBoundsOffCount(offset, length, bytes.length));
> 
> Can you avoid the extra constructor by applying `checkBoundOffCount` to the offset argument; it returns the offset.
> 
> this(bytes, checkBoundsOffCount(offset, length, bytes.length), length, Charset.defaultCharset());
> 
> or call `Preconditions.checkFromIndexSize` directly.

But if I roll back the added constructor I'll go through existing public one `public String(byte[] bytes, int offset, int length, Charset charset)` doing bounds check twice, won't I?

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

PR: https://git.openjdk.org/jdk/pull/9407

From djelinski at openjdk.org  Fri Jul  8 07:08:50 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 8 Jul 2022 07:08:50 GMT
Subject: RFR: 8289768: Clean up unused code [v2]
In-Reply-To: <7Cpve0LsselBf8cHCfT_4qs3j1XeaNFmxP62RFSMW8A=.8d642396-9421-4099-bfad-21aeeffaaa35@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
 <umrx8D9dOcsFUPI5GdEOsuWNNVw_nBeV_2GlhdsIJy0=.08bd28d4-a345-4d83-8f53-1e7bae70b939@github.com>
 <7Cpve0LsselBf8cHCfT_4qs3j1XeaNFmxP62RFSMW8A=.8d642396-9421-4099-bfad-21aeeffaaa35@github.com>
Message-ID: <5lYmVui3caVoMyThlWMlQP1etBfuLQan6v6OUIBYh_o=.e1d33b03-8791-4462-a9e7-b13287df2aa8@github.com>

On Thu, 7 Jul 2022 19:06:52 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Daniel Jeli?ski 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 remote-tracking branch 'origin' into unused-variables
>>  - Remove unused variables (windows)
>>  - Remove unused variables (macos)
>>  - Remove unused variables (linux)
>
> src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c line 308:
> 
>> 306:   ELF_SHDR* shbuf = NULL;
>> 307:   ELF_SHDR* cursct = NULL;
>> 308:   ELF_PHDR* phbuf = NULL;
> 
> phbuf is also essentially unused. The only reference is to free it if non-null, but it's always NULL, so that code can be removed too.

Good catch! Also removed similar code from macOS version.

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

PR: https://git.openjdk.org/jdk/pull/9383

From duke at openjdk.org  Fri Jul  8 09:13:51 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Fri, 8 Jul 2022 09:13:51 GMT
Subject: RFR: 8283082:
 sun.security.x509.X509CertImpl.delete("x509.info.validity") nulls out info
 field [v5]
In-Reply-To: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
References: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
Message-ID: <V2GuKDqPdn7D6QNUwtzu57hOxMeXwiDui6atvoXHUwk=.8b2e22df-d76b-4aea-ba22-c324f5ce8499@github.com>

> Could you please review the changes?
> This is to address the issue: https://bugs.openjdk.org/browse/JDK-8283082?jql=labels%20%3D%20starter-bug

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

  Address trailing whitespace reported by jcheck in GHA

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9306/files
  - new: https://git.openjdk.org/jdk/pull/9306/files/fcafa9d0..d74fedd5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9306&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9306&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/9306

From duke at openjdk.org  Fri Jul  8 09:07:39 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Fri, 8 Jul 2022 09:07:39 GMT
Subject: RFR: 8283082:
 sun.security.x509.X509CertImpl.delete("x509.info.validity") nulls out info
 field [v4]
In-Reply-To: <fQ9nyipH3fNpgrNNtWGwZA0vzfKi1T7VUU3BZTrPMc0=.89957b7e-e2a9-42ea-8f22-a584751a1f7f@github.com>
References: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
 <fQ9nyipH3fNpgrNNtWGwZA0vzfKi1T7VUU3BZTrPMc0=.89957b7e-e2a9-42ea-8f22-a584751a1f7f@github.com>
Message-ID: <pWD2MFhQHX726xC7P-PztaQohlK7hj_WsljQEZpvc2s=.e2183661-c1d3-4d33-aa6e-91cd09f31ad6@github.com>

On Fri, 8 Jul 2022 09:00:56 GMT, Jayashree Huttanagoudar <duke at openjdk.org> wrote:

>> Could you please review the changes?
>> This is to address the issue: https://bugs.openjdk.org/browse/JDK-8283082?jql=labels%20%3D%20starter-bug
>
> Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment to polish regression test.
>   - Verified the newly added test case before and after the patch.

I made the suggested changes to the test case and verified before and after the patch with jtreg.
Steps followed are as below:

export JTREG_JAVA=/usr/bin/java

Before Patch:

jtreg/bin/jtreg -jdk:/root/jdk/build.master/linux-x86_64-server-release/images/jdk/ test/jdk/sun/security/x509/X509CertImpl/
Test results: passed: 5; failed: 1
Report written to /root/jdk/JTreport/html/report.html
Results written to /root/jdk/JTwork
Error: Some tests failed or other problems occurred.

# cat /root/jdk/JTwork/jtData/harness.trace
# Trace file started at 2022-07-08T04:47:29-0400
# JT Harness version 6.0
# class directory: /root/jdk/jtreg/lib/javatest.jar
# using java: /usr/lib/jvm/java-18-openjdk-18.0.1.0.10-1.rolling.fc36.x86_64
2022-07-08T04:47:29-0400 Starting tests.
Test suite class: com.sun.javatest.regtest.config.RegressionTestSuite
Test finder class: com.sun.javatest.regtest.config.RegressionTestFinder
2022-07-08T04:47:30-0400 Test starting: sun/security/x509/X509CertImpl/CertificateValidation.java
2022-07-08T04:47:30-0400 Test finished: sun/security/x509/X509CertImpl/CertificateValidation.java: Passed. Execution successful
2022-07-08T04:47:30-0400 Test starting: sun/security/x509/X509CertImpl/ECSigParamsVerifyWithCert.java
2022-07-08T04:47:31-0400 Test finished: sun/security/x509/X509CertImpl/ECSigParamsVerifyWithCert.java: Passed. Execution successful
2022-07-08T04:47:31-0400 Test starting: sun/security/x509/X509CertImpl/GetFingerprintError.java
2022-07-08T04:47:31-0400 Test finished: sun/security/x509/X509CertImpl/GetFingerprintError.java: Passed. Execution successful
2022-07-08T04:47:31-0400 Test starting: sun/security/x509/X509CertImpl/JDK8283082.java
2022-07-08T04:47:31-0400 Test finished: sun/security/x509/X509CertImpl/JDK8283082.java: Failed. Execution failed: `main' threw exception: java.lang.NullPointerException: Cannot invoke "sun.security.x509.X509CertInfo.set(String, Object)" because "this.info" is null
2022-07-08T04:47:31-0400 Test starting: sun/security/x509/X509CertImpl/V3Certificate.java
2022-07-08T04:47:32-0400 Test finished: sun/security/x509/X509CertImpl/V3Certificate.java: Passed. Execution successful
2022-07-08T04:47:32-0400 Test starting: sun/security/x509/X509CertImpl/Verify.java
2022-07-08T04:47:32-0400 Test finished: sun/security/x509/X509CertImpl/Verify.java: Passed. Execution successful
2022-07-08T04:47:32-0400 Doing post-run cleanup
2022-07-08T04:47:32-0400 Completed: Some tests did not pass


After Patch:

jtreg/bin/jtreg -jdk:/root/jdk/build.8283082/linux-x86_64-server-release/images/jdk/ test/jdk/sun/security/x509/X509CertImpl/
Directory "JTwork" not found: creating
Directory "JTreport" not found: creating
Test results: passed: 6
Report written to /root/jdk/JTreport/html/report.html
Results written to /root/jdk/JTwork

# cat /root/jdk/JTwork/jtData/harness.trace
# Trace file started at 2022-07-08T04:44:58-0400
# JT Harness version 6.0
# class directory: /root/jdk/jtreg/lib/javatest.jar
# using java: /usr/lib/jvm/java-18-openjdk-18.0.1.0.10-1.rolling.fc36.x86_64
2022-07-08T04:44:58-0400 Starting tests.
Test suite class: com.sun.javatest.regtest.config.RegressionTestSuite
Test finder class: com.sun.javatest.regtest.config.RegressionTestFinder
2022-07-08T04:44:58-0400 Test starting: sun/security/x509/X509CertImpl/CertificateValidation.java
2022-07-08T04:44:59-0400 Test finished: sun/security/x509/X509CertImpl/CertificateValidation.java: Passed. Execution successful
2022-07-08T04:44:59-0400 Test starting: sun/security/x509/X509CertImpl/ECSigParamsVerifyWithCert.java
2022-07-08T04:45:00-0400 Test finished: sun/security/x509/X509CertImpl/ECSigParamsVerifyWithCert.java: Passed. Execution successful
2022-07-08T04:45:00-0400 Test starting: sun/security/x509/X509CertImpl/GetFingerprintError.java
2022-07-08T04:45:01-0400 Test finished: sun/security/x509/X509CertImpl/GetFingerprintError.java: Passed. Execution successful
2022-07-08T04:45:01-0400 Test starting: sun/security/x509/X509CertImpl/JDK8283082.java
2022-07-08T04:45:02-0400 Test finished: sun/security/x509/X509CertImpl/JDK8283082.java: Passed. Execution successful
2022-07-08T04:45:02-0400 Test starting: sun/security/x509/X509CertImpl/V3Certificate.java
2022-07-08T04:45:04-0400 Test finished: sun/security/x509/X509CertImpl/V3Certificate.java: Passed. Execution successful
2022-07-08T04:45:04-0400 Test starting: sun/security/x509/X509CertImpl/Verify.java
2022-07-08T04:45:05-0400 Test finished: sun/security/x509/X509CertImpl/Verify.java: Passed. Execution successful
2022-07-08T04:45:05-0400 Doing post-run cleanup
2022-07-08T04:45:05-0400 Completed: All tests passed


So, this confirms that our test case is exercising the changes and producing the right results.
Could you please have a look at the recent changes?

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

PR: https://git.openjdk.org/jdk/pull/9306

From duke at openjdk.org  Fri Jul  8 09:00:56 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Fri, 8 Jul 2022 09:00:56 GMT
Subject: RFR: 8283082:
 sun.security.x509.X509CertImpl.delete("x509.info.validity") nulls out info
 field [v4]
In-Reply-To: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
References: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
Message-ID: <fQ9nyipH3fNpgrNNtWGwZA0vzfKi1T7VUU3BZTrPMc0=.89957b7e-e2a9-42ea-8f22-a584751a1f7f@github.com>

> Could you please review the changes?
> This is to address the issue: https://bugs.openjdk.org/browse/JDK-8283082?jql=labels%20%3D%20starter-bug

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

  Address review comment to polish regression test.
  - Verified the newly added test case before and after the patch.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9306/files
  - new: https://git.openjdk.org/jdk/pull/9306/files/5d89e9b0..fcafa9d0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9306&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9306&range=02-03

  Stats: 32 lines in 1 file changed: 32 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9306.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9306/head:pull/9306

PR: https://git.openjdk.org/jdk/pull/9306

From djelinski at openjdk.org  Fri Jul  8 07:08:46 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 8 Jul 2022 07:08:46 GMT
Subject: RFR: 8289768: Clean up unused code [v3]
In-Reply-To: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
Message-ID: <Omx-_YGG52LbvB5MDiNE6Pbe9KVRtIOGyX0-vlezeVY=.8fd6eeff-62e5-481a-bd49-6c405fcd7cf5@github.com>

> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
> 
> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
> 
> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.

Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:

 - Update copyright
 - Remove more unused variables

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9383/files
  - new: https://git.openjdk.org/jdk/pull/9383/files/b4cd5374..da30ef90

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9383&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9383&range=01-02

  Stats: 30 lines in 26 files changed: 0 ins; 4 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/9383.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9383/head:pull/9383

PR: https://git.openjdk.org/jdk/pull/9383

From coleenp at openjdk.org  Fri Jul  8 12:51:42 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 8 Jul 2022 12:51:42 GMT
Subject: RFR: 8271707: migrate tests to use jdk.test.whitebox.WhiteBox
In-Reply-To: <-l-lc8D0eUr1WpTplIgI8Zz2VDpvUEA_LCkxovQueek=.53c06318-45d5-4637-8fe4-adfcea65b121@github.com>
References: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>
 <-l-lc8D0eUr1WpTplIgI8Zz2VDpvUEA_LCkxovQueek=.53c06318-45d5-4637-8fe4-adfcea65b121@github.com>
Message-ID: <Yrfv7H3auoYd296-igfoIn4LX5BpmuGxetYFtRrZzH8=.ea9f5a66-f00b-48d1-a465-0adb83acd4db@github.com>

On Fri, 8 Jul 2022 06:12:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This change uses sed to change sun.hotspot.WhiteBox to jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly.  Due to indirect inclusions of some of the test libraries, changing a few wasn't a reliable option, and I need the new one for a different change I was looking at.
>> The non-sed changes are for jdk/test/whitebox/WhiteBox to add some code for GC that was only added to the sun version.
>> Also, the ClassFileInstaller has a label for sun.hotspot.Whitebox so that didn't change with the edit.
>> Tested with tiers1-6.
>
> I skimmed the diff and this seems fine.
> 
> Are we not going to remove the old WhiteBox at the same time?
> 
> Thanks.

@dholmes-ora We'll remove it with this patch JDK-8275662 and the other obsolete sun.hotspot test classes which will be easier to look at.
Thanks for reviewing.

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

PR: https://git.openjdk.org/jdk/pull/9417

From duke at openjdk.org  Fri Jul  8 11:31:46 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Fri, 8 Jul 2022 11:31:46 GMT
Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule
 is not logged
In-Reply-To: <R0zl8UunTV29IF1LgFlH2Xns12lg9ni2gTAEyHOtNI4=.9ea5aa0d-f7dd-4ac1-9b3f-b5f84b2f4a99@github.com>
References: <R0zl8UunTV29IF1LgFlH2Xns12lg9ni2gTAEyHOtNI4=.9ea5aa0d-f7dd-4ac1-9b3f-b5f84b2f4a99@github.com>
Message-ID: <vhMNc5EvGPHuhDaOcCuGUqt-4dmeMl89E1gfn8y_KPk=.eb4ceb9a-c57e-4456-bc27-5ba9341a84b7@github.com>

On Tue, 14 Jun 2022 19:07:24 GMT, Jayashree Huttanagoudar <duke at openjdk.org> wrote:

> Could you please review the changes?
> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug

Looks like already the test cases which serve our purpose to test our patch are already here: https://github.com/openjdk/jdk/tree/master/test/jdk/javax/security/auth/login/LoginContext
For eg: https://github.com/openjdk/jdk/blob/master/test/jdk/javax/security/auth/login/LoginContext/SmartLoginModule.java 
Am I guessing it right?

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

PR: https://git.openjdk.org/jdk/pull/9159

From duke at openjdk.org  Fri Jul  8 13:34:28 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Fri, 8 Jul 2022 13:34:28 GMT
Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule
 is not logged
In-Reply-To: <J-UTyB3fqztSpxV7sgEppFBixitJVR_LlhN2zCS5xd0=.453e4bc9-c593-4686-936c-e0d74a0e8043@github.com>
References: <R0zl8UunTV29IF1LgFlH2Xns12lg9ni2gTAEyHOtNI4=.9ea5aa0d-f7dd-4ac1-9b3f-b5f84b2f4a99@github.com>
 <J-UTyB3fqztSpxV7sgEppFBixitJVR_LlhN2zCS5xd0=.453e4bc9-c593-4686-936c-e0d74a0e8043@github.com>
Message-ID: <nRL4BxVrUQJc2RlriE7b9lVwVo7HlqAtcrSVJ87bE-o=.0a37c6bb-5f78-41f1-816e-c759be64a65c@github.com>

On Fri, 8 Jul 2022 13:12:23 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> `SmartLoginModule.java` is a class used by a test, itself is not one since there's no `main()` method.
> 
You are right.
> Your new test needs to be a regression test, which means before the fix it fails and after the fix it succeeds. Also, seeing the exception message in a jtreg output with your own eyes is not a test. The test itself should detect the exception and decide whether it's a success or a failure. In the case, I'd recommend you use the `System.setErr` method to store the output into a `ByteArrayOutputStream` and then look into it.

Okay! To me at present this looks like a big task to do ;) May be because I haven't written any such tests so far :)
Let me consider this as an opportunity :) I will give a try.

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

PR: https://git.openjdk.org/jdk/pull/9159

From duke at openjdk.org  Fri Jul  8 13:32:45 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Fri, 8 Jul 2022 13:32:45 GMT
Subject: RFR: 8283082:
 sun.security.x509.X509CertImpl.delete("x509.info.validity") nulls out info
 field [v5]
In-Reply-To: <Ug6oTC1Yv6IgNQSAIi6c_h3kSBDPUAhie0G9kgyrte8=.dce68f97-bab4-40a4-ba4b-de03d701ddb4@github.com>
References: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
 <V2GuKDqPdn7D6QNUwtzu57hOxMeXwiDui6atvoXHUwk=.8b2e22df-d76b-4aea-ba22-c324f5ce8499@github.com>
 <Ug6oTC1Yv6IgNQSAIi6c_h3kSBDPUAhie0G9kgyrte8=.dce68f97-bab4-40a4-ba4b-de03d701ddb4@github.com>
Message-ID: <9dm-pDXnNpJv3a2V14Jt2FzBWAhazYkAbx6MU8M5Yhg=.b457eb8b-8254-4518-bdb5-9f236a49541d@github.com>

On Fri, 8 Jul 2022 13:01:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Great, this looks good. Please use 2022 in the copyright year of the test. You might also want to use your own company's name since this is a new test. See https://github.com/openjdk/jdk/blob/1ee80e03adfae5f428519f7c134e78a0f277a0a5/test/jdk/sun/security/pkcs11/Cipher/EncryptionPadding.java for an example or ask a colleague on what the correct words should be.

Sure. Thank you.

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

PR: https://git.openjdk.org/jdk/pull/9306

From jvernee at openjdk.org  Fri Jul  8 11:25:56 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 8 Jul 2022 11:25:56 GMT
Subject: [jdk19] RFR: 8287809: Revisit implementation of memory session
 [v6]
In-Reply-To: <eR3Wu-bSjrIgEjrFw3tqt3P38BIWgYSNQNF8pYcS_Dw=.bb171234-043b-446b-8760-79e2e00a2f46@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
 <eR3Wu-bSjrIgEjrFw3tqt3P38BIWgYSNQNF8pYcS_Dw=.bb171234-043b-446b-8760-79e2e00a2f46@github.com>
Message-ID: <Sa7mZQHwuv6W_x_aoAO8UYS2n1CHScANT4yhZneli54=.0503a8db-75d5-4e40-a55e-75d20bc8507d@github.com>

On Wed, 6 Jul 2022 21:50:36 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Turn non-closeable view back into MemorySession impl

Marked as reviewed by jvernee (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/22

From kdriver at openjdk.org  Fri Jul  8 14:50:30 2022
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 8 Jul 2022 14:50:30 GMT
Subject: Withdrawn: 8289939: Add flag to restrict public exponent as described
 in SP 800-56B
In-Reply-To: <EscA4XUvqqsANjaJecqb3sBqU9TGIWhD1vhEoyju2_g=.92cbd78f-acb6-42eb-af78-a92e93633a6a@github.com>
References: <EscA4XUvqqsANjaJecqb3sBqU9TGIWhD1vhEoyju2_g=.92cbd78f-acb6-42eb-af78-a92e93633a6a@github.com>
Message-ID: <gdgobgXb4NOKh0fy6A8evGOloms3QPgya85gg-HmV2w=.1a268ead-7a5d-4adf-9237-2687c8a2d9d7@github.com>

On Thu, 7 Jul 2022 19:04:41 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

> [SP 800-56B](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Br2.pdf) stipulates that the publicExponent e "shall" be 65,537 ? e < 2^256

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/9413

From weijun at openjdk.org  Fri Jul  8 13:15:31 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 8 Jul 2022 13:15:31 GMT
Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule
 is not logged
In-Reply-To: <R0zl8UunTV29IF1LgFlH2Xns12lg9ni2gTAEyHOtNI4=.9ea5aa0d-f7dd-4ac1-9b3f-b5f84b2f4a99@github.com>
References: <R0zl8UunTV29IF1LgFlH2Xns12lg9ni2gTAEyHOtNI4=.9ea5aa0d-f7dd-4ac1-9b3f-b5f84b2f4a99@github.com>
Message-ID: <J-UTyB3fqztSpxV7sgEppFBixitJVR_LlhN2zCS5xd0=.453e4bc9-c593-4686-936c-e0d74a0e8043@github.com>

On Tue, 14 Jun 2022 19:07:24 GMT, Jayashree Huttanagoudar <duke at openjdk.org> wrote:

> Could you please review the changes?
> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug

`SmartLoginModule.java` is a class used by a test, itself is not one since there's no `main()` method.

Your new test needs to be a regression test, which means before the fix it fails and after the fix it succeeds. Also, seeing the exception message in a jtreg output with your own eyes is not a test. The test itself should detect the exception and decide whether it's a success or a failure. In the case, I'd recommend you use the `System.setErr` method to store the output into a `ByteArrayOutputStream` and then look into it.

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

PR: https://git.openjdk.org/jdk/pull/9159

From weijun at openjdk.org  Fri Jul  8 13:05:52 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 8 Jul 2022 13:05:52 GMT
Subject: RFR: 8283082:
 sun.security.x509.X509CertImpl.delete("x509.info.validity") nulls out info
 field [v5]
In-Reply-To: <V2GuKDqPdn7D6QNUwtzu57hOxMeXwiDui6atvoXHUwk=.8b2e22df-d76b-4aea-ba22-c324f5ce8499@github.com>
References: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
 <V2GuKDqPdn7D6QNUwtzu57hOxMeXwiDui6atvoXHUwk=.8b2e22df-d76b-4aea-ba22-c324f5ce8499@github.com>
Message-ID: <Ug6oTC1Yv6IgNQSAIi6c_h3kSBDPUAhie0G9kgyrte8=.dce68f97-bab4-40a4-ba4b-de03d701ddb4@github.com>

On Fri, 8 Jul 2022 09:13:51 GMT, Jayashree Huttanagoudar <duke at openjdk.org> wrote:

>> Could you please review the changes?
>> This is to address the issue: https://bugs.openjdk.org/browse/JDK-8283082?jql=labels%20%3D%20starter-bug
>
> Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address trailing whitespace reported by jcheck in GHA

Great, this looks good. Please use 2022 in the copyright year of the test. You might also want to use your own company's name since this is a new test. See https://github.com/openjdk/jdk/blob/1ee80e03adfae5f428519f7c134e78a0f277a0a5/test/jdk/sun/security/pkcs11/Cipher/EncryptionPadding.java for an example or ask a colleague on what the correct words should be.

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

PR: https://git.openjdk.org/jdk/pull/9306

From duke at openjdk.org  Fri Jul  8 13:55:47 2022
From: duke at openjdk.org (XenoAmess)
Date: Fri, 8 Jul 2022 13:55:47 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v17]
In-Reply-To: <oPgxqmLOciqOKyyiyXij5NljzGJ9bvo1SJWczC4V5ls=.1cd484f7-78d4-4f5e-9563-6d5d5af802ac@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
 <oPgxqmLOciqOKyyiyXij5NljzGJ9bvo1SJWczC4V5ls=.1cd484f7-78d4-4f5e-9563-6d5d5af802ac@github.com>
Message-ID: <ncwUG3zMZJwRuht4NVtdAYhNbJ_cOOmqFwgoKWWKAfI=.e720813d-a741-44a6-af67-78496099b8f8@github.com>

On Wed, 1 Jun 2022 16:45:35 GMT, liach <duke at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   do it as naotoj said
>
> 'the new' fix should be applied to newHashMap etc. too.

> @liach
> 
> > 'the new' fix should be applied to newHashMap etc. too.
> 
> I've filed [JDK-8289872](https://bugs.openjdk.org/browse/JDK-8289872) for this. It's a small thing but best to fix it before we forget about it.

Sorry for I already forgotten it.

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

PR: https://git.openjdk.org/jdk/pull/8302

From rriggs at openjdk.org  Fri Jul  8 14:07:32 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 8 Jul 2022 14:07:32 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[]
In-Reply-To: <nKquvMxiD3EKvHHXEffLjQPfv0boqHtD8rZQ03UVkkQ=.5f86c56b-b5a5-4fe5-a7cc-4fb041828ca1@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
 <Xg9s8Vevl5-T8n4HJ8iQuIwxbU3ny9nLpD_5X_H7Yes=.1d9d7d50-f37c-4e33-8ca0-0b89af3f0a7b@github.com>
 <nKquvMxiD3EKvHHXEffLjQPfv0boqHtD8rZQ03UVkkQ=.5f86c56b-b5a5-4fe5-a7cc-4fb041828ca1@github.com>
Message-ID: <V533Tg4Gtp3-NhSHI9Quqy_7OfuHZoPxWThQW5qP1Yw=.a80cf27d-e09a-4725-aa96-940cc55f715e@github.com>

On Fri, 8 Jul 2022 07:37:36 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/String.java line 1429:
>> 
>>> 1427:      */
>>> 1428:     public String(byte[] bytes, int offset, int length) {
>>> 1429:         this(bytes, offset, length, Charset.defaultCharset(), checkBoundsOffCount(offset, length, bytes.length));
>> 
>> Can you avoid the extra constructor by applying `checkBoundOffCount` to the offset argument; it returns the offset.
>> 
>> this(bytes, checkBoundsOffCount(offset, length, bytes.length), length, Charset.defaultCharset());
>> 
>> or call `Preconditions.checkFromIndexSize` directly.
>
> But if I roll back the added constructor I'll go through existing public one `public String(byte[] bytes, int offset, int length, Charset charset)` doing bounds check twice, won't I?

The new constructor looks very odd, especially when it does not have an explanation and doesn't describe the required preconditions for calling it.  Is there a better way than adding a non-functional argument?
The "unused" name is going to draw a warning from IntelliJ and some enterprising developer is going to try to remove it, not understanding why its there. And there is a bit of overhead pushing the extra arg.

The constructor should be private, it has a very narrow scope of use given the lack of checking its args.

It would be nice if the Hotspot compiler would recognize the llmits on the range and optimize away the checks;
it would have broader applicability then this point fix.
I would be interesting to ask the compiler folks if that's a future optimization.
These source changes make it harder to understand what's happening where; though that is sometimes work it for a noticeable performance improvement.

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

PR: https://git.openjdk.org/jdk/pull/9407

From djelinski at openjdk.org  Fri Jul  8 07:12:44 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 8 Jul 2022 07:12:44 GMT
Subject: RFR: 8289768: Clean up unused code [v3]
In-Reply-To: <Omx-_YGG52LbvB5MDiNE6Pbe9KVRtIOGyX0-vlezeVY=.8fd6eeff-62e5-481a-bd49-6c405fcd7cf5@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
 <Omx-_YGG52LbvB5MDiNE6Pbe9KVRtIOGyX0-vlezeVY=.8fd6eeff-62e5-481a-bd49-6c405fcd7cf5@github.com>
Message-ID: <2_Xy-WrhqelW5xoQnKgSrnb1WSEENT6zlJ4ZRbnJDvo=.0e7b8752-9def-459a-ac6a-1172dbd3d5f7@github.com>

On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
>> 
>> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
>> 
>> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright
>  - Remove more unused variables

Copyrights updated.

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

PR: https://git.openjdk.org/jdk/pull/9383

From alanb at openjdk.org  Fri Jul  8 08:03:39 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Jul 2022 08:03:39 GMT
Subject: RFR: 8289768: Clean up unused code [v3]
In-Reply-To: <Omx-_YGG52LbvB5MDiNE6Pbe9KVRtIOGyX0-vlezeVY=.8fd6eeff-62e5-481a-bd49-6c405fcd7cf5@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
 <Omx-_YGG52LbvB5MDiNE6Pbe9KVRtIOGyX0-vlezeVY=.8fd6eeff-62e5-481a-bd49-6c405fcd7cf5@github.com>
Message-ID: <eHLckqcFYnMhyC7rkOqTdkPozbDzFLzUdXRMmSRtWfE=.937733de-7eec-4360-b491-bdd219ad8c38@github.com>

On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
>> 
>> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
>> 
>> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright
>  - Remove more unused variables

Marked as reviewed by alanb (Reviewer).

src/java.base/windows/native/libnio/fs/WindowsNativeDispatcher.c line 686:

> 684:     LPCWSTR lpFileName = jlong_to_ptr(pathAddress);
> 685:     PSECURITY_DESCRIPTOR pSecurityDescriptor = jlong_to_ptr(descAddress);
> 686:     DWORD lengthNeeded = 0;

lengthNeeded, it seems not :-)

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

PR: https://git.openjdk.org/jdk/pull/9383

From dholmes at openjdk.org  Fri Jul  8 06:15:42 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 8 Jul 2022 06:15:42 GMT
Subject: RFR: 8271707: migrate tests to use jdk.test.whitebox.WhiteBox
In-Reply-To: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>
References: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>
Message-ID: <-l-lc8D0eUr1WpTplIgI8Zz2VDpvUEA_LCkxovQueek=.53c06318-45d5-4637-8fe4-adfcea65b121@github.com>

On Thu, 7 Jul 2022 20:43:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change uses sed to change sun.hotspot.WhiteBox to jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly.  Due to indirect inclusions of some of the test libraries, changing a few wasn't a reliable option, and I need the new one for a different change I was looking at.
> The non-sed changes are for jdk/test/whitebox/WhiteBox to add some code for GC that was only added to the sun version.
> Also, the ClassFileInstaller has a label for sun.hotspot.Whitebox so that didn't change with the edit.
> Tested with tiers1-6.

I skimmed the diff and this seems fine.

Are we not going to remove the old WhiteBox at the same time?

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9417

From cjplummer at openjdk.org  Fri Jul  8 07:20:46 2022
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 8 Jul 2022 07:20:46 GMT
Subject: RFR: 8289768: Clean up unused code [v3]
In-Reply-To: <Omx-_YGG52LbvB5MDiNE6Pbe9KVRtIOGyX0-vlezeVY=.8fd6eeff-62e5-481a-bd49-6c405fcd7cf5@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
 <Omx-_YGG52LbvB5MDiNE6Pbe9KVRtIOGyX0-vlezeVY=.8fd6eeff-62e5-481a-bd49-6c405fcd7cf5@github.com>
Message-ID: <HWiis80fIvQdlOVtea6thFNk_VbOGDHltnJPDJMdo68=.7b9929c1-1a6c-48e3-bef3-369b91fda72e@github.com>

On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
>> 
>> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
>> 
>> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright
>  - Remove more unused variables

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9383

From coleenp at openjdk.org  Fri Jul  8 15:58:31 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 8 Jul 2022 15:58:31 GMT
Subject: RFR: 8271707: migrate tests to use jdk.test.whitebox.WhiteBox
In-Reply-To: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>
References: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>
Message-ID: <2mTLTyDQH8b2csvKDlgLMlfVhSm7JJXvFcuNMeqnYO0=.ab170919-9813-40be-a097-43671975d984@github.com>

On Thu, 7 Jul 2022 20:43:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change uses sed to change sun.hotspot.WhiteBox to jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly.  Due to indirect inclusions of some of the test libraries, changing a few wasn't a reliable option, and I need the new one for a different change I was looking at.
> The non-sed changes are for jdk/test/whitebox/WhiteBox to add some code for GC that was only added to the sun version.
> Also, the ClassFileInstaller has a label for sun.hotspot.Whitebox so that didn't change with the edit.
> Tested with tiers1-6.

Thanks Leonid!

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

PR: https://git.openjdk.org/jdk/pull/9417

From coleenp at openjdk.org  Fri Jul  8 15:58:32 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 8 Jul 2022 15:58:32 GMT
Subject: Integrated: 8271707: migrate tests to use jdk.test.whitebox.WhiteBox
In-Reply-To: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>
References: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>
Message-ID: <7OYMQYFZ2rIDV87GtSdBA2jbeOcjjsCVQq_GWOPfEoU=.846e9278-06ec-4428-83e9-d2a883a04e5f@github.com>

On Thu, 7 Jul 2022 20:43:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change uses sed to change sun.hotspot.WhiteBox to jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly.  Due to indirect inclusions of some of the test libraries, changing a few wasn't a reliable option, and I need the new one for a different change I was looking at.
> The non-sed changes are for jdk/test/whitebox/WhiteBox to add some code for GC that was only added to the sun version.
> Also, the ClassFileInstaller has a label for sun.hotspot.Whitebox so that didn't change with the edit.
> Tested with tiers1-6.

This pull request has now been integrated.

Changeset: e7795851
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e7795851d2e02389e63950fef939084b18ec4bfb
Stats:     2994 lines in 984 files changed: 6 ins; 0 del; 2988 mod

8271707: migrate tests to use jdk.test.whitebox.WhiteBox

Reviewed-by: lmesnik, dholmes

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

PR: https://git.openjdk.org/jdk/pull/9417

From weijun at openjdk.org  Fri Jul  8 18:41:02 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 8 Jul 2022 18:41:02 GMT
Subject: Integrated: 6522064: Aliases from Microsoft CryptoAPI has bad
 character encoding
In-Reply-To: <qBrTitaiup671MjRvJo8F3BnAvwzwOXYobE6eQLqWuA=.fae8fa8a-a38d-48dd-b4fc-3509a6616aee@github.com>
References: <qBrTitaiup671MjRvJo8F3BnAvwzwOXYobE6eQLqWuA=.fae8fa8a-a38d-48dd-b4fc-3509a6616aee@github.com>
Message-ID: <5yZWedQTObsCCtj3RDvt-vQ3UamJAxlk-1YQivUcQ3U=.9583ce82-cad7-4d2a-992c-ac2dfbb21486@github.com>

On Wed, 8 Jun 2022 13:42:43 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Switch to wide char version of `CertGetNameString` to get the non-ASCII name.

This pull request has now been integrated.

Changeset: 1877533f
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1877533f757731e2ce918230bfb345716954fa53
Stats:     89 lines in 2 files changed: 72 ins; 0 del; 17 mod

6522064: Aliases from Microsoft CryptoAPI has bad character encoding

Reviewed-by: coffeys, hchao

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

PR: https://git.openjdk.org/jdk/pull/9085

From weijun at openjdk.org  Fri Jul  8 18:43:43 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 8 Jul 2022 18:43:43 GMT
Subject: RFR: 8282038: CipherSpi.bufferCrypt leaves plaintext copy on the
 heap
In-Reply-To: <O5UWVsxkZjOxn00cp6ctISCpdHH8_oFGR2u2yJQIKCc=.8f1e61c2-1001-412a-a8f8-dbab165029e8@github.com>
References: <Vb-A1x2DjKeO-RxrYwvGH8rZ8kFmUa81XpbM5s9Kfgk=.36ceeaa3-b5e6-4522-9fd8-29537925980d@github.com>
 <uuFFoHmUXObQpSRG9KgJGyQ5SCjvbruUpPxwfQeoOwA=.a2565dbb-ce7e-4b09-a080-00088a021e8d@github.com>
 <VoMLfDi7RSiEo_c_k097cVInxHhg4g5HtudEGUtvESw=.916e3cd5-37e8-4271-a091-0b17676749b0@github.com>
 <zOrvDJF3XU4fzaWNzkS9TS5fgAxVS8c8dbgUrcRo2YI=.0bcb1d1b-253c-4342-8484-5c8e3ff78793@github.com>
 <O5UWVsxkZjOxn00cp6ctISCpdHH8_oFGR2u2yJQIKCc=.8f1e61c2-1001-412a-a8f8-dbab165029e8@github.com>
Message-ID: <7VSPWkd9JX7cGE9xbxh9XsoZB69QbLpf0VMDSp4j0ek=.e36cbbf7-d5e5-4485-9ce9-b0be725ef994@github.com>

On Tue, 21 Jun 2022 22:06:23 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Sounds good. Rest of changes look fine.
>
> I cannot reproduce this leak, but I found more by mixing the calls on byte array and `ByteBuffer`, and data length of whole block and half block. I'll study more and maybe some sort of fuzzy testing is needed.

Oh, this is taking longer than I expected.

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

PR: https://git.openjdk.org/jdk/pull/9158

From coleenp at openjdk.org  Fri Jul  8 21:50:12 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 8 Jul 2022 21:50:12 GMT
Subject: RFR: 8275662: remove test/lib/sun/hotspot
Message-ID: <AdfhGlSY_XGwFqphwO9_Ba_w_eBJDzZ9VF4VAhqLtf0=.235ea3d8-a365-41bf-84c0-76f964dd3bef@github.com>

This change removes the last remnants of sun/hotspot/WhiteBox.java and other classes, and uses the versions in jdk/test/whitebox.
I used sed to change sun.hotspot.{gc,code,cpuinfo} to jdk.test.whitebox and deleted the old files and some references to sun.hotspot.
Tested with tier1-4.

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

Commit messages:
 - 8275662: remove test/lib/sun/hotspot

Changes: https://git.openjdk.org/jdk/pull/9434/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9434&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8275662
  Stats: 1484 lines in 99 files changed: 0 ins; 1367 del; 117 mod
  Patch: https://git.openjdk.org/jdk/pull/9434.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9434/head:pull/9434

PR: https://git.openjdk.org/jdk/pull/9434

From mseledtsov at openjdk.org  Fri Jul  8 21:50:12 2022
From: mseledtsov at openjdk.org (Mikhailo Seledtsov)
Date: Fri, 8 Jul 2022 21:50:12 GMT
Subject: RFR: 8275662: remove test/lib/sun/hotspot
In-Reply-To: <AdfhGlSY_XGwFqphwO9_Ba_w_eBJDzZ9VF4VAhqLtf0=.235ea3d8-a365-41bf-84c0-76f964dd3bef@github.com>
References: <AdfhGlSY_XGwFqphwO9_Ba_w_eBJDzZ9VF4VAhqLtf0=.235ea3d8-a365-41bf-84c0-76f964dd3bef@github.com>
Message-ID: <-s197KfRIxYZ-QIqR_c48nZlUjed9kTjHTOGOqlVHWg=.a11735f0-9e5b-44f4-907a-c11230540a87@github.com>

On Fri, 8 Jul 2022 19:46:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the last remnants of sun/hotspot/WhiteBox.java and other classes, and uses the versions in jdk/test/whitebox.
> I used sed to change sun.hotspot.{gc,code,cpuinfo} to jdk.test.whitebox and deleted the old files and some references to sun.hotspot.
> Tested with tier1-4.

Changes look good to me. Thank you.

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

Marked as reviewed by mseledtsov (Committer).

PR: https://git.openjdk.org/jdk/pull/9434

From coleenp at openjdk.org  Fri Jul  8 21:50:13 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 8 Jul 2022 21:50:13 GMT
Subject: RFR: 8275662: remove test/lib/sun/hotspot
In-Reply-To: <AdfhGlSY_XGwFqphwO9_Ba_w_eBJDzZ9VF4VAhqLtf0=.235ea3d8-a365-41bf-84c0-76f964dd3bef@github.com>
References: <AdfhGlSY_XGwFqphwO9_Ba_w_eBJDzZ9VF4VAhqLtf0=.235ea3d8-a365-41bf-84c0-76f964dd3bef@github.com>
Message-ID: <mHvkNKVdiw_51YR0B9NyTxjObGk7XJd-nout8YVRlQg=.4728997d-04e2-4315-ac5e-1dfff8460c18@github.com>

On Fri, 8 Jul 2022 19:46:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the last remnants of sun/hotspot/WhiteBox.java and other classes, and uses the versions in jdk/test/whitebox.
> I used sed to change sun.hotspot.{gc,code,cpuinfo} to jdk.test.whitebox and deleted the old files and some references to sun.hotspot.
> Tested with tier1-4.

Thanks Misha!

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

PR: https://git.openjdk.org/jdk/pull/9434

From sspitsyn at openjdk.org  Fri Jul  8 22:47:40 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 8 Jul 2022 22:47:40 GMT
Subject: RFR: 8275662: remove test/lib/sun/hotspot
In-Reply-To: <AdfhGlSY_XGwFqphwO9_Ba_w_eBJDzZ9VF4VAhqLtf0=.235ea3d8-a365-41bf-84c0-76f964dd3bef@github.com>
References: <AdfhGlSY_XGwFqphwO9_Ba_w_eBJDzZ9VF4VAhqLtf0=.235ea3d8-a365-41bf-84c0-76f964dd3bef@github.com>
Message-ID: <V52aYwVRH0kBLgBO3M-HXA1LMRwDAD_Qm5rKwslBTKE=.3f2c1837-f04e-440e-b8ce-030ef63337f6@github.com>

On Fri, 8 Jul 2022 19:46:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the last remnants of sun/hotspot/WhiteBox.java and other classes, and uses the versions in jdk/test/whitebox.
> I used sed to change sun.hotspot.{gc,code,cpuinfo} to jdk.test.whitebox and deleted the old files and some references to sun.hotspot.
> Tested with tier1-4.

This looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9434

From lmesnik at openjdk.org  Sat Jul  9 03:46:42 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 9 Jul 2022 03:46:42 GMT
Subject: RFR: 8275662: remove test/lib/sun/hotspot
In-Reply-To: <AdfhGlSY_XGwFqphwO9_Ba_w_eBJDzZ9VF4VAhqLtf0=.235ea3d8-a365-41bf-84c0-76f964dd3bef@github.com>
References: <AdfhGlSY_XGwFqphwO9_Ba_w_eBJDzZ9VF4VAhqLtf0=.235ea3d8-a365-41bf-84c0-76f964dd3bef@github.com>
Message-ID: <wNgBDP3zkdRDdWjFrf3COMshqrDcKAJgBo9qvRdZm9I=.d3eb8acd-c4e6-4348-a34f-2fbf842846cf@github.com>

On Fri, 8 Jul 2022 19:46:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the last remnants of sun/hotspot/WhiteBox.java and other classes, and uses the versions in jdk/test/whitebox.
> I used sed to change sun.hotspot.{gc,code,cpuinfo} to jdk.test.whitebox and deleted the old files and some references to sun.hotspot.
> Tested with tier1-4.

Marked as reviewed by lmesnik (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9434

From jwaters at openjdk.org  Sat Jul  9 06:08:29 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 9 Jul 2022 06:08:29 GMT
Subject: RFR: 8289275: Remove incorrect __declspec(dllimport) attributes
 from pointers in jdk.crypto.cryptoki
In-Reply-To: <RAmmcj30-EkE6RgXo7rTp4M8RyaNAt5wBOcBpvxiLn0=.76b2d61e-4dc6-4958-8a2d-3ada3cfc4c98@github.com>
References: <yM6fqtQfhPvlMnxnqJbc1H-A3SJ0f6n4ee2zgGCmD7M=.d388accc-1210-40e7-8ae6-11118cec5156@github.com>
 <RAmmcj30-EkE6RgXo7rTp4M8RyaNAt5wBOcBpvxiLn0=.76b2d61e-4dc6-4958-8a2d-3ada3cfc4c98@github.com>
Message-ID: <ADt1KTKWq79HoCeJI2LREYjbLOspY2AO0zJfcV9EOK8=.eff00eff-cfe5-41e8-b225-1f96f5ce8d21@github.com>

On Thu, 7 Jul 2022 21:57:42 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> pkcs11.h is a standard header file from OASIS. Best to leave it alone. Just my .02.

The only change to pkcs11.h is in a comment though, the other changes are outside the ANSI C headers from the standard. Should I just revert the comment in that case?

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

PR: https://git.openjdk.org/jdk/pull/9353

From jwaters at openjdk.org  Sat Jul  9 07:46:39 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 9 Jul 2022 07:46:39 GMT
Subject: RFR: 8289275: Remove incorrect __declspec(dllimport) attributes
 from pointers in jdk.crypto.cryptoki [v2]
In-Reply-To: <yM6fqtQfhPvlMnxnqJbc1H-A3SJ0f6n4ee2zgGCmD7M=.d388accc-1210-40e7-8ae6-11118cec5156@github.com>
References: <yM6fqtQfhPvlMnxnqJbc1H-A3SJ0f6n4ee2zgGCmD7M=.d388accc-1210-40e7-8ae6-11118cec5156@github.com>
Message-ID: <9BH9HhbWMXPTlV-N-3W9_W1nVftWX-LTp36U6EzoVRo=.86c15789-1892-4b48-a8a3-f14f9f3b605c@github.com>

> Several instances of function pointers in jdk.crypto.cryptoki are marked with the dllimport attribute, which should only be applied to symbol declarations, of which a typedef'd function pointer is not. This would only be useful if a function pointer defined in the linked dll is desired to be imported, not if the pointer itself is created locally and used to store a function address. In addition to being incorrect, at least on the versions of Visual C++ the JDK supports today, it is also redundant; Typically they are used to avoid an indirect stub that jumps to the proper entry in the import address table, but usage of these typedefs involves loading the address of a function and directly (Usually through GetProcAddress, even in other cases it would simply be set to the address of a function anyway) assigning it to the pointer before immediately dispatching when called, which bypasses this procedure entirely and makes the attribute pointless.

Julian Waters 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 typedefs
 - Remove __declspec(dllimport) from pointers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9353/files
  - new: https://git.openjdk.org/jdk/pull/9353/files/f299e7c9..f6a94f41

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9353&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9353&range=00-01

  Stats: 26587 lines in 1649 files changed: 13298 ins; 4444 del; 8845 mod
  Patch: https://git.openjdk.org/jdk/pull/9353.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9353/head:pull/9353

PR: https://git.openjdk.org/jdk/pull/9353

From aturbanov at openjdk.org  Sat Jul  9 18:03:43 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 9 Jul 2022 18:03:43 GMT
Subject: Integrated: 8289274: Cleanup unnecessary null comparison before
 instanceof check in security modules
In-Reply-To: <qd5Ewuyi5C8hOlMKMyjD6Ofpyn-B7pGljsDqG8iBRIE=.71fb0398-960e-4681-a184-9eb133e20022@github.com>
References: <qd5Ewuyi5C8hOlMKMyjD6Ofpyn-B7pGljsDqG8iBRIE=.71fb0398-960e-4681-a184-9eb133e20022@github.com>
Message-ID: <347cfsSPzUPtIvlNpIygXnUGRtuTYVhnOQoIHAeZYE4=.86d095ba-a79b-4b0a-b141-1d027f75bdb5@github.com>

On Fri, 24 Jun 2022 18:27:05 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Update code checks both non-null and instance of a class in security classes.
> The checks and explicit casts could also be replaced with pattern matching for the instanceof operator.
> 
> See similar cleanup in java.base - [JDK-8258422](https://bugs.openjdk.java.net/browse/JDK-8258422)

This pull request has now been integrated.

Changeset: 87aa3ce0
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/87aa3ce03e5e294b35cf2cab3cbba0d1964bbbff
Stats:     94 lines in 14 files changed: 0 ins; 40 del; 54 mod

8289274: Cleanup unnecessary null comparison before instanceof check in security modules

Reviewed-by: mullan

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

PR: https://git.openjdk.org/jdk/pull/9284

From jwaters at openjdk.org  Sun Jul 10 08:22:53 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 10 Jul 2022 08:22:53 GMT
Subject: RFR: 8289275: Remove incorrect __declspec(dllimport) attributes
 from pointers in jdk.crypto.cryptoki [v2]
In-Reply-To: <9BH9HhbWMXPTlV-N-3W9_W1nVftWX-LTp36U6EzoVRo=.86c15789-1892-4b48-a8a3-f14f9f3b605c@github.com>
References: <yM6fqtQfhPvlMnxnqJbc1H-A3SJ0f6n4ee2zgGCmD7M=.d388accc-1210-40e7-8ae6-11118cec5156@github.com>
 <9BH9HhbWMXPTlV-N-3W9_W1nVftWX-LTp36U6EzoVRo=.86c15789-1892-4b48-a8a3-f14f9f3b605c@github.com>
Message-ID: <wkm4BA1EnBuNdbGhNDPf5w8pOkQb7uvfa9j52-P1n3E=.42fb2324-3813-48e2-9e98-97013ea75e38@github.com>

On Sat, 9 Jul 2022 07:46:39 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Several instances of function pointers in jdk.crypto.cryptoki are marked with the dllimport attribute, which should only be applied to symbol declarations, of which a typedef'd function pointer is not. This would only be useful if a function pointer defined in the linked dll is desired to be imported, not if the pointer itself is created locally and used to store a function address. In addition to being incorrect, at least on the versions of Visual C++ the JDK supports today, it is also redundant; Typically they are used to avoid an indirect stub that jumps to the proper entry in the import address table, but usage of these typedefs involves loading the address of a function and directly (Usually through GetProcAddress, even in other cases it would simply be set to the address of a function anyway) assigning it to the pointer before immediately dispatching when called, which bypasses this procedure entirely and makes the attribute pointless.
>
> Julian Waters 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 typedefs
>  - Remove __declspec(dllimport) from pointers

Tested with `Microsoft (R) C/C++ Optimizing Compiler Version 19.31.31104` while observing `FPTR_VersionCheck` used in the method `JNIEXPORT jboolean JNICALL Java_sun_security_pkcs11_Secmod_nssVersionCheck` (j2secmod.c, line 40 and line 54), no differences in the generated assembly snippets:

Without __declspec(dllimport):

   0:	48 83 ec 38          	sub    $0x38,%rsp
   4:	48 8d 0d 00 00 00 00 	lea    0x0(%rip),%rcx        # b <main+0xb>
   b:	ff 54 24 20          	call   *0x20(%rsp)
   f:	33 c0                	xor    %eax,%eax
  11:	48 83 c4 38          	add    $0x38,%rsp
  15:	c3                   	ret   
``` 

With __declspec(dllimport):

   0:	48 83 ec 38          	sub    $0x38,%rsp
   4:	48 8d 0d 00 00 00 00 	lea    0x0(%rip),%rcx        # b <main+0xb>
   b:	ff 54 24 20          	call   *0x20(%rsp)
   f:	33 c0                	xor    %eax,%eax
  11:	48 83 c4 38          	add    $0x38,%rsp
  15:	c3                   	ret

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

PR: https://git.openjdk.org/jdk/pull/9353

From michaelm at openjdk.org  Mon Jul 11 07:00:45 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 11 Jul 2022 07:00:45 GMT
Subject: RFR: 8289768: Clean up unused code [v3]
In-Reply-To: <Omx-_YGG52LbvB5MDiNE6Pbe9KVRtIOGyX0-vlezeVY=.8fd6eeff-62e5-481a-bd49-6c405fcd7cf5@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
 <Omx-_YGG52LbvB5MDiNE6Pbe9KVRtIOGyX0-vlezeVY=.8fd6eeff-62e5-481a-bd49-6c405fcd7cf5@github.com>
Message-ID: <HkJBah90Rykst8JP7axwitZPwaRlj_eHFD0U-wbUK6g=.875e3af1-c0b0-475a-ad0f-bba7d785dc67@github.com>

On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
>> 
>> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
>> 
>> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright
>  - Remove more unused variables

libnet changes look fine to me

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

Marked as reviewed by michaelm (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9383

From duke at openjdk.org  Mon Jul 11 08:07:28 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 11 Jul 2022 08:07:28 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[] [v2]
In-Reply-To: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
Message-ID: <QbYlemn0NGMLglclmATPHoJh63z_nzkp4aq53FVwy4w=.00ff0838-3bca-444c-83a2-ec12ef9de9f0@github.com>

> We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null.
> 
> Benchmark results:
> 
> before
> 
> Benchmark                                                  Mode  Cnt  Score   Error  Units
> StringConstructor.newStringFromArray                       avgt   50  4,815 ? 0,154  ns/op
> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,462 ? 0,068  ns/op
> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,653 ? 0,040  ns/op
> StringConstructor.newStringFromRangedArray                 avgt   50  5,090 ? 0,066  ns/op
> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,550 ? 0,041  ns/op
> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  8,080 ? 0,055  ns/op
> 
> after
> 
> Benchmark                                                  Mode  Cnt  Score   Error  Units
> StringConstructor.newStringFromArray                       avgt   50  4,595 ? 0,053  ns/op
> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,038 ? 0,062  ns/op
> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,035 ? 0,031  ns/op
> StringConstructor.newStringFromRangedArray                 avgt   50  4,084 ? 0,007  ns/op
> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,014 ? 0,008  ns/op
> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,466 ? 0,071  ns/op

?????? ??????? 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 8289908
 - 8289908: Make constructor private and use trailing Void instead of int
 - 8289908: Skip bounds check for cases when String is constructed from entirely used byte[]

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9407/files
  - new: https://git.openjdk.org/jdk/pull/9407/files/567727e9..294e91f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9407&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9407&range=00-01

  Stats: 11699 lines in 1295 files changed: 3911 ins; 1617 del; 6171 mod
  Patch: https://git.openjdk.org/jdk/pull/9407.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9407/head:pull/9407

PR: https://git.openjdk.org/jdk/pull/9407

From duke at openjdk.org  Mon Jul 11 08:07:28 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 11 Jul 2022 08:07:28 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[] [v2]
In-Reply-To: <V533Tg4Gtp3-NhSHI9Quqy_7OfuHZoPxWThQW5qP1Yw=.a80cf27d-e09a-4725-aa96-940cc55f715e@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
 <Xg9s8Vevl5-T8n4HJ8iQuIwxbU3ny9nLpD_5X_H7Yes=.1d9d7d50-f37c-4e33-8ca0-0b89af3f0a7b@github.com>
 <nKquvMxiD3EKvHHXEffLjQPfv0boqHtD8rZQ03UVkkQ=.5f86c56b-b5a5-4fe5-a7cc-4fb041828ca1@github.com>
 <V533Tg4Gtp3-NhSHI9Quqy_7OfuHZoPxWThQW5qP1Yw=.a80cf27d-e09a-4725-aa96-940cc55f715e@github.com>
Message-ID: <DT8NcKbz0Fba_uUCgvhJwTawsW5dinvIHDLR5u81ayQ=.7db6e1c8-fa0f-42ee-b3a3-1263fe3137e4@github.com>

On Fri, 8 Jul 2022 14:04:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> But if I roll back the added constructor I'll go through existing public one `public String(byte[] bytes, int offset, int length, Charset charset)` doing bounds check twice, won't I?
>
> The new constructor looks very odd, especially when it does not have an explanation and doesn't describe the required preconditions for calling it.  Is there a better way than adding a non-functional argument?
> The "unused" name is going to draw a warning from IntelliJ and some enterprising developer is going to try to remove it, not understanding why its there. And there is a bit of overhead pushing the extra arg.
> 
> The constructor should be private, it has a very narrow scope of use given the lack of checking its args.
> 
> It would be nice if the Hotspot compiler would recognize the llmits on the range and optimize away the checks;
> it would have broader applicability then this point fix.
> I would be interesting to ask the compiler folks if that's a future optimization.
> These source changes make it harder to understand what's happening where; though that is sometimes work it for a noticeable performance improvement.

Well, we already have e.g. `String(char[], int, int, Void)` and `String(AbstractStringBuilder asb, Void sig)` where trailing argument is for disambiguation against private constructors. I did the same for mine and applied the same naming as in other trailing `Void` params.

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

PR: https://git.openjdk.org/jdk/pull/9407

From chegar at openjdk.org  Mon Jul 11 08:13:45 2022
From: chegar at openjdk.org (Chris Hegarty)
Date: Mon, 11 Jul 2022 08:13:45 GMT
Subject: RFR: 8289768: Clean up unused code [v3]
In-Reply-To: <Omx-_YGG52LbvB5MDiNE6Pbe9KVRtIOGyX0-vlezeVY=.8fd6eeff-62e5-481a-bd49-6c405fcd7cf5@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
 <Omx-_YGG52LbvB5MDiNE6Pbe9KVRtIOGyX0-vlezeVY=.8fd6eeff-62e5-481a-bd49-6c405fcd7cf5@github.com>
Message-ID: <0LufT1j0Gvkv3sFYqCQUR7aBmIU9lHIdOWBHVJyDc-M=.ee7f2980-e54f-4507-9ce3-73378faad4b8@github.com>

On Fri, 8 Jul 2022 07:08:46 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
>> 
>> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
>> 
>> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright
>  - Remove more unused variables

LGTM

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

Marked as reviewed by chegar (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9383

From duke at openjdk.org  Mon Jul 11 11:46:21 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 11 Jul 2022 11:46:21 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[] [v3]
In-Reply-To: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
Message-ID: <pVBwKW5EPHx2LowsLrAJWlan24BN1r7a38Jle0zkaKE=.029f206e-b640-4572-88a0-4bb3f9df9a2a@github.com>

> We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null.
> 
> Benchmark results:
> 
> before
> 
> Benchmark                                                  Mode  Cnt  Score   Error  Units
> StringConstructor.newStringFromArray                       avgt   50  4,815 ? 0,154  ns/op
> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,462 ? 0,068  ns/op
> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,653 ? 0,040  ns/op
> StringConstructor.newStringFromRangedArray                 avgt   50  5,090 ? 0,066  ns/op
> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,550 ? 0,041  ns/op
> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  8,080 ? 0,055  ns/op
> 
> after
> 
> Benchmark                                                  Mode  Cnt  Score   Error  Units
> StringConstructor.newStringFromArray                       avgt   50  4,595 ? 0,053  ns/op
> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,038 ? 0,062  ns/op
> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,035 ? 0,031  ns/op
> StringConstructor.newStringFromRangedArray                 avgt   50  4,084 ? 0,007  ns/op
> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,014 ? 0,008  ns/op
> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,466 ? 0,071  ns/op

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

  8289908: Fixed tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9407/files
  - new: https://git.openjdk.org/jdk/pull/9407/files/294e91f7..b7375cd3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9407&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9407&range=01-02

  Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/9407.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9407/head:pull/9407

PR: https://git.openjdk.org/jdk/pull/9407

From duke at openjdk.org  Mon Jul 11 12:25:39 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 11 Jul 2022 12:25:39 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[] [v3]
In-Reply-To: <DT8NcKbz0Fba_uUCgvhJwTawsW5dinvIHDLR5u81ayQ=.7db6e1c8-fa0f-42ee-b3a3-1263fe3137e4@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
 <Xg9s8Vevl5-T8n4HJ8iQuIwxbU3ny9nLpD_5X_H7Yes=.1d9d7d50-f37c-4e33-8ca0-0b89af3f0a7b@github.com>
 <nKquvMxiD3EKvHHXEffLjQPfv0boqHtD8rZQ03UVkkQ=.5f86c56b-b5a5-4fe5-a7cc-4fb041828ca1@github.com>
 <V533Tg4Gtp3-NhSHI9Quqy_7OfuHZoPxWThQW5qP1Yw=.a80cf27d-e09a-4725-aa96-940cc55f715e@github.com>
 <DT8NcKbz0Fba_uUCgvhJwTawsW5dinvIHDLR5u81ayQ=.7db6e1c8-fa0f-42ee-b3a3-1263fe3137e4@github.com>
Message-ID: <mS162Cy-DL-dLLgL4ZtZ3hXudpcpWZPoDoiq99f8IAw=.ba25b054-953d-4878-a258-24f7146830aa@github.com>

On Mon, 11 Jul 2022 08:02:43 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> The new constructor looks very odd, especially when it does not have an explanation and doesn't describe the required preconditions for calling it.  Is there a better way than adding a non-functional argument?
>> The "unused" name is going to draw a warning from IntelliJ and some enterprising developer is going to try to remove it, not understanding why its there. And there is a bit of overhead pushing the extra arg.
>> 
>> The constructor should be private, it has a very narrow scope of use given the lack of checking its args.
>> 
>> It would be nice if the Hotspot compiler would recognize the llmits on the range and optimize away the checks;
>> it would have broader applicability then this point fix.
>> I would be interesting to ask the compiler folks if that's a future optimization.
>> These source changes make it harder to understand what's happening where; though that is sometimes work it for a noticeable performance improvement.
>
> Well, we already have e.g. `String(char[], int, int, Void)` and `String(AbstractStringBuilder asb, Void sig)` where trailing argument is for disambiguation against private constructors. I did the same for mine and applied the same naming as in other trailing `Void` params.

Benchmark results after:

Benchmark                                                  Mode  Cnt  Score   Error  Units
StringConstructor.newStringFromArray                       avgt   50  4,354 ? 0,195  ns/op
StringConstructor.newStringFromArrayWithCharset            avgt   50  4,035 ? 0,088  ns/op
StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,166 ? 0,062  ns/op
StringConstructor.newStringFromRangedArray                 avgt   50  4,132 ? 0,054  ns/op
StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,416 ? 0,206  ns/op
StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,421 ? 0,041  ns/op

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

PR: https://git.openjdk.org/jdk/pull/9407

From coleenp at openjdk.org  Mon Jul 11 13:11:31 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 11 Jul 2022 13:11:31 GMT
Subject: RFR: 8275662: remove test/lib/sun/hotspot
In-Reply-To: <AdfhGlSY_XGwFqphwO9_Ba_w_eBJDzZ9VF4VAhqLtf0=.235ea3d8-a365-41bf-84c0-76f964dd3bef@github.com>
References: <AdfhGlSY_XGwFqphwO9_Ba_w_eBJDzZ9VF4VAhqLtf0=.235ea3d8-a365-41bf-84c0-76f964dd3bef@github.com>
Message-ID: <e4O1m9UgwgphpjdPzu_JPMkSG5dn52HNHFcu1IEK1s8=.dae503d1-d1fa-4c4e-b3b6-4daca7e6e581@github.com>

On Fri, 8 Jul 2022 19:46:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the last remnants of sun/hotspot/WhiteBox.java and other classes, and uses the versions in jdk/test/whitebox.
> I used sed to change sun.hotspot.{gc,code,cpuinfo} to jdk.test.whitebox and deleted the old files and some references to sun.hotspot.
> Tested with tier1-4.

Thanks Serguei and Leonid.

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

PR: https://git.openjdk.org/jdk/pull/9434

From coleenp at openjdk.org  Mon Jul 11 13:11:31 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 11 Jul 2022 13:11:31 GMT
Subject: Integrated: 8275662: remove test/lib/sun/hotspot
In-Reply-To: <AdfhGlSY_XGwFqphwO9_Ba_w_eBJDzZ9VF4VAhqLtf0=.235ea3d8-a365-41bf-84c0-76f964dd3bef@github.com>
References: <AdfhGlSY_XGwFqphwO9_Ba_w_eBJDzZ9VF4VAhqLtf0=.235ea3d8-a365-41bf-84c0-76f964dd3bef@github.com>
Message-ID: <pZ-QyeoWcffbd2TfIqvEs8_VZTzzWBj-1tWqQX4JGe0=.76fe639c-a0a8-489f-96a8-1e992987ffb7@github.com>

On Fri, 8 Jul 2022 19:46:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the last remnants of sun/hotspot/WhiteBox.java and other classes, and uses the versions in jdk/test/whitebox.
> I used sed to change sun.hotspot.{gc,code,cpuinfo} to jdk.test.whitebox and deleted the old files and some references to sun.hotspot.
> Tested with tier1-4.

This pull request has now been integrated.

Changeset: 0c370089
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0c37008917789e7b631b5c18e6f54454b1bfe038
Stats:     1484 lines in 99 files changed: 0 ins; 1367 del; 117 mod

8275662: remove test/lib/sun/hotspot

Reviewed-by: mseledtsov, sspitsyn, lmesnik

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

PR: https://git.openjdk.org/jdk/pull/9434

From mcimadamore at openjdk.org  Mon Jul 11 14:33:12 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 11 Jul 2022 14:33:12 GMT
Subject: [jdk19] Integrated: 8287809: Revisit implementation of memory session
In-Reply-To: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
Message-ID: <K8huEFChasp4lO9_8RkWWqKnVzSNV8xsD_Tp8fn2bAk=.91b69fbc-0f64-4309-a2b5-a34743e694a8@github.com>

On Wed, 15 Jun 2022 18:06:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017

This pull request has now been integrated.

Changeset: fed3af8a
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/fed3af8ae069fc760a24e750292acbb468b14ce5
Stats:     429 lines in 21 files changed: 47 ins; 102 del; 280 mod

8287809: Revisit implementation of memory session

Reviewed-by: jvernee

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

PR: https://git.openjdk.org/jdk19/pull/22

From sirajn2050 at gmail.com  Sat Jul  9 14:11:58 2022
From: sirajn2050 at gmail.com (=?UTF-8?B?2LPYsdin2Kwg2YbZiNix2KPYrdmF2K8=?=)
Date: Sat, 9 Jul 2022 17:11:58 +0300
Subject: RFR 8050427 LoginContext tests to cover JDK-4703361
Message-ID: <CACkLwdE0VdsqAP563yuKu7_+HcdoAi=ZTZoGMo4acEBnY1uvdQ@mail.gmail.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220709/bbf6753a/attachment-0001.htm>

From mullan at openjdk.org  Mon Jul 11 18:55:43 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 11 Jul 2022 18:55:43 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after
 login failure
In-Reply-To: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
References: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
Message-ID: <-F3_RMWJoYj6NeLHHLh30W38GT0bktYDwoWP8nUqBR0=.8b7a9bcd-d2aa-4343-98f6-0bd62254eb29@github.com>

On Fri, 1 Jul 2022 17:31:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add null-checks in all `LoginModule` implementations. It's possible that an application calls `logout` after a login failure, where most internal variables for principals and credentials are null and removing a null from the `Subject`'s principals and credentials sets will trigger a `NullPointerException`.

A couple of minor comments so far; still reviewing.

src/jdk.security.auth/share/classes/com/sun/security/auth/module/JndiLoginModule.java line 483:

> 481:             subject.getPrincipals().remove(GIDPrincipal);
> 482:         }
> 483:         if (supplementaryGroups != null) {

This line is harmless, but you could take it out as supplementaryGroups is never null.

src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java line 289:

> 287:             subject.getPrincipals().remove(GIDPrincipal);
> 288:         }
> 289:         if (supplementaryGroups != null) {

This line is harmless, but you could take it out as supplementaryGroups is never null.

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

PR: https://git.openjdk.org/jdk/pull/9348

From weijun at openjdk.org  Mon Jul 11 19:54:08 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 11 Jul 2022 19:54:08 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after
 login failure
In-Reply-To: <-F3_RMWJoYj6NeLHHLh30W38GT0bktYDwoWP8nUqBR0=.8b7a9bcd-d2aa-4343-98f6-0bd62254eb29@github.com>
References: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
 <-F3_RMWJoYj6NeLHHLh30W38GT0bktYDwoWP8nUqBR0=.8b7a9bcd-d2aa-4343-98f6-0bd62254eb29@github.com>
Message-ID: <Pxiz_QIweF1r4LPXb0uvYEWmEHJgMORlpXNMvnT7gRw=.271dba19-4a26-4561-a848-674f28fb6cf1@github.com>

On Mon, 11 Jul 2022 18:49:26 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Add null-checks in all `LoginModule` implementations. It's possible that an application calls `logout` after a login failure, where most internal variables for principals and credentials are null and removing a null from the `Subject`'s principals and credentials sets will trigger a `NullPointerException`.
>
> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java line 289:
> 
>> 287:             subject.getPrincipals().remove(GIDPrincipal);
>> 288:         }
>> 289:         if (supplementaryGroups != null) {
> 
> This line is harmless, but you could take it out as supplementaryGroups is never null.

Yes, in fact, whenever `add()` is called, a `new UnixNumericGroupPrincipal(...)` is added. So it seems there is no need to check the elements inside as well. Same in `JndiLoginModule`. In `NTLoginModule`, while the `groups` array itself can be null, its element is also never null.

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

PR: https://git.openjdk.org/jdk/pull/9348

From mullan at openjdk.org  Mon Jul 11 20:32:47 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 11 Jul 2022 20:32:47 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after
 login failure
In-Reply-To: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
References: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
Message-ID: <gZ4Izl3lAA0IAsFT9dgmEGWocMhP4o1lbX-tsQv9urA=.678243f0-3422-4bef-ab91-c866680069bf@github.com>

On Fri, 1 Jul 2022 17:31:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add null-checks in all `LoginModule` implementations. It's possible that an application calls `logout` after a login failure, where most internal variables for principals and credentials are null and removing a null from the `Subject`'s principals and credentials sets will trigger a `NullPointerException`.

Changes requested by mullan (Reviewer).

src/java.base/share/classes/javax/security/auth/spi/LoginModule.java line 231:

> 229:      *      before removing it from the Principals or Credentials set
> 230:      *      of a {@code Subject}, otherwise a {@code NullPointerException} will
> 231:      *      be thrown. This is especially important when this method is called

I might also add: "... will be thrown as these sets prohibit null elements." Even better, you could add a hyperlink "these sets prohibit null elements" to the `Subject` constructor which states this.

Also, I recommend updating the `Subject` constructors and clarifying that removing null elements also causes an NPE. Basically update the following sentence (change in italics):

These Sets also prohibit null elements, and attempts to add, *query, or remove* a null element will result in a NullPointerException.

src/java.base/share/classes/javax/security/auth/spi/LoginModule.java line 231:

> 229:      *      before removing it from the Principals or Credentials set
> 230:      *      of a {@code Subject}, otherwise a {@code NullPointerException} will
> 231:      *      be thrown. This is especially important when this method is called

s/when/if/

test/jdk/javax/security/auth/login/modules/SafeLogout.java line 37:

> 35:  * @bug 8282730
> 36:  * @key randomness
> 37:  * @summary LdapLoginModule throw NPE from logout method after login failure

I think the summary can be more descriptive here and doesn't have to match the bug description. How about "Check that all LoginModule implementations don't throw NPE from logout method after login failure"

test/jdk/javax/security/auth/login/modules/SafeLogout.java line 51:

> 49: 
> 50:     static void test(int pos) throws Exception {
> 51:         // Create random JAAS login config.

I'm probably missing something obvious, but can you explain why this test uses a random login config? I would add some comments explaining that more.

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

PR: https://git.openjdk.org/jdk/pull/9348

From weijun at openjdk.org  Mon Jul 11 21:05:57 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 11 Jul 2022 21:05:57 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after
 login failure
In-Reply-To: <gZ4Izl3lAA0IAsFT9dgmEGWocMhP4o1lbX-tsQv9urA=.678243f0-3422-4bef-ab91-c866680069bf@github.com>
References: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
 <gZ4Izl3lAA0IAsFT9dgmEGWocMhP4o1lbX-tsQv9urA=.678243f0-3422-4bef-ab91-c866680069bf@github.com>
Message-ID: <UwPcRFlhBb7-naf8td6hPCL9g3XXpLCAwjyIl2ECoHY=.873b96f3-d217-477d-8aab-72038b6867db@github.com>

On Mon, 11 Jul 2022 20:09:31 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Add null-checks in all `LoginModule` implementations. It's possible that an application calls `logout` after a login failure, where most internal variables for principals and credentials are null and removing a null from the `Subject`'s principals and credentials sets will trigger a `NullPointerException`.
>
> test/jdk/javax/security/auth/login/modules/SafeLogout.java line 37:
> 
>> 35:  * @bug 8282730
>> 36:  * @key randomness
>> 37:  * @summary LdapLoginModule throw NPE from logout method after login failure
> 
> I think the summary can be more descriptive here and doesn't have to match the bug description. How about "Check that all LoginModule implementations don't throw NPE from logout method after login failure"

OK.

> test/jdk/javax/security/auth/login/modules/SafeLogout.java line 51:
> 
>> 49: 
>> 50:     static void test(int pos) throws Exception {
>> 51:         // Create random JAAS login config.
> 
> I'm probably missing something obvious, but can you explain why this test uses a random login config? I would add some comments explaining that more.

I cannot find a way to test all combinations so I make it random. If it really fails I make sure the login module name, flag, and whether there is a login attempt are printed out so I can reproduce it.

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

PR: https://git.openjdk.org/jdk/pull/9348

From mullan at openjdk.org  Mon Jul 11 21:20:39 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 11 Jul 2022 21:20:39 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after
 login failure
In-Reply-To: <Pxiz_QIweF1r4LPXb0uvYEWmEHJgMORlpXNMvnT7gRw=.271dba19-4a26-4561-a848-674f28fb6cf1@github.com>
References: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
 <-F3_RMWJoYj6NeLHHLh30W38GT0bktYDwoWP8nUqBR0=.8b7a9bcd-d2aa-4343-98f6-0bd62254eb29@github.com>
 <Pxiz_QIweF1r4LPXb0uvYEWmEHJgMORlpXNMvnT7gRw=.271dba19-4a26-4561-a848-674f28fb6cf1@github.com>
Message-ID: <57gnKKoaEwrb6gmhLtqoKQ0NujbJDGrPfSZh6-vNemA=.0cd1be66-ae3f-415a-bc52-6ba1be8e0f93@github.com>

On Mon, 11 Jul 2022 19:49:13 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java line 289:
>> 
>>> 287:             subject.getPrincipals().remove(GIDPrincipal);
>>> 288:         }
>>> 289:         if (supplementaryGroups != null) {
>> 
>> This line is harmless, but you could take it out as supplementaryGroups is never null.
>
> Yes, in fact, whenever `add()` is called, a `new UnixNumericGroupPrincipal(...)` is added. So it seems there is no need to check the elements inside as well. Same in `JndiLoginModule`. In `NTLoginModule`, while the `groups` array itself can be null, its element is also never null.

Right, agreed.

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

PR: https://git.openjdk.org/jdk/pull/9348

From duke at openjdk.org  Mon Jul 11 21:30:15 2022
From: duke at openjdk.org (Mark Powers)
Date: Mon, 11 Jul 2022 21:30:15 GMT
Subject: RFR: 4887998: Use Integer.rotateLeft() and rotateRight() in crypto
 implementations
Message-ID: <LVEXGxnQ0Fg1--fMtObYItYsIzJkTZDa_ooNoqgswcg=.8e792a04-35d1-4b58-9637-791e640c0fcf@github.com>

https://bugs.openjdk.org/browse/JDK-4887998

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

Commit messages:
 - Merge
 - first iteration

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

PR: https://git.openjdk.org/jdk/pull/9456

From weijun at openjdk.org  Mon Jul 11 21:42:49 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 11 Jul 2022 21:42:49 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after
 login failure
In-Reply-To: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
References: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
Message-ID: <jI94De9wTeVEx_Y9s-EqIANIF-XBqDCE8xC19KlHDSQ=.22b853cf-78c7-475f-84c7-024f6ef74863@github.com>

On Fri, 1 Jul 2022 17:31:06 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add null-checks in all `LoginModule` implementations. It's possible that an application calls `logout` after a login failure, where most internal variables for principals and credentials are null and removing a null from the `Subject`'s principals and credentials sets will trigger a `NullPointerException`.

New commits pushed. BTW, in the 2nd one, I reverted some `{@code null}` changes since it looks like "null" is used as an adjective here instead of a Java keyword. The same style appears multiple times in other places.

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

PR: https://git.openjdk.org/jdk/pull/9348

From weijun at openjdk.org  Mon Jul 11 21:42:47 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 11 Jul 2022 21:42:47 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after
 login failure [v2]
In-Reply-To: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
References: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
Message-ID: <1ZHEi8CMhofV9fyWUc5peKwyEkjkpkY__iIiwtSv_A4=.5505724e-a98d-4300-9172-8a546abd92d6@github.com>

> Add null-checks in all `LoginModule` implementations. It's possible that an application calls `logout` after a login failure, where most internal variables for principals and credentials are null and removing a null from the `Subject`'s principals and credentials sets will trigger a `NullPointerException`.

Weijun Wang has updated the pull request incrementally with two additional commits since the last revision:

 - null not in code
 - sean comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9348/files
  - new: https://git.openjdk.org/jdk/pull/9348/files/b3e1f541..810a0114

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9348&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9348&range=00-01

  Stats: 49 lines in 7 files changed: 8 ins; 7 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/9348.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9348/head:pull/9348

PR: https://git.openjdk.org/jdk/pull/9348

From weijun at openjdk.org  Mon Jul 11 22:42:51 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 11 Jul 2022 22:42:51 GMT
Subject: RFR: 4887998: Use Integer.rotateLeft() and rotateRight() in crypto
 implementations
In-Reply-To: <LVEXGxnQ0Fg1--fMtObYItYsIzJkTZDa_ooNoqgswcg=.8e792a04-35d1-4b58-9637-791e640c0fcf@github.com>
References: <LVEXGxnQ0Fg1--fMtObYItYsIzJkTZDa_ooNoqgswcg=.8e792a04-35d1-4b58-9637-791e640c0fcf@github.com>
Message-ID: <u5J049CsOhWAJy7cVn1z-8wTUymovMwMlWiY5rRbSbg=.da50fa03-c358-468e-8d9c-cba74640e290@github.com>

On Mon, 11 Jul 2022 21:20:43 GMT, Mark Powers <duke at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-4887998

Two comments:
1. There are many unnecessary parenthesis, like `(32 - s)` or `(Integer... + 5)`.
2. Why choose `rotateRight` and not `rotateLeft`? https://en.wikipedia.org/wiki/SHA-1 uses "circular left shift operation" to describe the rotation.

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

PR: https://git.openjdk.org/jdk/pull/9456

From duke at openjdk.org  Tue Jul 12 00:48:19 2022
From: duke at openjdk.org (Mark Powers)
Date: Tue, 12 Jul 2022 00:48:19 GMT
Subject: RFR: 4887998: Use Integer.rotateLeft() and rotateRight() in crypto
 implementations
In-Reply-To: <LVEXGxnQ0Fg1--fMtObYItYsIzJkTZDa_ooNoqgswcg=.8e792a04-35d1-4b58-9637-791e640c0fcf@github.com>
References: <LVEXGxnQ0Fg1--fMtObYItYsIzJkTZDa_ooNoqgswcg=.8e792a04-35d1-4b58-9637-791e640c0fcf@github.com>
Message-ID: <QKh3oTUmrt2ZNehIfZy5oQGwAOVgV3ZBLoTwqNXSts8=.adbf2f5b-154e-49f6-9da3-1f75cce3284f@github.com>

On Mon, 11 Jul 2022 21:20:43 GMT, Mark Powers <duke at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-4887998

1. I tried to keep as much of the original parenthesis as possible. I can do the minimum number if that is what you prefer.
2. I'll change MD4, MD5, and SHA-1 to use `rotateLeft` in keeping with how they are described in their respective RFCs.

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

PR: https://git.openjdk.org/jdk/pull/9456

From duke at openjdk.org  Tue Jul 12 03:02:16 2022
From: duke at openjdk.org (Mark Powers)
Date: Tue, 12 Jul 2022 03:02:16 GMT
Subject: RFR: 4887998: Use Integer.rotateLeft() and rotateRight() in crypto
 implementations [v2]
In-Reply-To: <LVEXGxnQ0Fg1--fMtObYItYsIzJkTZDa_ooNoqgswcg=.8e792a04-35d1-4b58-9637-791e640c0fcf@github.com>
References: <LVEXGxnQ0Fg1--fMtObYItYsIzJkTZDa_ooNoqgswcg=.8e792a04-35d1-4b58-9637-791e640c0fcf@github.com>
Message-ID: <IgzQOrXkg0orrUwADv9tsfAjWrUE5PS0PfCzfWQgRUw=.ed9d703c-dbd3-45d2-8d82-9a760979c019@github.com>

> https://bugs.openjdk.org/browse/JDK-4887998

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

  second iteration

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9456/files
  - new: https://git.openjdk.org/jdk/pull/9456/files/e93aa8e9..919851a4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9456&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9456&range=00-01

  Stats: 16 lines in 3 files changed: 0 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/9456.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9456/head:pull/9456

PR: https://git.openjdk.org/jdk/pull/9456

From jbhateja at openjdk.org  Tue Jul 12 05:24:45 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 12 Jul 2022 05:24:45 GMT
Subject: RFR: 4887998: Use Integer.rotateLeft() and rotateRight() in crypto
 implementations
In-Reply-To: <QKh3oTUmrt2ZNehIfZy5oQGwAOVgV3ZBLoTwqNXSts8=.adbf2f5b-154e-49f6-9da3-1f75cce3284f@github.com>
References: <LVEXGxnQ0Fg1--fMtObYItYsIzJkTZDa_ooNoqgswcg=.8e792a04-35d1-4b58-9637-791e640c0fcf@github.com>
 <QKh3oTUmrt2ZNehIfZy5oQGwAOVgV3ZBLoTwqNXSts8=.adbf2f5b-154e-49f6-9da3-1f75cce3284f@github.com>
Message-ID: <3IJmYUczCfKXgc7QJzu7rV1ZiLVgDniSoJpxXqQ0UmU=.74151974-b817-4b84-9835-0a0d9179953b@github.com>

On Tue, 12 Jul 2022 00:44:37 GMT, Mark Powers <duke at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-4887998
>
> 1. I tried to keep as much of the original parenthesis as possible. I can do the minimum number if that is what you prefer.
> 2. I'll change MD4, MD5, and SHA-1 to use `rotateLeft` in keeping with how they are described in their respective RFCs.

Hi @mcpowers , Currently scalar rotate inferencing is done by way of ideal transforms if it finds a matching graph pattern, apart from explicit replacement of  expression with Java SE APIs do we see any performance improvements with this patch.

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

PR: https://git.openjdk.org/jdk/pull/9456

From djelinski at openjdk.org  Tue Jul 12 11:34:43 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 12 Jul 2022 11:34:43 GMT
Subject: Integrated: 8289768: Clean up unused code
In-Reply-To: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
References: <nehhEkgli8579FpeJaBJd-I63OcfarH_XhHEBmW6R2A=.91a3cb1c-2482-42aa-bd69-a48f4bd48283@github.com>
Message-ID: <fcOcK4urRUx8yHC5j19TBmdIOnwWsM_OrGjKl8gKkrE=.69dd372d-d6d4-463a-8eff-8c69dc5f3eee@github.com>

On Tue, 5 Jul 2022 20:19:10 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch removes many unused variables and one unused label reported by the compilers when relevant warnings are enabled. 
> 
> The unused code was found by compiling after removing `unused` from the list of disabled warnings for [gcc](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L190) and [clang](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L203), and enabling [C4189](https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-4-c4189?view=msvc-170) MSVC warning.
> 
> I only removed variables that were uninitialized or initialized without side effects. I verified that the removed variables were not used in any `#ifdef`'d code. I checked that the changed code still compiles on Windows, Linux and Mac, both in release and debug versions.

This pull request has now been integrated.

Changeset: 04c47da1
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/04c47da118b2870d1c7525348a2ffdf9cd1cc0a4
Stats:     98 lines in 46 files changed: 0 ins; 69 del; 29 mod

8289768: Clean up unused code

Reviewed-by: dfuchs, lancea, weijun, naoto, cjplummer, alanb, michaelm, chegar

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

PR: https://git.openjdk.org/jdk/pull/9383

From duke at openjdk.org  Tue Jul 12 19:18:09 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Tue, 12 Jul 2022 19:18:09 GMT
Subject: RFR: 8283082:
 sun.security.x509.X509CertImpl.delete("x509.info.validity") nulls out info
 field [v6]
In-Reply-To: <eO_gP-nzYIxGTLHwRaNpyrJHbX8uqyAVQMOQP1sJ5j0=.91f717dc-d409-48d6-a4dc-44bcfa96f7d8@github.com>
References: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
 <dQbd8CFBuSgwtetQjH5-bPiNABd849yIPquGu6HYxoQ=.e34b33f5-236e-4220-8b8d-0817b37191c8@github.com>
 <eO_gP-nzYIxGTLHwRaNpyrJHbX8uqyAVQMOQP1sJ5j0=.91f717dc-d409-48d6-a4dc-44bcfa96f7d8@github.com>
Message-ID: <i1M6iloC7ErKn3qgMBph7bXm19yID3j5pxqKcbAC04s=.070a1e81-d38e-4f74-a453-8f4d5072dfdf@github.com>

On Tue, 12 Jul 2022 18:35:50 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> I haven't seen this error before. Try again.

Oh okay :) Sure I will try again

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

PR: https://git.openjdk.org/jdk/pull/9306

From mullan at openjdk.org  Tue Jul 12 19:43:46 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 12 Jul 2022 19:43:46 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after
 login failure [v2]
In-Reply-To: <Ec8Kl013J2bB-xzb4uJLUEKfLkPtSJbFIx_oRmzX86g=.7665f39d-77cd-4bdf-b3bf-9e31391a53c0@github.com>
References: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
 <gZ4Izl3lAA0IAsFT9dgmEGWocMhP4o1lbX-tsQv9urA=.678243f0-3422-4bef-ab91-c866680069bf@github.com>
 <UwPcRFlhBb7-naf8td6hPCL9g3XXpLCAwjyIl2ECoHY=.873b96f3-d217-477d-8aab-72038b6867db@github.com>
 <yEmSqmAaJeSsF6Tt32y91f7XXLFnQsst5nl2_bXUXwk=.7be090a8-0901-4e91-84ee-6f2db92e4a80@github.com>
 <Ec8Kl013J2bB-xzb4uJLUEKfLkPtSJbFIx_oRmzX86g=.7665f39d-77cd-4bdf-b3bf-9e31391a53c0@github.com>
Message-ID: <4zzxq4aPLUpZWLZLo8_XIig32zMw3QAXkEmCOGKqWGs=.c0870ba3-60d0-4b2b-8e25-5e80d6646503@github.com>

On Tue, 12 Jul 2022 17:38:38 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Why isn't it sufficient to just call logout once per each login module?
>
> I meant to make the test more real. When there are multiple login modules, the principals and credentials sets could be different. For example, the `privateCredential` NPE in `KeyStoreLoginModule` you found can only happen if there are other private credentials in the subject. (That said, my test hasn't been able to caught it because I haven't used a read-only subject).
> 
> How about I add another method in the test for the single login module module?

It's probably not necessary, I just wanted to understand your rationale. I would add a comment to the test like what you just explained above for future reference.

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

PR: https://git.openjdk.org/jdk/pull/9348

From duke at openjdk.org  Tue Jul 12 20:13:13 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Tue, 12 Jul 2022 20:13:13 GMT
Subject: RFR: 8283082:
 sun.security.x509.X509CertImpl.delete("x509.info.validity") nulls out info
 field [v6]
In-Reply-To: <eO_gP-nzYIxGTLHwRaNpyrJHbX8uqyAVQMOQP1sJ5j0=.91f717dc-d409-48d6-a4dc-44bcfa96f7d8@github.com>
References: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
 <dQbd8CFBuSgwtetQjH5-bPiNABd849yIPquGu6HYxoQ=.e34b33f5-236e-4220-8b8d-0817b37191c8@github.com>
 <eO_gP-nzYIxGTLHwRaNpyrJHbX8uqyAVQMOQP1sJ5j0=.91f717dc-d409-48d6-a4dc-44bcfa96f7d8@github.com>
Message-ID: <IWEJ7_Y_Pmlk38aeOtD1s_9tmClr5at06FOe1-jbypM=.ed1d2597-64f6-43ef-892f-42638db48e77@github.com>

On Tue, 12 Jul 2022 18:35:50 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments to update copyright section.
>
> I haven't seen this error before. Try again.

@wangweij Finally it worked somehow :) 
Thank you!

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

PR: https://git.openjdk.org/jdk/pull/9306

From duke at openjdk.org  Tue Jul 12 20:21:49 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Tue, 12 Jul 2022 20:21:49 GMT
Subject: Integrated: 8283082:
 sun.security.x509.X509CertImpl.delete("x509.info.validity") nulls out info
 field
In-Reply-To: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
References: <U8lrEGhlRLSrkzyrT2Iy-upcf6W6PjHPzsxDISfh7lQ=.457b4db7-ba70-4ecf-be30-eb980c2e3678@github.com>
Message-ID: <7k3mvEWetn9THFW9PxmWEpNPzzpIkecZBwv6YgbJfCc=.e916f679-a0ae-444d-a2ba-b62dbc37404b@github.com>

On Tue, 28 Jun 2022 08:33:58 GMT, Jayashree Huttanagoudar <duke at openjdk.org> wrote:

> Could you please review the changes?
> This is to address the issue: https://bugs.openjdk.org/browse/JDK-8283082?jql=labels%20%3D%20starter-bug

This pull request has now been integrated.

Changeset: 31f7fc04
Author:    Jayashree Huttanagoudar <jhuttana at redhat.com>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/31f7fc043b4616cb2d5f161cda357d0ebfb795f0
Stats:     46 lines in 2 files changed: 45 ins; 0 del; 1 mod

8283082: sun.security.x509.X509CertImpl.delete("x509.info.validity") nulls out info field

Reviewed-by: weijun

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

PR: https://git.openjdk.org/jdk/pull/9306

From prr at openjdk.org  Tue Jul 12 22:32:53 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 12 Jul 2022 22:32:53 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[] [v3]
In-Reply-To: <pVBwKW5EPHx2LowsLrAJWlan24BN1r7a38Jle0zkaKE=.029f206e-b640-4572-88a0-4bb3f9df9a2a@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
 <pVBwKW5EPHx2LowsLrAJWlan24BN1r7a38Jle0zkaKE=.029f206e-b640-4572-88a0-4bb3f9df9a2a@github.com>
Message-ID: <-ieBZH9T_kfEdWWQPOAijkh7qx8gCm_OspehCdbfTPo=.c749524e-ac7f-4b04-8d82-5b50da62fd55@github.com>

On Mon, 11 Jul 2022 11:46:21 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null.
>> 
>> Benchmark results:
>> 
>> before
>> 
>> Benchmark                                                  Mode  Cnt  Score   Error  Units
>> StringConstructor.newStringFromArray                       avgt   50  4,815 ? 0,154  ns/op
>> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,462 ? 0,068  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,653 ? 0,040  ns/op
>> StringConstructor.newStringFromRangedArray                 avgt   50  5,090 ? 0,066  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,550 ? 0,041  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  8,080 ? 0,055  ns/op
>> 
>> after
>> 
>> Benchmark                                                  Mode  Cnt  Score   Error  Units
>> StringConstructor.newStringFromArray                       avgt   50  4,595 ? 0,053  ns/op
>> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,038 ? 0,062  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,035 ? 0,031  ns/op
>> StringConstructor.newStringFromRangedArray                 avgt   50  4,084 ? 0,007  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,014 ? 0,008  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,466 ? 0,071  ns/op
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289908: Fixed tests

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9407

From jbhateja at openjdk.org  Wed Jul 13 04:53:43 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 13 Jul 2022 04:53:43 GMT
Subject: RFR: 4887998: Use Integer.rotateLeft() and rotateRight() in crypto
 implementations
In-Reply-To: <NBsL6WGepEJyr905KaHIFFN87vm7biW4QCtoJy3Roso=.16e1a43c-ccb9-45f9-90fa-8d98d61b7ebf@github.com>
References: <LVEXGxnQ0Fg1--fMtObYItYsIzJkTZDa_ooNoqgswcg=.8e792a04-35d1-4b58-9637-791e640c0fcf@github.com>
 <QKh3oTUmrt2ZNehIfZy5oQGwAOVgV3ZBLoTwqNXSts8=.adbf2f5b-154e-49f6-9da3-1f75cce3284f@github.com>
 <NBsL6WGepEJyr905KaHIFFN87vm7biW4QCtoJy3Roso=.16e1a43c-ccb9-45f9-90fa-8d98d61b7ebf@github.com>
Message-ID: <SLCqpzkMu4AehpHUKFp9MUo2ArxhJAHfZulASIW9wIM=.0861b821-538a-485b-a6f9-21e12ac04f6d@github.com>

On Tue, 12 Jul 2022 14:34:32 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> 1. I tried to keep as much of the original parenthesis as possible. I can do the minimum number if that is what you prefer.
>> 2. I'll change MD4, MD5, and SHA-1 to use `rotateLeft` in keeping with how they are described in their respective RFCs.
>
>> * I tried to keep as much of the original parenthesis as possible. I can do the minimum number if that is what you prefer.
> 
> Yes, it's always a good choice to keep the styles consistent. With you recent code change from `rotateRight(a, (32 -b))` to `rotateLeft(a, b)`, I think it already looks much better.

> @wangweij , I agree it looks much better. Thanks for the `rotateLeft` suggestion.
> 
> @jatin-bhateja , I ran micro performance tests on my MacBook (macosx-aarch64) and didn't see any change in performance. Can you suggest a test that might show better performance? I'm assuming it would involve some platform other than my laptop.

Hi @mcpowers , Before pattern matching over graph snippet, rotate routines which are non-intrinsic will get in-lined, so your change should ideally not impact the generate JIT code.

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

PR: https://git.openjdk.org/jdk/pull/9456

From Ravi.Patel8 at ibm.com  Wed Jul 13 11:38:18 2022
From: Ravi.Patel8 at ibm.com (Ravi Patel8)
Date: Wed, 13 Jul 2022 11:38:18 +0000
Subject: Case-sensitive Keystore for PKCS#12
Message-ID: <BN7PR15MB232128CDD129CB81C8818F1AA5899@BN7PR15MB2321.namprd15.prod.outlook.com>

We have a customer who is having a security requirement. He wants to know, Is it possible to have case-sensitive support for PKCS#12? We referred the RFCs for PKCS#12. We found that PKCS#12 uses a case in-sensitive alias and the alias Name is mapped with friendlyName attribute, which is specified as  "caseIgnoreMatch" as below.

friendlyName ATTRIBUTE ::= {
           WITH SYNTAX BMPString (SIZE(1..pkcs-9-ub-friendlyName))
           EQUALITY MATCHING RULE caseIgnoreMatch
           SINGLE VALUE TRUE
           ID pkcs-9-at-friendlyName
   }

The RFCs can be found here:
https://datatracker.ietf.org/doc/html/rfc7292
https://datatracker.ietf.org/doc/html/rfc2985#page-19

The JKS key store(case in-sensitive alias)  has a special version (CaseExactJKS) that uses case sensitive aliases.
So similarly, Will it be acceptable to have a case sensitive version of PKCS#12 as CaseExactPKCS12 which will use case sensitive aliases?

From duke at openjdk.org  Wed Jul 13 15:11:25 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 13 Jul 2022 15:11:25 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[] [v4]
In-Reply-To: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
Message-ID: <xW3ApUDqkQJaFZu3ImpF6NAO_3aYLZUr4ED8p_VA31U=.98167a32-6ed7-4dc6-ba38-6ed4fb38edf3@github.com>

> We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null.
> 
> Benchmark results:
> 
> before
> 
> Benchmark                                                  Mode  Cnt  Score   Error  Units
> StringConstructor.newStringFromArray                       avgt   50  4,815 ? 0,154  ns/op
> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,462 ? 0,068  ns/op
> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,653 ? 0,040  ns/op
> StringConstructor.newStringFromRangedArray                 avgt   50  5,090 ? 0,066  ns/op
> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,550 ? 0,041  ns/op
> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  8,080 ? 0,055  ns/op
> 
> after
> 
> Benchmark                                                  Mode  Cnt  Score   Error  Units
> StringConstructor.newStringFromArray                       avgt   50  4,595 ? 0,053  ns/op
> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,038 ? 0,062  ns/op
> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,035 ? 0,031  ns/op
> StringConstructor.newStringFromRangedArray                 avgt   50  4,084 ? 0,007  ns/op
> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,014 ? 0,008  ns/op
> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,466 ? 0,071  ns/op

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

 - 8289908: Rework constructor
 - Merge branch 'master' into 8289908
 - 8289908: Fixed tests
 - Merge branch 'master' into 8289908
 - 8289908: Make constructor private and use trailing Void instead of int
 - 8289908: Skip bounds check for cases when String is constructed from entirely used byte[]

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9407/files
  - new: https://git.openjdk.org/jdk/pull/9407/files/b7375cd3..f653a67b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9407&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9407&range=02-03

  Stats: 62100 lines in 564 files changed: 33281 ins; 20833 del; 7986 mod
  Patch: https://git.openjdk.org/jdk/pull/9407.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9407/head:pull/9407

PR: https://git.openjdk.org/jdk/pull/9407

From duke at openjdk.org  Wed Jul 13 15:11:26 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 13 Jul 2022 15:11:26 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[] [v4]
In-Reply-To: <T6IkvLl16MCSqESKmPcKlaKWGtAF4wq4w4Ds_BCh8BI=.c7517f48-3868-4b81-aa49-bac37884a3a8@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
 <Xg9s8Vevl5-T8n4HJ8iQuIwxbU3ny9nLpD_5X_H7Yes=.1d9d7d50-f37c-4e33-8ca0-0b89af3f0a7b@github.com>
 <nKquvMxiD3EKvHHXEffLjQPfv0boqHtD8rZQ03UVkkQ=.5f86c56b-b5a5-4fe5-a7cc-4fb041828ca1@github.com>
 <V533Tg4Gtp3-NhSHI9Quqy_7OfuHZoPxWThQW5qP1Yw=.a80cf27d-e09a-4725-aa96-940cc55f715e@github.com>
 <DT8NcKbz0Fba_uUCgvhJwTawsW5dinvIHDLR5u81ayQ=.7db6e1c8-fa0f-42ee-b3a3-1263fe3137e4@github.com>
 <mS162Cy-DL-dLLgL4ZtZ3hXudpcpWZPoDoiq99f8IAw=.ba25b054-953d-4878-a258-24f7146830aa@github.com>
 <T6IkvLl16MCSqESKmPcKlaKWGtAF4wq4w4Ds_BCh8BI=.c7517f48-3868-4b81-aa49-bac37884a3a8@github.com>
Message-ID: <ylv_SbISGQ36yLy5VMpDarMACBMEuoWyMYpQW8gV8vA=.71c7ee41-3938-4c73-8619-9e144401cb6f@github.com>

On Tue, 12 Jul 2022 15:57:12 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Benchmark results after:
>> 
>> Benchmark                                                  Mode  Cnt  Score   Error  Units
>> StringConstructor.newStringFromArray                       avgt   50  4,354 ? 0,195  ns/op
>> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,035 ? 0,088  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,166 ? 0,062  ns/op
>> StringConstructor.newStringFromRangedArray                 avgt   50  4,132 ? 0,054  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,416 ? 0,206  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,421 ? 0,041  ns/op
>
> Matching the existing Void argument looks better.
> The new private method should have a comment saying that it does not do any precondition checks on the arguments.
> 
> (Reordering the arguments is an alternative to adding an argument, for example, (Charset, byte[], int, int).
> But it is less readable and can raise questions due to the different order of arguments.)

Updated PR. With newer version I get these results:

Benchmark                                                  Mode  Cnt  Score   Error  Units
StringConstructor.newStringFromArray                       avgt   50  4,831 ? 0,205  ns/op
StringConstructor.newStringFromArrayWithCharset            avgt   50  3,940 ? 0,008  ns/op
StringConstructor.newStringFromArrayWithCharsetName        avgt   50  7,662 ? 0,112  ns/op
StringConstructor.newStringFromRangedArray                 avgt   50  4,175 ? 0,065  ns/op
StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  3,970 ? 0,037  ns/op
StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,480 ? 0,014  ns/op

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

PR: https://git.openjdk.org/jdk/pull/9407

From rriggs at openjdk.org  Wed Jul 13 15:47:12 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Jul 2022 15:47:12 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[] [v4]
In-Reply-To: <xW3ApUDqkQJaFZu3ImpF6NAO_3aYLZUr4ED8p_VA31U=.98167a32-6ed7-4dc6-ba38-6ed4fb38edf3@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
 <xW3ApUDqkQJaFZu3ImpF6NAO_3aYLZUr4ED8p_VA31U=.98167a32-6ed7-4dc6-ba38-6ed4fb38edf3@github.com>
Message-ID: <TNoirDRkJlc33IpPN3824nJK0aEfh4U6iWhMl8E0yA8=.5c9bf27f-95ee-410d-859b-10cab6e1447c@github.com>

On Wed, 13 Jul 2022 15:11:25 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null.
>> 
>> Benchmark results:
>> 
>> before
>> 
>> Benchmark                                                  Mode  Cnt  Score   Error  Units
>> StringConstructor.newStringFromArray                       avgt   50  4,815 ? 0,154  ns/op
>> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,462 ? 0,068  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,653 ? 0,040  ns/op
>> StringConstructor.newStringFromRangedArray                 avgt   50  5,090 ? 0,066  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,550 ? 0,041  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  8,080 ? 0,055  ns/op
>> 
>> after
>> 
>> Benchmark                                                  Mode  Cnt  Score   Error  Units
>> StringConstructor.newStringFromArray                       avgt   50  4,595 ? 0,053  ns/op
>> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,038 ? 0,062  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,035 ? 0,031  ns/op
>> StringConstructor.newStringFromRangedArray                 avgt   50  4,084 ? 0,007  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,014 ? 0,008  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,466 ? 0,071  ns/op
>
> ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - 8289908: Rework constructor
>  - Merge branch 'master' into 8289908
>  - 8289908: Fixed tests
>  - Merge branch 'master' into 8289908
>  - 8289908: Make constructor private and use trailing Void instead of int
>  - 8289908: Skip bounds check for cases when String is constructed from entirely used byte[]

Looks good, thanks for the updates.

src/java.base/share/classes/java/lang/String.java line 528:

> 526:      * <p>
> 527:      * Important: parameter order of this method is deliberately changed in order to
> 528:      * disambiguate it against other similar methods ot this class.

typo?  "ot this".

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9407

From valeriep at openjdk.org  Wed Jul 13 16:44:00 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 13 Jul 2022 16:44:00 GMT
Subject: RFR: 8289275: Remove incorrect __declspec(dllimport) attributes
 from pointers in jdk.crypto.cryptoki
In-Reply-To: <ADt1KTKWq79HoCeJI2LREYjbLOspY2AO0zJfcV9EOK8=.eff00eff-cfe5-41e8-b225-1f96f5ce8d21@github.com>
References: <yM6fqtQfhPvlMnxnqJbc1H-A3SJ0f6n4ee2zgGCmD7M=.d388accc-1210-40e7-8ae6-11118cec5156@github.com>
 <RAmmcj30-EkE6RgXo7rTp4M8RyaNAt5wBOcBpvxiLn0=.76b2d61e-4dc6-4958-8a2d-3ada3cfc4c98@github.com>
 <ADt1KTKWq79HoCeJI2LREYjbLOspY2AO0zJfcV9EOK8=.eff00eff-cfe5-41e8-b225-1f96f5ce8d21@github.com>
Message-ID: <e42d0XH1Jnl0gDzLGnej1uoJhx_OmYluz-1Z6ZiazCc=.1b56434d-8e6b-447f-be90-80cedcda10a9@github.com>

On Sat, 9 Jul 2022 06:05:09 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> > pkcs11.h is a standard header file from OASIS. Best to leave it alone. Just my .02.
> 
> The only change to pkcs11.h is in a comment though, the other changes are outside the ANSI C headers from the standard. Should I just revert the comment in that case?

Sounds good to me.
Will take a look at the rest of changes in a day or two.
Thanks!

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

PR: https://git.openjdk.org/jdk/pull/9353

From duke at openjdk.org  Wed Jul 13 17:42:18 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 13 Jul 2022 17:42:18 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[] [v5]
In-Reply-To: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
Message-ID: <UTP-wL0LhGwu_iNeqDDkR9_3PoVH9FHDkfGr8zDsOLc=.a45cd753-c036-4ea6-8cbb-4b9ccbaeaf98@github.com>

> We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null.
> 
> Benchmark results:
> 
> before
> 
> Benchmark                                                  Mode  Cnt  Score   Error  Units
> StringConstructor.newStringFromArray                       avgt   50  4,815 ? 0,154  ns/op
> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,462 ? 0,068  ns/op
> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,653 ? 0,040  ns/op
> StringConstructor.newStringFromRangedArray                 avgt   50  5,090 ? 0,066  ns/op
> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,550 ? 0,041  ns/op
> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  8,080 ? 0,055  ns/op
> 
> after
> 
> Benchmark                                                  Mode  Cnt  Score   Error  Units
> StringConstructor.newStringFromArray                       avgt   50  4,595 ? 0,053  ns/op
> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,038 ? 0,062  ns/op
> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,035 ? 0,031  ns/op
> StringConstructor.newStringFromRangedArray                 avgt   50  4,084 ? 0,007  ns/op
> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,014 ? 0,008  ns/op
> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,466 ? 0,071  ns/op

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

 - 8289908: Fix typo
 - 8289908: Fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9407/files
  - new: https://git.openjdk.org/jdk/pull/9407/files/f653a67b..72146f7d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9407&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9407&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/9407

From duke at openjdk.org  Wed Jul 13 17:42:23 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 13 Jul 2022 17:42:23 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[] [v4]
In-Reply-To: <TNoirDRkJlc33IpPN3824nJK0aEfh4U6iWhMl8E0yA8=.5c9bf27f-95ee-410d-859b-10cab6e1447c@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
 <xW3ApUDqkQJaFZu3ImpF6NAO_3aYLZUr4ED8p_VA31U=.98167a32-6ed7-4dc6-ba38-6ed4fb38edf3@github.com>
 <TNoirDRkJlc33IpPN3824nJK0aEfh4U6iWhMl8E0yA8=.5c9bf27f-95ee-410d-859b-10cab6e1447c@github.com>
Message-ID: <cn9daN0Chjd9H6T25qdokpLduOZ9evfMjlLpKahhfi8=.a7eedd74-0ab4-4e9b-bf7d-94140e5ee64c@github.com>

On Wed, 13 Jul 2022 15:44:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - 8289908: Rework constructor
>>  - Merge branch 'master' into 8289908
>>  - 8289908: Fixed tests
>>  - Merge branch 'master' into 8289908
>>  - 8289908: Make constructor private and use trailing Void instead of int
>>  - 8289908: Skip bounds check for cases when String is constructed from entirely used byte[]
>
> src/java.base/share/classes/java/lang/String.java line 528:
> 
>> 526:      * <p>
>> 527:      * Important: parameter order of this method is deliberately changed in order to
>> 528:      * disambiguate it against other similar methods ot this class.
> 
> typo?  "ot this".

Changed to "of this"

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

PR: https://git.openjdk.org/jdk/pull/9407

From mstjohns at comcast.net  Wed Jul 13 19:19:24 2022
From: mstjohns at comcast.net (Michael StJohns)
Date: Wed, 13 Jul 2022 15:19:24 -0400
Subject: Case-sensitive Keystore for PKCS#12
In-Reply-To: <BN7PR15MB232128CDD129CB81C8818F1AA5899@BN7PR15MB2321.namprd15.prod.outlook.com>
References: <BN7PR15MB232128CDD129CB81C8818F1AA5899@BN7PR15MB2321.namprd15.prod.outlook.com>
Message-ID: <c7ae23b0-0598-30b5-4d6f-30a9038dd5eb@comcast.net>

On 7/13/2022 7:38 AM, Ravi Patel8 wrote:
> We have a customer who is having a security requirement. He wants to know, Is it possible to have case-sensitive support for PKCS#12? We referred the RFCs for PKCS#12. We found that PKCS#12 uses a case in-sensitive alias and the alias Name is mapped with friendlyName attribute, which is specified as  "caseIgnoreMatch" as below.
>
> friendlyName ATTRIBUTE ::= {
>             WITH SYNTAX BMPString (SIZE(1..pkcs-9-ub-friendlyName))
>             EQUALITY MATCHING RULE caseIgnoreMatch
>             SINGLE VALUE TRUE
>             ID pkcs-9-at-friendlyName
>     }
>
> The RFCs can be found here:
> https://datatracker.ietf.org/doc/html/rfc7292
> https://datatracker.ietf.org/doc/html/rfc2985#page-19
>
> The JKS key store(case in-sensitive alias)  has a special version (CaseExactJKS) that uses case sensitive aliases.
> So similarly, Will it be acceptable to have a case sensitive version of PKCS#12 as CaseExactPKCS12 which will use case sensitive aliases?

Not quite.? Not if you're using friendlyName as the alias which the JDK 
implementations do.?? You could define another attribute - something 
like this:

caseAliasName ATTRIBUTE ::= {
 ????? WITH SYNTAX UniversalString (SIZE(1..newvalue))
 ????? EQUALITY MATCHING RULE id-mr-caseExactMatch
 ????? SINGLE VALUE TRUE
 ????? ID newoid
}

and implement your own version of the pkcs12 key store provider that 
understood this and used the caseAliasName as the alias for the KeyStore 
entry instead of friendlyName.

Mike



From xuelei.f at gmail.com  Wed Jul 13 19:26:48 2022
From: xuelei.f at gmail.com (Xuelei Fan)
Date: Wed, 13 Jul 2022 12:26:48 -0700
Subject: Case-sensitive Keystore for PKCS#12
In-Reply-To: <BN7PR15MB232128CDD129CB81C8818F1AA5899@BN7PR15MB2321.namprd15.prod.outlook.com>
References: <BN7PR15MB232128CDD129CB81C8818F1AA5899@BN7PR15MB2321.namprd15.prod.outlook.com>
Message-ID: <DE7172CE-4305-4AF3-99B3-0BBC29A5F641@gmail.com>

Is it possible make it in the application layer?  For example, mapping case-sensitive name to case-in-sensitive name before calling into the standard KeyStore APIs.  It may be not good to break the standards for corner cases?

Xuelei

> On Jul 13, 2022, at 4:38 AM, Ravi Patel8 <Ravi.Patel8 at ibm.com> wrote:
> 
> We have a customer who is having a security requirement. He wants to know, Is it possible to have case-sensitive support for PKCS#12? We referred the RFCs for PKCS#12. We found that PKCS#12 uses a case in-sensitive alias and the alias Name is mapped with friendlyName attribute, which is specified as  "caseIgnoreMatch" as below.
> 
> friendlyName ATTRIBUTE ::= {
>           WITH SYNTAX BMPString (SIZE(1..pkcs-9-ub-friendlyName))
>           EQUALITY MATCHING RULE caseIgnoreMatch
>           SINGLE VALUE TRUE
>           ID pkcs-9-at-friendlyName
>   }
> 
> The RFCs can be found here:
> https://datatracker.ietf.org/doc/html/rfc7292
> https://datatracker.ietf.org/doc/html/rfc2985#page-19
> 
> The JKS key store(case in-sensitive alias)  has a special version (CaseExactJKS) that uses case sensitive aliases.
> So similarly, Will it be acceptable to have a case sensitive version of PKCS#12 as CaseExactPKCS12 which will use case sensitive aliases?


From mstjohns at comcast.net  Wed Jul 13 21:20:24 2022
From: mstjohns at comcast.net (Michael StJohns)
Date: Wed, 13 Jul 2022 17:20:24 -0400
Subject: Case-sensitive Keystore for PKCS#12
In-Reply-To: <DE7172CE-4305-4AF3-99B3-0BBC29A5F641@gmail.com>
References: <BN7PR15MB232128CDD129CB81C8818F1AA5899@BN7PR15MB2321.namprd15.prod.outlook.com>
 <DE7172CE-4305-4AF3-99B3-0BBC29A5F641@gmail.com>
Message-ID: <a42ac1a6-fb4b-33eb-4621-d43fdf7dbd62@comcast.net>

On 7/13/2022 3:26 PM, Xuelei Fan wrote:
> Is it possible make it in the application layer?  For example, mapping case-sensitive name to case-in-sensitive name before calling into the standard KeyStore APIs.  It may be not good to break the standards for corner cases?
>
> Xuelei

Hi Xuelei -

It wouldn't actually be breaking the PKCS12 spec - the addition of more 
attributes is part of the standard.? Nor, given the CaseExactJKS 
implementation, would it be breaking the JDK spec AFAICT.? There is this 
in the KeyStore javadoc:

> Whether aliases are case sensitive is implementation dependent. In 
> order to avoid problems, it is recommended not to use aliases in a 
> KeyStore that only differ in case. 
The approach you suggest wouldn't work, because you couldn't store one 
key with "MikesKey" and another with "MIKESKEY" in the Keystore.

Hmm - let me rephrase that slightly.? You could use this approach, but 
not in the way you suggested.? Instead, you'd need a transform from a 
String to a unique string that you could use inside the key store.? The 
actual alias within the keystore would be the unique string.

One way of doing that: Lowercase the string.? Prepend the string with a 
2 character length field.?? Post pend the string with a hex field of 
CEIL(length/16) characters, each hex character representing 16 bits that 
indicate the case of the string.

e.g. "Mike" -> "04mike8"

Just a thought - Mike

>
>> On Jul 13, 2022, at 4:38 AM, Ravi Patel8 <Ravi.Patel8 at ibm.com> wrote:
>>
>> We have a customer who is having a security requirement. He wants to know, Is it possible to have case-sensitive support for PKCS#12? We referred the RFCs for PKCS#12. We found that PKCS#12 uses a case in-sensitive alias and the alias Name is mapped with friendlyName attribute, which is specified as  "caseIgnoreMatch" as below.
>>
>> friendlyName ATTRIBUTE ::= {
>>            WITH SYNTAX BMPString (SIZE(1..pkcs-9-ub-friendlyName))
>>            EQUALITY MATCHING RULE caseIgnoreMatch
>>            SINGLE VALUE TRUE
>>            ID pkcs-9-at-friendlyName
>>    }
>>
>> The RFCs can be found here:
>> https://datatracker.ietf.org/doc/html/rfc7292
>> https://datatracker.ietf.org/doc/html/rfc2985#page-19
>>
>> The JKS key store(case in-sensitive alias)  has a special version (CaseExactJKS) that uses case sensitive aliases.
>> So similarly, Will it be acceptable to have a case sensitive version of PKCS#12 as CaseExactPKCS12 which will use case sensitive aliases?



From xuelei.f at gmail.com  Wed Jul 13 21:40:29 2022
From: xuelei.f at gmail.com (Xuelei Fan)
Date: Wed, 13 Jul 2022 14:40:29 -0700
Subject: Case-sensitive Keystore for PKCS#12
In-Reply-To: <a42ac1a6-fb4b-33eb-4621-d43fdf7dbd62@comcast.net>
References: <BN7PR15MB232128CDD129CB81C8818F1AA5899@BN7PR15MB2321.namprd15.prod.outlook.com>
 <DE7172CE-4305-4AF3-99B3-0BBC29A5F641@gmail.com>
 <a42ac1a6-fb4b-33eb-4621-d43fdf7dbd62@comcast.net>
Message-ID: <6A9FFB3F-0D38-477A-BCDB-D1CFB927715B@gmail.com>



> On Jul 13, 2022, at 2:20 PM, Michael StJohns <mstjohns at comcast.net> wrote:
> 
> On 7/13/2022 3:26 PM, Xuelei Fan wrote:
>> Is it possible make it in the application layer?  For example, mapping case-sensitive name to case-in-sensitive name before calling into the standard KeyStore APIs.  It may be not good to break the standards for corner cases?
>> 
>> Xuelei
> 
> Hi Xuelei -
> 
> It wouldn't actually be breaking the PKCS12 spec - the addition of more attributes is part of the standard.
I agreed it could not break PKCS12 spec.  I referred to the friendlyName spec in PKCS12.  An additional attribute could be used for the case-in-sensitive name support.  But there is a need to define and support the attribute in the KeyStore implementation, just as you described in your previous reply.


>   Nor, given the CaseExactJKS implementation, would it be breaking the JDK spec AFAICT.  There is this in the KeyStore javadoc:
> 
>> Whether aliases are case sensitive is implementation dependent. In order to avoid problems, it is recommended not to use aliases in a KeyStore that only differ in case. 
> The approach you suggest wouldn't work, because you couldn't store one key with "MikesKey" and another with "MIKESKEY" in the Keystore.
> 

I did not meant to cover the case.  It may be fine to use a map, in which ?MikesKey? may be mapped to ?mikeskkey-1000100?, and MIKESKEY to ?mikeskkey-0000000?, or something else like you described below ("Mike" -> "04mike8?).

Xuelei


> Hmm - let me rephrase that slightly.  You could use this approach, but not in the way you suggested.  Instead, you'd need a transform from a String to a unique string that you could use inside the key store.  The actual alias within the keystore would be the unique string.
> 
> One way of doing that: Lowercase the string.  Prepend the string with a 2 character length field.   Post pend the string with a hex field of CEIL(length/16) characters, each hex character representing 16 bits that indicate the case of the string.
> 
> e.g. "Mike" -> "04mike8"
> 
> Just a thought - Mike
> 
>> 
>>> On Jul 13, 2022, at 4:38 AM, Ravi Patel8 <Ravi.Patel8 at ibm.com> wrote:
>>> 
>>> We have a customer who is having a security requirement. He wants to know, Is it possible to have case-sensitive support for PKCS#12? We referred the RFCs for PKCS#12. We found that PKCS#12 uses a case in-sensitive alias and the alias Name is mapped with friendlyName attribute, which is specified as  "caseIgnoreMatch" as below.
>>> 
>>> friendlyName ATTRIBUTE ::= {
>>>           WITH SYNTAX BMPString (SIZE(1..pkcs-9-ub-friendlyName))
>>>           EQUALITY MATCHING RULE caseIgnoreMatch
>>>           SINGLE VALUE TRUE
>>>           ID pkcs-9-at-friendlyName
>>>   }
>>> 
>>> The RFCs can be found here:
>>> https://datatracker.ietf.org/doc/html/rfc7292
>>> https://datatracker.ietf.org/doc/html/rfc2985#page-19
>>> 
>>> The JKS key store(case in-sensitive alias)  has a special version (CaseExactJKS) that uses case sensitive aliases.
>>> So similarly, Will it be acceptable to have a case sensitive version of PKCS#12 as CaseExactPKCS12 which will use case sensitive aliases?
> 
> 


From jwaters at openjdk.org  Thu Jul 14 02:26:58 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 14 Jul 2022 02:26:58 GMT
Subject: RFR: 8289275: Remove incorrect __declspec(dllimport) attributes
 from pointers in jdk.crypto.cryptoki
In-Reply-To: <e42d0XH1Jnl0gDzLGnej1uoJhx_OmYluz-1Z6ZiazCc=.1b56434d-8e6b-447f-be90-80cedcda10a9@github.com>
References: <yM6fqtQfhPvlMnxnqJbc1H-A3SJ0f6n4ee2zgGCmD7M=.d388accc-1210-40e7-8ae6-11118cec5156@github.com>
 <RAmmcj30-EkE6RgXo7rTp4M8RyaNAt5wBOcBpvxiLn0=.76b2d61e-4dc6-4958-8a2d-3ada3cfc4c98@github.com>
 <ADt1KTKWq79HoCeJI2LREYjbLOspY2AO0zJfcV9EOK8=.eff00eff-cfe5-41e8-b225-1f96f5ce8d21@github.com>
 <e42d0XH1Jnl0gDzLGnej1uoJhx_OmYluz-1Z6ZiazCc=.1b56434d-8e6b-447f-be90-80cedcda10a9@github.com>
Message-ID: <jgSJF1Hi2Cim7l_bLTyuTrsvGR4Ms0-dGRfuLQ9Sj20=.8c1413e4-856d-4e4a-a7a5-aaea5d979760@github.com>

On Wed, 13 Jul 2022 16:40:48 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> > > pkcs11.h is a standard header file from OASIS. Best to leave it alone. Just my .02.
> > 
> > 
> > The only change to pkcs11.h is in a comment though, the other changes are outside the ANSI C headers from the standard. Should I just revert the comment in that case?
> 
> Sounds good to me. Will take a look at the rest of changes in a day or two. Thanks!

Alright, will do. I also do want to look at p11_md.h to see if my changes are appropriate in the meantime, as I have a feeling it can be accomplished somewhat more elegantly

Thanks for the review!

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

PR: https://git.openjdk.org/jdk/pull/9353

From jwaters at openjdk.org  Thu Jul 14 02:43:52 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 14 Jul 2022 02:43:52 GMT
Subject: RFR: 8289275: Remove incorrect __declspec(dllimport) attributes
 from pointers in jdk.crypto.cryptoki [v3]
In-Reply-To: <yM6fqtQfhPvlMnxnqJbc1H-A3SJ0f6n4ee2zgGCmD7M=.d388accc-1210-40e7-8ae6-11118cec5156@github.com>
References: <yM6fqtQfhPvlMnxnqJbc1H-A3SJ0f6n4ee2zgGCmD7M=.d388accc-1210-40e7-8ae6-11118cec5156@github.com>
Message-ID: <FKkjNv-bNhZSvG-SG7Ko4i0as2OSnxgLxeK18WYW-1Y=.044546a8-da98-4b20-9800-2539c7199a65@github.com>

> Several instances of function pointers in jdk.crypto.cryptoki are marked with the dllimport attribute, which should only be applied to symbol declarations, of which a typedef'd function pointer is not. This would only be useful if a function pointer defined in the linked dll is desired to be imported, not if the pointer itself is created locally and used to store a function address. In addition to being incorrect, at least on the versions of Visual C++ the JDK supports today, it is also redundant; Typically they are used to avoid an indirect stub that jumps to the proper entry in the import address table, but usage of these typedefs involves loading the address of a function and directly (Usually through GetProcAddress, even in other cases it would simply be set to the address of a function anyway) assigning it to the pointer before immediately dispatching when called, which bypasses this procedure entirely and makes the attribute pointless.

Julian Waters 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 typedefs
 - Merge branch 'master' into typedefs
 - Remove __declspec(dllimport) from pointers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9353/files
  - new: https://git.openjdk.org/jdk/pull/9353/files/f6a94f41..f0115500

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9353&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9353&range=01-02

  Stats: 64346 lines in 627 files changed: 34706 ins; 21440 del; 8200 mod
  Patch: https://git.openjdk.org/jdk/pull/9353.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9353/head:pull/9353

PR: https://git.openjdk.org/jdk/pull/9353

From jwaters at openjdk.org  Thu Jul 14 02:48:07 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 14 Jul 2022 02:48:07 GMT
Subject: RFR: 8289275: Remove incorrect __declspec(dllimport) attributes
 from pointers in jdk.crypto.cryptoki [v4]
In-Reply-To: <yM6fqtQfhPvlMnxnqJbc1H-A3SJ0f6n4ee2zgGCmD7M=.d388accc-1210-40e7-8ae6-11118cec5156@github.com>
References: <yM6fqtQfhPvlMnxnqJbc1H-A3SJ0f6n4ee2zgGCmD7M=.d388accc-1210-40e7-8ae6-11118cec5156@github.com>
Message-ID: <yBbfEsFgVweDrmKL3Yfcq-s955rIPChU6gRP31n92sg=.9b12b2a4-a1fd-430d-bd8a-206820a13370@github.com>

> Several instances of function pointers in jdk.crypto.cryptoki are marked with the dllimport attribute, which should only be applied to symbol declarations, of which a typedef'd function pointer is not. This would only be useful if a function pointer defined in the linked dll is desired to be imported, not if the pointer itself is created locally and used to store a function address. In addition to being incorrect, at least on the versions of Visual C++ the JDK supports today, it is also redundant; Typically they are used to avoid an indirect stub that jumps to the proper entry in the import address table, but usage of these typedefs involves loading the address of a function and directly (Usually through GetProcAddress, even in other cases it would simply be set to the address of a function anyway) assigning it to the pointer before immediately dispatching when called, which bypasses this procedure entirely and makes the attribute pointless.

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

  Revert changes to pkcs11.h

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9353/files
  - new: https://git.openjdk.org/jdk/pull/9353/files/f0115500..3babccb2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9353&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9353&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/9353

From aturbanov at openjdk.org  Thu Jul 14 11:51:15 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 14 Jul 2022 11:51:15 GMT
Subject: RFR: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[] [v5]
In-Reply-To: <UTP-wL0LhGwu_iNeqDDkR9_3PoVH9FHDkfGr8zDsOLc=.a45cd753-c036-4ea6-8cbb-4b9ccbaeaf98@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
 <UTP-wL0LhGwu_iNeqDDkR9_3PoVH9FHDkfGr8zDsOLc=.a45cd753-c036-4ea6-8cbb-4b9ccbaeaf98@github.com>
Message-ID: <EggfXMph6fkkDm743D0_lvGGFIrYih-CV50uqi9Z0Eg=.dc39ff6c-a116-423e-a222-36f098b377ce@github.com>

On Wed, 13 Jul 2022 17:42:18 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null.
>> 
>> Benchmark results:
>> 
>> before
>> 
>> Benchmark                                                  Mode  Cnt  Score   Error  Units
>> StringConstructor.newStringFromArray                       avgt   50  4,815 ? 0,154  ns/op
>> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,462 ? 0,068  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,653 ? 0,040  ns/op
>> StringConstructor.newStringFromRangedArray                 avgt   50  5,090 ? 0,066  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,550 ? 0,041  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  8,080 ? 0,055  ns/op
>> 
>> after
>> 
>> Benchmark                                                  Mode  Cnt  Score   Error  Units
>> StringConstructor.newStringFromArray                       avgt   50  4,595 ? 0,053  ns/op
>> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,038 ? 0,062  ns/op
>> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,035 ? 0,031  ns/op
>> StringConstructor.newStringFromRangedArray                 avgt   50  4,084 ? 0,007  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,014 ? 0,008  ns/op
>> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,466 ? 0,071  ns/op
>
> ?????? ??????? has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8289908: Fix typo
>  - 8289908: Fix typo

Marked as reviewed by aturbanov (Committer).

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

PR: https://git.openjdk.org/jdk/pull/9407

From Ravi.Patel8 at ibm.com  Thu Jul 14 12:56:22 2022
From: Ravi.Patel8 at ibm.com (Ravi Patel8)
Date: Thu, 14 Jul 2022 12:56:22 +0000
Subject: Case-sensitive Keystore for PKCS#12
In-Reply-To: <6A9FFB3F-0D38-477A-BCDB-D1CFB927715B@gmail.com>
References: <BN7PR15MB232128CDD129CB81C8818F1AA5899@BN7PR15MB2321.namprd15.prod.outlook.com>
 <DE7172CE-4305-4AF3-99B3-0BBC29A5F641@gmail.com>
 <a42ac1a6-fb4b-33eb-4621-d43fdf7dbd62@comcast.net>
 <6A9FFB3F-0D38-477A-BCDB-D1CFB927715B@gmail.com>
Message-ID: <BN7PR15MB23215251CA5961F14DD433ABA5889@BN7PR15MB2321.namprd15.prod.outlook.com>

Thank you for the suggested solutions with an added attribute and a new provider. Do you think it is something that could be contributed to the JDK, or do you suggest this should be taken up as an external provider?
________________________________
From: security-dev <security-dev-retn at openjdk.org> on behalf of Xuelei Fan <xuelei.f at gmail.com>
Sent: Thursday, July 14, 2022 3:10 AM
To: Michael StJohns <mstjohns at comcast.net>
Cc: security-dev at openjdk.org <security-dev at openjdk.org>
Subject: [EXTERNAL] Re: Case-sensitive Keystore for PKCS#12



> On Jul 13, 2022, at 2:20 PM, Michael StJohns <mstjohns at comcast.net> wrote:
>
> On 7/13/2022 3:26 PM, Xuelei Fan wrote:
>> Is it possible make it in the application layer?  For example, mapping case-sensitive name to case-in-sensitive name before calling into the standard KeyStore APIs.  It may be not good to break the standards for corner cases?
>>
>> Xuelei
>
> Hi Xuelei -
>
> It wouldn't actually be breaking the PKCS12 spec - the addition of more attributes is part of the standard.
I agreed it could not break PKCS12 spec.  I referred to the friendlyName spec in PKCS12.  An additional attribute could be used for the case-in-sensitive name support.  But there is a need to define and support the attribute in the KeyStore implementation, just as you described in your previous reply.


>   Nor, given the CaseExactJKS implementation, would it be breaking the JDK spec AFAICT.  There is this in the KeyStore javadoc:
>
>> Whether aliases are case sensitive is implementation dependent. In order to avoid problems, it is recommended not to use aliases in a KeyStore that only differ in case.
> The approach you suggest wouldn't work, because you couldn't store one key with "MikesKey" and another with "MIKESKEY" in the Keystore.
>

I did not meant to cover the case.  It may be fine to use a map, in which ?MikesKey? may be mapped to ?mikeskkey-1000100?, and MIKESKEY to ?mikeskkey-0000000?, or something else like you described below ("Mike" -> "04mike8?).

Xuelei


> Hmm - let me rephrase that slightly.  You could use this approach, but not in the way you suggested.  Instead, you'd need a transform from a String to a unique string that you could use inside the key store.  The actual alias within the keystore would be the unique string.
>
> One way of doing that: Lowercase the string.  Prepend the string with a 2 character length field.   Post pend the string with a hex field of CEIL(length/16) characters, each hex character representing 16 bits that indicate the case of the string.
>
> e.g. "Mike" -> "04mike8"
>
> Just a thought - Mike
>
>>
>>> On Jul 13, 2022, at 4:38 AM, Ravi Patel8 <Ravi.Patel8 at ibm.com> wrote:
>>>
>>> We have a customer who is having a security requirement. He wants to know, Is it possible to have case-sensitive support for PKCS#12? We referred the RFCs for PKCS#12. We found that PKCS#12 uses a case in-sensitive alias and the alias Name is mapped with friendlyName attribute, which is specified as  "caseIgnoreMatch" as below.
>>>
>>> friendlyName ATTRIBUTE ::= {
>>>           WITH SYNTAX BMPString (SIZE(1..pkcs-9-ub-friendlyName))
>>>           EQUALITY MATCHING RULE caseIgnoreMatch
>>>           SINGLE VALUE TRUE
>>>           ID pkcs-9-at-friendlyName
>>>   }
>>>
>>> The RFCs can be found here:
>>> https://datatracker.ietf.org/doc/html/rfc7292
>>> https://datatracker.ietf.org/doc/html/rfc2985#page-19
>>>
>>> The JKS key store(case in-sensitive alias)  has a special version (CaseExactJKS) that uses case sensitive aliases.
>>> So similarly, Will it be acceptable to have a case sensitive version of PKCS#12 as CaseExactPKCS12 which will use case sensitive aliases?
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220714/3d680f65/attachment.htm>

From mullan at openjdk.org  Thu Jul 14 17:55:02 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 14 Jul 2022 17:55:02 GMT
Subject: RFR: 8289572: InputStream wrapping with BufferedInputStream is
 redundant in HttpTimestamper
In-Reply-To: <P9jIj_8YZm3wshGxV9ox_-38G9UfMWbKLy0z9u7Gfug=.adc2f80c-086c-4b9e-a70b-129b7ba746ff@github.com>
References: <P9jIj_8YZm3wshGxV9ox_-38G9UfMWbKLy0z9u7Gfug=.adc2f80c-086c-4b9e-a70b-129b7ba746ff@github.com>
Message-ID: <qBHLBkXq2q1KtACS4_Y4zFOCtylgy-wAEtTIs_Y0gyY=.559a5d18-f1e2-42cc-9af5-836dd8ee641a@github.com>

On Fri, 1 Jul 2022 08:06:10 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> In case we read all bytes from an `InputStream` we don't need wrapping with `BufferedInputStream` as the bytes are not written into internal buffer. With removal of redundant buffer we save 8 kB of allocated memory.

This is in security-libs code, so the JBS issue component should be "security-libs". The subcomponent should probably be "java.security".

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

PR: https://git.openjdk.org/jdk/pull/9343

From mullan at openjdk.org  Thu Jul 14 18:29:09 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 14 Jul 2022 18:29:09 GMT
Subject: RFR: 8289572: InputStream wrapping with BufferedInputStream is
 redundant in HttpTimestamper
In-Reply-To: <P9jIj_8YZm3wshGxV9ox_-38G9UfMWbKLy0z9u7Gfug=.adc2f80c-086c-4b9e-a70b-129b7ba746ff@github.com>
References: <P9jIj_8YZm3wshGxV9ox_-38G9UfMWbKLy0z9u7Gfug=.adc2f80c-086c-4b9e-a70b-129b7ba746ff@github.com>
Message-ID: <KI9sIkMewZK1tD9OcZWxVdGi4Mxw-swlW6SHFOAXvFQ=.6fbe43d6-451e-494e-94f1-9ba4e0cf6ccb@github.com>

On Fri, 1 Jul 2022 08:06:10 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> In case we read all bytes from an `InputStream` we don't need wrapping with `BufferedInputStream` as the bytes are not written into internal buffer. With removal of redundant buffer we save 8 kB of allocated memory.

Marked as reviewed by mullan (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9343

From duke at openjdk.org  Thu Jul 14 19:36:01 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 14 Jul 2022 19:36:01 GMT
Subject: RFR: 8289572: InputStream wrapping with BufferedInputStream is
 redundant in HttpTimestamper
In-Reply-To: <qBHLBkXq2q1KtACS4_Y4zFOCtylgy-wAEtTIs_Y0gyY=.559a5d18-f1e2-42cc-9af5-836dd8ee641a@github.com>
References: <P9jIj_8YZm3wshGxV9ox_-38G9UfMWbKLy0z9u7Gfug=.adc2f80c-086c-4b9e-a70b-129b7ba746ff@github.com>
 <qBHLBkXq2q1KtACS4_Y4zFOCtylgy-wAEtTIs_Y0gyY=.559a5d18-f1e2-42cc-9af5-836dd8ee641a@github.com>
Message-ID: <D6DKDa64o3ha5kU0JVRCSh9BFWbDyyMNbZGofYcc-sU=.707a966d-e61b-4d82-97f8-94e0e31aa273@github.com>

On Thu, 14 Jul 2022 17:51:43 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> In case we read all bytes from an `InputStream` we don't need wrapping with `BufferedInputStream` as the bytes are not written into internal buffer. With removal of redundant buffer we save 8 kB of allocated memory.
>
> This is in security-libs code, so the JBS issue component should be "security-libs". The subcomponent should probably be "java.security". It should also have an appropriate noreg label, as there is no regression test.

@seanjmullan done

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

PR: https://git.openjdk.org/jdk/pull/9343

From duke at openjdk.org  Fri Jul 15 13:05:38 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Fri, 15 Jul 2022 13:05:38 GMT
Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule
 is not logged [v2]
In-Reply-To: <R0zl8UunTV29IF1LgFlH2Xns12lg9ni2gTAEyHOtNI4=.9ea5aa0d-f7dd-4ac1-9b3f-b5f84b2f4a99@github.com>
References: <R0zl8UunTV29IF1LgFlH2Xns12lg9ni2gTAEyHOtNI4=.9ea5aa0d-f7dd-4ac1-9b3f-b5f84b2f4a99@github.com>
Message-ID: <l5cLrIX_ZKChDlSoPRHi2vuc2_Too5QEA2SuxLMT7Eo=.55d0fd2b-9e94-4bc6-a26e-8a5027b9bda4@github.com>

> Could you please review the changes?
> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug

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

  Add test case to verify the patch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9159/files
  - new: https://git.openjdk.org/jdk/pull/9159/files/13a51a6d..b91e7554

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9159&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/9159

From duke at openjdk.org  Fri Jul 15 13:06:51 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Fri, 15 Jul 2022 13:06:51 GMT
Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule
 is not logged
In-Reply-To: <J-UTyB3fqztSpxV7sgEppFBixitJVR_LlhN2zCS5xd0=.453e4bc9-c593-4686-936c-e0d74a0e8043@github.com>
References: <R0zl8UunTV29IF1LgFlH2Xns12lg9ni2gTAEyHOtNI4=.9ea5aa0d-f7dd-4ac1-9b3f-b5f84b2f4a99@github.com>
 <J-UTyB3fqztSpxV7sgEppFBixitJVR_LlhN2zCS5xd0=.453e4bc9-c593-4686-936c-e0d74a0e8043@github.com>
Message-ID: <gu8lXyg_3tF2sa7CULqNLBSXjF1EvHMGsVLQMOUfLrk=.15e186fd-821e-4612-8a58-92a784252951@github.com>

On Fri, 8 Jul 2022 13:12:23 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Could you please review the changes?
>> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug
>
> `SmartLoginModule.java` is a class used by a test, itself is not one since there's no `main()` method.
> 
> Your new test needs to be a regression test, which means before the fix it fails and after the fix it succeeds. Also, seeing the exception message in a jtreg output with your own eyes is not a test. The test itself should detect the exception and decide whether it's a success or a failure. In the case, I'd recommend you use the `System.setErr` method to store the output into a `ByteArrayOutputStream` and then look into it.

@wangweij I was trying to add a tets case(I can say its still primary version of the test case. Still there are modifications needed)
First I wanted to make it fit with framework with suitable annotations like `@test` `@compile` and `@run` etc. 

When I am trying the below command, its failing with some exit status which I am unable to find why! :

# jtreg/bin/jtreg -jdk:/root/jdk/build/linux-x86_64-server-release/images/jdk/ -verbose test/jdk/javax/security/auth/login/LoginContext/jaaslogin/
runner starting test: javax/security/auth/login/LoginContext/jaaslogin/sample/SampleAcn.java
runner finished test: javax/security/auth/login/LoginContext/jaaslogin/sample/SampleAcn.java
Failed. Unexpected exit from test [exit code: 255]
Test results: failed: 1
Report written to /root/jdk/JTreport/html/report.html
Results written to /root/jdk/JTwork
Error: Some tests failed or other problems occurred.

I will also investigate further but if you notice something evident could you please let me know whats wrong here?

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

PR: https://git.openjdk.org/jdk/pull/9159

From weijun at openjdk.org  Sat Jul 16 03:08:00 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 16 Jul 2022 03:08:00 GMT
Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule
 is not logged [v2]
In-Reply-To: <l5cLrIX_ZKChDlSoPRHi2vuc2_Too5QEA2SuxLMT7Eo=.55d0fd2b-9e94-4bc6-a26e-8a5027b9bda4@github.com>
References: <R0zl8UunTV29IF1LgFlH2Xns12lg9ni2gTAEyHOtNI4=.9ea5aa0d-f7dd-4ac1-9b3f-b5f84b2f4a99@github.com>
 <l5cLrIX_ZKChDlSoPRHi2vuc2_Too5QEA2SuxLMT7Eo=.55d0fd2b-9e94-4bc6-a26e-8a5027b9bda4@github.com>
Message-ID: <AKlSlIx6nPSfj7xvxscp2XyuZXh4q4sQV5y3djTrAqA=.237ece76-6b83-4b61-97d9-8bf221ce55a3@github.com>

On Fri, 15 Jul 2022 13:05:38 GMT, Jayashree Huttanagoudar <duke at openjdk.org> wrote:

>> Could you please review the changes?
>> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug
>
> Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test case to verify the patch

There is a .jtr file inside the JTwork directory containing the detail output.

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

PR: https://git.openjdk.org/jdk/pull/9159

From weijun at openjdk.org  Sat Jul 16 13:36:13 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 16 Jul 2022 13:36:13 GMT
Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule
 is not logged [v2]
In-Reply-To: <l5cLrIX_ZKChDlSoPRHi2vuc2_Too5QEA2SuxLMT7Eo=.55d0fd2b-9e94-4bc6-a26e-8a5027b9bda4@github.com>
References: <R0zl8UunTV29IF1LgFlH2Xns12lg9ni2gTAEyHOtNI4=.9ea5aa0d-f7dd-4ac1-9b3f-b5f84b2f4a99@github.com>
 <l5cLrIX_ZKChDlSoPRHi2vuc2_Too5QEA2SuxLMT7Eo=.55d0fd2b-9e94-4bc6-a26e-8a5027b9bda4@github.com>
Message-ID: <k4rbRUGJ49pJV3G_UqTbSQCWQDWisQVFr8l89oqE81I=.80daa8a6-e3ba-4a18-b564-062af2f9e8e6@github.com>

On Fri, 15 Jul 2022 13:05:38 GMT, Jayashree Huttanagoudar <duke at openjdk.org> wrote:

>> Could you please review the changes?
>> This patch is to address : https://bugs.openjdk.org/browse/JDK-8215916?jql=labels%20%3D%20starter-bug
>
> Jayashree Huttanagoudar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test case to verify the patch

There are quite some JAAS tests inside `test/jdk/javax/security/auth/login` where you can copy. The one you found has a very old copyright header and invalid format (like trailing spaces...). Also, I don't think it's worth implementing a new principal and a new login module. You can just using the out-of-box UnixLoginModule and NTLoginModule.

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

PR: https://git.openjdk.org/jdk/pull/9159

From weijun at openjdk.org  Sat Jul 16 13:46:58 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 16 Jul 2022 13:46:58 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after
 login failure [v3]
In-Reply-To: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
References: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
Message-ID: <UqMU7DhaoXfwQOo0lW8mUdfpTkZs9ri5ZomMCTeoUrc=.fe42548b-22ff-4874-b2a2-02ae147766fc@github.com>

> Add null-checks in all `LoginModule` implementations. It's possible that an application calls `logout` after a login failure, where most internal variables for principals and credentials are null and removing a null from the `Subject`'s principals and credentials sets will trigger a `NullPointerException`.

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

  more comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9348/files
  - new: https://git.openjdk.org/jdk/pull/9348/files/810a0114..86c1fd65

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9348&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9348&range=01-02

  Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9348.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9348/head:pull/9348

PR: https://git.openjdk.org/jdk/pull/9348

From duke at openjdk.org  Sat Jul 16 15:26:58 2022
From: duke at openjdk.org (Jayashree Huttanagoudar)
Date: Sat, 16 Jul 2022 15:26:58 GMT
Subject: RFR: 8215916: The failure reason of an optional JAAS LoginModule
 is not logged [v2]
In-Reply-To: <k4rbRUGJ49pJV3G_UqTbSQCWQDWisQVFr8l89oqE81I=.80daa8a6-e3ba-4a18-b564-062af2f9e8e6@github.com>
References: <R0zl8UunTV29IF1LgFlH2Xns12lg9ni2gTAEyHOtNI4=.9ea5aa0d-f7dd-4ac1-9b3f-b5f84b2f4a99@github.com>
 <l5cLrIX_ZKChDlSoPRHi2vuc2_Too5QEA2SuxLMT7Eo=.55d0fd2b-9e94-4bc6-a26e-8a5027b9bda4@github.com>
 <k4rbRUGJ49pJV3G_UqTbSQCWQDWisQVFr8l89oqE81I=.80daa8a6-e3ba-4a18-b564-062af2f9e8e6@github.com>
Message-ID: <ZxJchzvr6PmPBL_C3QnAQyJizdvqAAJm4OWM6sLrVRA=.01c47ca8-85dc-4946-86a0-3879394d7352@github.com>

On Sat, 16 Jul 2022 13:32:44 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> There are quite some JAAS tests inside `test/jdk/javax/security/auth/login` where you can copy. The one you found has a very old copyright header and invalid format (like trailing spaces...). Also, I don't think it's worth implementing a new principal and a new login module. You can just using the out-of-box UnixLoginModule and NTLoginModule.

That makes sense :) I will try that.

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

PR: https://git.openjdk.org/jdk/pull/9159

From dholmes at openjdk.org  Sun Jul 17 23:03:37 2022
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 17 Jul 2022 23:03:37 GMT
Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC
Message-ID: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>

Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains.

All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed.  Additionally:

The Java manpage was missing updates from:
- [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page.

The Java manpage has slight formatting differences from:
- [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux
- [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS

The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20)


The keytool manpage was missing updates from:
- [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page.
- [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA

The jar manpage was missing updates from:
- [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)

The jarsigner manpage was missing updates from:
- [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page.
- [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA

The javadoc manpage was missing updates from:
- [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option

The jmod manpage was missing updates from:
- [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)

The jpackage manpage was missing updates from:
- [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature
- [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19
- [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code

The jshell manpage was missing updates from:
- [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page.

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

Commit messages:
 - 8278274: Update nroff pages in JDK 19 before RC

Changes: https://git.openjdk.org/jdk19/pull/145/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=145&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8278274
  Stats: 515 lines in 28 files changed: 431 ins; 16 del; 68 mod
  Patch: https://git.openjdk.org/jdk19/pull/145.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/145/head:pull/145

PR: https://git.openjdk.org/jdk19/pull/145

From jjg at openjdk.org  Mon Jul 18 15:24:06 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 18 Jul 2022 15:24:06 GMT
Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC
In-Reply-To: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
References: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
Message-ID: <75mqpwhSuTfYsLguWkG0izRelatkAX7wOwsjC3crYFI=.2449d017-855e-4da9-b1b3-2fcee65cba2c@github.com>

On Sun, 17 Jul 2022 22:44:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains.
> 
> All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed.  Additionally:
> 
> The Java manpage was missing updates from:
> - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page.
> 
> The Java manpage has slight formatting differences from:
> - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux
> - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS
> 
> The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20)
> 
> 
> The keytool manpage was missing updates from:
> - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page.
> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
> 
> The jar manpage was missing updates from:
> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
> 
> The jarsigner manpage was missing updates from:
> - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page.
> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
> 
> The javadoc manpage was missing updates from:
> - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option
> 
> The jmod manpage was missing updates from:
> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
> 
> The jpackage manpage was missing updates from:
> - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature
> - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19
> - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code
> 
> The jshell manpage was missing updates from:
> - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page.

src/java.base/share/man/keytool.1 line 456:

> 454: \f[CB]PrivateKeyEntry\f[R] for the signer that already exists in the
> 455: keystore.
> 456: This option is used to sign the certificate with the signer?s private

Not a problem with this PR as such, but we still have a `?` character in the output.

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

PR: https://git.openjdk.org/jdk19/pull/145

From jjg at openjdk.org  Mon Jul 18 15:30:09 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 18 Jul 2022 15:30:09 GMT
Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC
In-Reply-To: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
References: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
Message-ID: <UwyC1L1eTUZSFy6b2EYlgy4FkUS1laKFq-MMuFvZKw0=.40611a87-50c9-43b0-9d50-a3e24e6c359e@github.com>

On Sun, 17 Jul 2022 22:44:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains.
> 
> All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed.  Additionally:
> 
> The Java manpage was missing updates from:
> - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page.
> 
> The Java manpage has slight formatting differences from:
> - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux
> - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS
> 
> The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20)
> 
> 
> The keytool manpage was missing updates from:
> - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page.
> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
> 
> The jar manpage was missing updates from:
> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
> 
> The jarsigner manpage was missing updates from:
> - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page.
> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
> 
> The javadoc manpage was missing updates from:
> - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option
> 
> The jmod manpage was missing updates from:
> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
> 
> The jpackage manpage was missing updates from:
> - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature
> - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19
> - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code
> 
> The jshell manpage was missing updates from:
> - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page.

The version changes in each file look good (`19-ea` to `19`).
The changes for javadoc look good.

I looked over the other changes for other files, and while they look good, I cannot speak for their technical accuracy. That being said, this is an automated process deriving info from upstream, so is likely OK.

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

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/145

From mullan at openjdk.org  Mon Jul 18 15:53:43 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 18 Jul 2022 15:53:43 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after
 login failure [v3]
In-Reply-To: <UqMU7DhaoXfwQOo0lW8mUdfpTkZs9ri5ZomMCTeoUrc=.fe42548b-22ff-4874-b2a2-02ae147766fc@github.com>
References: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
 <UqMU7DhaoXfwQOo0lW8mUdfpTkZs9ri5ZomMCTeoUrc=.fe42548b-22ff-4874-b2a2-02ae147766fc@github.com>
Message-ID: <1aNdi1otctsMilW_hV8c8KVYdrdnqqGF3pH4EjDf74M=.24bf0523-545a-4bba-9ef8-d3eb5bc21382@github.com>

On Sat, 16 Jul 2022 13:46:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add null-checks in all `LoginModule` implementations. It's possible that an application calls `logout` after a login failure, where most internal variables for principals and credentials are null and removing a null from the `Subject`'s principals and credentials sets will trigger a `NullPointerException`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more comment

I can also review the CSR when it is ready.

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

Marked as reviewed by mullan (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9348

From duke at openjdk.org  Mon Jul 18 17:14:50 2022
From: duke at openjdk.org (Mark Powers)
Date: Mon, 18 Jul 2022 17:14:50 GMT
Subject: RFR: 4887998: Use Integer.rotateLeft() and rotateRight() in crypto
 implementations [v2]
In-Reply-To: <IgzQOrXkg0orrUwADv9tsfAjWrUE5PS0PfCzfWQgRUw=.ed9d703c-dbd3-45d2-8d82-9a760979c019@github.com>
References: <LVEXGxnQ0Fg1--fMtObYItYsIzJkTZDa_ooNoqgswcg=.8e792a04-35d1-4b58-9637-791e640c0fcf@github.com>
 <IgzQOrXkg0orrUwADv9tsfAjWrUE5PS0PfCzfWQgRUw=.ed9d703c-dbd3-45d2-8d82-9a760979c019@github.com>
Message-ID: <3tYAq5b69hEZHr6FVKE_owDWQ5u0mHZ_c_vYGaywNz8=.cad2d931-cf84-4a40-8a00-2ad4a7934e3a@github.com>

On Tue, 12 Jul 2022 03:02:16 GMT, Mark Powers <duke at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-4887998
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   second iteration

Is there anything more that I need to check before integration?

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

PR: https://git.openjdk.org/jdk/pull/9456

From duke at openjdk.org  Mon Jul 18 17:20:08 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 18 Jul 2022 17:20:08 GMT
Subject: Integrated: 8289908: Skip bounds check for cases when String is
 constructed from entirely used byte[]
In-Reply-To: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
References: <-aIdom0T8w1cLhdq-VKOmN0-kp3-aeDcDir--9PRUuc=.12a5b344-21f6-4cec-9237-db8b1e108a5c@github.com>
Message-ID: <kgNxmv6OzEQK3mQVd_R6Vhx_IgMVBH82h0a4-SNcSA0=.d50be8bd-d9bd-4be6-ade3-ed1b9d215daf@github.com>

On Thu, 7 Jul 2022 10:21:06 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> We can skip bounds check and null check for Charset in case we use the array entirely and the Charset is either default one or proven to be non-null.
> 
> Benchmark results:
> 
> before
> 
> Benchmark                                                  Mode  Cnt  Score   Error  Units
> StringConstructor.newStringFromArray                       avgt   50  4,815 ? 0,154  ns/op
> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,462 ? 0,068  ns/op
> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,653 ? 0,040  ns/op
> StringConstructor.newStringFromRangedArray                 avgt   50  5,090 ? 0,066  ns/op
> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,550 ? 0,041  ns/op
> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  8,080 ? 0,055  ns/op
> 
> after
> 
> Benchmark                                                  Mode  Cnt  Score   Error  Units
> StringConstructor.newStringFromArray                       avgt   50  4,595 ? 0,053  ns/op
> StringConstructor.newStringFromArrayWithCharset            avgt   50  4,038 ? 0,062  ns/op
> StringConstructor.newStringFromArrayWithCharsetName        avgt   50  8,035 ? 0,031  ns/op
> StringConstructor.newStringFromRangedArray                 avgt   50  4,084 ? 0,007  ns/op
> StringConstructor.newStringFromRangedArrayWithCharset      avgt   50  4,014 ? 0,008  ns/op
> StringConstructor.newStringFromRangedArrayWithCharsetName  avgt   50  7,466 ? 0,071  ns/op

This pull request has now been integrated.

Changeset: efed7a7f
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/efed7a7f65c0fa4b757ac6b448d11d7ddebdcc9a
Stats:     97 lines in 5 files changed: 84 ins; 1 del; 12 mod

8289908: Skip bounds check for cases when String is constructed from entirely used byte[]

Reviewed-by: prr, rriggs, aturbanov

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

PR: https://git.openjdk.org/jdk/pull/9407

From weijun at openjdk.org  Mon Jul 18 17:54:09 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 18 Jul 2022 17:54:09 GMT
Subject: RFR: 8282730: LdapLoginModule throw NPE from logout method after
 login failure [v3]
In-Reply-To: <UqMU7DhaoXfwQOo0lW8mUdfpTkZs9ri5ZomMCTeoUrc=.fe42548b-22ff-4874-b2a2-02ae147766fc@github.com>
References: <w4_nBSZQ3c1rUm36Mn84MwNnjmvT3e5xN4ctdn9n_yM=.82709386-43e1-4e33-94d8-2d80d29a3c9c@github.com>
 <UqMU7DhaoXfwQOo0lW8mUdfpTkZs9ri5ZomMCTeoUrc=.fe42548b-22ff-4874-b2a2-02ae147766fc@github.com>
Message-ID: <BpA-ZGs_Y2Qe_8SCxpZa-IRUwwHlE_3cetmkgQgIjSA=.bcd1b6cb-0b8c-46f8-95f9-96006434cdfb@github.com>

On Sat, 16 Jul 2022 13:46:58 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add null-checks in all `LoginModule` implementations. It's possible that an application calls `logout` after a login failure, where most internal variables for principals and credentials are null and removing a null from the `Subject`'s principals and credentials sets will trigger a `NullPointerException`.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more comment

Thanks. CSR is filed at https://bugs.openjdk.org/browse/JDK-8290119. I've also written a release note at https://bugs.openjdk.org/browse/JDK-8290467. Please take a review.

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

PR: https://git.openjdk.org/jdk/pull/9348

From weijun at openjdk.org  Mon Jul 18 18:49:04 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 18 Jul 2022 18:49:04 GMT
Subject: RFR: 4887998: Use Integer.rotateLeft() and rotateRight() in crypto
 implementations [v2]
In-Reply-To: <IgzQOrXkg0orrUwADv9tsfAjWrUE5PS0PfCzfWQgRUw=.ed9d703c-dbd3-45d2-8d82-9a760979c019@github.com>
References: <LVEXGxnQ0Fg1--fMtObYItYsIzJkTZDa_ooNoqgswcg=.8e792a04-35d1-4b58-9637-791e640c0fcf@github.com>
 <IgzQOrXkg0orrUwADv9tsfAjWrUE5PS0PfCzfWQgRUw=.ed9d703c-dbd3-45d2-8d82-9a760979c019@github.com>
Message-ID: <4jS56AYwnaNBU5A0ekl6r8OY3-mmecV9Ju012oLtPPY=.4854d22f-5b46-475c-bf73-ff442f5bfa2e@github.com>

On Tue, 12 Jul 2022 03:02:16 GMT, Mark Powers <duke at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-4887998
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   second iteration

Looks good to me. No more comment.

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

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9456

From duke at openjdk.org  Mon Jul 18 20:55:02 2022
From: duke at openjdk.org (Mark Powers)
Date: Mon, 18 Jul 2022 20:55:02 GMT
Subject: Integrated: 4887998: Use Integer.rotateLeft() and rotateRight() in
 crypto implementations
In-Reply-To: <LVEXGxnQ0Fg1--fMtObYItYsIzJkTZDa_ooNoqgswcg=.8e792a04-35d1-4b58-9637-791e640c0fcf@github.com>
References: <LVEXGxnQ0Fg1--fMtObYItYsIzJkTZDa_ooNoqgswcg=.8e792a04-35d1-4b58-9637-791e640c0fcf@github.com>
Message-ID: <jMFJOvGrSlnOvsE_G7abMm3TH8DNFHvNsJDOEpTcLQ8=.0fbf9439-504e-4fea-8b5a-6eb5918d4f82@github.com>

On Mon, 11 Jul 2022 21:20:43 GMT, Mark Powers <duke at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-4887998

This pull request has now been integrated.

Changeset: b65f7ec2
Author:    Mark Powers <mark.powers at oracle.com>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b65f7ec2f149d688a37b2c5b2ece312b52133dec
Stats:     31 lines in 5 files changed: 0 ins; 0 del; 31 mod

4887998: Use Integer.rotateLeft() and rotateRight() in crypto implementations

Reviewed-by: weijun

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

PR: https://git.openjdk.org/jdk/pull/9456

From rriggs at openjdk.org  Mon Jul 18 22:21:04 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Jul 2022 22:21:04 GMT
Subject: RFR: 8288568: Reduce runtime of java.security microbenchmarks [v2]
In-Reply-To: <NzdPkZd4JpMSRw2aZsDDAPl5_rE6Wk9Ni3ihepZF06M=.7cb1f36a-c1ac-42cc-bd02-1d2be87b2965@github.com>
References: <Nrhp4VhuA-8CXq8Q-RSswJ142xXlU9_90QSihB9-5qw=.fad10540-8ac6-4f4a-a749-582fb4680ee3@github.com>
 <NzdPkZd4JpMSRw2aZsDDAPl5_rE6Wk9Ni3ihepZF06M=.7cb1f36a-c1ac-42cc-bd02-1d2be87b2965@github.com>
Message-ID: <GuR4uqm2k-ePjdAqSLTEu8do3zwDJ0lCXpul79ORMGI=.19b9e7e3-3c34-4813-9c3c-8d798d5fa2ab@github.com>

On Fri, 17 Jun 2022 12:24:50 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> - Reduce forks, iteration, runtime to reduce runtime while maintaining high data quality on typical benchmarking hosts.
>> 
>> Reduces runtime from estimated 10+ hours to 54 minutes.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyrights, apply consistent settings to PermissionsImplies

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9189

From dholmes at openjdk.org  Mon Jul 18 23:32:04 2022
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 18 Jul 2022 23:32:04 GMT
Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC
In-Reply-To: <UwyC1L1eTUZSFy6b2EYlgy4FkUS1laKFq-MMuFvZKw0=.40611a87-50c9-43b0-9d50-a3e24e6c359e@github.com>
References: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
 <UwyC1L1eTUZSFy6b2EYlgy4FkUS1laKFq-MMuFvZKw0=.40611a87-50c9-43b0-9d50-a3e24e6c359e@github.com>
Message-ID: <Bx5KJ0K1oEDxEkvQf_xBVYiL1foF38AVFPy9tLp6YTg=.f851a628-86b6-4edf-89b1-c91f13728a51@github.com>

On Mon, 18 Jul 2022 15:26:23 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains.
>> 
>> All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed.  Additionally:
>> 
>> The Java manpage was missing updates from:
>> - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page.
>> 
>> The Java manpage has slight formatting differences from:
>> - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux
>> - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS
>> 
>> The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20)
>> 
>> 
>> The keytool manpage was missing updates from:
>> - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page.
>> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
>> 
>> The jar manpage was missing updates from:
>> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
>> 
>> The jarsigner manpage was missing updates from:
>> - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page.
>> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
>> 
>> The javadoc manpage was missing updates from:
>> - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option
>> 
>> The jmod manpage was missing updates from:
>> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
>> 
>> The jpackage manpage was missing updates from:
>> - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature
>> - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19
>> - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code
>> 
>> The jshell manpage was missing updates from:
>> - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page.
>
> The version changes in each file look good (`19-ea` to `19`).
> The changes for javadoc look good.
> 
> I looked over the other changes for other files, and while they look good, I cannot speak for their technical accuracy. That being said, this is an automated process deriving info from upstream, so is likely OK.

Thanks for the review @jonathan-gibbons ! I'll wait a day in case there are any further comments.

> src/java.base/share/man/keytool.1 line 456:
> 
>> 454: \f[CB]PrivateKeyEntry\f[R] for the signer that already exists in the
>> 455: keystore.
>> 456: This option is used to sign the certificate with the signer?s private
> 
> Not a problem with this PR as such, but we still have a `?` character in the output.

Yeah I spotted that too, but it would need to be fixed in source and nroff.  Must be some kind of "smart quote" from an editor. Do you think this needs to be fixed or just handle it in mainline?

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

PR: https://git.openjdk.org/jdk19/pull/145

From duke at openjdk.org  Tue Jul 19 00:34:17 2022
From: duke at openjdk.org (Hollow Man)
Date: Tue, 19 Jul 2022 00:34:17 GMT
Subject: RFR: 8290463: Fix several comment typos in sun.security.ec
Message-ID: <tXs7ctWIEY7Sos_N4SqbS4wsw_fNrateyck78k82qEE=.82640187-2b25-4dc0-afbb-33efc3150659@github.com>

inifinity -> infinity
nonnce -> nonce
hasg -> hash

Signed-off-by: Hollow Man <hollowman at opensuse.org>

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

Commit messages:
 - Fix several comment typos in sun.security.ec

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

PR: https://git.openjdk.org/jdk/pull/9541

From xuelei at openjdk.org  Tue Jul 19 00:49:03 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 19 Jul 2022 00:49:03 GMT
Subject: RFR: 8290463: Fix several comment typos in sun.security.ec
In-Reply-To: <tXs7ctWIEY7Sos_N4SqbS4wsw_fNrateyck78k82qEE=.82640187-2b25-4dc0-afbb-33efc3150659@github.com>
References: <tXs7ctWIEY7Sos_N4SqbS4wsw_fNrateyck78k82qEE=.82640187-2b25-4dc0-afbb-33efc3150659@github.com>
Message-ID: <CaNYFZs10s0ZPHbEEV0iYS4RpePJYTzqYoFaK29_QQw=.7deeb65a-0476-4297-9ab2-f69fee196f13@github.com>

On Mon, 18 Jul 2022 15:22:16 GMT, Hollow Man <duke at openjdk.org> wrote:

> inifinity -> infinity
> nonnce -> nonce
> hasg -> hash
> 
> Signed-off-by: Hollow Man <hollowman at opensuse.org>

Looks good to me.  Thanks!

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

Marked as reviewed by xuelei (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9541

From duke at openjdk.org  Tue Jul 19 01:53:03 2022
From: duke at openjdk.org (Hollow Man)
Date: Tue, 19 Jul 2022 01:53:03 GMT
Subject: Integrated: 8290463: Fix several comment typos in sun.security.ec
In-Reply-To: <tXs7ctWIEY7Sos_N4SqbS4wsw_fNrateyck78k82qEE=.82640187-2b25-4dc0-afbb-33efc3150659@github.com>
References: <tXs7ctWIEY7Sos_N4SqbS4wsw_fNrateyck78k82qEE=.82640187-2b25-4dc0-afbb-33efc3150659@github.com>
Message-ID: <xFvHQ1S6MRAkNg67RPacXQzkbdszeJELZNrwjHkXZQ8=.35e5170f-64fc-4db0-9501-2672891979fa@github.com>

On Mon, 18 Jul 2022 15:22:16 GMT, Hollow Man <duke at openjdk.org> wrote:

> inifinity -> infinity
> nonnce -> nonce
> hasg -> hash
> 
> Signed-off-by: Hollow Man <hollowman at opensuse.org>

This pull request has now been integrated.

Changeset: af86cd3d
Author:    Hollow Man <hollowman at opensuse.org>
Committer: Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/af86cd3d8c0f8a874d1b738ad0caeeb7cd4c61d0
Stats:     4 lines in 3 files changed: 0 ins; 0 del; 4 mod

8290463: Fix several comment typos in sun.security.ec

Reviewed-by: xuelei

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

PR: https://git.openjdk.org/jdk/pull/9541

From mbaesken at openjdk.org  Tue Jul 19 13:22:46 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 19 Jul 2022 13:22:46 GMT
Subject: RFR: JDK-8290532: Adjust PKCS11Exception and handle more PKCS11 error
 codes
Message-ID: <kccdSpgGrSgPAyqLQNOGBo7QqMF-hxiHfc_rO9X-sL8=.f56646dd-d135-4f1a-85fb-34bcfdcc648e@github.com>

The issue https://bugs.openjdk.org/browse/JDK-8282538 gave an example of the following PKCS11 exception (see attached jtr files of that bug) :

.... Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: 0xCE534351

Unfortunately the error code 0xCE534351 is currently not in the RV/errorMap table of PKCS11Exception, That's why we get this
hex code and no more descriptive output, this could be improved.

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

Commit messages:
 - JDK-8290532

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

PR: https://git.openjdk.org/jdk/pull/9555

From mbaesken at openjdk.org  Tue Jul 19 14:10:59 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 19 Jul 2022 14:10:59 GMT
Subject: RFR: JDK-8290532: Adjust PKCS11Exception and handle more PKCS11
 error codes
In-Reply-To: <kccdSpgGrSgPAyqLQNOGBo7QqMF-hxiHfc_rO9X-sL8=.f56646dd-d135-4f1a-85fb-34bcfdcc648e@github.com>
References: <kccdSpgGrSgPAyqLQNOGBo7QqMF-hxiHfc_rO9X-sL8=.f56646dd-d135-4f1a-85fb-34bcfdcc648e@github.com>
Message-ID: <rmoTjkXj6AKYQdlqZPmfydFhyuCrBGT0LbITXldGYgo=.7ed87942-0c54-425d-ad35-ea3f564b5655@github.com>

On Tue, 19 Jul 2022 13:14:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The issue https://bugs.openjdk.org/browse/JDK-8282538 gave an example of the following PKCS11 exception (see attached jtr files of that bug) :
> 
> .... Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: 0xCE534351
> 
> Unfortunately the error code 0xCE534351 is currently not in the RV/errorMap table of PKCS11Exception, That's why we get this
> hex code and no more descriptive output, this could be improved.

Btw.  there are for most (all?)  pkcs11 error/return codes good  error descriptions available here http://docs.oasis-open.org/pkcs11/pkcs11-base/v3.0/os/pkcs11-base-v3.0-os.html   (5.1 Function return values) ; should we maybe extend the exception message with a short text

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

PR: https://git.openjdk.org/jdk/pull/9555

From duke at openjdk.org  Tue Jul 19 14:57:24 2022
From: duke at openjdk.org (Mark Powers)
Date: Tue, 19 Jul 2022 14:57:24 GMT
Subject: RFR: JDK-8155039 Simplify code to setup SSLContextImpl and
 TrustManagerFactoryImpl
Message-ID: <tDZXU5n4r_MmyIbI0EKeHldOYdmAvveZuStqGhdvQG0=.d7649485-91ac-4de7-b30a-78ff6bc77450@github.com>

https://bugs.openjdk.org/browse/JDK-8155039

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

Commit messages:
 - fourth iteration
 - third iteration
 - second iteration
 - first iteration

Changes: https://git.openjdk.org/jdk/pull/9542/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9542&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8155039
  Stats: 85 lines in 4 files changed: 48 ins; 29 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/9542.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9542/head:pull/9542

PR: https://git.openjdk.org/jdk/pull/9542

From weijun at openjdk.org  Tue Jul 19 16:48:57 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 19 Jul 2022 16:48:57 GMT
Subject: RFR: JDK-8155039 Simplify code to setup SSLContextImpl and
 TrustManagerFactoryImpl
In-Reply-To: <tDZXU5n4r_MmyIbI0EKeHldOYdmAvveZuStqGhdvQG0=.d7649485-91ac-4de7-b30a-78ff6bc77450@github.com>
References: <tDZXU5n4r_MmyIbI0EKeHldOYdmAvveZuStqGhdvQG0=.d7649485-91ac-4de7-b30a-78ff6bc77450@github.com>
Message-ID: <EZVJDhkQ6CxwXB0bngD1GZRJP7fKqTw_WZ4BQZSE6lk=.12296b48-dd92-4d7e-82f0-4fe82c1d09c5@github.com>

On Mon, 18 Jul 2022 17:53:56 GMT, Mark Powers <duke at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8155039

I'm not sure if this is worth doing. It looks like after the code change each of the 2 constructors is only used once by one of the 2 new `privilegedGetFileInputStream` methods, and then each new method is only used once in JSSE.

Also, the `SecurityManager` API including these `doPrivileged` calls were deprecated for removal in JDK 17. I doubt spending more time tuning them makes us any good.

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

PR: https://git.openjdk.org/jdk/pull/9542

From duke at openjdk.org  Tue Jul 19 18:28:49 2022
From: duke at openjdk.org (Mark Powers)
Date: Tue, 19 Jul 2022 18:28:49 GMT
Subject: RFR: JDK-8155039 Simplify code to setup SSLContextImpl and
 TrustManagerFactoryImpl
In-Reply-To: <tDZXU5n4r_MmyIbI0EKeHldOYdmAvveZuStqGhdvQG0=.d7649485-91ac-4de7-b30a-78ff6bc77450@github.com>
References: <tDZXU5n4r_MmyIbI0EKeHldOYdmAvveZuStqGhdvQG0=.d7649485-91ac-4de7-b30a-78ff6bc77450@github.com>
Message-ID: <6E0E_GNjfkt9KA24XWFLxoPE4sVPHMz-sdE0-NLhM7U=.61a81d37-48ee-4efc-bc32-ffe70c6b1c35@github.com>

On Mon, 18 Jul 2022 17:53:56 GMT, Mark Powers <duke at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8155039

Can't say I disagree. That would leave removing the unused method from TrustManagerFactoryImpl.java and a couple of typos.

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

PR: https://git.openjdk.org/jdk/pull/9542

From weijun at openjdk.org  Tue Jul 19 18:42:44 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 19 Jul 2022 18:42:44 GMT
Subject: RFR: JDK-8155039 Simplify code to setup SSLContextImpl and
 TrustManagerFactoryImpl
In-Reply-To: <tDZXU5n4r_MmyIbI0EKeHldOYdmAvveZuStqGhdvQG0=.d7649485-91ac-4de7-b30a-78ff6bc77450@github.com>
References: <tDZXU5n4r_MmyIbI0EKeHldOYdmAvveZuStqGhdvQG0=.d7649485-91ac-4de7-b30a-78ff6bc77450@github.com>
Message-ID: <qpMsXJlqhDCeD-exr7G-5YTz5ZjDb7serW2j-ZteoBo=.9fbe59f9-c7cd-4f1d-aad3-9e5df7464ea8@github.com>

On Mon, 18 Jul 2022 17:53:56 GMT, Mark Powers <duke at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8155039

We can do them in a separate cleanup and close this one with Will-Not-Fix. Otherwise, you need to change the title of this bug to "cleanup something" and a historian will find it confusing on what was determined.

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

PR: https://git.openjdk.org/jdk/pull/9542

From valeriep at openjdk.org  Tue Jul 19 20:41:01 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Tue, 19 Jul 2022 20:41:01 GMT
Subject: RFR: JDK-8290532: Adjust PKCS11Exception and handle more PKCS11
 error codes
In-Reply-To: <kccdSpgGrSgPAyqLQNOGBo7QqMF-hxiHfc_rO9X-sL8=.f56646dd-d135-4f1a-85fb-34bcfdcc648e@github.com>
References: <kccdSpgGrSgPAyqLQNOGBo7QqMF-hxiHfc_rO9X-sL8=.f56646dd-d135-4f1a-85fb-34bcfdcc648e@github.com>
Message-ID: <nHrj7MaUPu_5eriWSRF0mMmtuZeM0oO2WJ4hAIuC-TM=.7e1e5252-9460-4d99-bd50-1cebde19836e@github.com>

On Tue, 19 Jul 2022 13:14:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The issue https://bugs.openjdk.org/browse/JDK-8282538 gave an example of the following PKCS11 exception (see attached jtr files of that bug) :
> 
> .... Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: 0xCE534351
> 
> Unfortunately the error code 0xCE534351 is currently not in the RV/errorMap table of PKCS11Exception, That's why we get this
> hex code and no more descriptive output, this could be improved.

None of the 3 proposed error codes in this PR is in the standard PKCS#11 header files - two of them are vendor specific. For vendor specific error code, such direct mapping may be incorrect. As for CKR_COPY_PROHIBITED, I can't find any reference in your cited PKCS#11 spec above. Do you have other standard source for it?

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

PR: https://git.openjdk.org/jdk/pull/9555

From duke at openjdk.org  Tue Jul 19 20:59:47 2022
From: duke at openjdk.org (David Schlosnagle)
Date: Tue, 19 Jul 2022 20:59:47 GMT
Subject: RFR: 8288568: Reduce runtime of java.security microbenchmarks [v2]
In-Reply-To: <NzdPkZd4JpMSRw2aZsDDAPl5_rE6Wk9Ni3ihepZF06M=.7cb1f36a-c1ac-42cc-bd02-1d2be87b2965@github.com>
References: <Nrhp4VhuA-8CXq8Q-RSswJ142xXlU9_90QSihB9-5qw=.fad10540-8ac6-4f4a-a749-582fb4680ee3@github.com>
 <NzdPkZd4JpMSRw2aZsDDAPl5_rE6Wk9Ni3ihepZF06M=.7cb1f36a-c1ac-42cc-bd02-1d2be87b2965@github.com>
Message-ID: <T13-C1Xva_YWgzs90azJwu0tRTR8PNTqtBYfZs8O5iI=.d5e819b0-9c4b-4153-a875-c520158a2303@github.com>

On Fri, 17 Jun 2022 12:24:50 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> - Reduce forks, iteration, runtime to reduce runtime while maintaining high data quality on typical benchmarking hosts.
>> 
>> Reduces runtime from estimated 10+ hours to 54 minutes.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyrights, apply consistent settings to PermissionsImplies

test/micro/org/openjdk/bench/java/security/SSLHandshake.java line 56:

> 54: @Warmup(iterations = 5, time = 1)
> 55: @Measurement(iterations = 5, time = 1)
> 56: @Fork(value = 3)

should the `@Warmup`, `@Measurement`, and `@Fork` be removed from the `doHandshake()` benchmark on lines 115-117 below so that these take effect?

https://github.com/openjdk/jdk/blob/c2cbeb3ee875936c98bb15ec32d692f7d866df76/test/micro/org/openjdk/bench/java/security/SSLHandshake.java#L111-L115

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

PR: https://git.openjdk.org/jdk/pull/9189

From valeriep at openjdk.org  Wed Jul 20 00:01:46 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 20 Jul 2022 00:01:46 GMT
Subject: RFR: 8289275: Remove incorrect __declspec(dllimport) attributes
 from pointers in jdk.crypto.cryptoki [v4]
In-Reply-To: <yBbfEsFgVweDrmKL3Yfcq-s955rIPChU6gRP31n92sg=.9b12b2a4-a1fd-430d-bd8a-206820a13370@github.com>
References: <yM6fqtQfhPvlMnxnqJbc1H-A3SJ0f6n4ee2zgGCmD7M=.d388accc-1210-40e7-8ae6-11118cec5156@github.com>
 <yBbfEsFgVweDrmKL3Yfcq-s955rIPChU6gRP31n92sg=.9b12b2a4-a1fd-430d-bd8a-206820a13370@github.com>
Message-ID: <GLhp1Z9jLxPS0GBsqaTJpxRq4y4tax_gyVOLMPsSP2k=.4d71bfbc-b66f-4572-9fa5-fd4e3a778b12@github.com>

On Thu, 14 Jul 2022 02:48:07 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Several instances of function pointers in jdk.crypto.cryptoki are marked with the dllimport attribute, which should only be applied to symbol declarations, of which a typedef'd function pointer is not. This would only be useful if a function pointer defined in the linked dll is desired to be imported, not if the pointer itself is created locally and used to store a function address. In addition to being incorrect, at least on the versions of Visual C++ the JDK supports today, it is also redundant; Typically they are used to avoid an indirect stub that jumps to the proper entry in the import address table, but usage of these typedefs involves loading the address of a function and directly (Usually through GetProcAddress, even in other cases it would simply be set to the address of a function anyway) assigning it to the pointer before immediately dispatching when called, which bypasses this procedure entirely and makes the attribute pointless.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to pkcs11.h

Marked as reviewed by valeriep (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9353

From dholmes at openjdk.org  Wed Jul 20 04:44:05 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Jul 2022 04:44:05 GMT
Subject: [jdk19] Integrated: 8278274: Update nroff pages in JDK 19 before RC
In-Reply-To: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
References: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
Message-ID: <AMZ5T-Qky56FldFenzaRAnlaGG4Nxts3inu5GfIlS3c=.7e260c05-107b-48dd-b04b-48e791d0a7d6@github.com>

On Sun, 17 Jul 2022 22:44:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review these changes to the nroff manpage files so that they match their markdown sources that Oracle maintains.
> 
> All pages at a minimum have 19-ea replaced with 19, and copyright set to 2022 if needed.  Additionally:
> 
> The Java manpage was missing updates from:
> - [JDK-8282018](https://bugs.openjdk.org/browse/JDK-8282018): Add captions to tables on java man page.
> 
> The Java manpage has slight formatting differences from:
> - [JDK-8262004](https://bugs.openjdk.org/browse/JDK-8262004): Classpath separator: Man page says semicolon; should be colon on Linux
> - [JDK-8236569](https://bugs.openjdk.org/browse/JDK-8236569): -Xss not multiple of 4K does not work for the main thread on macOS
> 
> The Java manpage has a typo fixed in mainline by [JDK-8279047](https://bugs.openjdk.org/browse/JDK-8279047) (for JDK 20)
> 
> 
> The keytool manpage was missing updates from:
> - [JDK-8282014](https://bugs.openjdk.org/browse/JDK-8282014): Add captions to tables on keytool man page.
> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
> 
> The jar manpage was missing updates from:
> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
> 
> The jarsigner manpage was missing updates from:
> - [JDK-8282015](https://bugs.openjdk.org/browse/JDK-8282015): Add captions to tables on jarsigner man page.
> - [JDK-8267319](https://bugs.openjdk.org/browse/JDK-8267319): Use larger default key sizes and algorithms based on CNSA
> 
> The javadoc manpage was missing updates from:
> - [JDK-8279034](https://bugs.openjdk.org/browse/JDK-8279034): Update man page for javadoc `--date` option
> 
> The jmod manpage was missing updates from:
> - [JDK-8278764](https://bugs.openjdk.org/browse/JDK-8278764): jar and jmod man pages need the new --date documenting from CSR [JDK-8277755](https://bugs.openjdk.org/browse/JDK-8277755)
> 
> The jpackage manpage was missing updates from:
> - [JDK-8285146](https://bugs.openjdk.org/browse/JDK-8285146): Document jpackage resource dir feature
> - [JDK-8284695](https://bugs.openjdk.org/browse/JDK-8284695): Update jpackage man pages for JDK 19
> - [JDK-8284209](https://bugs.openjdk.org/browse/JDK-8284209): Replace remaining usages of 'a the' in source code
> 
> The jshell manpage was missing updates from:
> - [JDK-8282016](https://bugs.openjdk.org/browse/JDK-8282016): Add captions to tables on jshell man page.

This pull request has now been integrated.

Changeset: 618f3a82
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/618f3a82a4d45cdb66b86259ae60dd1c322b987b
Stats:     515 lines in 28 files changed: 431 ins; 16 del; 68 mod

8278274: Update nroff pages in JDK 19 before RC

Reviewed-by: jjg

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

PR: https://git.openjdk.org/jdk19/pull/145

From dholmes at openjdk.org  Wed Jul 20 05:37:13 2022
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Jul 2022 05:37:13 GMT
Subject: [jdk19] RFR: 8278274: Update nroff pages in JDK 19 before RC
In-Reply-To: <Bx5KJ0K1oEDxEkvQf_xBVYiL1foF38AVFPy9tLp6YTg=.f851a628-86b6-4edf-89b1-c91f13728a51@github.com>
References: <d3yzjvTqRkMax-Aq0esRIjkMIZQizVgw_zuq41xVhw8=.bfd1fe45-9d79-4bda-bced-234a4f91a227@github.com>
 <UwyC1L1eTUZSFy6b2EYlgy4FkUS1laKFq-MMuFvZKw0=.40611a87-50c9-43b0-9d50-a3e24e6c359e@github.com>
 <Bx5KJ0K1oEDxEkvQf_xBVYiL1foF38AVFPy9tLp6YTg=.f851a628-86b6-4edf-89b1-c91f13728a51@github.com>
Message-ID: <BhpRMQOoet5mjjrvmhiT1okUnn9PAbPuGa4PE3HNaAM=.2461be8a-096b-4e18-88f2-10b9e2dc519d@github.com>

On Mon, 18 Jul 2022 23:27:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/java.base/share/man/keytool.1 line 456:
>> 
>>> 454: \f[CB]PrivateKeyEntry\f[R] for the signer that already exists in the
>>> 455: keystore.
>>> 456: This option is used to sign the certificate with the signer?s private
>> 
>> Not a problem with this PR as such, but we still have a `?` character in the output.
>
> Yeah I spotted that too, but it would need to be fixed in source and nroff.  Must be some kind of "smart quote" from an editor. Do you think this needs to be fixed or just handle it in mainline?

Filed [JDK-8290626](https://bugs.openjdk.org/browse/JDK-8290626). It can easily be fixed before RDP2.

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

PR: https://git.openjdk.org/jdk19/pull/145

From mbaesken at openjdk.org  Wed Jul 20 06:52:02 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 20 Jul 2022 06:52:02 GMT
Subject: RFR: JDK-8290532: Adjust PKCS11Exception and handle more PKCS11
 error codes
In-Reply-To: <nHrj7MaUPu_5eriWSRF0mMmtuZeM0oO2WJ4hAIuC-TM=.7e1e5252-9460-4d99-bd50-1cebde19836e@github.com>
References: <kccdSpgGrSgPAyqLQNOGBo7QqMF-hxiHfc_rO9X-sL8=.f56646dd-d135-4f1a-85fb-34bcfdcc648e@github.com>
 <nHrj7MaUPu_5eriWSRF0mMmtuZeM0oO2WJ4hAIuC-TM=.7e1e5252-9460-4d99-bd50-1cebde19836e@github.com>
Message-ID: <3MPgwbE2bq-WSPhDi-PZET_EHGq-zMASUEHX0MnFYbM=.80a8d14b-68bc-4442-be4c-3466c86eee9e@github.com>

On Tue, 19 Jul 2022 20:37:09 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> None of the 3 proposed error codes in this PR is in the standard PKCS#11 header files - two of them are vendor specific. For vendor specific error code, such direct mapping may be incorrect. As for CKR_COPY_PROHIBITED, I can't find any reference in your cited PKCS#11 spec above. Do you have other standard source for it?

Hi Valerie, yes 0xCE534351L and 0xCE534352L are vendor specific but I added them because we got those  (well the first one) in our jtreg test (please see JDK-8282538 for a detailled description,  we got the same on RHEL9 instead of CentOS). So they are rather common errors on Linux I think and it would be nice to have them.
The  CKR_COPY_PROHIBITED  seems to be deprecated, see this discussion  https://lists.oasis-open.org/archives/pkcs11/201306/msg00073.html  ;  so maybe we do not need it any more these days.
The older documentation still mentions it http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/cs01/pkcs11-base-v2.40-cs01.html  .

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

PR: https://git.openjdk.org/jdk/pull/9555

From Ravi.Patel8 at ibm.com  Wed Jul 20 10:39:24 2022
From: Ravi.Patel8 at ibm.com (Ravi Patel8)
Date: Wed, 20 Jul 2022 10:39:24 +0000
Subject: Case-sensitive Keystore for PKCS#12
In-Reply-To: <BN7PR15MB23215251CA5961F14DD433ABA5889@BN7PR15MB2321.namprd15.prod.outlook.com>
References: <BN7PR15MB232128CDD129CB81C8818F1AA5899@BN7PR15MB2321.namprd15.prod.outlook.com>
 <DE7172CE-4305-4AF3-99B3-0BBC29A5F641@gmail.com>
 <a42ac1a6-fb4b-33eb-4621-d43fdf7dbd62@comcast.net>
 <6A9FFB3F-0D38-477A-BCDB-D1CFB927715B@gmail.com>
 <BN7PR15MB23215251CA5961F14DD433ABA5889@BN7PR15MB2321.namprd15.prod.outlook.com>
Message-ID: <BN7PR15MB2321C89DF26D49D1C42AE215A58E9@BN7PR15MB2321.namprd15.prod.outlook.com>

Hi Mike and Xuelei,

Thank you for the suggested solutions with an added attribute and a new provider. Do you think it is something that could be contributed to the JDK, or do you suggest this should be taken up as an external provider?
________________________________
From: Ravi Patel8 <Ravi.Patel8 at ibm.com>
Sent: Thursday, July 14, 2022 6:26 PM
To: Xuelei Fan <xuelei.f at gmail.com>; Michael StJohns <mstjohns at comcast.net>
Cc: security-dev at openjdk.org <security-dev at openjdk.org>
Subject: Re: [EXTERNAL] Re: Case-sensitive Keystore for PKCS#12

Thank you for the suggested solutions with an added attribute and a new provider. Do you think it is something that could be contributed to the JDK, or do you suggest this should be taken up as an external provider?
________________________________
From: security-dev <security-dev-retn at openjdk.org> on behalf of Xuelei Fan <xuelei.f at gmail.com>
Sent: Thursday, July 14, 2022 3:10 AM
To: Michael StJohns <mstjohns at comcast.net>
Cc: security-dev at openjdk.org <security-dev at openjdk.org>
Subject: [EXTERNAL] Re: Case-sensitive Keystore for PKCS#12



> On Jul 13, 2022, at 2:20 PM, Michael StJohns <mstjohns at comcast.net> wrote:
>
> On 7/13/2022 3:26 PM, Xuelei Fan wrote:
>> Is it possible make it in the application layer?  For example, mapping case-sensitive name to case-in-sensitive name before calling into the standard KeyStore APIs.  It may be not good to break the standards for corner cases?
>>
>> Xuelei
>
> Hi Xuelei -
>
> It wouldn't actually be breaking the PKCS12 spec - the addition of more attributes is part of the standard.
I agreed it could not break PKCS12 spec.  I referred to the friendlyName spec in PKCS12.  An additional attribute could be used for the case-in-sensitive name support.  But there is a need to define and support the attribute in the KeyStore implementation, just as you described in your previous reply.


>   Nor, given the CaseExactJKS implementation, would it be breaking the JDK spec AFAICT.  There is this in the KeyStore javadoc:
>
>> Whether aliases are case sensitive is implementation dependent. In order to avoid problems, it is recommended not to use aliases in a KeyStore that only differ in case.
> The approach you suggest wouldn't work, because you couldn't store one key with "MikesKey" and another with "MIKESKEY" in the Keystore.
>

I did not meant to cover the case.  It may be fine to use a map, in which ?MikesKey? may be mapped to ?mikeskkey-1000100?, and MIKESKEY to ?mikeskkey-0000000?, or something else like you described below ("Mike" -> "04mike8?).

Xuelei


> Hmm - let me rephrase that slightly.  You could use this approach, but not in the way you suggested.  Instead, you'd need a transform from a String to a unique string that you could use inside the key store.  The actual alias within the keystore would be the unique string.
>
> One way of doing that: Lowercase the string.  Prepend the string with a 2 character length field.   Post pend the string with a hex field of CEIL(length/16) characters, each hex character representing 16 bits that indicate the case of the string.
>
> e.g. "Mike" -> "04mike8"
>
> Just a thought - Mike
>
>>
>>> On Jul 13, 2022, at 4:38 AM, Ravi Patel8 <Ravi.Patel8 at ibm.com> wrote:
>>>
>>> We have a customer who is having a security requirement. He wants to know, Is it possible to have case-sensitive support for PKCS#12? We referred the RFCs for PKCS#12. We found that PKCS#12 uses a case in-sensitive alias and the alias Name is mapped with friendlyName attribute, which is specified as  "caseIgnoreMatch" as below.
>>>
>>> friendlyName ATTRIBUTE ::= {
>>>           WITH SYNTAX BMPString (SIZE(1..pkcs-9-ub-friendlyName))
>>>           EQUALITY MATCHING RULE caseIgnoreMatch
>>>           SINGLE VALUE TRUE
>>>           ID pkcs-9-at-friendlyName
>>>   }
>>>
>>> The RFCs can be found here:
>>> https://datatracker.ietf.org/doc/html/rfc7292
>>> https://datatracker.ietf.org/doc/html/rfc2985#page-19
>>>
>>> The JKS key store(case in-sensitive alias)  has a special version (CaseExactJKS) that uses case sensitive aliases.
>>> So similarly, Will it be acceptable to have a case sensitive version of PKCS#12 as CaseExactPKCS12 which will use case sensitive aliases?
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220720/baf776c5/attachment-0001.htm>

From mstjohns at comcast.net  Wed Jul 20 14:00:14 2022
From: mstjohns at comcast.net (Michael StJohns)
Date: Wed, 20 Jul 2022 10:00:14 -0400
Subject: Case-sensitive Keystore for PKCS#12
In-Reply-To: <BN7PR15MB2321C89DF26D49D1C42AE215A58E9@BN7PR15MB2321.namprd15.prod.outlook.com>
References: <BN7PR15MB232128CDD129CB81C8818F1AA5899@BN7PR15MB2321.namprd15.prod.outlook.com>
 <DE7172CE-4305-4AF3-99B3-0BBC29A5F641@gmail.com>
 <a42ac1a6-fb4b-33eb-4621-d43fdf7dbd62@comcast.net>
 <6A9FFB3F-0D38-477A-BCDB-D1CFB927715B@gmail.com>
 <BN7PR15MB23215251CA5961F14DD433ABA5889@BN7PR15MB2321.namprd15.prod.outlook.com>
 <BN7PR15MB2321C89DF26D49D1C42AE215A58E9@BN7PR15MB2321.namprd15.prod.outlook.com>
Message-ID: <989582ca-162b-5bce-0337-e67dd2b08ad4@comcast.net>

Hi Ravi -

Not speaking for the openjdk folk, I would expect you would be better 
off implementing this as an external KeyStore provider yourself as I 
would guess there isn't a broad demand for something that meets your 
requirements at this point.

Later, Mike


On 7/20/2022 6:39 AM, Ravi Patel8 wrote:
> Hi Mike and Xuelei,
>
> Thank you for the suggested solutions with an added attribute and a 
> new provider. Do you think it is something that could be contributed 
> to the JDK, or do you suggest this should be taken up as an external 
> provider?
> ------------------------------------------------------------------------
> *From:* Ravi Patel8 <Ravi.Patel8 at ibm.com>
> *Sent:* Thursday, July 14, 2022 6:26 PM
> *To:* Xuelei Fan <xuelei.f at gmail.com>; Michael StJohns 
> <mstjohns at comcast.net>
> *Cc:* security-dev at openjdk.org <security-dev at openjdk.org>
> *Subject:* Re: [EXTERNAL] Re: Case-sensitive Keystore for PKCS#12
> Thank you for the suggested solutions with an added attribute and a 
> new provider. Do you think it is something that could be contributed 
> to the JDK, or do you suggest this should be taken up as an external 
> provider?
> ------------------------------------------------------------------------
> *From:* security-dev <security-dev-retn at openjdk.org> on behalf of 
> Xuelei Fan <xuelei.f at gmail.com>
> *Sent:* Thursday, July 14, 2022 3:10 AM
> *To:* Michael StJohns <mstjohns at comcast.net>
> *Cc:* security-dev at openjdk.org <security-dev at openjdk.org>
> *Subject:* [EXTERNAL] Re: Case-sensitive Keystore for PKCS#12
>
>
> > On Jul 13, 2022, at 2:20 PM, Michael StJohns <mstjohns at comcast.net> 
> wrote:
> >
> > On 7/13/2022 3:26 PM, Xuelei Fan wrote:
> >> Is it possible make it in the application layer?? For example, 
> mapping case-sensitive name to case-in-sensitive name before calling 
> into the standard KeyStore APIs.? It may be not good to break the 
> standards for corner cases?
> >>
> >> Xuelei
> >
> > Hi Xuelei -
> >
> > It wouldn't actually be breaking the PKCS12 spec - the addition of 
> more attributes is part of the standard.
> I agreed it could not break PKCS12 spec.? I referred to the 
> friendlyName spec in PKCS12.? An additional attribute could be used 
> for the case-in-sensitive name support.? But there is a need to define 
> and support the attribute in the KeyStore implementation, just as you 
> described in your previous reply.
>
>
> >?? Nor, given the CaseExactJKS implementation, would it be breaking 
> the JDK spec AFAICT.? There is this in the KeyStore javadoc:
> >
> >> Whether aliases are case sensitive is implementation dependent. In 
> order to avoid problems, it is recommended not to use aliases in a 
> KeyStore that only differ in case.
> > The approach you suggest wouldn't work, because you couldn't store 
> one key with "MikesKey" and another with "MIKESKEY" in the Keystore.
> >
>
> I did not meant to cover the case.? It may be fine to use a map, in 
> which ?MikesKey? may be mapped to ?mikeskkey-1000100?, and MIKESKEY to 
> ?mikeskkey-0000000?, or something else like you described below 
> ("Mike" -> "04mike8?).
>
> Xuelei
>
>
> > Hmm - let me rephrase that slightly.? You could use this approach, 
> but not in the way you suggested. Instead, you'd need a transform from 
> a String to a unique string that you could use inside the key store. 
> The actual alias within the keystore would be the unique string.
> >
> > One way of doing that: Lowercase the string. Prepend the string with 
> a 2 character length field. Post pend the string with a hex field of 
> CEIL(length/16) characters, each hex character representing 16 bits 
> that indicate the case of the string.
> >
> > e.g. "Mike" -> "04mike8"
> >
> > Just a thought - Mike
> >
> >>
> >>> On Jul 13, 2022, at 4:38 AM, Ravi Patel8 <Ravi.Patel8 at ibm.com> wrote:
> >>>
> >>> We have a customer who is having a security requirement. He wants 
> to know, Is it possible to have case-sensitive support for PKCS#12? We 
> referred the RFCs for PKCS#12. We found that PKCS#12 uses a case 
> in-sensitive alias and the alias Name is mapped with friendlyName 
> attribute, which is specified as "caseIgnoreMatch" as below.
> >>>
> >>> friendlyName ATTRIBUTE ::= {
> >>>?????????? WITH SYNTAX BMPString (SIZE(1..pkcs-9-ub-friendlyName))
> >>>?????????? EQUALITY MATCHING RULE caseIgnoreMatch
> >>>?????????? SINGLE VALUE TRUE
> >>>?????????? ID pkcs-9-at-friendlyName
> >>>?? }
> >>>
> >>> The RFCs can be found here:
> >>> https://datatracker.ietf.org/doc/html/rfc7292
> >>> https://datatracker.ietf.org/doc/html/rfc2985#page-19
> >>>
> >>> The JKS key store(case in-sensitive alias) has a special version 
> (CaseExactJKS) that uses case sensitive aliases.
> >>> So similarly, Will it be acceptable to have a case sensitive 
> version of PKCS#12 as CaseExactPKCS12 which will use case sensitive 
> aliases?
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220720/4dc147a2/attachment.htm>

From xuelei.f at gmail.com  Wed Jul 20 14:04:37 2022
From: xuelei.f at gmail.com (Xuelei Fan)
Date: Wed, 20 Jul 2022 07:04:37 -0700
Subject: Case-sensitive Keystore for PKCS#12
In-Reply-To: <989582ca-162b-5bce-0337-e67dd2b08ad4@comcast.net>
References: <BN7PR15MB232128CDD129CB81C8818F1AA5899@BN7PR15MB2321.namprd15.prod.outlook.com>
 <DE7172CE-4305-4AF3-99B3-0BBC29A5F641@gmail.com>
 <a42ac1a6-fb4b-33eb-4621-d43fdf7dbd62@comcast.net>
 <6A9FFB3F-0D38-477A-BCDB-D1CFB927715B@gmail.com>
 <BN7PR15MB23215251CA5961F14DD433ABA5889@BN7PR15MB2321.namprd15.prod.outlook.com>
 <BN7PR15MB2321C89DF26D49D1C42AE215A58E9@BN7PR15MB2321.namprd15.prod.outlook.com>
 <989582ca-162b-5bce-0337-e67dd2b08ad4@comcast.net>
Message-ID: <59F0DA0A-0D11-449B-87F9-EC94AA9A606D@gmail.com>



> On Jul 20, 2022, at 7:00 AM, Michael StJohns <mstjohns at comcast.net> wrote:
> 
> Hi Ravi - 
> 
> Not speaking for the openjdk folk, I would expect you would be better off implementing this as an external KeyStore provider yourself as I would guess there isn't a broad demand for something that meets your requirements at this point.
> 
+1.

Xuelei

> Later, Mike
> 
> 
> On 7/20/2022 6:39 AM, Ravi Patel8 wrote:
>> Hi Mike and Xuelei,
>> 
>> Thank you for the suggested solutions with an added attribute and a new provider. Do you think it is something that could be contributed to the JDK, or do you suggest this should be taken up as an external provider?
>> From: Ravi Patel8 <Ravi.Patel8 at ibm.com> <mailto:Ravi.Patel8 at ibm.com>
>> Sent: Thursday, July 14, 2022 6:26 PM
>> To: Xuelei Fan <xuelei.f at gmail.com> <mailto:xuelei.f at gmail.com>; Michael StJohns <mstjohns at comcast.net> <mailto:mstjohns at comcast.net>
>> Cc: security-dev at openjdk.org <mailto:security-dev at openjdk.org> <security-dev at openjdk.org> <mailto:security-dev at openjdk.org>
>> Subject: Re: [EXTERNAL] Re: Case-sensitive Keystore for PKCS#12
>>  
>> Thank you for the suggested solutions with an added attribute and a new provider. Do you think it is something that could be contributed to the JDK, or do you suggest this should be taken up as an external provider?
>> From: security-dev <security-dev-retn at openjdk.org> <mailto:security-dev-retn at openjdk.org> on behalf of Xuelei Fan <xuelei.f at gmail.com> <mailto:xuelei.f at gmail.com>
>> Sent: Thursday, July 14, 2022 3:10 AM
>> To: Michael StJohns <mstjohns at comcast.net> <mailto:mstjohns at comcast.net>
>> Cc: security-dev at openjdk.org <mailto:security-dev at openjdk.org> <security-dev at openjdk.org> <mailto:security-dev at openjdk.org>
>> Subject: [EXTERNAL] Re: Case-sensitive Keystore for PKCS#12
>>  
>> 
>> 
>> > On Jul 13, 2022, at 2:20 PM, Michael StJohns <mstjohns at comcast.net> <mailto:mstjohns at comcast.net> wrote:
>> > 
>> > On 7/13/2022 3:26 PM, Xuelei Fan wrote:
>> >> Is it possible make it in the application layer?  For example, mapping case-sensitive name to case-in-sensitive name before calling into the standard KeyStore APIs.  It may be not good to break the standards for corner cases?
>> >> 
>> >> Xuelei
>> > 
>> > Hi Xuelei -
>> > 
>> > It wouldn't actually be breaking the PKCS12 spec - the addition of more attributes is part of the standard.
>> I agreed it could not break PKCS12 spec.  I referred to the friendlyName spec in PKCS12.  An additional attribute could be used for the case-in-sensitive name support.  But there is a need to define and support the attribute in the KeyStore implementation, just as you described in your previous reply.
>> 
>> 
>> >   Nor, given the CaseExactJKS implementation, would it be breaking the JDK spec AFAICT.  There is this in the KeyStore javadoc:
>> > 
>> >> Whether aliases are case sensitive is implementation dependent. In order to avoid problems, it is recommended not to use aliases in a KeyStore that only differ in case. 
>> > The approach you suggest wouldn't work, because you couldn't store one key with "MikesKey" and another with "MIKESKEY" in the Keystore.
>> > 
>> 
>> I did not meant to cover the case.  It may be fine to use a map, in which ?MikesKey? may be mapped to ?mikeskkey-1000100?, and MIKESKEY to ?mikeskkey-0000000?, or something else like you described below ("Mike" -> "04mike8?).
>> 
>> Xuelei
>> 
>> 
>> > Hmm - let me rephrase that slightly.  You could use this approach, but not in the way you suggested.  Instead, you'd need a transform from a String to a unique string that you could use inside the key store.  The actual alias within the keystore would be the unique string.
>> > 
>> > One way of doing that: Lowercase the string.  Prepend the string with a 2 character length field.   Post pend the string with a hex field of CEIL(length/16) characters, each hex character representing 16 bits that indicate the case of the string.
>> > 
>> > e.g. "Mike" -> "04mike8"
>> > 
>> > Just a thought - Mike
>> > 
>> >> 
>> >>> On Jul 13, 2022, at 4:38 AM, Ravi Patel8 <Ravi.Patel8 at ibm.com> <mailto:Ravi.Patel8 at ibm.com> wrote:
>> >>> 
>> >>> We have a customer who is having a security requirement. He wants to know, Is it possible to have case-sensitive support for PKCS#12? We referred the RFCs for PKCS#12. We found that PKCS#12 uses a case in-sensitive alias and the alias Name is mapped with friendlyName attribute, which is specified as  "caseIgnoreMatch" as below.
>> >>> 
>> >>> friendlyName ATTRIBUTE ::= {
>> >>>           WITH SYNTAX BMPString (SIZE(1..pkcs-9-ub-friendlyName))
>> >>>           EQUALITY MATCHING RULE caseIgnoreMatch
>> >>>           SINGLE VALUE TRUE
>> >>>           ID pkcs-9-at-friendlyName
>> >>>   }
>> >>> 
>> >>> The RFCs can be found here:
>> >>> https://datatracker.ietf.org/doc/html/rfc7292 <https://datatracker.ietf.org/doc/html/rfc7292> 
>> >>> https://datatracker.ietf.org/doc/html/rfc2985#page-19 <https://datatracker.ietf.org/doc/html/rfc2985#page-19> 
>> >>> 
>> >>> The JKS key store(case in-sensitive alias)  has a special version (CaseExactJKS) that uses case sensitive aliases.
>> >>> So similarly, Will it be acceptable to have a case sensitive version of PKCS#12 as CaseExactPKCS12 which will use case sensitive aliases?
>> > 
>> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220720/0e876ab5/attachment-0001.htm>

From valeriep at openjdk.org  Wed Jul 20 22:05:02 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 20 Jul 2022 22:05:02 GMT
Subject: RFR: JDK-8290532: Adjust PKCS11Exception and handle more PKCS11
 error codes
In-Reply-To: <kccdSpgGrSgPAyqLQNOGBo7QqMF-hxiHfc_rO9X-sL8=.f56646dd-d135-4f1a-85fb-34bcfdcc648e@github.com>
References: <kccdSpgGrSgPAyqLQNOGBo7QqMF-hxiHfc_rO9X-sL8=.f56646dd-d135-4f1a-85fb-34bcfdcc648e@github.com>
Message-ID: <jZEQdMB7PvwMF7cJmlFEIkWvzdnzTOX7-H6VupiOrcY=.73b43a6a-fa08-41f2-9af6-91678d2623e4@github.com>

On Tue, 19 Jul 2022 13:14:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The issue https://bugs.openjdk.org/browse/JDK-8282538 gave an example of the following PKCS11 exception (see attached jtr files of that bug) :
> 
> .... Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: 0xCE534351
> 
> Unfortunately the error code 0xCE534351 is currently not in the RV/errorMap table of PKCS11Exception, That's why we get this
> hex code and no more descriptive output, this could be improved.

I don't think it's worthwhile to add deprecated error codes. As for vendor specific error codes, I think they belong in a separate collection based on which vendor/PKCS#11 library is used.

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

PR: https://git.openjdk.org/jdk/pull/9555

From dcubed at openjdk.org  Wed Jul 20 22:44:07 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 20 Jul 2022 22:44:07 GMT
Subject: RFR: Merge jdk19
Message-ID: <AEogMC6k_YZRhpfkn8Nu7DO26WE_lY5ATIWJEZLLC6s=.2c11afbd-30cf-43c2-af5f-3a923e209370@github.com>

Merge jdk19 -> jdk20.

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

Commit messages:
 - Merge
 - 8290625: Test jdk/javadoc/tool/CheckManPageOptions.java after manpage update
 - 8278274: Update nroff pages in JDK 19 before RC
 - 8287916: Address the inconsistency between the constant array and pool size
 - 8285407: Improve Xalan supports
 - 8282676: Improve subject handling
 - 8284370: Improve zlib usage
 - 8283190: Improve MIDI processing
 - 8281866: Enhance MethodHandle invocations
 - 8281859: Improve class compilation
 - ... and 3 more: https://git.openjdk.org/jdk/compare/b1817a30...aaca8b9d

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

Changes: https://git.openjdk.org/jdk/pull/9578/files
  Stats: 504 lines in 28 files changed: 428 ins; 16 del; 60 mod
  Patch: https://git.openjdk.org/jdk/pull/9578.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9578/head:pull/9578

PR: https://git.openjdk.org/jdk/pull/9578

From dcubed at openjdk.org  Wed Jul 20 22:59:25 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 20 Jul 2022 22:59:25 GMT
Subject: RFR: Merge jdk19
In-Reply-To: <AEogMC6k_YZRhpfkn8Nu7DO26WE_lY5ATIWJEZLLC6s=.2c11afbd-30cf-43c2-af5f-3a923e209370@github.com>
References: <AEogMC6k_YZRhpfkn8Nu7DO26WE_lY5ATIWJEZLLC6s=.2c11afbd-30cf-43c2-af5f-3a923e209370@github.com>
Message-ID: <ejPn-O0FlUDlzib8bV49EnPrKYeCQTWUAxRY9CayeqY=.76121730-cfaa-40f3-8be6-6c71897bbe0b@github.com>

On Wed, 20 Jul 2022 22:20:31 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Merge jdk19 -> jdk20.

Mach5 Tier1 passed.

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

PR: https://git.openjdk.org/jdk/pull/9578

From dcubed at openjdk.org  Wed Jul 20 22:59:26 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 20 Jul 2022 22:59:26 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <AEogMC6k_YZRhpfkn8Nu7DO26WE_lY5ATIWJEZLLC6s=.2c11afbd-30cf-43c2-af5f-3a923e209370@github.com>
References: <AEogMC6k_YZRhpfkn8Nu7DO26WE_lY5ATIWJEZLLC6s=.2c11afbd-30cf-43c2-af5f-3a923e209370@github.com>
Message-ID: <NlbvRtErZWaBJsWsUjWLzQw8ZBrSn6f81MI1KQ_VE_k=.28531e99-8501-4f25-b621-52c51ef0b37c@github.com>

On Wed, 20 Jul 2022 22:20:31 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Merge jdk19 -> jdk20.

This pull request has now been integrated.

Changeset: 9c19d89c
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9c19d89c9c564e436732c5f7851f4960fb5d783c
Stats:     504 lines in 28 files changed: 428 ins; 16 del; 60 mod

Merge

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

PR: https://git.openjdk.org/jdk/pull/9578

From dholmes at openjdk.org  Thu Jul 21 00:43:38 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Jul 2022 00:43:38 GMT
Subject: RFR: 8290489: Initial nroff manpage generation for JDK 20
Message-ID: <Oh3Bd-n_TP1kz1Ir2uR8dmgdQouSgZ24rzV1rhKVzLU=.ebb70241-1990-49a6-a47a-f56df55570de@github.com>

The version will be 20-ea and the copyright year 2023 (for March 2023 release date).

Thanks.

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

Commit messages:
 - 8290489: Initial nroff manpage generation for JDK 20

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

PR: https://git.openjdk.org/jdk/pull/9581

From dcubed at openjdk.org  Thu Jul 21 01:07:02 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 21 Jul 2022 01:07:02 GMT
Subject: RFR: 8290489: Initial nroff manpage generation for JDK 20
In-Reply-To: <Oh3Bd-n_TP1kz1Ir2uR8dmgdQouSgZ24rzV1rhKVzLU=.ebb70241-1990-49a6-a47a-f56df55570de@github.com>
References: <Oh3Bd-n_TP1kz1Ir2uR8dmgdQouSgZ24rzV1rhKVzLU=.ebb70241-1990-49a6-a47a-f56df55570de@github.com>
Message-ID: <2chBf83EGB9f7D67rYVKNXRnOOWKUa0hLm7XNhCa5QU=.9bca77c8-36e8-4763-af9b-3d8c1df238c1@github.com>

On Thu, 21 Jul 2022 00:34:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The version will be 20-ea and the copyright year 2023 (for March 2023 release date).
> 
> Thanks.

Thumbs up. This is a trivial change.

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9581

From jwaters at openjdk.org  Thu Jul 21 02:09:45 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 21 Jul 2022 02:09:45 GMT
Subject: RFR: 8289275: Remove incorrect __declspec(dllimport) attributes
 from pointers in jdk.crypto.cryptoki
In-Reply-To: <e42d0XH1Jnl0gDzLGnej1uoJhx_OmYluz-1Z6ZiazCc=.1b56434d-8e6b-447f-be90-80cedcda10a9@github.com>
References: <yM6fqtQfhPvlMnxnqJbc1H-A3SJ0f6n4ee2zgGCmD7M=.d388accc-1210-40e7-8ae6-11118cec5156@github.com>
 <RAmmcj30-EkE6RgXo7rTp4M8RyaNAt5wBOcBpvxiLn0=.76b2d61e-4dc6-4958-8a2d-3ada3cfc4c98@github.com>
 <ADt1KTKWq79HoCeJI2LREYjbLOspY2AO0zJfcV9EOK8=.eff00eff-cfe5-41e8-b225-1f96f5ce8d21@github.com>
 <e42d0XH1Jnl0gDzLGnej1uoJhx_OmYluz-1Z6ZiazCc=.1b56434d-8e6b-447f-be90-80cedcda10a9@github.com>
Message-ID: <-W7gOUCmcUOFhZP9HQRte7EhjmQLSM_PGGAcjJWIwG0=.3148e3d2-83a6-4437-8f2f-3985a28d59a1@github.com>

On Wed, 13 Jul 2022 16:40:48 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>>> pkcs11.h is a standard header file from OASIS. Best to leave it alone. Just my .02.
>> 
>> The only change to pkcs11.h is in a comment though, the other changes are outside the ANSI C headers from the standard. Should I just revert the comment in that case?
>
>> > pkcs11.h is a standard header file from OASIS. Best to leave it alone. Just my .02.
>> 
>> The only change to pkcs11.h is in a comment though, the other changes are outside the ANSI C headers from the standard. Should I just revert the comment in that case?
> 
> Sounds good to me.
> Will take a look at the rest of changes in a day or two.
> Thanks!

@valeriepeng Might need you to sponsor this, thanks for the review!

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

PR: https://git.openjdk.org/jdk/pull/9353

From dholmes at openjdk.org  Thu Jul 21 05:49:57 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Jul 2022 05:49:57 GMT
Subject: RFR: 8290489: Initial nroff manpage generation for JDK 20
In-Reply-To: <2chBf83EGB9f7D67rYVKNXRnOOWKUa0hLm7XNhCa5QU=.9bca77c8-36e8-4763-af9b-3d8c1df238c1@github.com>
References: <Oh3Bd-n_TP1kz1Ir2uR8dmgdQouSgZ24rzV1rhKVzLU=.ebb70241-1990-49a6-a47a-f56df55570de@github.com>
 <2chBf83EGB9f7D67rYVKNXRnOOWKUa0hLm7XNhCa5QU=.9bca77c8-36e8-4763-af9b-3d8c1df238c1@github.com>
Message-ID: <gZuNsiJo3fWnsEb8TsdEbuKySkKHTvKtpP6T_zaRfuI=.04048e7d-88cf-43ba-959d-67a5b14eb833@github.com>

On Thu, 21 Jul 2022 01:03:46 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> The version will be 20-ea and the copyright year 2023 (for March 2023 release date).
>> 
>> Thanks.
>
> Thumbs up. This is a trivial change.

Thanks @dcubed-ojdk !

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

PR: https://git.openjdk.org/jdk/pull/9581

From mbaesken at openjdk.org  Thu Jul 21 07:07:40 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 21 Jul 2022 07:07:40 GMT
Subject: RFR: JDK-8290532: Adjust PKCS11Exception and handle more PKCS11
 error codes
In-Reply-To: <jZEQdMB7PvwMF7cJmlFEIkWvzdnzTOX7-H6VupiOrcY=.73b43a6a-fa08-41f2-9af6-91678d2623e4@github.com>
References: <kccdSpgGrSgPAyqLQNOGBo7QqMF-hxiHfc_rO9X-sL8=.f56646dd-d135-4f1a-85fb-34bcfdcc648e@github.com>
 <jZEQdMB7PvwMF7cJmlFEIkWvzdnzTOX7-H6VupiOrcY=.73b43a6a-fa08-41f2-9af6-91678d2623e4@github.com>
Message-ID: <jpimSYECuy0kph07aUev4HVt3R9kLlPumwsJqxeatoo=.6ceca69e-9580-40f4-b52f-fdc16986d956@github.com>

On Wed, 20 Jul 2022 22:01:18 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> I don't think it's worthwhile to add deprecated error codes. As for vendor specific error codes, I think they belong in a separate collection based on which vendor/PKCS#11 library is used.

Okay makes sense then we leave the deprecated error code out. Do you have an idea how to easily get the vendor info of the lib ? A separate per vendor table sounds like a good idea.

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

PR: https://git.openjdk.org/jdk/pull/9555

From duke at openjdk.org  Thu Jul 21 15:50:35 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 21 Jul 2022 15:50:35 GMT
Subject: RFR: 8290824: Use InputStream.readAllBytes() instead of surrogate code
Message-ID: <U1UZQYOalHr0MinGKEmLn5-TiVXSq2GCVG97bnyv-U8=.abdafbf5-11c9-4c39-b9a3-4e74ffefcb33@github.com>

We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`.

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

Commit messages:
 - 8290824: Remove unused JavaDoc
 - 8290824: Use InputStream.readAllBytes() instead of surrogate code

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

PR: https://git.openjdk.org/jdk/pull/9596

From mr at openjdk.org  Thu Jul 21 17:32:58 2022
From: mr at openjdk.org (Mark Reinhold)
Date: Thu, 21 Jul 2022 17:32:58 GMT
Subject: RFR: 8290824: Use InputStream.readAllBytes() instead of surrogate
 code
In-Reply-To: <U1UZQYOalHr0MinGKEmLn5-TiVXSq2GCVG97bnyv-U8=.abdafbf5-11c9-4c39-b9a3-4e74ffefcb33@github.com>
References: <U1UZQYOalHr0MinGKEmLn5-TiVXSq2GCVG97bnyv-U8=.abdafbf5-11c9-4c39-b9a3-4e74ffefcb33@github.com>
Message-ID: <YVIf-QrVr7R-Q-oEOrmO4l-ccqyIufjS-_2zX8HW6Mk=.5b4a9ea8-36c2-48e2-b2c0-e557092f9561@github.com>

On Thu, 21 Jul 2022 15:37:40 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`.

Why do you say ?instead of surrogate code?? I don?t see any Unicode surrogate processing here, but maybe you mean something else. Would ?instead of explicit loops? be a better summary?

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

PR: https://git.openjdk.org/jdk/pull/9596

From weijun at openjdk.org  Thu Jul 21 18:32:10 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 21 Jul 2022 18:32:10 GMT
Subject: RFR: 8290824: Use InputStream.readAllBytes() instead of surrogate
 code
In-Reply-To: <U1UZQYOalHr0MinGKEmLn5-TiVXSq2GCVG97bnyv-U8=.abdafbf5-11c9-4c39-b9a3-4e74ffefcb33@github.com>
References: <U1UZQYOalHr0MinGKEmLn5-TiVXSq2GCVG97bnyv-U8=.abdafbf5-11c9-4c39-b9a3-4e74ffefcb33@github.com>
Message-ID: <m1PGNhOrF_zSGoO_ULPA0SBwFgXUa8ZqBWErs2ltTx0=.64a08d68-3f55-4e77-b05a-ab7e497a16d0@github.com>

On Thu, 21 Jul 2022 15:37:40 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`.

The `X509CertPath.java` change looks fine, but I'm not sure about the other one. It means the whole content from the input stream is read into a single array and this could lead to a sudden peak memory usage if the size is big.

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

PR: https://git.openjdk.org/jdk/pull/9596

From jwaters at openjdk.org  Thu Jul 21 19:16:03 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 21 Jul 2022 19:16:03 GMT
Subject: Integrated: 8289275: Remove incorrect __declspec(dllimport) attributes
 from pointers in jdk.crypto.cryptoki
In-Reply-To: <yM6fqtQfhPvlMnxnqJbc1H-A3SJ0f6n4ee2zgGCmD7M=.d388accc-1210-40e7-8ae6-11118cec5156@github.com>
References: <yM6fqtQfhPvlMnxnqJbc1H-A3SJ0f6n4ee2zgGCmD7M=.d388accc-1210-40e7-8ae6-11118cec5156@github.com>
Message-ID: <HmASedOCoWtLrjgjOzGiASgWIQfA1J_GBrk6v5a8cdg=.3d5d43f4-de21-4bac-9d64-a592c4356498@github.com>

On Sat, 2 Jul 2022 02:12:15 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Several instances of function pointers in jdk.crypto.cryptoki are marked with the dllimport attribute, which should only be applied to symbol declarations, of which a typedef'd function pointer is not. This would only be useful if a function pointer defined in the linked dll is desired to be imported, not if the pointer itself is created locally and used to store a function address. In addition to being incorrect, at least on the versions of Visual C++ the JDK supports today, it is also redundant; Typically they are used to avoid an indirect stub that jumps to the proper entry in the import address table, but usage of these typedefs involves loading the address of a function and directly (Usually through GetProcAddress, even in other cases it would simply be set to the address of a function anyway) assigning it to the pointer before immediately dispatching when called, which bypasses this procedure entirely and makes the attribute pointless.

This pull request has now been integrated.

Changeset: 0dda3c14
Author:    Julian Waters <jwaters at openjdk.org>
Committer: Valerie Peng <valeriep at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0dda3c14ebe040158dcc5a87d349d5286c48b573
Stats:     6 lines in 2 files changed: 0 ins; 0 del; 6 mod

8289275: Remove incorrect __declspec(dllimport) attributes from pointers in jdk.crypto.cryptoki

Reviewed-by: valeriep

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

PR: https://git.openjdk.org/jdk/pull/9353

From duke at openjdk.org  Thu Jul 21 19:49:08 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 21 Jul 2022 19:49:08 GMT
Subject: RFR: 8290824: Use InputStream.readAllBytes() instead of surrogate
 code
In-Reply-To: <U1UZQYOalHr0MinGKEmLn5-TiVXSq2GCVG97bnyv-U8=.abdafbf5-11c9-4c39-b9a3-4e74ffefcb33@github.com>
References: <U1UZQYOalHr0MinGKEmLn5-TiVXSq2GCVG97bnyv-U8=.abdafbf5-11c9-4c39-b9a3-4e74ffefcb33@github.com>
Message-ID: <Hx1G88Ke0v4xZE2wGJ5jfA5UNuRoeMwR0qh-XuW0wpI=.e8544d9a-5218-41f5-bf84-dfe0b8311d33@github.com>

On Thu, 21 Jul 2022 15:37:40 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`.

By "surrogate code" I mean hand-written snippets reading all the bytes from an InputStream.

> It means the whole content from the input stream is read into a single array and this could lead to a sudden peak memory usage if the size is big.

`InputStream.readAllBytes()` reads data from the InputStream in chunks of 8192 bytes, then combines them into one resulting array which is returned. In theory this could lead even to OOME in case the size the resulting array exceeds `Integer.MAX_VALUE`, I doubt however this would ever happen.

I've looked into the history of `ModulerHashes`: prior to `byte[]` it used `ByteBuffer` of the same size (32 kB) as intermediate storage. I think digesting all the data at once might be faster than doing it chunk by chunk, on the other hand I understand memory concern.

Can I reliably measure it somehow?

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

PR: https://git.openjdk.org/jdk/pull/9596

From mr at openjdk.org  Thu Jul 21 21:18:04 2022
From: mr at openjdk.org (Mark Reinhold)
Date: Thu, 21 Jul 2022 21:18:04 GMT
Subject: RFR: 8290824: Use InputStream.readAllBytes() instead of surrogate
 code
In-Reply-To: <U1UZQYOalHr0MinGKEmLn5-TiVXSq2GCVG97bnyv-U8=.abdafbf5-11c9-4c39-b9a3-4e74ffefcb33@github.com>
References: <U1UZQYOalHr0MinGKEmLn5-TiVXSq2GCVG97bnyv-U8=.abdafbf5-11c9-4c39-b9a3-4e74ffefcb33@github.com>
Message-ID: <LCSx9KZhGjWxCoz13xu1PGmB0eixUgPfMS0YKV1vBCY=.5f39b3f4-69a7-4ecf-9770-9a22f1feb587@github.com>

On Thu, 21 Jul 2022 15:37:40 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`.

If by ?surrogates? you mean ?substitutes?, then this wording is confusing. At the time these explicit loops were written they weren?t surrogates for anything, since `InputStream::readAllBytes` didn?t yet exist. Please revise the summary to say ?... instead of explicit loops?.

I share @wangweij?s concern about the change to the `ModuleHashes` class. The original code does not read the entirety of each stream into a single byte array because it doesn?t need to in order to update the digest. Furthermore, it re-uses the same byte array for all of the (potentially many) input streams. Your change would allocate a new byte array for each input stream, which seems likely to be slower. Please measure this (using, e.g., [JMH]) before making such a change.

[JMH]: https://github.com/openjdk/jmh

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

PR: https://git.openjdk.org/jdk/pull/9596

From duke at openjdk.org  Thu Jul 21 21:18:29 2022
From: duke at openjdk.org (jquanC)
Date: Thu, 21 Jul 2022 21:18:29 GMT
Subject: RFR: 8290775: Some doc errors in DerOutputStream.java
Message-ID: <d0JtKYOw3Oq5E1_APQ1BltggmdIEqdM5IAv3sYgwqrk=.c06a1c15-911d-40b0-b3fc-f2b1a975dfda@github.com>

There are some doc errors in sun.security.util.DerOutputStream, like the followings,


/**
 * Private helper routine for writing DER encoded string values.
 * @param s the string to write
 * @param stringTag one of the DER string tags that indicate which
 * encoding should be used to write the string out.
 * @param enc the name of the encoder that should be used corresponding
 * to the above tag.
 */
private void writeString(String s, byte stringTag, Charset charset) throws IOException

The parameter is charset, but not enc.


/**
 * Marshals a DER integer on the output stream.
 *
 * @param i the integer in bytes, equivalent to BigInteger::toByteArray.
 */
public void putInteger(byte[] buf) throws IOException {

The parameter is buf, but not i.

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

Commit messages:
 - 8290775: Some doc errors in DerOutputStream.java

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

PR: https://git.openjdk.org/jdk/pull/9585

From xuelei at openjdk.org  Thu Jul 21 21:56:04 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Thu, 21 Jul 2022 21:56:04 GMT
Subject: RFR: 8290775: Some doc errors in DerOutputStream.java
In-Reply-To: <d0JtKYOw3Oq5E1_APQ1BltggmdIEqdM5IAv3sYgwqrk=.c06a1c15-911d-40b0-b3fc-f2b1a975dfda@github.com>
References: <d0JtKYOw3Oq5E1_APQ1BltggmdIEqdM5IAv3sYgwqrk=.c06a1c15-911d-40b0-b3fc-f2b1a975dfda@github.com>
Message-ID: <yJSokluN4Z1l8TNzLa-xVlTh-cuNfJhGycOLQTO9LYM=.9875a66b-8a24-45c0-b3aa-b7daec5d3031@github.com>

On Thu, 21 Jul 2022 08:53:31 GMT, jquanC <duke at openjdk.org> wrote:

> There are some doc errors in sun.security.util.DerOutputStream, like the followings,
> 
> 
> /**
>  * Private helper routine for writing DER encoded string values.
>  * @param s the string to write
>  * @param stringTag one of the DER string tags that indicate which
>  * encoding should be used to write the string out.
>  * @param enc the name of the encoder that should be used corresponding
>  * to the above tag.
>  */
> private void writeString(String s, byte stringTag, Charset charset) throws IOException
> 
> The parameter is charset, but not enc.
> 
> 
> /**
>  * Marshals a DER integer on the output stream.
>  *
>  * @param i the integer in bytes, equivalent to BigInteger::toByteArray.
>  */
> public void putInteger(byte[] buf) throws IOException {
> 
> The parameter is buf, but not i.

Thanks for the update.  However, I have concerns about the update os parameter descriptions.

src/java.base/share/classes/sun/security/util/DerOutputStream.java line 178:

> 176:      * Marshals a DER integer on the output stream.
> 177:      *
> 178:      * @param buf buffered data, which must be DER-encoded

The information of the parameter, "the integer in bytes, equivalent to BigInteger::toByteArray", may be not necessary to be updated, which is right I think.

src/java.base/share/classes/sun/security/util/DerOutputStream.java line 464:

> 462:      * @param stringTag one of the DER string tags that indicate which
> 463:      * encoding should be used to write the string out.
> 464:      * @param charset the specified character set encodes a string into a

I think it may be not necessary to update the parameter description.

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

Changes requested by xuelei (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9585

From valeriep at openjdk.org  Thu Jul 21 22:14:02 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 21 Jul 2022 22:14:02 GMT
Subject: RFR: JDK-8290532: Adjust PKCS11Exception and handle more PKCS11
 error codes
In-Reply-To: <kccdSpgGrSgPAyqLQNOGBo7QqMF-hxiHfc_rO9X-sL8=.f56646dd-d135-4f1a-85fb-34bcfdcc648e@github.com>
References: <kccdSpgGrSgPAyqLQNOGBo7QqMF-hxiHfc_rO9X-sL8=.f56646dd-d135-4f1a-85fb-34bcfdcc648e@github.com>
Message-ID: <CrEyP9ar5EHSuaBztPkrrtHsQ1T-dRhpSvVbz24QXIk=.dadd4aed-c03d-4422-b00b-e8ad2a08c7e1@github.com>

On Tue, 19 Jul 2022 13:14:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The issue https://bugs.openjdk.org/browse/JDK-8282538 gave an example of the following PKCS11 exception (see attached jtr files of that bug) :
> 
> .... Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: 0xCE534351
> 
> Unfortunately the error code 0xCE534351 is currently not in the RV/errorMap table of PKCS11Exception, That's why we get this
> hex code and no more descriptive output, this could be improved.

PKCS11Exception objects are constructed by PKCS#11 JNI code and vendor info is not readily available there. One easy compromise is to keep the hex error code value but append the string form when there is a match., i.e. 

+    public static enum RV_VENDOR {
+        // NSS
+        CKR_NSS_CERTDB_FAILED(0xCE534351L),
+        CKR_NSS_KEYDB_FAILED(0xCE534352L);
+
+        private final long value;
+
+        RV_VENDOR(long value) {
+            this.value = value;
+        }
+    };
+
     private static String lookup(long errorCode) {
         for (RV r : RV.values()) {
             if (r.value == errorCode) {
                 return r.name();
             }
         }

-        // for unknown PKCS11 return values, just use hex as its string
-        return "0x" + Functions.toFullHexString((int)errorCode);
+        // for unknown PKCS11 return values, use hex as its string
+        String res = "0x" + Functions.toFullHexString((int)errorCode);
+        // for vendor-defined values, check the enum for vendors and include
+        // potential matches
+        if ((errorCode & 0x80000000L) != 0) {
+            // for unknown PKCS11 return values, just use hex as its string
+            for (RV_VENDOR r : RV_VENDOR.values()) {
+                if (r.value == errorCode) {
+                    res += ("(" + r.name() + ")");
+                    break;
+                }
+            }
+        }
+        return res;


This way, even if the vendor is not NSS, but the original return value is still available for callers. 
Just my .02.

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

PR: https://git.openjdk.org/jdk/pull/9555

From duke at openjdk.org  Fri Jul 22 01:47:03 2022
From: duke at openjdk.org (jquanC)
Date: Fri, 22 Jul 2022 01:47:03 GMT
Subject: RFR: 8290775: Some doc errors in DerOutputStream.java
In-Reply-To: <d0JtKYOw3Oq5E1_APQ1BltggmdIEqdM5IAv3sYgwqrk=.c06a1c15-911d-40b0-b3fc-f2b1a975dfda@github.com>
References: <d0JtKYOw3Oq5E1_APQ1BltggmdIEqdM5IAv3sYgwqrk=.c06a1c15-911d-40b0-b3fc-f2b1a975dfda@github.com>
Message-ID: <mcRTWijh9SCAq4W5EgaS-PWMNL3L14sY_jE-AkSMLRU=.2c364d34-273c-45e3-a371-8356dc0f9e7b@github.com>

On Thu, 21 Jul 2022 08:53:31 GMT, jquanC <duke at openjdk.org> wrote:

> There are some doc errors in sun.security.util.DerOutputStream, like the followings,
> 
> 
> /**
>  * Private helper routine for writing DER encoded string values.
>  * @param s the string to write
>  * @param stringTag one of the DER string tags that indicate which
>  * encoding should be used to write the string out.
>  * @param enc the name of the encoder that should be used corresponding
>  * to the above tag.
>  */
> private void writeString(String s, byte stringTag, Charset charset) throws IOException
> 
> The parameter is charset, but not enc.
> 
> 
> /**
>  * Marshals a DER integer on the output stream.
>  *
>  * @param i the integer in bytes, equivalent to BigInteger::toByteArray.
>  */
> public void putInteger(byte[] buf) throws IOException {
> 
> The parameter is buf, but not i.

Thanks for your careful check!


On the first point, I am not careful enough. As you said, there is no need to modify it cause it is quite clear at the end of the sentence.
On the second point, I have some doubts. 1) Here don't need to add ***@***.*** charset" because it's clear to everyone? ***@***.*** enc" does not seem to be used in the method. Shouldn't it be deleted?



Looking forward to your guidance.&nbsp;Thanks again!




------------------&nbsp;????&nbsp;------------------
???:                                                                                                                        "openjdk/jdk"                                                                                    ***@***.***&gt;;
????:&nbsp;2022?7?22?(???) ??5:53
***@***.***&gt;;
***@***.******@***.***&gt;;
??:&nbsp;Re: [openjdk/jdk] 8290775: Some doc errors in DerOutputStream.java (PR #9585)





 
@XueleiFan requested changes on this pull request.
 
Thanks for the update.  However, I have concerns about the update os parameter descriptions.

 
In src/java.base/share/classes/sun/security/util/DerOutputStream.java:
 &gt; @@ -175,7 +175,7 @@ public void putInteger(BigInteger i) throws IOException {      /**       * Marshals a DER integer on the output stream.       * -     * @param i the integer in bytes, equivalent to BigInteger::toByteArray. +     * @param buf buffered data, which must be DER-encoded  
The information of the parameter, "the integer in bytes, equivalent to BigInteger::toByteArray", may be not necessary to be updated, which is right I think.
 
 
In src/java.base/share/classes/sun/security/util/DerOutputStream.java:
 &gt; @@ -461,8 +461,8 @@ public void putGeneralString(String s) throws IOException {       * @param s the string to write       * @param stringTag one of the DER string tags that indicate which       * encoding should be used to write the string out. -     * @param enc the name of the encoder that should be used corresponding -     * to the above tag. +     * @param charset the specified character set encodes a string into a  
I think it may be not necessary to update the parameter description.
 
?
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: ***@***.***&gt;

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

PR: https://git.openjdk.org/jdk/pull/9585

From dholmes at openjdk.org  Fri Jul 22 04:45:03 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 22 Jul 2022 04:45:03 GMT
Subject: Integrated: 8290489: Initial nroff manpage generation for JDK 20
In-Reply-To: <Oh3Bd-n_TP1kz1Ir2uR8dmgdQouSgZ24rzV1rhKVzLU=.ebb70241-1990-49a6-a47a-f56df55570de@github.com>
References: <Oh3Bd-n_TP1kz1Ir2uR8dmgdQouSgZ24rzV1rhKVzLU=.ebb70241-1990-49a6-a47a-f56df55570de@github.com>
Message-ID: <2vnXOAQlpH9CGjFVkGkL4pWyCPxneNmWrxV8V6j5b_w=.c951b25d-e0cd-4902-ad79-200ca4238f91@github.com>

On Thu, 21 Jul 2022 00:34:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The version will be 20-ea and the copyright year 2023 (for March 2023 release date).
> 
> Thanks.

This pull request has now been integrated.

Changeset: e9f97b2e
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e9f97b2e8cf301ba6b69101e5efc5c71d26bc87b
Stats:     28 lines in 28 files changed: 0 ins; 0 del; 28 mod

8290489: Initial nroff manpage generation for JDK 20

Reviewed-by: dcubed

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

PR: https://git.openjdk.org/jdk/pull/9581

From xuelei at openjdk.org  Fri Jul 22 05:29:46 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 22 Jul 2022 05:29:46 GMT
Subject: RFR: 8290775: Some doc errors in DerOutputStream.java
In-Reply-To: <mcRTWijh9SCAq4W5EgaS-PWMNL3L14sY_jE-AkSMLRU=.2c364d34-273c-45e3-a371-8356dc0f9e7b@github.com>
References: <d0JtKYOw3Oq5E1_APQ1BltggmdIEqdM5IAv3sYgwqrk=.c06a1c15-911d-40b0-b3fc-f2b1a975dfda@github.com>
 <mcRTWijh9SCAq4W5EgaS-PWMNL3L14sY_jE-AkSMLRU=.2c364d34-273c-45e3-a371-8356dc0f9e7b@github.com>
Message-ID: <A1Be_IM4t-x_pT9Pc4x1KpBTHcBYW2EoMTq3ej3Zg2A=.d4001400-7fc0-484d-be48-e1cf3ebea23e@github.com>

On Fri, 22 Jul 2022 01:43:06 GMT, jquanC <duke at openjdk.org> wrote:

> On the second point, I have some doubts. 1) Here don't need to add ***@***.*** charset" because it's clear to everyone? ***@***.*** enc" does not seem to be used in the method. Shouldn't it be deleted?

Sorry for the confusing.

I think it is fine to update the "param enc" to "param charset", but it may be not necessary to update the parameter description.  With "parameter description", I refer to this part, "the name of the encoder that should be used corresponding to the above tag". 

The parameter description may be still confusing to someone, as the 'the name of the encoder' is not well-defined here.  Maybe, it could be simplified as "the charset that ..."


Here is the proposed update:

-     * @param enc the name of the encoder that should be used corresponding
-    * to the above tag.
+    * @param charset the specified character set encodes a string into a
+    * sequence of bytes using


I may use an update like :

-     * @param enc the name of the encoder that should be used corresponding
-    * to the above tag.
+    * @param charset the charset that is should used corresponding to the
+    * above tag.

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

PR: https://git.openjdk.org/jdk/pull/9585

From jpai at openjdk.org  Fri Jul 22 06:11:05 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 22 Jul 2022 06:11:05 GMT
Subject: RFR: 8289572: InputStream wrapping with BufferedInputStream is
 redundant in HttpTimestamper
In-Reply-To: <P9jIj_8YZm3wshGxV9ox_-38G9UfMWbKLy0z9u7Gfug=.adc2f80c-086c-4b9e-a70b-129b7ba746ff@github.com>
References: <P9jIj_8YZm3wshGxV9ox_-38G9UfMWbKLy0z9u7Gfug=.adc2f80c-086c-4b9e-a70b-129b7ba746ff@github.com>
Message-ID: <o3gVp7muYOUyfEONRIVpJn75AMWbmUBlKc885nt_aL4=.2f90cf38-75e1-4c2b-ae29-492a36bb31ae@github.com>

On Fri, 1 Jul 2022 08:06:10 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> In case we read all bytes from an `InputStream` we don't need wrapping with `BufferedInputStream` as the bytes are not written into internal buffer. With removal of redundant buffer we save 8 kB of allocated memory.

I see that Sean has approved this PR. I'll run some tests internally with this change and if it goes fine, then I'll go ahead and sponsor this today.

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

PR: https://git.openjdk.org/jdk/pull/9343

From duke at openjdk.org  Fri Jul 22 07:09:59 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 22 Jul 2022 07:09:59 GMT
Subject: RFR: 8290824: Use InputStream.readAllBytes() instead of explicit
 loops
In-Reply-To: <LCSx9KZhGjWxCoz13xu1PGmB0eixUgPfMS0YKV1vBCY=.5f39b3f4-69a7-4ecf-9770-9a22f1feb587@github.com>
References: <U1UZQYOalHr0MinGKEmLn5-TiVXSq2GCVG97bnyv-U8=.abdafbf5-11c9-4c39-b9a3-4e74ffefcb33@github.com>
 <LCSx9KZhGjWxCoz13xu1PGmB0eixUgPfMS0YKV1vBCY=.5f39b3f4-69a7-4ecf-9770-9a22f1feb587@github.com>
Message-ID: <huumxfM0MAX_escnh3Pvk0ZPF2P-L7JVXr-fRNkTgGA=.4538d446-5768-4ca0-86fb-c72905d3c73c@github.com>

On Thu, 21 Jul 2022 21:14:44 GMT, Mark Reinhold <mr at openjdk.org> wrote:

> Please revise the summary to say ?... instead of explicit loops?.

Done.

> Please measure this (using, e.g., [JMH](https://github.com/openjdk/jmh)) before making such a change.

I'm aware of JMH, I was asking mostly about public API I should call in a benchmark to execute the changed code.

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

PR: https://git.openjdk.org/jdk/pull/9596

From duke at openjdk.org  Fri Jul 22 08:27:38 2022
From: duke at openjdk.org (jquanC)
Date: Fri, 22 Jul 2022 08:27:38 GMT
Subject: RFR: 8290775: Some doc errors in DerOutputStream.java [v2]
In-Reply-To: <d0JtKYOw3Oq5E1_APQ1BltggmdIEqdM5IAv3sYgwqrk=.c06a1c15-911d-40b0-b3fc-f2b1a975dfda@github.com>
References: <d0JtKYOw3Oq5E1_APQ1BltggmdIEqdM5IAv3sYgwqrk=.c06a1c15-911d-40b0-b3fc-f2b1a975dfda@github.com>
Message-ID: <NxAHf7RpmNLwfYJ-tv_cPZeFNAqQKFbThI1EVSWsg08=.96661d57-c6f0-455e-8bd5-e044f6434935@github.com>

> There are some doc errors in sun.security.util.DerOutputStream, like the followings,
> 
> 
> /**
>  * Private helper routine for writing DER encoded string values.
>  * @param s the string to write
>  * @param stringTag one of the DER string tags that indicate which
>  * encoding should be used to write the string out.
>  * @param enc the name of the encoder that should be used corresponding
>  * to the above tag.
>  */
> private void writeString(String s, byte stringTag, Charset charset) throws IOException
> 
> The parameter is charset, but not enc.
> 
> 
> /**
>  * Marshals a DER integer on the output stream.
>  *
>  * @param i the integer in bytes, equivalent to BigInteger::toByteArray.
>  */
> public void putInteger(byte[] buf) throws IOException {
> 
> The parameter is buf, but not i.

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

  8290775: Some doc errors in DerOutputStream.java    Update: better improvement

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9585/files
  - new: https://git.openjdk.org/jdk/pull/9585/files/c6f17c8f..c2a0a8b1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9585&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9585&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/9585

From duke at openjdk.org  Fri Jul 22 09:04:37 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 22 Jul 2022 09:04:37 GMT
Subject: RFR: 8290824: Use InputStream.readAllBytes() instead of explicit
 loops
In-Reply-To: <U1UZQYOalHr0MinGKEmLn5-TiVXSq2GCVG97bnyv-U8=.abdafbf5-11c9-4c39-b9a3-4e74ffefcb33@github.com>
References: <U1UZQYOalHr0MinGKEmLn5-TiVXSq2GCVG97bnyv-U8=.abdafbf5-11c9-4c39-b9a3-4e74ffefcb33@github.com>
Message-ID: <75Z4l_p686QUxHIeWcYbnLf6jpumFGmdpEgFy_REWPg=.7a41bc88-44b3-4f50-94fa-98d2565d3d6a@github.com>

On Thu, 21 Jul 2022 15:37:40 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`.

Could one advise how to execute smth like `jmod hash --module-path ~/openjdk-18.0.2/Contents/Home/jmods --hash-modules .*`? This command doesn't work for me.

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

PR: https://git.openjdk.org/jdk/pull/9596

From mbaesken at openjdk.org  Fri Jul 22 10:22:39 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 22 Jul 2022 10:22:39 GMT
Subject: RFR: JDK-8290532: Adjust PKCS11Exception and handle more PKCS11
 error codes [v2]
In-Reply-To: <kccdSpgGrSgPAyqLQNOGBo7QqMF-hxiHfc_rO9X-sL8=.f56646dd-d135-4f1a-85fb-34bcfdcc648e@github.com>
References: <kccdSpgGrSgPAyqLQNOGBo7QqMF-hxiHfc_rO9X-sL8=.f56646dd-d135-4f1a-85fb-34bcfdcc648e@github.com>
Message-ID: <rGcN9Uh7tBrYgWvbUVtwRVt8XY1_IDMc65ud_AOHmc4=.401c70e1-363f-4241-8802-df5c0e6f4388@github.com>

> The issue https://bugs.openjdk.org/browse/JDK-8282538 gave an example of the following PKCS11 exception (see attached jtr files of that bug) :
> 
> .... Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: 0xCE534351
> 
> Unfortunately the error code 0xCE534351 is currently not in the RV/errorMap table of PKCS11Exception, That's why we get this
> hex code and no more descriptive output, this could be improved.

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

  do not add the deprecated CKR_COPY_PROHIBITED, handle vendor pkcs11 error codes differently

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9555/files
  - new: https://git.openjdk.org/jdk/pull/9555/files/a25101d5..f0fc6d73

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9555&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9555&range=00-01

  Stats: 30 lines in 1 file changed: 24 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/9555.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9555/head:pull/9555

PR: https://git.openjdk.org/jdk/pull/9555

From mbaesken at openjdk.org  Fri Jul 22 10:26:04 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 22 Jul 2022 10:26:04 GMT
Subject: RFR: JDK-8290532: Adjust PKCS11Exception and handle more PKCS11
 error codes [v2]
In-Reply-To: <rGcN9Uh7tBrYgWvbUVtwRVt8XY1_IDMc65ud_AOHmc4=.401c70e1-363f-4241-8802-df5c0e6f4388@github.com>
References: <kccdSpgGrSgPAyqLQNOGBo7QqMF-hxiHfc_rO9X-sL8=.f56646dd-d135-4f1a-85fb-34bcfdcc648e@github.com>
 <rGcN9Uh7tBrYgWvbUVtwRVt8XY1_IDMc65ud_AOHmc4=.401c70e1-363f-4241-8802-df5c0e6f4388@github.com>
Message-ID: <IwwBw8vjPEpPBRL4njVQ4pPMvxXtslZfoVT17wxKMB4=.edf0b389-21d9-40b3-bb92-0b9645bcb469@github.com>

On Fri, 22 Jul 2022 10:22:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The issue https://bugs.openjdk.org/browse/JDK-8282538 gave an example of the following PKCS11 exception (see attached jtr files of that bug) :
>> 
>> .... Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: 0xCE534351
>> 
>> Unfortunately the error code 0xCE534351 is currently not in the RV/errorMap table of PKCS11Exception, That's why we get this
>> hex code and no more descriptive output, this could be improved.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do not add the deprecated CKR_COPY_PROHIBITED, handle vendor pkcs11 error codes differently

Hi Valerie that sounds like a good idea, I adjusted the PR .

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

PR: https://git.openjdk.org/jdk/pull/9555

From jpai at openjdk.org  Fri Jul 22 11:51:09 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 22 Jul 2022 11:51:09 GMT
Subject: RFR: 8289572: InputStream wrapping with BufferedInputStream is
 redundant in HttpTimestamper
In-Reply-To: <P9jIj_8YZm3wshGxV9ox_-38G9UfMWbKLy0z9u7Gfug=.adc2f80c-086c-4b9e-a70b-129b7ba746ff@github.com>
References: <P9jIj_8YZm3wshGxV9ox_-38G9UfMWbKLy0z9u7Gfug=.adc2f80c-086c-4b9e-a70b-129b7ba746ff@github.com>
Message-ID: <9gozaVvnjxUFmWmRBeuk8LCro2oVXsNbuxzdy8giFBw=.a778c61d-9cc8-438f-8374-c83c53a5fc58@github.com>

On Fri, 1 Jul 2022 08:06:10 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> In case we read all bytes from an `InputStream` we don't need wrapping with `BufferedInputStream` as the bytes are not written into internal buffer. With removal of redundant buffer we save 8 kB of allocated memory.

The tests completed without any related issues.

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

PR: https://git.openjdk.org/jdk/pull/9343

From duke at openjdk.org  Fri Jul 22 11:53:42 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 22 Jul 2022 11:53:42 GMT
Subject: Integrated: 8289572: InputStream wrapping with BufferedInputStream is
 redundant in HttpTimestamper
In-Reply-To: <P9jIj_8YZm3wshGxV9ox_-38G9UfMWbKLy0z9u7Gfug=.adc2f80c-086c-4b9e-a70b-129b7ba746ff@github.com>
References: <P9jIj_8YZm3wshGxV9ox_-38G9UfMWbKLy0z9u7Gfug=.adc2f80c-086c-4b9e-a70b-129b7ba746ff@github.com>
Message-ID: <hZZp54QdDuAWQ99dKPbDAig6zykYoO8UX3B5rORFf1Q=.5f04c09a-10e9-4846-86d1-e1545cc8e479@github.com>

On Fri, 1 Jul 2022 08:06:10 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> In case we read all bytes from an `InputStream` we don't need wrapping with `BufferedInputStream` as the bytes are not written into internal buffer. With removal of redundant buffer we save 8 kB of allocated memory.

This pull request has now been integrated.

Changeset: 75c1e999
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/75c1e99968da1ee2f33a8c3a70070832fb403104
Stats:     6 lines in 1 file changed: 2 ins; 1 del; 3 mod

8289572: InputStream wrapping with BufferedInputStream is redundant in HttpTimestamper

Reviewed-by: jpai, mullan

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

PR: https://git.openjdk.org/jdk/pull/9343

From weijun at openjdk.org  Fri Jul 22 12:47:05 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 22 Jul 2022 12:47:05 GMT
Subject: RFR: 8290775: Some doc errors in DerOutputStream.java [v2]
In-Reply-To: <NxAHf7RpmNLwfYJ-tv_cPZeFNAqQKFbThI1EVSWsg08=.96661d57-c6f0-455e-8bd5-e044f6434935@github.com>
References: <d0JtKYOw3Oq5E1_APQ1BltggmdIEqdM5IAv3sYgwqrk=.c06a1c15-911d-40b0-b3fc-f2b1a975dfda@github.com>
 <NxAHf7RpmNLwfYJ-tv_cPZeFNAqQKFbThI1EVSWsg08=.96661d57-c6f0-455e-8bd5-e044f6434935@github.com>
Message-ID: <1bQq7UGi_bg8J0VYe1R7_Q7fZHTItCW93huZh4YAKTY=.3b4a218c-2792-4b49-b430-7287ae071dd2@github.com>

On Fri, 22 Jul 2022 08:27:38 GMT, jquanC <duke at openjdk.org> wrote:

>> There are some doc errors in sun.security.util.DerOutputStream, like the followings,
>> 
>> 
>> /**
>>  * Private helper routine for writing DER encoded string values.
>>  * @param s the string to write
>>  * @param stringTag one of the DER string tags that indicate which
>>  * encoding should be used to write the string out.
>>  * @param enc the name of the encoder that should be used corresponding
>>  * to the above tag.
>>  */
>> private void writeString(String s, byte stringTag, Charset charset) throws IOException
>> 
>> The parameter is charset, but not enc.
>> 
>> 
>> /**
>>  * Marshals a DER integer on the output stream.
>>  *
>>  * @param i the integer in bytes, equivalent to BigInteger::toByteArray.
>>  */
>> public void putInteger(byte[] buf) throws IOException {
>> 
>> The parameter is buf, but not i.
>
> jquanC has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290775: Some doc errors in DerOutputStream.java    Update: better improvement

`s/is should used/should be used/`.

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

PR: https://git.openjdk.org/jdk/pull/9585

From duke at openjdk.org  Fri Jul 22 13:16:41 2022
From: duke at openjdk.org (jquanC)
Date: Fri, 22 Jul 2022 13:16:41 GMT
Subject: RFR: 8290775: Some doc errors in DerOutputStream.java [v2]
In-Reply-To: <1bQq7UGi_bg8J0VYe1R7_Q7fZHTItCW93huZh4YAKTY=.3b4a218c-2792-4b49-b430-7287ae071dd2@github.com>
References: <d0JtKYOw3Oq5E1_APQ1BltggmdIEqdM5IAv3sYgwqrk=.c06a1c15-911d-40b0-b3fc-f2b1a975dfda@github.com>
 <NxAHf7RpmNLwfYJ-tv_cPZeFNAqQKFbThI1EVSWsg08=.96661d57-c6f0-455e-8bd5-e044f6434935@github.com>
 <1bQq7UGi_bg8J0VYe1R7_Q7fZHTItCW93huZh4YAKTY=.3b4a218c-2792-4b49-b430-7287ae071dd2@github.com>
Message-ID: <fdgqdp8JUg8n8hNZLL3_yOSpDQM3Ps0XiOz_jR4ZuIg=.3fe1e179-0847-41e6-b532-2b65766c4e82@github.com>

On Fri, 22 Jul 2022 12:44:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> `s/is should used/should be used/`.

Thanks for your advice!
Yes, the passive voice should be used.
I may offer an update like:

@param charset the charset should be used corresponding to the above tag.

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

PR: https://git.openjdk.org/jdk/pull/9585

From duke at openjdk.org  Fri Jul 22 14:56:34 2022
From: duke at openjdk.org (jquanC)
Date: Fri, 22 Jul 2022 14:56:34 GMT
Subject: RFR: 8290775: Some doc errors in DerOutputStream.java [v3]
In-Reply-To: <d0JtKYOw3Oq5E1_APQ1BltggmdIEqdM5IAv3sYgwqrk=.c06a1c15-911d-40b0-b3fc-f2b1a975dfda@github.com>
References: <d0JtKYOw3Oq5E1_APQ1BltggmdIEqdM5IAv3sYgwqrk=.c06a1c15-911d-40b0-b3fc-f2b1a975dfda@github.com>
Message-ID: <CmXPQuOY_G8El7CxPzYw-I5xxWl8C6XiODDBTxEoeSA=.18715492-e9d1-4063-89d7-a793955720dd@github.com>

> There are some doc errors in sun.security.util.DerOutputStream, like the followings,
> 
> 
> /**
>  * Private helper routine for writing DER encoded string values.
>  * @param s the string to write
>  * @param stringTag one of the DER string tags that indicate which
>  * encoding should be used to write the string out.
>  * @param enc the name of the encoder that should be used corresponding
>  * to the above tag.
>  */
> private void writeString(String s, byte stringTag, Charset charset) throws IOException
> 
> The parameter is charset, but not enc.
> 
> 
> /**
>  * Marshals a DER integer on the output stream.
>  *
>  * @param i the integer in bytes, equivalent to BigInteger::toByteArray.
>  */
> public void putInteger(byte[] buf) throws IOException {
> 
> The parameter is buf, but not i.

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

  8290775: Some doc errors in DerOutputStream.java  Update:correct the tense problem of expression

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9585/files
  - new: https://git.openjdk.org/jdk/pull/9585/files/c2a0a8b1..c2a05304

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9585&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9585&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/9585

From xuelei at openjdk.org  Fri Jul 22 15:14:45 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 22 Jul 2022 15:14:45 GMT
Subject: RFR: 8290775: Some doc errors in DerOutputStream.java [v3]
In-Reply-To: <CmXPQuOY_G8El7CxPzYw-I5xxWl8C6XiODDBTxEoeSA=.18715492-e9d1-4063-89d7-a793955720dd@github.com>
References: <d0JtKYOw3Oq5E1_APQ1BltggmdIEqdM5IAv3sYgwqrk=.c06a1c15-911d-40b0-b3fc-f2b1a975dfda@github.com>
 <CmXPQuOY_G8El7CxPzYw-I5xxWl8C6XiODDBTxEoeSA=.18715492-e9d1-4063-89d7-a793955720dd@github.com>
Message-ID: <KPMDMp0gBah3UUaPvS_S8aANMVzIIBJ7fRrCElBoGqI=.0d3d56c7-8874-47be-a8e4-169a50f69f3b@github.com>

On Fri, 22 Jul 2022 14:56:34 GMT, jquanC <duke at openjdk.org> wrote:

>> There are some doc errors in sun.security.util.DerOutputStream, like the followings,
>> 
>> 
>> /**
>>  * Private helper routine for writing DER encoded string values.
>>  * @param s the string to write
>>  * @param stringTag one of the DER string tags that indicate which
>>  * encoding should be used to write the string out.
>>  * @param enc the name of the encoder that should be used corresponding
>>  * to the above tag.
>>  */
>> private void writeString(String s, byte stringTag, Charset charset) throws IOException
>> 
>> The parameter is charset, but not enc.
>> 
>> 
>> /**
>>  * Marshals a DER integer on the output stream.
>>  *
>>  * @param i the integer in bytes, equivalent to BigInteger::toByteArray.
>>  */
>> public void putInteger(byte[] buf) throws IOException {
>> 
>> The parameter is buf, but not i.
>
> jquanC has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290775: Some doc errors in DerOutputStream.java  Update:correct the tense problem of expression

src/java.base/share/classes/sun/security/util/DerOutputStream.java line 464:

> 462:      * @param stringTag one of the DER string tags that indicate which
> 463:      * encoding should be used to write the string out.
> 464:      * @param charset the charset should be used corresponding to the

I may suggest to add 'that' back.  Without it, the meaning of the sentence may be different.

... the charset should be used corresponding to the above tag.
vs
... the charset **that** should be used corresponding to the above tag.

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

PR: https://git.openjdk.org/jdk/pull/9585

From duke at openjdk.org  Fri Jul 22 15:53:48 2022
From: duke at openjdk.org (Mark Powers)
Date: Fri, 22 Jul 2022 15:53:48 GMT
Subject: RFR: JDK-8155039 Simplify code to setup SSLContextImpl and
 TrustManagerFactoryImpl
In-Reply-To: <tDZXU5n4r_MmyIbI0EKeHldOYdmAvveZuStqGhdvQG0=.d7649485-91ac-4de7-b30a-78ff6bc77450@github.com>
References: <tDZXU5n4r_MmyIbI0EKeHldOYdmAvveZuStqGhdvQG0=.d7649485-91ac-4de7-b30a-78ff6bc77450@github.com>
Message-ID: <L_gv_PnQqIVEFGQw6CTFAfa03RL9J8rXYKuis6PyTS0=.f5f7dbf3-44fc-440c-84dc-5670963a6058@github.com>

On Mon, 18 Jul 2022 17:53:56 GMT, Mark Powers <duke at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8155039

JDK-8290887 has been filed for the separate cleanup.

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

PR: https://git.openjdk.org/jdk/pull/9542

From duke at openjdk.org  Fri Jul 22 15:59:04 2022
From: duke at openjdk.org (jquanC)
Date: Fri, 22 Jul 2022 15:59:04 GMT
Subject: RFR: 8290775: Some doc errors in DerOutputStream.java [v3]
In-Reply-To: <KPMDMp0gBah3UUaPvS_S8aANMVzIIBJ7fRrCElBoGqI=.0d3d56c7-8874-47be-a8e4-169a50f69f3b@github.com>
References: <d0JtKYOw3Oq5E1_APQ1BltggmdIEqdM5IAv3sYgwqrk=.c06a1c15-911d-40b0-b3fc-f2b1a975dfda@github.com>
 <CmXPQuOY_G8El7CxPzYw-I5xxWl8C6XiODDBTxEoeSA=.18715492-e9d1-4063-89d7-a793955720dd@github.com>
 <KPMDMp0gBah3UUaPvS_S8aANMVzIIBJ7fRrCElBoGqI=.0d3d56c7-8874-47be-a8e4-169a50f69f3b@github.com>
Message-ID: <JBHysD8PK_g-B18AHLOFR0cdh99kerW1iDsf_ika3W4=.0fd27b2a-a564-4741-a0d2-dfcfdf885228@github.com>

On Fri, 22 Jul 2022 15:11:43 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> jquanC has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8290775: Some doc errors in DerOutputStream.java  Update:correct the tense problem of expression
>
> src/java.base/share/classes/sun/security/util/DerOutputStream.java line 464:
> 
>> 462:      * @param stringTag one of the DER string tags that indicate which
>> 463:      * encoding should be used to write the string out.
>> 464:      * @param charset the charset should be used corresponding to the
> 
> I may suggest to add 'that' back.  Without it, the meaning of the sentence may be different.
> 
> ... the charset should be used corresponding to the above tag.
> vs
> ... the charset **that** should be used corresponding to the above tag.

Thanks again for all the above suggestions sincerely!
To avoid adding your troubles, I should end up using the following expression:

the charset that should be used corresponding to the above tag.

I'm trying to understand the difference between the two.
The first sentence may be understood as "the process of using charset" according to the above label.
The second sentence(use that) can better express "the choice of charset" needs to be based on the above label.
Is this correct?

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

PR: https://git.openjdk.org/jdk/pull/9585

From duke at openjdk.org  Fri Jul 22 16:29:55 2022
From: duke at openjdk.org (jquanC)
Date: Fri, 22 Jul 2022 16:29:55 GMT
Subject: RFR: 8290775: Some doc errors in DerOutputStream.java [v4]
In-Reply-To: <d0JtKYOw3Oq5E1_APQ1BltggmdIEqdM5IAv3sYgwqrk=.c06a1c15-911d-40b0-b3fc-f2b1a975dfda@github.com>
References: <d0JtKYOw3Oq5E1_APQ1BltggmdIEqdM5IAv3sYgwqrk=.c06a1c15-911d-40b0-b3fc-f2b1a975dfda@github.com>
Message-ID: <bUvRz3W0g4GwY9jf2m-1KUkMfmC0YiAhGnDKbeKm4Jg=.79c24a2e-6d0a-4a48-82ef-85e7bddf51a0@github.com>

> There are some doc errors in sun.security.util.DerOutputStream, like the followings,
> 
> 
> /**
>  * Private helper routine for writing DER encoded string values.
>  * @param s the string to write
>  * @param stringTag one of the DER string tags that indicate which
>  * encoding should be used to write the string out.
>  * @param enc the name of the encoder that should be used corresponding
>  * to the above tag.
>  */
> private void writeString(String s, byte stringTag, Charset charset) throws IOException
> 
> The parameter is charset, but not enc.
> 
> 
> /**
>  * Marshals a DER integer on the output stream.
>  *
>  * @param i the integer in bytes, equivalent to BigInteger::toByteArray.
>  */
> public void putInteger(byte[] buf) throws IOException {
> 
> The parameter is buf, but not i.

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

  8290775: Some doc errors in DerOutputStream.java  Update: better expression

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9585/files
  - new: https://git.openjdk.org/jdk/pull/9585/files/c2a05304..b8b25f25

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9585&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9585&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/9585

From weijun at openjdk.org  Fri Jul 22 17:42:20 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 22 Jul 2022 17:42:20 GMT
Subject: RFR: 8290775: Some doc errors in DerOutputStream.java [v4]
In-Reply-To: <bUvRz3W0g4GwY9jf2m-1KUkMfmC0YiAhGnDKbeKm4Jg=.79c24a2e-6d0a-4a48-82ef-85e7bddf51a0@github.com>
References: <d0JtKYOw3Oq5E1_APQ1BltggmdIEqdM5IAv3sYgwqrk=.c06a1c15-911d-40b0-b3fc-f2b1a975dfda@github.com>
 <bUvRz3W0g4GwY9jf2m-1KUkMfmC0YiAhGnDKbeKm4Jg=.79c24a2e-6d0a-4a48-82ef-85e7bddf51a0@github.com>
Message-ID: <UqItvXhAzO0BSXhBe0_vqsPGKFXXu5Ai9bSSCjbx7sU=.668a221c-1830-4859-b9ae-ed9bec4e4f08@github.com>

On Fri, 22 Jul 2022 16:29:55 GMT, jquanC <duke at openjdk.org> wrote:

>> There are some doc errors in sun.security.util.DerOutputStream, like the followings,
>> 
>> 
>> /**
>>  * Private helper routine for writing DER encoded string values.
>>  * @param s the string to write
>>  * @param stringTag one of the DER string tags that indicate which
>>  * encoding should be used to write the string out.
>>  * @param enc the name of the encoder that should be used corresponding
>>  * to the above tag.
>>  */
>> private void writeString(String s, byte stringTag, Charset charset) throws IOException
>> 
>> The parameter is charset, but not enc.
>> 
>> 
>> /**
>>  * Marshals a DER integer on the output stream.
>>  *
>>  * @param i the integer in bytes, equivalent to BigInteger::toByteArray.
>>  */
>> public void putInteger(byte[] buf) throws IOException {
>> 
>> The parameter is buf, but not i.
>
> jquanC has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290775: Some doc errors in DerOutputStream.java  Update: better expression

Two comments:
1. You reverted the `s/i/buf/` change in `putInteger`.
2. The other constructor also uses `an DER output steam`. Since you already fixed one, please take care of this one as well.

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

PR: https://git.openjdk.org/jdk/pull/9585

From weijun at openjdk.org  Fri Jul 22 17:42:22 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 22 Jul 2022 17:42:22 GMT
Subject: RFR: 8290775: Some doc errors in DerOutputStream.java [v3]
In-Reply-To: <JBHysD8PK_g-B18AHLOFR0cdh99kerW1iDsf_ika3W4=.0fd27b2a-a564-4741-a0d2-dfcfdf885228@github.com>
References: <d0JtKYOw3Oq5E1_APQ1BltggmdIEqdM5IAv3sYgwqrk=.c06a1c15-911d-40b0-b3fc-f2b1a975dfda@github.com>
 <CmXPQuOY_G8El7CxPzYw-I5xxWl8C6XiODDBTxEoeSA=.18715492-e9d1-4063-89d7-a793955720dd@github.com>
 <KPMDMp0gBah3UUaPvS_S8aANMVzIIBJ7fRrCElBoGqI=.0d3d56c7-8874-47be-a8e4-169a50f69f3b@github.com>
 <JBHysD8PK_g-B18AHLOFR0cdh99kerW1iDsf_ika3W4=.0fd27b2a-a564-4741-a0d2-dfcfdf885228@github.com>
Message-ID: <Ocg0JaSAPCvaP-BIeTSwYRfyAhVAl0NII2ZnT1GtzSs=.107feeb9-bcbb-40d0-9b16-15341ba05f79@github.com>

On Fri, 22 Jul 2022 15:56:58 GMT, jquanC <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/util/DerOutputStream.java line 464:
>> 
>>> 462:      * @param stringTag one of the DER string tags that indicate which
>>> 463:      * encoding should be used to write the string out.
>>> 464:      * @param charset the charset should be used corresponding to the
>> 
>> I may suggest to add 'that' back.  Without it, the meaning of the sentence may be different.
>> 
>> ... the charset should be used corresponding to the above tag.
>> vs
>> ... the charset **that** should be used corresponding to the above tag.
>
> Thanks again for all the above suggestions sincerely!
> To avoid adding your troubles, I should end up using the following expression:
> 
> the charset that should be used corresponding to the above tag.
> 
> I'm trying to understand the difference between the two.
> The first sentence may be understood as "the process of using charset" according to the above tag.
> The second sentence(use that) can better express "the choice of charset" needs to be based on the above tag.
> Is this correct?

A spec for an argument should be a noun. You can add attributes to describe it in more detail, which can be an adjective, or even a clause. This is what's shown in the 2nd line (I cannot call it a sentence because it's just a noun with an attributive clause). On the other hand, the 1st is a full sentence and it's not what we need here.

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

PR: https://git.openjdk.org/jdk/pull/9585

From duke at openjdk.org  Fri Jul 22 20:21:06 2022
From: duke at openjdk.org (Mark Powers)
Date: Fri, 22 Jul 2022 20:21:06 GMT
Subject: Withdrawn: JDK-8155039 Simplify code to setup SSLContextImpl and
 TrustManagerFactoryImpl
In-Reply-To: <tDZXU5n4r_MmyIbI0EKeHldOYdmAvveZuStqGhdvQG0=.d7649485-91ac-4de7-b30a-78ff6bc77450@github.com>
References: <tDZXU5n4r_MmyIbI0EKeHldOYdmAvveZuStqGhdvQG0=.d7649485-91ac-4de7-b30a-78ff6bc77450@github.com>
Message-ID: <x_BHeifyMNLYCnI3O4gtlmOfWSWeCxeCHxDl30uO_Wc=.62a9d858-232e-4fb3-a881-aeef54871a76@github.com>

On Mon, 18 Jul 2022 17:53:56 GMT, Mark Powers <duke at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8155039

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/9542

From duke at openjdk.org  Fri Jul 22 20:21:30 2022
From: duke at openjdk.org (Mark Powers)
Date: Fri, 22 Jul 2022 20:21:30 GMT
Subject: RFR: JDK-8290887 unused private method in TrustManagerFactoryImpl
Message-ID: <uZaz0EIJDmhZo5L-hqp5n7GUyMCDGkhYrBqUj-GqFqc=.9980d8d1-1b63-4957-bde2-feaa64e2b9f4@github.com>

https://bugs.openjdk.org/browse/JDK-8290887

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

Commit messages:
 - first iteration

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

PR: https://git.openjdk.org/jdk/pull/9616

From duke at openjdk.org  Fri Jul 22 20:28:03 2022
From: duke at openjdk.org (Mark Powers)
Date: Fri, 22 Jul 2022 20:28:03 GMT
Subject: RFR: JDK-8155039 Simplify code to setup SSLContextImpl and
 TrustManagerFactoryImpl
In-Reply-To: <tDZXU5n4r_MmyIbI0EKeHldOYdmAvveZuStqGhdvQG0=.d7649485-91ac-4de7-b30a-78ff6bc77450@github.com>
References: <tDZXU5n4r_MmyIbI0EKeHldOYdmAvveZuStqGhdvQG0=.d7649485-91ac-4de7-b30a-78ff6bc77450@github.com>
Message-ID: <bQGPafQorpt4ukODi4Lod9Fz-HdWTjHL7I5l6uTvddE=.57a79923-e93a-42a9-bb38-55eca2ee3168@github.com>

On Mon, 18 Jul 2022 17:53:56 GMT, Mark Powers <duke at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8155039

Opened JDK-8290887 to fix a different issue while working on JDK-8155039.
Closing JDK-8155039 as Will-Not-Fix.

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

PR: https://git.openjdk.org/jdk/pull/9542

From weijun at openjdk.org  Fri Jul 22 20:46:47 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 22 Jul 2022 20:46:47 GMT
Subject: RFR: JDK-8290887 Unused private method in TrustManagerFactoryImpl
In-Reply-To: <uZaz0EIJDmhZo5L-hqp5n7GUyMCDGkhYrBqUj-GqFqc=.9980d8d1-1b63-4957-bde2-feaa64e2b9f4@github.com>
References: <uZaz0EIJDmhZo5L-hqp5n7GUyMCDGkhYrBqUj-GqFqc=.9980d8d1-1b63-4957-bde2-feaa64e2b9f4@github.com>
Message-ID: <UgDlLkKady1LTLiFYTgpPmyUT58gnnU8GcBwAWRLVAs=.399c9583-a96b-4564-9bbb-6a19268933e0@github.com>

On Fri, 22 Jul 2022 17:59:51 GMT, Mark Powers <duke at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8290887

LGTM.

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

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9616

From duke at openjdk.org  Fri Jul 22 21:16:00 2022
From: duke at openjdk.org (Mark Powers)
Date: Fri, 22 Jul 2022 21:16:00 GMT
Subject: RFR: JDK-8290887 Unused private method in TrustManagerFactoryImpl
In-Reply-To: <uZaz0EIJDmhZo5L-hqp5n7GUyMCDGkhYrBqUj-GqFqc=.9980d8d1-1b63-4957-bde2-feaa64e2b9f4@github.com>
References: <uZaz0EIJDmhZo5L-hqp5n7GUyMCDGkhYrBqUj-GqFqc=.9980d8d1-1b63-4957-bde2-feaa64e2b9f4@github.com>
Message-ID: <EvcpW6Zgvucr01ON_UrB70-Sozd0K972-7i1CuMdspQ=.cdebb154-88c9-48c8-8330-0c71d152de26@github.com>

On Fri, 22 Jul 2022 17:59:51 GMT, Mark Powers <duke at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8290887

Thanks.

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

PR: https://git.openjdk.org/jdk/pull/9616

From xuelei at openjdk.org  Fri Jul 22 21:46:58 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 22 Jul 2022 21:46:58 GMT
Subject: RFR: JDK-8290887 Unused private method in TrustManagerFactoryImpl
In-Reply-To: <uZaz0EIJDmhZo5L-hqp5n7GUyMCDGkhYrBqUj-GqFqc=.9980d8d1-1b63-4957-bde2-feaa64e2b9f4@github.com>
References: <uZaz0EIJDmhZo5L-hqp5n7GUyMCDGkhYrBqUj-GqFqc=.9980d8d1-1b63-4957-bde2-feaa64e2b9f4@github.com>
Message-ID: <Kh7Fx87u3kCMibog0umDHuNh1X4I0t5Ka4IxiGZQAP4=.3dd61811-495d-4fd4-802f-6671d22f3a75@github.com>

On Fri, 22 Jul 2022 17:59:51 GMT, Mark Powers <duke at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8290887

Marked as reviewed by xuelei (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9616

From duke at openjdk.org  Sat Jul 23 01:46:01 2022
From: duke at openjdk.org (jquanC)
Date: Sat, 23 Jul 2022 01:46:01 GMT
Subject: RFR: 8290775: Some doc errors in DerOutputStream.java [v4]
In-Reply-To: <UqItvXhAzO0BSXhBe0_vqsPGKFXXu5Ai9bSSCjbx7sU=.668a221c-1830-4859-b9ae-ed9bec4e4f08@github.com>
References: <d0JtKYOw3Oq5E1_APQ1BltggmdIEqdM5IAv3sYgwqrk=.c06a1c15-911d-40b0-b3fc-f2b1a975dfda@github.com>
 <bUvRz3W0g4GwY9jf2m-1KUkMfmC0YiAhGnDKbeKm4Jg=.79c24a2e-6d0a-4a48-82ef-85e7bddf51a0@github.com>
 <UqItvXhAzO0BSXhBe0_vqsPGKFXXu5Ai9bSSCjbx7sU=.668a221c-1830-4859-b9ae-ed9bec4e4f08@github.com>
Message-ID: <O3BeYjiroUOzwx2kq3ywu9iKkTgmlMn4-n6kJVvTNRg=.8df29dd3-5172-49de-8f42-9b40c9012ef7@github.com>

On Fri, 22 Jul 2022 17:39:20 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Two comments:
> 
> 1. You reverted the `s/i/buf/` change in `putInteger`.
> 2. The other constructor also uses `an DER output steam`. Since you already fixed one, please take care of this one as well.

Got it, I will take care of that.

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

PR: https://git.openjdk.org/jdk/pull/9585

From duke at openjdk.org  Sat Jul 23 01:46:02 2022
From: duke at openjdk.org (jquanC)
Date: Sat, 23 Jul 2022 01:46:02 GMT
Subject: RFR: 8290775: Some doc errors in DerOutputStream.java [v3]
In-Reply-To: <Ocg0JaSAPCvaP-BIeTSwYRfyAhVAl0NII2ZnT1GtzSs=.107feeb9-bcbb-40d0-9b16-15341ba05f79@github.com>
References: <d0JtKYOw3Oq5E1_APQ1BltggmdIEqdM5IAv3sYgwqrk=.c06a1c15-911d-40b0-b3fc-f2b1a975dfda@github.com>
 <CmXPQuOY_G8El7CxPzYw-I5xxWl8C6XiODDBTxEoeSA=.18715492-e9d1-4063-89d7-a793955720dd@github.com>
 <KPMDMp0gBah3UUaPvS_S8aANMVzIIBJ7fRrCElBoGqI=.0d3d56c7-8874-47be-a8e4-169a50f69f3b@github.com>
 <JBHysD8PK_g-B18AHLOFR0cdh99kerW1iDsf_ika3W4=.0fd27b2a-a564-4741-a0d2-dfcfdf885228@github.com>
 <Ocg0JaSAPCvaP-BIeTSwYRfyAhVAl0NII2ZnT1GtzSs=.107feeb9-bcbb-40d0-9b16-15341ba05f79@github.com>
Message-ID: <oiCoC5R-sWMIiWa0_M8uXgLgMu2iCh4JfcTawkMQGrg=.7638129d-9f8a-4a9b-a170-b72fc93b9be2@github.com>

On Fri, 22 Jul 2022 17:37:40 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> A spec for an argument should be a noun. You can add attributes to describe it in more detail, which can be an adjective, or even a clause. This is what's shown in the 2nd line (I cannot call it a sentence because it's just a noun with an attributive clause). On the other hand, the 1st is a full sentence and it's not what we need here.

Thanks so much for your detailed explanation.
I get it now.

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

PR: https://git.openjdk.org/jdk/pull/9585

From achung at openjdk.org  Sat Jul 23 03:11:02 2022
From: achung at openjdk.org (Alisen Chung)
Date: Sat, 23 Jul 2022 03:11:02 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update - msgdrop
 10
Message-ID: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>

open l10n msg drop
All tests passed.

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

Commit messages:
 - open l10n drop

Changes: https://git.openjdk.org/jdk19/pull/154/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=154&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290889
  Stats: 3930 lines in 44 files changed: 3336 ins; 540 del; 54 mod
  Patch: https://git.openjdk.org/jdk19/pull/154.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/154/head:pull/154

PR: https://git.openjdk.org/jdk19/pull/154

From duke at openjdk.org  Sat Jul 23 05:29:07 2022
From: duke at openjdk.org (jquanC)
Date: Sat, 23 Jul 2022 05:29:07 GMT
Subject: RFR: 8290775: Some doc errors in DerOutputStream.java [v5]
In-Reply-To: <d0JtKYOw3Oq5E1_APQ1BltggmdIEqdM5IAv3sYgwqrk=.c06a1c15-911d-40b0-b3fc-f2b1a975dfda@github.com>
References: <d0JtKYOw3Oq5E1_APQ1BltggmdIEqdM5IAv3sYgwqrk=.c06a1c15-911d-40b0-b3fc-f2b1a975dfda@github.com>
Message-ID: <_XWAlJoorIIxTVriu2cx4NZ4bH-I77iqQIJhnwD6bkc=.93773aa5-f273-4bc5-82c6-1e51098ee80b@github.com>

> There are some doc errors in sun.security.util.DerOutputStream, like the followings,
> 
> 
> /**
>  * Private helper routine for writing DER encoded string values.
>  * @param s the string to write
>  * @param stringTag one of the DER string tags that indicate which
>  * encoding should be used to write the string out.
>  * @param enc the name of the encoder that should be used corresponding
>  * to the above tag.
>  */
> private void writeString(String s, byte stringTag, Charset charset) throws IOException
> 
> The parameter is charset, but not enc.
> 
> 
> /**
>  * Marshals a DER integer on the output stream.
>  *
>  * @param i the integer in bytes, equivalent to BigInteger::toByteArray.
>  */
> public void putInteger(byte[] buf) throws IOException {
> 
> The parameter is buf, but not i.

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

  8290775: Some doc errors in DerOutputStream.java  Update: add a modification and improve an expression according to the specification

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9585/files
  - new: https://git.openjdk.org/jdk/pull/9585/files/b8b25f25..14b2802c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9585&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9585&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/9585

From xuelei at openjdk.org  Sat Jul 23 05:35:03 2022
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Sat, 23 Jul 2022 05:35:03 GMT
Subject: RFR: 8290775: Some doc errors in DerOutputStream.java [v5]
In-Reply-To: <_XWAlJoorIIxTVriu2cx4NZ4bH-I77iqQIJhnwD6bkc=.93773aa5-f273-4bc5-82c6-1e51098ee80b@github.com>
References: <d0JtKYOw3Oq5E1_APQ1BltggmdIEqdM5IAv3sYgwqrk=.c06a1c15-911d-40b0-b3fc-f2b1a975dfda@github.com>
 <_XWAlJoorIIxTVriu2cx4NZ4bH-I77iqQIJhnwD6bkc=.93773aa5-f273-4bc5-82c6-1e51098ee80b@github.com>
Message-ID: <51WLxTGgTwzYNlUntlEwlE-vCkfBTDLste5FjSbRnCk=.a326e20c-6195-4040-ab4b-a573425d4fd9@github.com>

On Sat, 23 Jul 2022 05:29:07 GMT, jquanC <duke at openjdk.org> wrote:

>> There are some doc errors in sun.security.util.DerOutputStream, like the followings,
>> 
>> 
>> /**
>>  * Private helper routine for writing DER encoded string values.
>>  * @param s the string to write
>>  * @param stringTag one of the DER string tags that indicate which
>>  * encoding should be used to write the string out.
>>  * @param enc the name of the encoder that should be used corresponding
>>  * to the above tag.
>>  */
>> private void writeString(String s, byte stringTag, Charset charset) throws IOException
>> 
>> The parameter is charset, but not enc.
>> 
>> 
>> /**
>>  * Marshals a DER integer on the output stream.
>>  *
>>  * @param i the integer in bytes, equivalent to BigInteger::toByteArray.
>>  */
>> public void putInteger(byte[] buf) throws IOException {
>> 
>> The parameter is buf, but not i.
>
> jquanC has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290775: Some doc errors in DerOutputStream.java  Update: add a modification and improve an expression according to the specification

Looks good to me.  Thanks!

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

Marked as reviewed by xuelei (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9585

From duke at openjdk.org  Sat Jul 23 05:40:58 2022
From: duke at openjdk.org (jquanC)
Date: Sat, 23 Jul 2022 05:40:58 GMT
Subject: RFR: 8290775: Some doc errors in DerOutputStream.java [v5]
In-Reply-To: <51WLxTGgTwzYNlUntlEwlE-vCkfBTDLste5FjSbRnCk=.a326e20c-6195-4040-ab4b-a573425d4fd9@github.com>
References: <d0JtKYOw3Oq5E1_APQ1BltggmdIEqdM5IAv3sYgwqrk=.c06a1c15-911d-40b0-b3fc-f2b1a975dfda@github.com>
 <_XWAlJoorIIxTVriu2cx4NZ4bH-I77iqQIJhnwD6bkc=.93773aa5-f273-4bc5-82c6-1e51098ee80b@github.com>
 <51WLxTGgTwzYNlUntlEwlE-vCkfBTDLste5FjSbRnCk=.a326e20c-6195-4040-ab4b-a573425d4fd9@github.com>
Message-ID: <vaCjZBqwSYFD4jzo4Cy2H9fOufAqXxmcucOqW03V-ZY=.bc8f5154-4bc9-4ba6-95fb-8d05c15b716d@github.com>

On Sat, 23 Jul 2022 05:31:29 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Looks good to me. Thanks!

Cheers and appreciation! And I have learned more from your guidance.

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

PR: https://git.openjdk.org/jdk/pull/9585

From aturbanov at openjdk.org  Sat Jul 23 18:13:37 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 23 Jul 2022 18:13:37 GMT
Subject: RFR: 8290824: Use InputStream.readAllBytes() instead of explicit
 loops
In-Reply-To: <U1UZQYOalHr0MinGKEmLn5-TiVXSq2GCVG97bnyv-U8=.abdafbf5-11c9-4c39-b9a3-4e74ffefcb33@github.com>
References: <U1UZQYOalHr0MinGKEmLn5-TiVXSq2GCVG97bnyv-U8=.abdafbf5-11c9-4c39-b9a3-4e74ffefcb33@github.com>
Message-ID: <2PIIeyDxI3wzRLKMLgHy22LmmZobKIYeYtcDwZ1yhyk=.7846ffdd-cbe7-4c8b-9008-c905629570c6@github.com>

On Thu, 21 Jul 2022 15:37:40 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`.

Ow. I've created similar PR for `X509CertPath` recently #9263

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

PR: https://git.openjdk.org/jdk/pull/9596

From duke at openjdk.org  Sat Jul 23 18:44:44 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sat, 23 Jul 2022 18:44:44 GMT
Subject: RFR: 8290824: Use InputStream.readAllBytes() instead of explicit
 loops
In-Reply-To: <2PIIeyDxI3wzRLKMLgHy22LmmZobKIYeYtcDwZ1yhyk=.7846ffdd-cbe7-4c8b-9008-c905629570c6@github.com>
References: <U1UZQYOalHr0MinGKEmLn5-TiVXSq2GCVG97bnyv-U8=.abdafbf5-11c9-4c39-b9a3-4e74ffefcb33@github.com>
 <2PIIeyDxI3wzRLKMLgHy22LmmZobKIYeYtcDwZ1yhyk=.7846ffdd-cbe7-4c8b-9008-c905629570c6@github.com>
Message-ID: <rX25-K3_TaqM70Jg27onprB6Nefy0RdLSeD0IvVeE-Y=.f5a9a293-4f0e-4fe6-8fa4-cf1b6b8af2be@github.com>

On Sat, 23 Jul 2022 18:10:15 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`.
>
> Ow. I've created similar PR for `X509CertPath` recently #9263

@turbanoff I'll then remove the mentioned piece from this PR

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

PR: https://git.openjdk.org/jdk/pull/9596

From duke at openjdk.org  Sat Jul 23 18:48:51 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sat, 23 Jul 2022 18:48:51 GMT
Subject: RFR: 8289659: Refactor I/O stream copying to use
 InputStream.readAllBytes in X509CertPath
In-Reply-To: <wj4QPVNRRYV0CDdbtG9UN7H-iFvtDd7Og9araPbw4YY=.b575524d-215c-4026-bdac-57b6e7f4ecdd@github.com>
References: <wj4QPVNRRYV0CDdbtG9UN7H-iFvtDd7Og9araPbw4YY=.b575524d-215c-4026-bdac-57b6e7f4ecdd@github.com>
Message-ID: <RBEqwU7prW_PT3OObZW86TSnynL_1kCfQr82G8c5jxY=.ec790b43-9bc9-42c4-8bd8-49eded79fa63@github.com>

On Thu, 23 Jun 2022 19:32:44 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Use `InputStream.readAllBytes` instead of manually written method.
> 
> Skipped this method in [JDK-8080272](https://bugs.openjdk.org/browse/JDK-8080272)

Marked as reviewed by stsypanov at github.com (no known OpenJDK username).

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

PR: https://git.openjdk.org/jdk/pull/9263

From duke at openjdk.org  Sun Jul 24 12:42:42 2022
From: duke at openjdk.org (longxu0509)
Date: Sun, 24 Jul 2022 12:42:42 GMT
Subject: RFR: 8290669: Fix wording in sun.security.ec
Message-ID: <k9rQZLuJplCS6F4sYk_4Vwbraicv7UZdHMn5KsKLAtY=.f4c865d4-4490-436e-b78f-cab012bda6c4@github.com>

this patch fixes several wording in sun.security.ec

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

Commit messages:
 - Fix wording in sun.security.ec

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

PR: https://git.openjdk.org/jdk/pull/9606

From duke at openjdk.org  Mon Jul 25 06:40:49 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 25 Jul 2022 06:40:49 GMT
Subject: RFR: 8290824: Use InputStream.readAllBytes() instead of explicit
 loops [v2]
In-Reply-To: <U1UZQYOalHr0MinGKEmLn5-TiVXSq2GCVG97bnyv-U8=.abdafbf5-11c9-4c39-b9a3-4e74ffefcb33@github.com>
References: <U1UZQYOalHr0MinGKEmLn5-TiVXSq2GCVG97bnyv-U8=.abdafbf5-11c9-4c39-b9a3-4e74ffefcb33@github.com>
Message-ID: <kofU3T98_NaXfo3Dbi2Sme_2C3HPl0g0QDk2az8TdKo=.6cdab01e-45f7-4ab3-b2a4-bff5c4e16e78@github.com>

> We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`.

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

  8278461: Revert X509CertPath

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9596/files
  - new: https://git.openjdk.org/jdk/pull/9596/files/04415d08..0079ed3b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9596&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9596&range=00-01

  Stats: 24 lines in 1 file changed: 17 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/9596.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9596/head:pull/9596

PR: https://git.openjdk.org/jdk/pull/9596

From duke at openjdk.org  Mon Jul 25 08:56:10 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 25 Jul 2022 08:56:10 GMT
Subject: RFR: 8290824: Use InputStream.readAllBytes() instead of explicit
 loops [v2]
In-Reply-To: <kofU3T98_NaXfo3Dbi2Sme_2C3HPl0g0QDk2az8TdKo=.6cdab01e-45f7-4ab3-b2a4-bff5c4e16e78@github.com>
References: <U1UZQYOalHr0MinGKEmLn5-TiVXSq2GCVG97bnyv-U8=.abdafbf5-11c9-4c39-b9a3-4e74ffefcb33@github.com>
 <kofU3T98_NaXfo3Dbi2Sme_2C3HPl0g0QDk2az8TdKo=.6cdab01e-45f7-4ab3-b2a4-bff5c4e16e78@github.com>
Message-ID: <pE69pPTeLJKzRT5nc6UMeckS2Pt-om-hTFPPa_gywI8=.980c9510-6eca-4dc9-8cc0-e329e3eb3c22@github.com>

On Mon, 25 Jul 2022 06:40:49 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8278461: Revert X509CertPath

I've measured this with benchmark

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
@Fork(jvmArgsAppend = {"-Xms1g", "-Xmx1g"})
public class HashBenchmark {

  private final Path path = Path.of("/Users/stsypanov/Library/Java/JavaVirtualMachines/openjdk-18.0.2/Contents/Home/jmods");
  private final ModuleFinder finder = ModulePath.of(Runtime.version(), true, path);

  @Benchmark
  public byte[] hash() throws Exception {
    return hash(finder, "java.base");
  }

  private byte[] hash(ModuleFinder finder, String name) throws Exception {
    ModuleReference mref = finder.find(name).orElseThrow(RuntimeException::new);
    try (ModuleReader reader = mref.open()) {
      return ModuleHashes.computeHash(reader, "SHA-256");
    }
  }
}

and indeed the change makes things slower:

baseline
Benchmark                                            Mode  Cnt         Score         Error   Units
HashBenchmark.hash                                   avgt   50       174,632 ?       5,581   ms/op
HashBenchmark.hash:?gc.alloc.rate                    avgt   50       165,848 ?       4,574  MB/sec
HashBenchmark.hash:?gc.alloc.rate.norm               avgt   50  31773902,052 ?   24870,662    B/op
HashBenchmark.hash:?gc.churn.G1_Eden_Space           avgt   50       166,357 ?       9,399  MB/sec
HashBenchmark.hash:?gc.churn.G1_Eden_Space.norm      avgt   50  31891221,589 ? 1725370,956    B/op
HashBenchmark.hash:?gc.churn.G1_Old_Gen              avgt   50         5,553 ?       0,327  MB/sec
HashBenchmark.hash:?gc.churn.G1_Old_Gen.norm         avgt   50   1064354,875 ?   60435,285    B/op
HashBenchmark.hash:?gc.churn.G1_Survivor_Space       avgt   50         0,034 ?       0,032  MB/sec
HashBenchmark.hash:?gc.churn.G1_Survivor_Space.norm  avgt   50      6754,365 ?    6398,008    B/op
HashBenchmark.hash:?gc.count                         avgt   50       144,000                counts
HashBenchmark.hash:?gc.time                          avgt   50       249,000                    ms

patched

Benchmark                                            Mode  Cnt          Score         Error   Units
HashBenchmark.hash                                   avgt   50        192,068 ?       8,236   ms/op
HashBenchmark.hash:?gc.alloc.rate                    avgt   50        568,790 ?      22,912  MB/sec
HashBenchmark.hash:?gc.alloc.rate.norm               avgt   50  119441637,758 ?   28476,724    B/op
HashBenchmark.hash:?gc.churn.G1_Eden_Space           avgt   50        568,892 ?      26,936  MB/sec
HashBenchmark.hash:?gc.churn.G1_Eden_Space.norm      avgt   50  119444622,067 ? 2746230,425    B/op
HashBenchmark.hash:?gc.churn.G1_Old_Gen              avgt   50          4,964 ?       0,238  MB/sec
HashBenchmark.hash:?gc.churn.G1_Old_Gen.norm         avgt   50    1042019,563 ?   23557,187    B/op
HashBenchmark.hash:?gc.churn.G1_Survivor_Space       avgt   50          0,043 ?       0,033  MB/sec
HashBenchmark.hash:?gc.churn.G1_Survivor_Space.norm  avgt   50       9130,656 ?    7040,858    B/op
HashBenchmark.hash:?gc.count                         avgt   50        492,000                counts
HashBenchmark.hash:?gc.time                          avgt   50        738,000                    ms

I'll close this PR then.

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

PR: https://git.openjdk.org/jdk/pull/9596

From duke at openjdk.org  Mon Jul 25 08:56:11 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 25 Jul 2022 08:56:11 GMT
Subject: Withdrawn: 8290824: Use InputStream.readAllBytes() instead of explicit
 loops
In-Reply-To: <U1UZQYOalHr0MinGKEmLn5-TiVXSq2GCVG97bnyv-U8=.abdafbf5-11c9-4c39-b9a3-4e74ffefcb33@github.com>
References: <U1UZQYOalHr0MinGKEmLn5-TiVXSq2GCVG97bnyv-U8=.abdafbf5-11c9-4c39-b9a3-4e74ffefcb33@github.com>
Message-ID: <fIoxTPfpsMmJdk_-jQh4hMqaN3LyY9Ncoc_krcDJ_8E=.a1f7283d-1c28-4740-9795-1cbbbc14c52d@github.com>

On Thu, 21 Jul 2022 15:37:40 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> We can use `InputStream.readAllBytes()` in `ModuleHashes` and `X509CertPath`.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/9596

From aturbanov at openjdk.org  Mon Jul 25 10:09:02 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 25 Jul 2022 10:09:02 GMT
Subject: RFR: 8289659: Refactor I/O stream copying to use
 InputStream.readAllBytes in X509CertPath
In-Reply-To: <wj4QPVNRRYV0CDdbtG9UN7H-iFvtDd7Og9araPbw4YY=.b575524d-215c-4026-bdac-57b6e7f4ecdd@github.com>
References: <wj4QPVNRRYV0CDdbtG9UN7H-iFvtDd7Og9araPbw4YY=.b575524d-215c-4026-bdac-57b6e7f4ecdd@github.com>
Message-ID: <Nf_h6TuMg507m72GrpN5a2YKZO7_z5josQBDf4SThe4=.45589f1b-a107-4a09-8dd5-f1099190180c@github.com>

On Thu, 23 Jun 2022 19:32:44 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Use `InputStream.readAllBytes` instead of manually written method.
> 
> Skipped this method in [JDK-8080272](https://bugs.openjdk.org/browse/JDK-8080272)

I think we need approve from security team.
@seanjmullan @wangweij can you please have a look?

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

PR: https://git.openjdk.org/jdk/pull/9263

From duke at openjdk.org  Mon Jul 25 10:14:00 2022
From: duke at openjdk.org (Guzhenyuan)
Date: Mon, 25 Jul 2022 10:14:00 GMT
Subject: RFR: 8276660: Scalability bottleneck in
 java.security.Provider.getService() [v2]
In-Reply-To: <w6LDIKTRdwPAwYCXzjmF_XZArMxFSIjfYYk56qonvwQ=.3f5fca0f-e61e-418c-936a-ab16d0d3b5e5@github.com>
References: <UYZKq0NwhkPnJvIgo4bxggAjRQGO_DMJiw_r7ackWxM=.469b7fe2-1e43-432f-afaa-92da218ee3f5@github.com>
 <S6hBTzTEP_QnmVW0KiERvRgaUT3bMYFOL0x5sT4Qp_I=.1cb5cdb4-f74d-4153-b178-ec179036805d@github.com>
 <upmxCyeWKNkxpsA11kjdmXV4ipxZYkzUxktDvviFFS0=.54acf4ff-0434-46cf-a9a6-809cfff7febd@github.com>
 <w6LDIKTRdwPAwYCXzjmF_XZArMxFSIjfYYk56qonvwQ=.3f5fca0f-e61e-418c-936a-ab16d0d3b5e5@github.com>
Message-ID: <7TS8KpadotBWY8cTqk0Ijppx6No1ArlcgbDevh6TULs=.b583545e-f6d1-441e-8d54-c31cef533532@github.com>

On Tue, 30 Nov 2021 23:03:42 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

> > Consider this case, two threads are changing a value at the same time. Since the method is not synchonized, thread1 might finish the first part of the method (`super.replace`) earlier than thread2, but it finishes the second part (`parseLegacy`) later than thread2. At the end, the internal entrySet has thread2's value but the legacy map has thread1's value.
> 
> Well, then the synchronized keyword should be put on the public methods instead of the internal parseLegacy() method, no? Otherwise, the super.xxx() and the internal legacyMap may not updated in sync. The public methods did have the synchronized keywords which I removed since the putService() call isn't synchronized either (and it updates the serviceMap first and then stores the String-String mapping into super.xxx()). The main performance bottleneck is in getService(), so I can add back the "synchronized" keywords to other public methods if you are concerned.

Can you tell me which version of jdk fixes these bugs

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

PR: https://git.openjdk.org/jdk/pull/6513

From weijun at openjdk.org  Mon Jul 25 13:25:01 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 25 Jul 2022 13:25:01 GMT
Subject: RFR: 8289659: Refactor I/O stream copying to use
 InputStream.readAllBytes in X509CertPath
In-Reply-To: <wj4QPVNRRYV0CDdbtG9UN7H-iFvtDd7Og9araPbw4YY=.b575524d-215c-4026-bdac-57b6e7f4ecdd@github.com>
References: <wj4QPVNRRYV0CDdbtG9UN7H-iFvtDd7Og9araPbw4YY=.b575524d-215c-4026-bdac-57b6e7f4ecdd@github.com>
Message-ID: <BIvqh9v2Az-YO_X_10i0_kaobkK396Qt4WIcbcPTtJM=.74bcedbe-c6ca-4192-8ec3-0807dfab0d3e@github.com>

On Thu, 23 Jun 2022 19:32:44 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Use `InputStream.readAllBytes` instead of manually written method.
> 
> Skipped this method in [JDK-8080272](https://bugs.openjdk.org/browse/JDK-8080272)

Looks good to me. Thanks.

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

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9263

From weijun at openjdk.org  Mon Jul 25 13:33:11 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 25 Jul 2022 13:33:11 GMT
Subject: RFR: 8276660: Scalability bottleneck in
 java.security.Provider.getService() [v2]
In-Reply-To: <7TS8KpadotBWY8cTqk0Ijppx6No1ArlcgbDevh6TULs=.b583545e-f6d1-441e-8d54-c31cef533532@github.com>
References: <UYZKq0NwhkPnJvIgo4bxggAjRQGO_DMJiw_r7ackWxM=.469b7fe2-1e43-432f-afaa-92da218ee3f5@github.com>
 <S6hBTzTEP_QnmVW0KiERvRgaUT3bMYFOL0x5sT4Qp_I=.1cb5cdb4-f74d-4153-b178-ec179036805d@github.com>
 <upmxCyeWKNkxpsA11kjdmXV4ipxZYkzUxktDvviFFS0=.54acf4ff-0434-46cf-a9a6-809cfff7febd@github.com>
 <w6LDIKTRdwPAwYCXzjmF_XZArMxFSIjfYYk56qonvwQ=.3f5fca0f-e61e-418c-936a-ab16d0d3b5e5@github.com>
 <7TS8KpadotBWY8cTqk0Ijppx6No1ArlcgbDevh6TULs=.b583545e-f6d1-441e-8d54-c31cef533532@github.com>
Message-ID: <r_ceI5IoDU3dofBgCQaeRfgMpNDgmPNPE3INofTvUpw=.a2fb2314-f84c-4eb9-8cb3-7572808819b5@github.com>

On Mon, 25 Jul 2022 08:55:30 GMT, Guzhenyuan <duke at openjdk.org> wrote:

> Can you tell me which version of jdk fixes these bugs

You mean *this* bug? Click on the "Issue" link and you can it was included in JDK 18.

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

PR: https://git.openjdk.org/jdk/pull/6513

From aturbanov at openjdk.org  Mon Jul 25 14:15:10 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 25 Jul 2022 14:15:10 GMT
Subject: Integrated: 8289659: Refactor I/O stream copying to use
 InputStream.readAllBytes in X509CertPath
In-Reply-To: <wj4QPVNRRYV0CDdbtG9UN7H-iFvtDd7Og9araPbw4YY=.b575524d-215c-4026-bdac-57b6e7f4ecdd@github.com>
References: <wj4QPVNRRYV0CDdbtG9UN7H-iFvtDd7Og9araPbw4YY=.b575524d-215c-4026-bdac-57b6e7f4ecdd@github.com>
Message-ID: <5YITIVoKPEArslwmfP8I0twoP9dV4pOmqQK2E4O-rwY=.3c71a041-08d2-4980-b045-17911429ad01@github.com>

On Thu, 23 Jun 2022 19:32:44 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Use `InputStream.readAllBytes` instead of manually written method.
> 
> Skipped this method in [JDK-8080272](https://bugs.openjdk.org/browse/JDK-8080272)

This pull request has now been integrated.

Changeset: 0ca74f53
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0ca74f538e1a8a351cc0631c5fe397a74653ce6f
Stats:     20 lines in 1 file changed: 0 ins; 17 del; 3 mod

8289659: Refactor I/O stream copying to use InputStream.readAllBytes in X509CertPath

Reviewed-by: attila, weijun

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

PR: https://git.openjdk.org/jdk/pull/9263

From naoto at openjdk.org  Mon Jul 25 17:05:38 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 25 Jul 2022 17:05:38 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update -
 msgdrop 10
In-Reply-To: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
Message-ID: <H6f17TB5GpzVnnzK7uUw7zQeqXFv4hr_-adfUI5D5D4=.a1cd4524-a11c-4749-b253-cb6c24303849@github.com>

On Sat, 23 Jul 2022 03:03:25 GMT, Alisen Chung <achung at openjdk.org> wrote:

> open l10n msg drop
> All tests passed.

Changes requested by naoto (Reviewer).

src/java.base/share/classes/sun/util/resources/CurrencyNames_de.properties line 63:

> 61: # written authorization of the copyright holder.
> 62: 
> 63: ADP=ADP

These currency symbols (`XXX=XXX`) are all in the base `CurrencyNames.properties`, so not needed in each localized resources (They are in the base in order to avoid throwing exceptions).

Also, the localized files should not reside in `java.base`, but to be merged with the ones in `jdk.localedata` module

These comments hold for all localized resources (de, ja, zh-CN). For furure reference, it may be good to add some comment in the base `CurrencyNames.properties` about this.

src/java.base/share/data/currency/CurrencyData_de.properties line 1:

> 1: #

`CurrencyData.properties` is not a localizable resource bundle, but a properties file containing currency data. No need to add these localized resources.

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

PR: https://git.openjdk.org/jdk19/pull/154

From asemenyuk at openjdk.org  Mon Jul 25 18:52:15 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 25 Jul 2022 18:52:15 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update -
 msgdrop 10
In-Reply-To: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
Message-ID: <1Ziaq5GCAhIwzw1n5Vex22mK_sBGUknmSn_0xsxlysE=.87eb8ad1-7e05-458f-ba04-25fcfce81fc8@github.com>

On Sat, 23 Jul 2022 03:03:25 GMT, Alisen Chung <achung at openjdk.org> wrote:

> open l10n msg drop
> All tests passed.

Why `MSG_Help_mac_launcher` in [src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_de.properties](https://github.com/openjdk/jdk19/pull/154/files#diff-2e1b121e201e1040827d5b68ebdd852615e611904db783806a753dc6980e97fa) is left not localized? Is it intended to be localized in the next drop?

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

PR: https://git.openjdk.org/jdk19/pull/154

From valeriep at openjdk.org  Mon Jul 25 21:33:04 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 25 Jul 2022 21:33:04 GMT
Subject: RFR: JDK-8290532: Adjust PKCS11Exception and handle more PKCS11
 error codes [v2]
In-Reply-To: <IwwBw8vjPEpPBRL4njVQ4pPMvxXtslZfoVT17wxKMB4=.edf0b389-21d9-40b3-bb92-0b9645bcb469@github.com>
References: <kccdSpgGrSgPAyqLQNOGBo7QqMF-hxiHfc_rO9X-sL8=.f56646dd-d135-4f1a-85fb-34bcfdcc648e@github.com>
 <rGcN9Uh7tBrYgWvbUVtwRVt8XY1_IDMc65ud_AOHmc4=.401c70e1-363f-4241-8802-df5c0e6f4388@github.com>
 <IwwBw8vjPEpPBRL4njVQ4pPMvxXtslZfoVT17wxKMB4=.edf0b389-21d9-40b3-bb92-0b9645bcb469@github.com>
Message-ID: <oG55wEcyBzYm-O1iJ8B6Q9ivQlE3cv_S2u4ZocqOS-o=.f2b596bd-9053-45e3-82f0-8ff70431ec05@github.com>

On Fri, 22 Jul 2022 10:22:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hi Valerie that sounds like a good idea, I adjusted the PR .

Have you verified the new output and see if it addresses your need? I will also run the regression tests just to be safe. Thanks~

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

PR: https://git.openjdk.org/jdk/pull/9555

From valeriep at openjdk.org  Mon Jul 25 21:33:09 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Mon, 25 Jul 2022 21:33:09 GMT
Subject: RFR: JDK-8290532: Adjust PKCS11Exception and handle more PKCS11
 error codes [v2]
In-Reply-To: <rGcN9Uh7tBrYgWvbUVtwRVt8XY1_IDMc65ud_AOHmc4=.401c70e1-363f-4241-8802-df5c0e6f4388@github.com>
References: <kccdSpgGrSgPAyqLQNOGBo7QqMF-hxiHfc_rO9X-sL8=.f56646dd-d135-4f1a-85fb-34bcfdcc648e@github.com>
 <rGcN9Uh7tBrYgWvbUVtwRVt8XY1_IDMc65ud_AOHmc4=.401c70e1-363f-4241-8802-df5c0e6f4388@github.com>
Message-ID: <dg6JnYOi9VgZK1jDtQd0QwIOXi5kFABuS5hKoqo5ec8=.05335669-534f-4ae0-a790-b2dd143075e4@github.com>

On Fri, 22 Jul 2022 10:22:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The issue https://bugs.openjdk.org/browse/JDK-8282538 gave an example of the following PKCS11 exception (see attached jtr files of that bug) :
>> 
>> .... Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: 0xCE534351
>> 
>> Unfortunately the error code 0xCE534351 is currently not in the RV/errorMap table of PKCS11Exception, That's why we get this
>> hex code and no more descriptive output, this could be improved.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do not add the deprecated CKR_COPY_PROHIBITED, handle vendor pkcs11 error codes differently

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java line 206:

> 204:         // potential matches
> 205:         if ((errorCode & 0x80000000L) != 0) {
> 206:             // for unknown PKCS11 return values, just use hex as its string

nit: dup with line 201; can be removed.

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

PR: https://git.openjdk.org/jdk/pull/9555

From mullan at openjdk.org  Tue Jul 26 13:50:02 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 26 Jul 2022 13:50:02 GMT
Subject: RFR: JDK-8290887 Unused private method in TrustManagerFactoryImpl
In-Reply-To: <uZaz0EIJDmhZo5L-hqp5n7GUyMCDGkhYrBqUj-GqFqc=.9980d8d1-1b63-4957-bde2-feaa64e2b9f4@github.com>
References: <uZaz0EIJDmhZo5L-hqp5n7GUyMCDGkhYrBqUj-GqFqc=.9980d8d1-1b63-4957-bde2-feaa64e2b9f4@github.com>
Message-ID: <IzoVPYDuZQJoi53nVFxgQHpYtMJAmE9Br5Wnk7cmeUM=.e430a3b8-33a0-4465-8a1e-f00ea0a71ac4@github.com>

On Fri, 22 Jul 2022 17:59:51 GMT, Mark Powers <duke at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8290887

src/java.base/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java line 108:

> 106:     }
> 107: 
> 108:     /*

I think you can also remove the `import java.io.*` on line 28 now that this block of code has been removed.

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

PR: https://git.openjdk.org/jdk/pull/9616

From mullan at openjdk.org  Tue Jul 26 13:56:28 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 26 Jul 2022 13:56:28 GMT
Subject: RFR: 8290669: Fix wording in sun.security.ec
In-Reply-To: <k9rQZLuJplCS6F4sYk_4Vwbraicv7UZdHMn5KsKLAtY=.f4c865d4-4490-436e-b78f-cab012bda6c4@github.com>
References: <k9rQZLuJplCS6F4sYk_4Vwbraicv7UZdHMn5KsKLAtY=.f4c865d4-4490-436e-b78f-cab012bda6c4@github.com>
Message-ID: <TUHEe7umTpk9r9v5dXqpn43N1DycOTvmAbPre3kEw_A=.cc61eb5b-dad4-49eb-a614-1933075a5d87@github.com>

On Fri, 22 Jul 2022 02:15:44 GMT, longxu0509 <duke at openjdk.org> wrote:

> this patch fixes several wording in sun.security.ec

Marked as reviewed by mullan (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9606

From mullan at openjdk.org  Tue Jul 26 14:00:58 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 26 Jul 2022 14:00:58 GMT
Subject: RFR: 8290669: Fix wording in sun.security.ec
In-Reply-To: <k9rQZLuJplCS6F4sYk_4Vwbraicv7UZdHMn5KsKLAtY=.f4c865d4-4490-436e-b78f-cab012bda6c4@github.com>
References: <k9rQZLuJplCS6F4sYk_4Vwbraicv7UZdHMn5KsKLAtY=.f4c865d4-4490-436e-b78f-cab012bda6c4@github.com>
Message-ID: <60b8I142TY0bz4miGtpJ39OkAvH_JFdpeiQPhxsPViU=.da273579-baa1-4dcb-863e-d673dd20b187@github.com>

On Fri, 22 Jul 2022 02:15:44 GMT, longxu0509 <duke at openjdk.org> wrote:

> this patch fixes several wording in sun.security.ec

I think "noreg-trivial" is a more appropriate label for this bug than "noreg-cleanup". "noreg-cleanup", as defined in the [OpenJDK Developer's Guide](https://openjdk.org/guide/) is:

"Change is a cleanup or refactoring of existing code that is covered by existing tests."

This fixes typos and removes one commented-out line, so it isn't changing any real code.

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

PR: https://git.openjdk.org/jdk/pull/9606

From jjiang at openjdk.org  Tue Jul 26 14:18:43 2022
From: jjiang at openjdk.org (John Jiang)
Date: Tue, 26 Jul 2022 14:18:43 GMT
Subject: RFR: 8290669: Fix wording in sun.security.ec
In-Reply-To: <k9rQZLuJplCS6F4sYk_4Vwbraicv7UZdHMn5KsKLAtY=.f4c865d4-4490-436e-b78f-cab012bda6c4@github.com>
References: <k9rQZLuJplCS6F4sYk_4Vwbraicv7UZdHMn5KsKLAtY=.f4c865d4-4490-436e-b78f-cab012bda6c4@github.com>
Message-ID: <NSba9X1f5msk7GorSF6smSi7Uyi8Ombvjrv7eLhNHvs=.a379b04e-6b98-4615-a34f-241faea1a82e@github.com>

On Fri, 22 Jul 2022 02:15:44 GMT, longxu0509 <duke at openjdk.org> wrote:

> this patch fixes several wording in sun.security.ec

Just changed the label in this JBS.
Thanks!

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

PR: https://git.openjdk.org/jdk/pull/9606

From duke at openjdk.org  Tue Jul 26 15:09:49 2022
From: duke at openjdk.org (longxu0509)
Date: Tue, 26 Jul 2022 15:09:49 GMT
Subject: Integrated: 8290669: Fix wording in sun.security.ec
In-Reply-To: <k9rQZLuJplCS6F4sYk_4Vwbraicv7UZdHMn5KsKLAtY=.f4c865d4-4490-436e-b78f-cab012bda6c4@github.com>
References: <k9rQZLuJplCS6F4sYk_4Vwbraicv7UZdHMn5KsKLAtY=.f4c865d4-4490-436e-b78f-cab012bda6c4@github.com>
Message-ID: <ioMejSECUNeD23RtGugFNYXA4N9cu54KjEYdjlJwPd0=.3f94e341-49a6-42cc-8472-17e22176aae7@github.com>

On Fri, 22 Jul 2022 02:15:44 GMT, longxu0509 <duke at openjdk.org> wrote:

> this patch fixes several wording in sun.security.ec

This pull request has now been integrated.

Changeset: 2ae8e311
Author:    longxu0509 <longxu at mail.ustc.edu.cn>
Committer: John Jiang <jjiang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2ae8e3118385bdf93c50bca550334734b69bc2b6
Stats:     3 lines in 3 files changed: 0 ins; 1 del; 2 mod

8290669: Fix wording in sun.security.ec

Reviewed-by: mullan

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

PR: https://git.openjdk.org/jdk/pull/9606

From duke at openjdk.org  Tue Jul 26 15:10:15 2022
From: duke at openjdk.org (Mark Powers)
Date: Tue, 26 Jul 2022 15:10:15 GMT
Subject: RFR: JDK-8290887 Unused private method in TrustManagerFactoryImpl
 [v2]
In-Reply-To: <uZaz0EIJDmhZo5L-hqp5n7GUyMCDGkhYrBqUj-GqFqc=.9980d8d1-1b63-4957-bde2-feaa64e2b9f4@github.com>
References: <uZaz0EIJDmhZo5L-hqp5n7GUyMCDGkhYrBqUj-GqFqc=.9980d8d1-1b63-4957-bde2-feaa64e2b9f4@github.com>
Message-ID: <_TcdnXeYT0UwKXi0VSzCRp2lErEYADXlSbmtPL6Pox4=.6a9dc795-ae82-4cc2-a163-0064a96ec100@github.com>

> https://bugs.openjdk.org/browse/JDK-8290887

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

  second iteration

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9616/files
  - new: https://git.openjdk.org/jdk/pull/9616/files/6d466322..c57bf5c9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9616&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9616&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/9616

From mullan at openjdk.org  Tue Jul 26 15:10:16 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 26 Jul 2022 15:10:16 GMT
Subject: RFR: JDK-8290887 Unused private method in TrustManagerFactoryImpl
 [v2]
In-Reply-To: <_TcdnXeYT0UwKXi0VSzCRp2lErEYADXlSbmtPL6Pox4=.6a9dc795-ae82-4cc2-a163-0064a96ec100@github.com>
References: <uZaz0EIJDmhZo5L-hqp5n7GUyMCDGkhYrBqUj-GqFqc=.9980d8d1-1b63-4957-bde2-feaa64e2b9f4@github.com>
 <_TcdnXeYT0UwKXi0VSzCRp2lErEYADXlSbmtPL6Pox4=.6a9dc795-ae82-4cc2-a163-0064a96ec100@github.com>
Message-ID: <JHo3KCMn0nU4PdB-uX6GnixM2b7wCOl0X-sK-mL74lw=.02843de6-89c0-407c-a64a-6048dcfd6f83@github.com>

On Tue, 26 Jul 2022 15:07:03 GMT, Mark Powers <duke at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8290887
>
> Mark Powers has updated the pull request incrementally with one additional commit since the last revision:
> 
>   second iteration

Marked as reviewed by mullan (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9616

From achung at openjdk.org  Tue Jul 26 18:34:58 2022
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 26 Jul 2022 18:34:58 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update -
 msgdrop 10
In-Reply-To: <1Ziaq5GCAhIwzw1n5Vex22mK_sBGUknmSn_0xsxlysE=.87eb8ad1-7e05-458f-ba04-25fcfce81fc8@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
 <1Ziaq5GCAhIwzw1n5Vex22mK_sBGUknmSn_0xsxlysE=.87eb8ad1-7e05-458f-ba04-25fcfce81fc8@github.com>
Message-ID: <C1YU7iK0K6YjRCepyBlgesZDowUHqG11k9-7EuUwrlo=.fabcf888-a415-47c3-bdc2-2cf37684108b@github.com>

On Mon, 25 Jul 2022 18:48:25 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Why `MSG_Help_mac_launcher` in [src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_de.properties](https://github.com/openjdk/jdk19/pull/154/files#diff-2e1b121e201e1040827d5b68ebdd852615e611904db783806a753dc6980e97fa) is left not localized? Is it intended to be localized in the next drop?

Probably will be left for next drop

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

PR: https://git.openjdk.org/jdk19/pull/154

From achung at openjdk.org  Tue Jul 26 20:24:14 2022
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 26 Jul 2022 20:24:14 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update -
 msgdrop 10 [v2]
In-Reply-To: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
Message-ID: <dZ3e2I9I68fQ6AR4dLBeLnXlwgYejqstcByber6aIBs=.bae6a5fa-59be-4fea-b44d-1cdde31ee22b@github.com>

> open l10n msg drop
> All tests passed.

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

  merged currencyname property files into localedata

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/154/files
  - new: https://git.openjdk.org/jdk19/pull/154/files/334f4c76..7ab703ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk19&pr=154&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=154&range=00-01

  Stats: 1540 lines in 7 files changed: 3 ins; 1534 del; 3 mod
  Patch: https://git.openjdk.org/jdk19/pull/154.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/154/head:pull/154

PR: https://git.openjdk.org/jdk19/pull/154

From duke at openjdk.org  Tue Jul 26 20:26:41 2022
From: duke at openjdk.org (Mark Powers)
Date: Tue, 26 Jul 2022 20:26:41 GMT
Subject: Integrated: JDK-8290887 Unused private method in
 TrustManagerFactoryImpl
In-Reply-To: <uZaz0EIJDmhZo5L-hqp5n7GUyMCDGkhYrBqUj-GqFqc=.9980d8d1-1b63-4957-bde2-feaa64e2b9f4@github.com>
References: <uZaz0EIJDmhZo5L-hqp5n7GUyMCDGkhYrBqUj-GqFqc=.9980d8d1-1b63-4957-bde2-feaa64e2b9f4@github.com>
Message-ID: <luyKM_Xi3AzHZRfy9eenpixnqMaQBCsb-b2KP0ROMrQ=.08e5b5a5-d131-41f3-aa9f-9d3b19308185@github.com>

On Fri, 22 Jul 2022 17:59:51 GMT, Mark Powers <duke at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8290887

This pull request has now been integrated.

Changeset: 4d796ee8
Author:    Mark Powers <mark.powers at oracle.com>
Committer: Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4d796ee8abd4eabc5d5d3034f236e8f4289ca048
Stats:     27 lines in 1 file changed: 0 ins; 25 del; 2 mod

8290887: Unused private method in TrustManagerFactoryImpl

Reviewed-by: weijun, xuelei, mullan

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

PR: https://git.openjdk.org/jdk/pull/9616

From achung at openjdk.org  Tue Jul 26 20:31:44 2022
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 26 Jul 2022 20:31:44 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
Message-ID: <kyU6nIIGoMX_otMTj_M8I7RVJwm85FOaTi05QHsi1nM=.2d4a5ec1-411f-4eaa-9def-b0b7239e632c@github.com>

> open l10n msg drop
> All tests passed.

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

  removed localized files from base

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/154/files
  - new: https://git.openjdk.org/jdk19/pull/154/files/7ab703ed..6776bd0f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk19&pr=154&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=154&range=01-02

  Stats: 1722 lines in 3 files changed: 0 ins; 1722 del; 0 mod
  Patch: https://git.openjdk.org/jdk19/pull/154.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/154/head:pull/154

PR: https://git.openjdk.org/jdk19/pull/154

From mbaesken at openjdk.org  Wed Jul 27 11:40:02 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 27 Jul 2022 11:40:02 GMT
Subject: RFR: JDK-8290532: Adjust PKCS11Exception and handle more PKCS11
 error codes [v3]
In-Reply-To: <kccdSpgGrSgPAyqLQNOGBo7QqMF-hxiHfc_rO9X-sL8=.f56646dd-d135-4f1a-85fb-34bcfdcc648e@github.com>
References: <kccdSpgGrSgPAyqLQNOGBo7QqMF-hxiHfc_rO9X-sL8=.f56646dd-d135-4f1a-85fb-34bcfdcc648e@github.com>
Message-ID: <2zX1DXvqDHadZPNmpgThKwWwchyI77IuDN64kdZWNbw=.11ca953d-bbc7-43c8-9aac-972b7e2d2fb1@github.com>

> The issue https://bugs.openjdk.org/browse/JDK-8282538 gave an example of the following PKCS11 exception (see attached jtr files of that bug) :
> 
> .... Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: 0xCE534351
> 
> Unfortunately the error code 0xCE534351 is currently not in the RV/errorMap table of PKCS11Exception, That's why we get this
> hex code and no more descriptive output, this could be improved.

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

  Small adjustments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9555/files
  - new: https://git.openjdk.org/jdk/pull/9555/files/f0fc6d73..85e2648d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9555&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9555&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/9555

From mbaesken at openjdk.org  Wed Jul 27 11:44:58 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 27 Jul 2022 11:44:58 GMT
Subject: RFR: JDK-8290532: Adjust PKCS11Exception and handle more PKCS11
 error codes [v2]
In-Reply-To: <dg6JnYOi9VgZK1jDtQd0QwIOXi5kFABuS5hKoqo5ec8=.05335669-534f-4ae0-a790-b2dd143075e4@github.com>
References: <kccdSpgGrSgPAyqLQNOGBo7QqMF-hxiHfc_rO9X-sL8=.f56646dd-d135-4f1a-85fb-34bcfdcc648e@github.com>
 <rGcN9Uh7tBrYgWvbUVtwRVt8XY1_IDMc65ud_AOHmc4=.401c70e1-363f-4241-8802-df5c0e6f4388@github.com>
 <dg6JnYOi9VgZK1jDtQd0QwIOXi5kFABuS5hKoqo5ec8=.05335669-534f-4ae0-a790-b2dd143075e4@github.com>
Message-ID: <_-USsCrzCi4aKPPB5Onnuo93iAClVeWZPn4zDXJMSw8=.45035cb4-3f17-4668-a7d3-f34803a5d6a2@github.com>

On Mon, 25 Jul 2022 21:27:34 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   do not add the deprecated CKR_COPY_PROHIBITED, handle vendor pkcs11 error codes differently
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java line 206:
> 
>> 204:         // potential matches
>> 205:         if ((errorCode & 0x80000000L) != 0) {
>> 206:             // for unknown PKCS11 return values, just use hex as its string
> 
> nit: dup with line 201; can be removed.

Hi Valerie I removed the comment line, also removed the '(' ')' at one place where they seem to be not needed.
Regarding "adresses the new output my needs" - ideally I would like to see some error text like the ones we find at http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html  where the eror codes are explained.
But adding the (I think rather common) vendor errors is an improvement.

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

PR: https://git.openjdk.org/jdk/pull/9555

From valeriep at openjdk.org  Wed Jul 27 17:02:41 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 27 Jul 2022 17:02:41 GMT
Subject: RFR: JDK-8290532: Adjust PKCS11Exception and handle more PKCS11
 error codes [v3]
In-Reply-To: <2zX1DXvqDHadZPNmpgThKwWwchyI77IuDN64kdZWNbw=.11ca953d-bbc7-43c8-9aac-972b7e2d2fb1@github.com>
References: <kccdSpgGrSgPAyqLQNOGBo7QqMF-hxiHfc_rO9X-sL8=.f56646dd-d135-4f1a-85fb-34bcfdcc648e@github.com>
 <2zX1DXvqDHadZPNmpgThKwWwchyI77IuDN64kdZWNbw=.11ca953d-bbc7-43c8-9aac-972b7e2d2fb1@github.com>
Message-ID: <QR48nqTpAojnED4XA1arw7BjiKFoa4EZ51Zu9UuvgZ8=.c936a767-926b-49e2-ae86-f45a0b9e52f6@github.com>

On Wed, 27 Jul 2022 11:40:02 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The issue https://bugs.openjdk.org/browse/JDK-8282538 gave an example of the following PKCS11 exception (see attached jtr files of that bug) :
>> 
>> .... Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: 0xCE534351
>> 
>> Unfortunately the error code 0xCE534351 is currently not in the RV/errorMap table of PKCS11Exception, That's why we get this
>> hex code and no more descriptive output, this could be improved.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small adjustments

Marked as reviewed by valeriep (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9555

From valeriep at openjdk.org  Wed Jul 27 17:02:42 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Wed, 27 Jul 2022 17:02:42 GMT
Subject: RFR: JDK-8290532: Adjust PKCS11Exception and handle more PKCS11
 error codes [v2]
In-Reply-To: <_-USsCrzCi4aKPPB5Onnuo93iAClVeWZPn4zDXJMSw8=.45035cb4-3f17-4668-a7d3-f34803a5d6a2@github.com>
References: <kccdSpgGrSgPAyqLQNOGBo7QqMF-hxiHfc_rO9X-sL8=.f56646dd-d135-4f1a-85fb-34bcfdcc648e@github.com>
 <rGcN9Uh7tBrYgWvbUVtwRVt8XY1_IDMc65ud_AOHmc4=.401c70e1-363f-4241-8802-df5c0e6f4388@github.com>
 <dg6JnYOi9VgZK1jDtQd0QwIOXi5kFABuS5hKoqo5ec8=.05335669-534f-4ae0-a790-b2dd143075e4@github.com>
 <_-USsCrzCi4aKPPB5Onnuo93iAClVeWZPn4zDXJMSw8=.45035cb4-3f17-4668-a7d3-f34803a5d6a2@github.com>
Message-ID: <XHErTZhhP_cShiqtGSiYDQM73SU538wRBPSQ7oVHncI=.b1040c13-3237-4706-80cc-79d635c5b90c@github.com>

On Wed, 27 Jul 2022 11:41:07 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java line 206:
>> 
>>> 204:         // potential matches
>>> 205:         if ((errorCode & 0x80000000L) != 0) {
>>> 206:             // for unknown PKCS11 return values, just use hex as its string
>> 
>> nit: dup with line 201; can be removed.
>
> Hi Valerie I removed the comment line, also removed the '(' ')' at one place where they seem to be not needed.
> Regarding "adresses the new output my needs" - ideally I would like to see some error text like the ones we find at http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html  where the eror codes are explained.
> But adding the (I think rather common) vendor errors is an improvement.

For standard errors (except the deprecated one), the output is their name (e.g. CKR_xxx) instead of the value (0xABxxx hex). Vendor error code is vendor specific. It'd be nice if PKCS#11 API would provide an method for retrieving a String info based on error code, then callers won't have to refer to vendor's doc for the meaning.

Changes look good to me. Test result looks clean too.

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

PR: https://git.openjdk.org/jdk/pull/9555

From weijun at openjdk.org  Wed Jul 27 23:07:57 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 27 Jul 2022 23:07:57 GMT
Subject: RFR: 6587699: Document DigestInputStream behavior when skip() or
 mark() / reset() is used
Message-ID: <5Rr8LpWgPXGH3WACAg_ha6cSlWTpJgDAIRzTna5XPew=.e6ae100d-2714-402d-b25c-1dacf9553941@github.com>

Add an `@implNote` to clarify the behavior when these methods are called. A new test is added.

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

Commit messages:
 - the implNote and new test

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

PR: https://git.openjdk.org/jdk/pull/9667

From wetmore at openjdk.org  Thu Jul 28 00:02:06 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 28 Jul 2022 00:02:06 GMT
Subject: RFR: 6383195: javax.crypto.spec.PBEKeySpec is not thread safe
Message-ID: <3YBCQsXxW5zVSuPhGYoGHiPtCYYdGkrTDxT_pGXXBA0=.38376a3f-ae2d-4fa5-afc1-0d4c3ac9f136@github.com>

Simple fix to a long-standing threading bug to help clear the backlog.

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

Commit messages:
 - 6383195: javax.crypto.spec.PBEKeySpec is not thread safe

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

PR: https://git.openjdk.org/jdk/pull/9668

From wetmore at openjdk.org  Thu Jul 28 01:01:36 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 28 Jul 2022 01:01:36 GMT
Subject: RFR: 6587699: Document DigestInputStream behavior when skip() or
 mark() / reset() is used
In-Reply-To: <5Rr8LpWgPXGH3WACAg_ha6cSlWTpJgDAIRzTna5XPew=.e6ae100d-2714-402d-b25c-1dacf9553941@github.com>
References: <5Rr8LpWgPXGH3WACAg_ha6cSlWTpJgDAIRzTna5XPew=.e6ae100d-2714-402d-b25c-1dacf9553941@github.com>
Message-ID: <4BINwMEZfOOHqHCMa4q4W6S7yO1Z83bugClNiONstzc=.c33d8a7b-baaa-40c1-a96b-e7da224b7067@github.com>

On Wed, 27 Jul 2022 23:02:03 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add an `@implNote` to clarify the behavior when these methods are called. A new test is added.

Be sure to update the commit message.  :)  

Hope to look at the rest later.

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

PR: https://git.openjdk.org/jdk/pull/9667

From wetmore at openjdk.org  Thu Jul 28 01:11:18 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 28 Jul 2022 01:11:18 GMT
Subject: RFR: 6587699: Document DigestInputStream behavior when skip() or
 mark() / reset() is used
In-Reply-To: <5Rr8LpWgPXGH3WACAg_ha6cSlWTpJgDAIRzTna5XPew=.e6ae100d-2714-402d-b25c-1dacf9553941@github.com>
References: <5Rr8LpWgPXGH3WACAg_ha6cSlWTpJgDAIRzTna5XPew=.e6ae100d-2714-402d-b25c-1dacf9553941@github.com>
Message-ID: <q6S6d0WFdOO-8XQulhNYJk07RO9NkKqGKa8oaIKv0GI=.69a9f785-d8b5-4dc4-b2dc-db209a170ae1@github.com>

On Wed, 27 Jul 2022 23:02:03 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> Add an `@implNote` to clarify the behavior when these methods are called. A new test is added.

I'll approve this after CSR is approved.

src/java.base/share/classes/java/security/DigestInputStream.java line 54:

> 52:  * digest to be computed, leaving the original digest untouched.
> 53:  *
> 54:  * @implNote This implementation updates and only updates the message digest

The "updates and only updates" feel awkward.  Maybe just the one mention of update?

src/java.base/share/classes/java/security/DigestInputStream.java line 55:

> 53:  *
> 54:  * @implNote This implementation updates and only updates the message digest
> 55:  *      with data actually read from the input stream when it is turned on.

"when it is turned on"?  You could probably just end with "actually read from the input stream."

src/java.base/share/classes/java/security/DigestInputStream.java line 56:

> 54:  * @implNote This implementation updates and only updates the message digest
> 55:  *      with data actually read from the input stream when it is turned on.
> 56:  *      This includes various {@code read} methods, {@code transferTo},

includes the various

src/java.base/share/classes/java/security/DigestInputStream.java line 57:

> 55:  *      with data actually read from the input stream when it is turned on.
> 56:  *      This includes various {@code read} methods, {@code transferTo},
> 57:  *      {@code readAllBytes}, and {@code readNBytes}. Specifically, data

Specifically
->
Additionally ?

test/jdk/java/security/DigestInputStream/TestSkipAndReset.java line 62:

> 60: 
> 61:         byte[] hash = md.digest();
> 62:         byte[] directHash = md.digest("1267967889090".getBytes(StandardCharsets.UTF_8));

Very clear test, thank you.

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

PR: https://git.openjdk.org/jdk/pull/9667

From weijun at openjdk.org  Thu Jul 28 01:30:28 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 28 Jul 2022 01:30:28 GMT
Subject: RFR: 6587699: Document DigestInputStream behavior when skip() or
 mark() / reset() is used
In-Reply-To: <q6S6d0WFdOO-8XQulhNYJk07RO9NkKqGKa8oaIKv0GI=.69a9f785-d8b5-4dc4-b2dc-db209a170ae1@github.com>
References: <5Rr8LpWgPXGH3WACAg_ha6cSlWTpJgDAIRzTna5XPew=.e6ae100d-2714-402d-b25c-1dacf9553941@github.com>
 <q6S6d0WFdOO-8XQulhNYJk07RO9NkKqGKa8oaIKv0GI=.69a9f785-d8b5-4dc4-b2dc-db209a170ae1@github.com>
Message-ID: <py14buscs_MxG_izUqG2vN7X-b9_lzy6o_4tbDYOgWo=.56656bc0-23e8-43e8-86a7-b109200d2964@github.com>

On Thu, 28 Jul 2022 01:09:13 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> I'll approve this after CSR is approved.

Can you approve the PR when you're OK with the text? Unless the CSR is approved I won't be able to integrate it anyway. I usually wait for the PR to be approved first before writing the CSR so I don't need to update text on both sides.

> src/java.base/share/classes/java/security/DigestInputStream.java line 54:
> 
>> 52:  * digest to be computed, leaving the original digest untouched.
>> 53:  *
>> 54:  * @implNote This implementation updates and only updates the message digest
> 
> The "updates and only updates" feel awkward.  Maybe just the one mention of update?

I'm using the "if and only if" style, which means other non-read methods will not update the message digest.

> src/java.base/share/classes/java/security/DigestInputStream.java line 55:
> 
>> 53:  *
>> 54:  * @implNote This implementation updates and only updates the message digest
>> 55:  *      with data actually read from the input stream when it is turned on.
> 
> "when it is turned on"?  You could probably just end with "actually read from the input stream."

This is about the `on(boolean)` method. I just want to be precise.

> src/java.base/share/classes/java/security/DigestInputStream.java line 57:
> 
>> 55:  *      with data actually read from the input stream when it is turned on.
>> 56:  *      This includes various {@code read} methods, {@code transferTo},
>> 57:  *      {@code readAllBytes}, and {@code readNBytes}. Specifically, data
> 
> Specifically
> ->
> Additionally ?

Maybe I should use "especially". This is not "additionally" because `skip` is not one of these "read"-methods.

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

PR: https://git.openjdk.org/jdk/pull/9667

From weijun at openjdk.org  Thu Jul 28 01:37:07 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 28 Jul 2022 01:37:07 GMT
Subject: RFR: 6587699: Document DigestInputStream behavior when skip() or
 mark() / reset() is used [v2]
In-Reply-To: <5Rr8LpWgPXGH3WACAg_ha6cSlWTpJgDAIRzTna5XPew=.e6ae100d-2714-402d-b25c-1dacf9553941@github.com>
References: <5Rr8LpWgPXGH3WACAg_ha6cSlWTpJgDAIRzTna5XPew=.e6ae100d-2714-402d-b25c-1dacf9553941@github.com>
Message-ID: <SQOz3WH9qvo0msR74tjvQjaxqNOc67QfzuD95KHb9jE=.aca4d886-dc71-45ef-b977-4ebdde36b2af@github.com>

> Add an `@implNote` to clarify the behavior when these methods are called. A new test is added.

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

  Brad comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9667/files
  - new: https://git.openjdk.org/jdk/pull/9667/files/41aa7d22..a6304352

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9667&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9667&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/9667

From weijun at openjdk.org  Thu Jul 28 01:37:08 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 28 Jul 2022 01:37:08 GMT
Subject: RFR: 6587699: Document DigestInputStream behavior when skip() or
 mark() / reset() is used
In-Reply-To: <4BINwMEZfOOHqHCMa4q4W6S7yO1Z83bugClNiONstzc=.c33d8a7b-baaa-40c1-a96b-e7da224b7067@github.com>
References: <5Rr8LpWgPXGH3WACAg_ha6cSlWTpJgDAIRzTna5XPew=.e6ae100d-2714-402d-b25c-1dacf9553941@github.com>
 <4BINwMEZfOOHqHCMa4q4W6S7yO1Z83bugClNiONstzc=.c33d8a7b-baaa-40c1-a96b-e7da224b7067@github.com>
Message-ID: <mnArJsqwkju6Hhe5Q2L6maY_K3yfgvBxgN2tsjHcMTY=.7dc95b62-35e8-4afa-8e12-50779f46db1d@github.com>

On Thu, 28 Jul 2022 00:57:54 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> Be sure to update the commit message. :)

I think there is no need to use the bug description as the commit message, and I usually just use "the fix" as the commit message for the 1st commit.

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

PR: https://git.openjdk.org/jdk/pull/9667

From weijun at openjdk.org  Thu Jul 28 01:45:05 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 28 Jul 2022 01:45:05 GMT
Subject: RFR: 6383195: javax.crypto.spec.PBEKeySpec is not thread safe
In-Reply-To: <3YBCQsXxW5zVSuPhGYoGHiPtCYYdGkrTDxT_pGXXBA0=.38376a3f-ae2d-4fa5-afc1-0d4c3ac9f136@github.com>
References: <3YBCQsXxW5zVSuPhGYoGHiPtCYYdGkrTDxT_pGXXBA0=.38376a3f-ae2d-4fa5-afc1-0d4c3ac9f136@github.com>
Message-ID: <GfFtq9GJY3E5VdNMVmtTxOKXkIKD5C521VlGZjCLqL4=.c65032e6-a11b-45d1-a981-864e32e0d676@github.com>

On Wed, 27 Jul 2022 23:53:53 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> Simple fix to a long-standing threading bug to help clear the bug backlog.  
> 
> Without the synchronized, the test case fails almost immediately.  
> 
> Running JPRT with tier1/tier2.

LGTM.

BTW, how often can you observe a test failure before the code change?

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

Marked as reviewed by weijun (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9668

From wetmore at openjdk.org  Thu Jul 28 05:34:37 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 28 Jul 2022 05:34:37 GMT
Subject: RFR: 6383195: javax.crypto.spec.PBEKeySpec is not thread safe
In-Reply-To: <GfFtq9GJY3E5VdNMVmtTxOKXkIKD5C521VlGZjCLqL4=.c65032e6-a11b-45d1-a981-864e32e0d676@github.com>
References: <3YBCQsXxW5zVSuPhGYoGHiPtCYYdGkrTDxT_pGXXBA0=.38376a3f-ae2d-4fa5-afc1-0d4c3ac9f136@github.com>
 <GfFtq9GJY3E5VdNMVmtTxOKXkIKD5C521VlGZjCLqL4=.c65032e6-a11b-45d1-a981-864e32e0d676@github.com>
Message-ID: <U6_y21OZDoTxhmWInrhhwEz2115xMt7JDb7E3Qd-x64=.48445120-2868-428e-8119-840106865b22@github.com>

On Thu, 28 Jul 2022 01:42:23 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> BTW, how often can you observe a test failure before the code change?

Third time through the loop.


Testing: 
...
java.lang.RuntimeException: Inconsistent Password: 
	at PBEKeySpecRacing.lambda$main$0(PBEKeySpecRacing.java:61)
	at java.base/java.lang.Thread.run(Thread.java:1589)

I have one more tweak to make, will come back to this soon.

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

PR: https://git.openjdk.org/jdk/pull/9668

From mbaesken at openjdk.org  Thu Jul 28 07:34:27 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 28 Jul 2022 07:34:27 GMT
Subject: Integrated: JDK-8290532: Adjust PKCS11Exception and handle more PKCS11
 error codes
In-Reply-To: <kccdSpgGrSgPAyqLQNOGBo7QqMF-hxiHfc_rO9X-sL8=.f56646dd-d135-4f1a-85fb-34bcfdcc648e@github.com>
References: <kccdSpgGrSgPAyqLQNOGBo7QqMF-hxiHfc_rO9X-sL8=.f56646dd-d135-4f1a-85fb-34bcfdcc648e@github.com>
Message-ID: <PyU3nPN44B27C-Edq6WNcAIw3ySOpdGOozD-wTsCa1o=.d81a5f44-f7a9-4465-a55c-f4697f5316bc@github.com>

On Tue, 19 Jul 2022 13:14:17 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The issue https://bugs.openjdk.org/browse/JDK-8282538 gave an example of the following PKCS11 exception (see attached jtr files of that bug) :
> 
> .... Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: 0xCE534351
> 
> Unfortunately the error code 0xCE534351 is currently not in the RV/errorMap table of PKCS11Exception, That's why we get this
> hex code and no more descriptive output, this could be improved.

This pull request has now been integrated.

Changeset: 07f0612c
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/07f0612c9aa5641491516d9a0232392689d4c1ca
Stats:     25 lines in 1 file changed: 23 ins; 0 del; 2 mod

8290532: Adjust PKCS11Exception and handle more PKCS11 error codes

Reviewed-by: valeriep

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

PR: https://git.openjdk.org/jdk/pull/9555

From duke at openjdk.org  Thu Jul 28 14:37:43 2022
From: duke at openjdk.org (Mark Powers)
Date: Thu, 28 Jul 2022 14:37:43 GMT
Subject: RFR: JDK-8290975 Minor cleanup could be done in javax.security
Message-ID: <2RBSv8jeaBNPPQOpfGTnF0E80N4RrjKtoyuDkBNOt9w=.506f1854-e1bc-481a-9d64-8cbb593a330d@github.com>

https://bugs.openjdk.org/browse/JDK-8290975

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

Commit messages:
 - second iteration
 - first iteration

Changes: https://git.openjdk.org/jdk/pull/9664/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9664&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290975
  Stats: 125 lines in 16 files changed: 7 ins; 24 del; 94 mod
  Patch: https://git.openjdk.org/jdk/pull/9664.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9664/head:pull/9664

PR: https://git.openjdk.org/jdk/pull/9664

From jwaters at openjdk.org  Thu Jul 28 17:33:03 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 28 Jul 2022 17:33:03 GMT
Subject: RFR: 8291511: Redefinition of EXIT_FAILURE in libw2k_lsa_auth
Message-ID: <OUJtJIfd6HKYkMR-BwleAwsGf9rha8s7DRhxpEnpWBQ=.acd5c631-537d-4b27-a454-e16fe414f6e4@github.com>

EXIT_FAILURE is defined as -1 in NativeCreds.c, and is not only unused, but also incorrect, as it incorrectly redefines the existing EXIT_FAILURE, which is actually 1 on Windows, not -1. Can be safely commented out as it isn't used anywhere, except for in a call to ExitProcess which has also been commented out as well.

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

Commit messages:
 - Comment out EXIT_FAILURE redefinition

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

PR: https://git.openjdk.org/jdk/pull/9678

From kdriver at openjdk.org  Thu Jul 28 17:43:04 2022
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 28 Jul 2022 17:43:04 GMT
Subject: RFR: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0
Message-ID: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>

As mentioned in the bug report, this issue *should not* be a framework-level issue, since potentially an individual provider could create a keysize of zero to have a certain significance. 

In the changes made here, the check is for `keysize <= 0` and this message indicates this is a check characteristic to the `SunJCE` provider.

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

Commit messages:
 - update copyrights
 - initial commit

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

PR: https://git.openjdk.org/jdk/pull/9679

From wetmore at openjdk.org  Thu Jul 28 17:43:57 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 28 Jul 2022 17:43:57 GMT
Subject: RFR: 6587699: Document DigestInputStream behavior when skip() or
 mark() / reset() is used [v2]
In-Reply-To: <SQOz3WH9qvo0msR74tjvQjaxqNOc67QfzuD95KHb9jE=.aca4d886-dc71-45ef-b977-4ebdde36b2af@github.com>
References: <5Rr8LpWgPXGH3WACAg_ha6cSlWTpJgDAIRzTna5XPew=.e6ae100d-2714-402d-b25c-1dacf9553941@github.com>
 <SQOz3WH9qvo0msR74tjvQjaxqNOc67QfzuD95KHb9jE=.aca4d886-dc71-45ef-b977-4ebdde36b2af@github.com>
Message-ID: <yHufZW6743mb0TllPiWS12L8bYrMXJ0ZvAOlQy92OWk=.b9471fae-0cd7-4aee-8845-80058bb3c9d5@github.com>

On Thu, 28 Jul 2022 01:37:07 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add an `@implNote` to clarify the behavior when these methods are called. A new test is added.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Brad comment

Take or leave.  

Otherwise LGTM.

src/java.base/share/classes/java/security/DigestInputStream.java line 57:

> 55:  *      with data actually read from the input stream when it is turned on.
> 56:  *      This includes the various {@code read} methods, {@code transferTo},
> 57:  *      {@code readAllBytes}, and {@code readNBytes}. Especially, data

Maybe just "Note" instead of "Especially" (or just remove) as this doesn't seem to be an extra special situation.

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

Marked as reviewed by wetmore (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9667

From wetmore at openjdk.org  Thu Jul 28 17:43:59 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 28 Jul 2022 17:43:59 GMT
Subject: RFR: 6587699: Document DigestInputStream behavior when skip() or
 mark() / reset() is used [v2]
In-Reply-To: <py14buscs_MxG_izUqG2vN7X-b9_lzy6o_4tbDYOgWo=.56656bc0-23e8-43e8-86a7-b109200d2964@github.com>
References: <5Rr8LpWgPXGH3WACAg_ha6cSlWTpJgDAIRzTna5XPew=.e6ae100d-2714-402d-b25c-1dacf9553941@github.com>
 <q6S6d0WFdOO-8XQulhNYJk07RO9NkKqGKa8oaIKv0GI=.69a9f785-d8b5-4dc4-b2dc-db209a170ae1@github.com>
 <py14buscs_MxG_izUqG2vN7X-b9_lzy6o_4tbDYOgWo=.56656bc0-23e8-43e8-86a7-b109200d2964@github.com>
Message-ID: <8l59_UF_KT6ObAk0RlUy7lGfcUOaz5-ZtjgxBUJc1-k=.272bd84a-ca36-415a-bca5-e06a929479d9@github.com>

On Thu, 28 Jul 2022 01:23:12 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/DigestInputStream.java line 54:
>> 
>>> 52:  * digest to be computed, leaving the original digest untouched.
>>> 53:  *
>>> 54:  * @implNote This implementation updates and only updates the message digest
>> 
>> The "updates and only updates" feel awkward.  Maybe just the one mention of update?
>
> I'm using the "if and only if" style, which means other non-read methods will not update the message digest.

My feeling still remains.  I don't recall seeing a wording construction like this except for IFF, which is well-understood.  I think it could be said more compactly with:

`This implementation only updates the message digest with data actually read from the input stream when it is on. `

Just my $0.02.

>> src/java.base/share/classes/java/security/DigestInputStream.java line 55:
>> 
>>> 53:  *
>>> 54:  * @implNote This implementation updates and only updates the message digest
>>> 55:  *      with data actually read from the input stream when it is turned on.
>> 
>> "when it is turned on"?  You could probably just end with "actually read from the input stream."
>
> This is about the `on(boolean)` method. I just want to be precise.

Thanks.  It's been a long time since I've looked at DigestInputStream, forgot about the on/off mode.

>> src/java.base/share/classes/java/security/DigestInputStream.java line 57:
>> 
>>> 55:  *      with data actually read from the input stream when it is turned on.
>>> 56:  *      This includes various {@code read} methods, {@code transferTo},
>>> 57:  *      {@code readAllBytes}, and {@code readNBytes}. Specifically, data
>> 
>> Specifically
>> ->
>> Additionally ?
>
> Maybe I should use "especially". This is not "additionally" because `skip` is not one of these "read"-methods.

I meant additionally as in "here's an additional case to be aware of...", not "this is an additional read case..."

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

PR: https://git.openjdk.org/jdk/pull/9667

From wetmore at openjdk.org  Thu Jul 28 18:06:23 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 28 Jul 2022 18:06:23 GMT
Subject: RFR: 6383195: javax.crypto.spec.PBEKeySpec is not thread safe [v2]
In-Reply-To: <3YBCQsXxW5zVSuPhGYoGHiPtCYYdGkrTDxT_pGXXBA0=.38376a3f-ae2d-4fa5-afc1-0d4c3ac9f136@github.com>
References: <3YBCQsXxW5zVSuPhGYoGHiPtCYYdGkrTDxT_pGXXBA0=.38376a3f-ae2d-4fa5-afc1-0d4c3ac9f136@github.com>
Message-ID: <qnD1ZkeTHtgzgYAS1qRLySn7QwdCN5sl7zLr7yz24KE=.0a9e1732-6258-4db0-b826-7143a733a1af@github.com>

> Simple fix to a long-standing threading bug to help clear the bug backlog.  
> 
> Without the synchronized, the test case fails almost immediately.  
> 
> Running JPRT with tier1/tier2.

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

  Minor update to better note failures

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9668/files
  - new: https://git.openjdk.org/jdk/pull/9668/files/13b296e4..c932188b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9668&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9668&range=00-01

  Stats: 15 lines in 1 file changed: 11 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9668.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9668/head:pull/9668

PR: https://git.openjdk.org/jdk/pull/9668

From duke at openjdk.org  Thu Jul 28 19:07:45 2022
From: duke at openjdk.org (Mark Powers)
Date: Thu, 28 Jul 2022 19:07:45 GMT
Subject: RFR: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0
In-Reply-To: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
References: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
Message-ID: <vaGONCwObyU-Kb8_7_SMwnoBn4uKsI3zB2OjiiDDtBo=.fc4dff17-d2ac-4e9f-9da5-c8d58d2184b2@github.com>

On Thu, 28 Jul 2022 17:32:57 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

> As mentioned in the bug report, this issue *should not* be a framework-level issue, since potentially an individual provider could create a keysize of zero to have a certain significance. 
> 
> In the changes made here, the check is for `keysize <= 0` and this message indicates this is a check characteristic to the `SunJCE` provider.

src/java.base/share/classes/com/sun/crypto/provider/HmacMD5KeyGenerator.java line 92:

> 90:     protected void engineInit(int keysize, SecureRandom random) {
> 91: 
> 92:         if(keysize <= 0) {

Add space after` if`.

src/java.base/share/classes/com/sun/crypto/provider/HmacSHA1KeyGenerator.java line 92:

> 90:     protected void engineInit(int keysize, SecureRandom random) {
> 91: 
> 92:         if(keysize <= 0) {

Space after `if`.

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

PR: https://git.openjdk.org/jdk/pull/9679

From kdriver at openjdk.org  Thu Jul 28 20:02:29 2022
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 28 Jul 2022 20:02:29 GMT
Subject: RFR: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0 [v2]
In-Reply-To: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
References: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
Message-ID: <sNRUCmfD0J-YdmsTHSJE9LpJgRG9jmnK_vXpjcxxtfM=.ef8d33eb-0dbf-4810-bad6-b6a73121d62a@github.com>

> As mentioned in the bug report, this issue *should not* be a framework-level issue, since potentially an individual provider could create a keysize of zero to have a certain significance. 
> 
> In the changes made here, the check is for `keysize <= 0` and this message indicates this is a check characteristic to the `SunJCE` provider.

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

  formatting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9679/files
  - new: https://git.openjdk.org/jdk/pull/9679/files/5e8f1436..f0d0912a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9679&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9679&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/9679

From kdriver at openjdk.org  Thu Jul 28 20:02:33 2022
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 28 Jul 2022 20:02:33 GMT
Subject: RFR: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0 [v2]
In-Reply-To: <vaGONCwObyU-Kb8_7_SMwnoBn4uKsI3zB2OjiiDDtBo=.fc4dff17-d2ac-4e9f-9da5-c8d58d2184b2@github.com>
References: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
 <vaGONCwObyU-Kb8_7_SMwnoBn4uKsI3zB2OjiiDDtBo=.fc4dff17-d2ac-4e9f-9da5-c8d58d2184b2@github.com>
Message-ID: <i6fweuVTXxlpsrHoOfNWvH4OSVeknvpDDxgwNEFM3xA=.b127d097-97a8-4ddf-8a92-5c872b3d5d2b@github.com>

On Thu, 28 Jul 2022 19:03:17 GMT, Mark Powers <duke at openjdk.org> wrote:

>> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   formatting
>
> src/java.base/share/classes/com/sun/crypto/provider/HmacMD5KeyGenerator.java line 92:
> 
>> 90:     protected void engineInit(int keysize, SecureRandom random) {
>> 91: 
>> 92:         if(keysize <= 0) {
> 
> Add space after` if`.

changed.

> src/java.base/share/classes/com/sun/crypto/provider/HmacSHA1KeyGenerator.java line 92:
> 
>> 90:     protected void engineInit(int keysize, SecureRandom random) {
>> 91: 
>> 92:         if(keysize <= 0) {
> 
> Space after `if`.

changed.

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

PR: https://git.openjdk.org/jdk/pull/9679

From wetmore at openjdk.org  Thu Jul 28 20:36:35 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 28 Jul 2022 20:36:35 GMT
Subject: RFR: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0 [v2]
In-Reply-To: <sNRUCmfD0J-YdmsTHSJE9LpJgRG9jmnK_vXpjcxxtfM=.ef8d33eb-0dbf-4810-bad6-b6a73121d62a@github.com>
References: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
 <sNRUCmfD0J-YdmsTHSJE9LpJgRG9jmnK_vXpjcxxtfM=.ef8d33eb-0dbf-4810-bad6-b6a73121d62a@github.com>
Message-ID: <7jPiscIzOR7HKGuxr9xmeFAj7XMQXNipqQw6N1e1qcw=.e3e4b00c-a3d2-48c0-ac3c-64c639b4fa7c@github.com>

On Thu, 28 Jul 2022 20:02:29 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> As mentioned in the bug report, this issue *should not* be a framework-level issue, since potentially an individual provider could create a keysize of zero to have a certain significance. 
>> 
>> In the changes made here, the check is for `keysize <= 0` and this message indicates this is a check characteristic to the `SunJCE` provider.
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   formatting

Needs regression tests.  

Have you looked at the other Key(Pair)Generators?  We've probably added more when this bug was filed.  I took a quick look at some, and they were covered.  (DES/DESede/Blowfish/AES/etc.)

src/java.base/share/classes/com/sun/crypto/provider/HmacMD5KeyGenerator.java line 93:

> 91: 
> 92:         if (keysize <= 0) {
> 93:             throw new IllegalArgumentException("keysize must not be <= 0 for SunJCE");

< 80 chars please

src/java.base/share/classes/com/sun/crypto/provider/HmacSHA1KeyGenerator.java line 93:

> 91: 
> 92:         if (keysize <= 0) {
> 93:             throw new IllegalArgumentException("keysize must not be <= 0 for SunJCE");

Same

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

PR: https://git.openjdk.org/jdk/pull/9679

From naoto at openjdk.org  Thu Jul 28 20:54:21 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 28 Jul 2022 20:54:21 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update -
 msgdrop 10 [v3]
In-Reply-To: <kyU6nIIGoMX_otMTj_M8I7RVJwm85FOaTi05QHsi1nM=.2d4a5ec1-411f-4eaa-9def-b0b7239e632c@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
 <kyU6nIIGoMX_otMTj_M8I7RVJwm85FOaTi05QHsi1nM=.2d4a5ec1-411f-4eaa-9def-b0b7239e632c@github.com>
Message-ID: <bhXKuIFtr_FTB_j6ewaj0WeGlxOXZZVs4tdVq7odvoQ=.3ad74be2-d23d-4140-b706-35c454576231@github.com>

On Tue, 26 Jul 2022 20:31:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> open l10n msg drop
>> All tests passed.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed localized files from base

- src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_en_US.properties: this should not be moved from `java.base` module
- I still need some comments explaining `XXX=XXX` in the root bundle of `CurrencyNames`. Something like 

These currency symbol entries are for the root bundle only to avoid throwing a MissingResourceException. Should not be copied into each localized resource bundle.

src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties line 63:

> 61: # written authorization of the copyright holder.
> 62: 
> 63: CNY=\uffe5

Do not remove the original translation.

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

Changes requested by naoto (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/154

From mullan at openjdk.org  Thu Jul 28 20:58:46 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 28 Jul 2022 20:58:46 GMT
Subject: RFR: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0 [v2]
In-Reply-To: <7jPiscIzOR7HKGuxr9xmeFAj7XMQXNipqQw6N1e1qcw=.e3e4b00c-a3d2-48c0-ac3c-64c639b4fa7c@github.com>
References: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
 <sNRUCmfD0J-YdmsTHSJE9LpJgRG9jmnK_vXpjcxxtfM=.ef8d33eb-0dbf-4810-bad6-b6a73121d62a@github.com>
 <7jPiscIzOR7HKGuxr9xmeFAj7XMQXNipqQw6N1e1qcw=.e3e4b00c-a3d2-48c0-ac3c-64c639b4fa7c@github.com>
Message-ID: <5owFXYA5GNEkIYbiDmsWMy7Txq5_5SLTlwtYlOAMpro=.4910da95-7a56-46a3-a900-3560343b7d62@github.com>

On Thu, 28 Jul 2022 20:24:53 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   formatting
>
> src/java.base/share/classes/com/sun/crypto/provider/HmacMD5KeyGenerator.java line 93:
> 
>> 91: 
>> 92:         if (keysize <= 0) {
>> 93:             throw new IllegalArgumentException("keysize must not be <= 0 for SunJCE");
> 
> < 80 chars please

The "for SunJCE" is odd to see in an exception message, I would leave that out.

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

PR: https://git.openjdk.org/jdk/pull/9679

From mullan at openjdk.org  Thu Jul 28 20:58:46 2022
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 28 Jul 2022 20:58:46 GMT
Subject: RFR: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0 [v2]
In-Reply-To: <5owFXYA5GNEkIYbiDmsWMy7Txq5_5SLTlwtYlOAMpro=.4910da95-7a56-46a3-a900-3560343b7d62@github.com>
References: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
 <sNRUCmfD0J-YdmsTHSJE9LpJgRG9jmnK_vXpjcxxtfM=.ef8d33eb-0dbf-4810-bad6-b6a73121d62a@github.com>
 <7jPiscIzOR7HKGuxr9xmeFAj7XMQXNipqQw6N1e1qcw=.e3e4b00c-a3d2-48c0-ac3c-64c639b4fa7c@github.com>
 <5owFXYA5GNEkIYbiDmsWMy7Txq5_5SLTlwtYlOAMpro=.4910da95-7a56-46a3-a900-3560343b7d62@github.com>
Message-ID: <OOeBubWfgkUfh8xScwgjMIhSLIvSXyU3i0zPampXXvs=.c5d33665-da1e-44ab-bedd-caaac441d23a@github.com>

On Thu, 28 Jul 2022 20:54:08 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/HmacMD5KeyGenerator.java line 93:
>> 
>>> 91: 
>>> 92:         if (keysize <= 0) {
>>> 93:             throw new IllegalArgumentException("keysize must not be <= 0 for SunJCE");
>> 
>> < 80 chars please
>
> The "for SunJCE" is odd to see in an exception message, I would leave that out.

A stack trace of the exception should be sufficient to tell what provider/code is generating it.

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

PR: https://git.openjdk.org/jdk/pull/9679

From kdriver at openjdk.org  Thu Jul 28 21:47:42 2022
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 28 Jul 2022 21:47:42 GMT
Subject: RFR: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0 [v3]
In-Reply-To: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
References: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
Message-ID: <HLVrmrD_sKhrZbA31e0wKoRt1pQegw7MPxl05eBzgT0=.c64850fe-ac43-4fde-a083-a85c580b8c11@github.com>

> As mentioned in the bug report, this issue *should not* be a framework-level issue, since potentially an individual provider could create a keysize of zero to have a certain significance. 
> 
> In the changes made here, the check is for `keysize <= 0` and this message indicates this is a check characteristic to the `SunJCE` provider.

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

  80 char line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9679/files
  - new: https://git.openjdk.org/jdk/pull/9679/files/f0d0912a..2cf5b7bf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9679&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9679&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/9679

From kdriver at openjdk.org  Thu Jul 28 21:47:43 2022
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 28 Jul 2022 21:47:43 GMT
Subject: RFR: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0 [v2]
In-Reply-To: <OOeBubWfgkUfh8xScwgjMIhSLIvSXyU3i0zPampXXvs=.c5d33665-da1e-44ab-bedd-caaac441d23a@github.com>
References: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
 <sNRUCmfD0J-YdmsTHSJE9LpJgRG9jmnK_vXpjcxxtfM=.ef8d33eb-0dbf-4810-bad6-b6a73121d62a@github.com>
 <7jPiscIzOR7HKGuxr9xmeFAj7XMQXNipqQw6N1e1qcw=.e3e4b00c-a3d2-48c0-ac3c-64c639b4fa7c@github.com>
 <5owFXYA5GNEkIYbiDmsWMy7Txq5_5SLTlwtYlOAMpro=.4910da95-7a56-46a3-a900-3560343b7d62@github.com>
 <OOeBubWfgkUfh8xScwgjMIhSLIvSXyU3i0zPampXXvs=.c5d33665-da1e-44ab-bedd-caaac441d23a@github.com>
Message-ID: <ez47IQhXCbHxr6fMfcwAt1-LoNx3Ff_Nk9b40NyAtQ0=.7c32cee1-5920-46b7-bf46-7c89d3901cd7@github.com>

On Thu, 28 Jul 2022 20:56:17 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> The "for SunJCE" is odd to see in an exception message, I would leave that out.
>
> A stack trace of the exception should be sufficient to tell what provider/code is generating it.

@seanjmullan I thought about this, but I added it due to the bug describing that this would be implementation-specific rather than framework-specific. I can take it out.

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

PR: https://git.openjdk.org/jdk/pull/9679

From kdriver at openjdk.org  Thu Jul 28 21:47:44 2022
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 28 Jul 2022 21:47:44 GMT
Subject: RFR: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0 [v2]
In-Reply-To: <ez47IQhXCbHxr6fMfcwAt1-LoNx3Ff_Nk9b40NyAtQ0=.7c32cee1-5920-46b7-bf46-7c89d3901cd7@github.com>
References: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
 <sNRUCmfD0J-YdmsTHSJE9LpJgRG9jmnK_vXpjcxxtfM=.ef8d33eb-0dbf-4810-bad6-b6a73121d62a@github.com>
 <7jPiscIzOR7HKGuxr9xmeFAj7XMQXNipqQw6N1e1qcw=.e3e4b00c-a3d2-48c0-ac3c-64c639b4fa7c@github.com>
 <5owFXYA5GNEkIYbiDmsWMy7Txq5_5SLTlwtYlOAMpro=.4910da95-7a56-46a3-a900-3560343b7d62@github.com>
 <OOeBubWfgkUfh8xScwgjMIhSLIvSXyU3i0zPampXXvs=.c5d33665-da1e-44ab-bedd-caaac441d23a@github.com>
 <ez47IQhXCbHxr6fMfcwAt1-LoNx3Ff_Nk9b40NyAtQ0=.7c32cee1-5920-46b7-bf46-7c89d3901cd7@github.com>
Message-ID: <SABfPdBKbfwFilJLWBVJCVXQJkgNrrrv1bOsVoFUK1M=.0679ebe4-0760-497f-8df4-a9d48efde258@github.com>

On Thu, 28 Jul 2022 21:40:49 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> A stack trace of the exception should be sufficient to tell what provider/code is generating it.
>
> @seanjmullan I thought about this, but I added it due to the bug describing that this would be implementation-specific rather than framework-specific. I can take it out.

> Needs regression tests.
> 
> Have you looked at the other Key(Pair)Generators? We've probably added more when this bug was filed. I took a quick look at some, and they were covered. (DES/DESede/Blowfish/AES/etc.)

@bradfordwetmore The bug mentions only the Hmac*KeyGenerators. I thought about this too, but you mentioned in your initial triage comment on the bug that it should be treated as only relevant to the classes I modified. Thoughts?

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

PR: https://git.openjdk.org/jdk/pull/9679

From kdriver at openjdk.org  Thu Jul 28 21:50:15 2022
From: kdriver at openjdk.org (Kevin Driver)
Date: Thu, 28 Jul 2022 21:50:15 GMT
Subject: RFR: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0 [v4]
In-Reply-To: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
References: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
Message-ID: <FPOKcypBZlF-ExSoSSzxeRoSPtUauCP260oelZC5Irg=.888a0dd3-3b24-4146-b581-98463861d761@github.com>

> As mentioned in the bug report, this issue *should not* be a framework-level issue, since potentially an individual provider could create a keysize of zero to have a certain significance. 
> 
> In the changes made here, the check is for `keysize <= 0` and this message indicates this is a check characteristic to the `SunJCE` provider.

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

  remove provider mention

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9679/files
  - new: https://git.openjdk.org/jdk/pull/9679/files/2cf5b7bf..3a7367e8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9679&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9679&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/9679

From darcy at openjdk.org  Thu Jul 28 21:50:43 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 28 Jul 2022 21:50:43 GMT
Subject: RFR: 6587699: Document DigestInputStream behavior when skip() or
 mark() / reset() is used [v2]
In-Reply-To: <8l59_UF_KT6ObAk0RlUy7lGfcUOaz5-ZtjgxBUJc1-k=.272bd84a-ca36-415a-bca5-e06a929479d9@github.com>
References: <5Rr8LpWgPXGH3WACAg_ha6cSlWTpJgDAIRzTna5XPew=.e6ae100d-2714-402d-b25c-1dacf9553941@github.com>
 <q6S6d0WFdOO-8XQulhNYJk07RO9NkKqGKa8oaIKv0GI=.69a9f785-d8b5-4dc4-b2dc-db209a170ae1@github.com>
 <py14buscs_MxG_izUqG2vN7X-b9_lzy6o_4tbDYOgWo=.56656bc0-23e8-43e8-86a7-b109200d2964@github.com>
 <8l59_UF_KT6ObAk0RlUy7lGfcUOaz5-ZtjgxBUJc1-k=.272bd84a-ca36-415a-bca5-e06a929479d9@github.com>
Message-ID: <9MPTj4QULx4u_fKWVv8HWU3Hg-sudcJOb4psoCXOogU=.9a04e03d-0390-4f0f-88bf-e169cc0368be@github.com>

On Thu, 28 Jul 2022 17:17:28 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> I'm using the "if and only if" style, which means other non-read methods will not update the message digest.
>
> My feeling still remains.  I don't recall seeing a wording construction like this except for IFF, which is well-understood.  I think it could be said more compactly with:
> 
> `This implementation only updates the message digest with data actually read from the input stream when it is on. `
> 
> Just my $0.02.

For your consideration, something like:
 "... This implementation will update the message digest if and only if the stream is on ...."

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

PR: https://git.openjdk.org/jdk/pull/9667

From wetmore at openjdk.org  Thu Jul 28 21:53:51 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 28 Jul 2022 21:53:51 GMT
Subject: RFR: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0 [v2]
In-Reply-To: <SABfPdBKbfwFilJLWBVJCVXQJkgNrrrv1bOsVoFUK1M=.0679ebe4-0760-497f-8df4-a9d48efde258@github.com>
References: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
 <sNRUCmfD0J-YdmsTHSJE9LpJgRG9jmnK_vXpjcxxtfM=.ef8d33eb-0dbf-4810-bad6-b6a73121d62a@github.com>
 <7jPiscIzOR7HKGuxr9xmeFAj7XMQXNipqQw6N1e1qcw=.e3e4b00c-a3d2-48c0-ac3c-64c639b4fa7c@github.com>
 <5owFXYA5GNEkIYbiDmsWMy7Txq5_5SLTlwtYlOAMpro=.4910da95-7a56-46a3-a900-3560343b7d62@github.com>
 <OOeBubWfgkUfh8xScwgjMIhSLIvSXyU3i0zPampXXvs=.c5d33665-da1e-44ab-bedd-caaac441d23a@github.com>
 <ez47IQhXCbHxr6fMfcwAt1-LoNx3Ff_Nk9b40NyAtQ0=.7c32cee1-5920-46b7-bf46-7c89d3901cd7@github.com>
 <SABfPdBKbfwFilJLWBVJCVXQJkgNrrrv1bOsVoFUK1M=.0679ebe4-0760-497f-8df4-a9d48efde258@github.com>
Message-ID: <wgnCwZCEHe_vq-ji1HgJa8TFNU75crpbX-NdyFfQGo0=.4d49ae08-d245-490c-9607-d66cc630a93d@github.com>

On Thu, 28 Jul 2022 21:43:19 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> @seanjmullan I thought about this, but I added it due to the bug describing that this would be implementation-specific rather than framework-specific. I can take it out.
>
>> Needs regression tests.
>> 
>> Have you looked at the other Key(Pair)Generators? We've probably added more when this bug was filed. I took a quick look at some, and they were covered. (DES/DESede/Blowfish/AES/etc.)
> 
> @bradfordwetmore The bug mentions only the Hmac*KeyGenerators. I thought about this too, but you mentioned in your initial triage comment on the bug that it should be treated as only relevant to the classes I modified. Thoughts?

What bug/Sean meant was that we wouldn't put in a check into java.security.* framework, but rather in sun.security.* implementation.  And that we don't need to put "SunJCE" in this particular throws message, as we'll know where it is from the stack trace.

My comment agrees that we have a problem in the JCE Hmac code, but there might be other locations where init's like this might allow for invalid 0 values.  It's just a general idea to check we didn't make the same issue elsewhere.

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

PR: https://git.openjdk.org/jdk/pull/9679

From wetmore at openjdk.org  Thu Jul 28 22:05:02 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 28 Jul 2022 22:05:02 GMT
Subject: RFR: 6383195: javax.crypto.spec.PBEKeySpec is not thread safe [v3]
In-Reply-To: <3YBCQsXxW5zVSuPhGYoGHiPtCYYdGkrTDxT_pGXXBA0=.38376a3f-ae2d-4fa5-afc1-0d4c3ac9f136@github.com>
References: <3YBCQsXxW5zVSuPhGYoGHiPtCYYdGkrTDxT_pGXXBA0=.38376a3f-ae2d-4fa5-afc1-0d4c3ac9f136@github.com>
Message-ID: <Ym9vYAjmNaKbRi2M7dJ4HFFg7MkmUFNC8xdKY3hZQsk=.5dc377eb-365a-46a4-8619-e26b0a0a86cf@github.com>

> Simple fix to a long-standing threading bug to help clear the bug backlog.  
> 
> Without the synchronized, the test case fails almost immediately.  
> 
> Running JPRT with tier1/tier2.

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

  Copyright Update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9668/files
  - new: https://git.openjdk.org/jdk/pull/9668/files/c932188b..b27a361f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9668&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9668&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/9668

From wetmore at openjdk.org  Thu Jul 28 22:07:46 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Thu, 28 Jul 2022 22:07:46 GMT
Subject: Integrated: 6383195: javax.crypto.spec.PBEKeySpec is not thread safe
In-Reply-To: <3YBCQsXxW5zVSuPhGYoGHiPtCYYdGkrTDxT_pGXXBA0=.38376a3f-ae2d-4fa5-afc1-0d4c3ac9f136@github.com>
References: <3YBCQsXxW5zVSuPhGYoGHiPtCYYdGkrTDxT_pGXXBA0=.38376a3f-ae2d-4fa5-afc1-0d4c3ac9f136@github.com>
Message-ID: <a-V5rZqNZX-bBS4PfxvYWbo9_PmLy0UqdAb0Phy6tEU=.9a34a67a-9bfe-42ad-86d6-15af8c0a39e6@github.com>

On Wed, 27 Jul 2022 23:53:53 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> Simple fix to a long-standing threading bug to help clear the bug backlog.  
> 
> Without the synchronized, the test case fails almost immediately.  
> 
> Running JPRT with tier1/tier2.

This pull request has now been integrated.

Changeset: 791fc579
Author:    Bradford Wetmore <wetmore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/791fc5791a029f3cf8ffbe78319e99b7703dd42b
Stats:     98 lines in 2 files changed: 95 ins; 0 del; 3 mod

6383195: javax.crypto.spec.PBEKeySpec is not thread safe

Reviewed-by: weijun

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

PR: https://git.openjdk.org/jdk/pull/9668

From weijun at openjdk.org  Thu Jul 28 22:32:50 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 28 Jul 2022 22:32:50 GMT
Subject: RFR: 6587699: Document DigestInputStream behavior when skip() or
 mark() / reset() is used [v2]
In-Reply-To: <9MPTj4QULx4u_fKWVv8HWU3Hg-sudcJOb4psoCXOogU=.9a04e03d-0390-4f0f-88bf-e169cc0368be@github.com>
References: <5Rr8LpWgPXGH3WACAg_ha6cSlWTpJgDAIRzTna5XPew=.e6ae100d-2714-402d-b25c-1dacf9553941@github.com>
 <q6S6d0WFdOO-8XQulhNYJk07RO9NkKqGKa8oaIKv0GI=.69a9f785-d8b5-4dc4-b2dc-db209a170ae1@github.com>
 <py14buscs_MxG_izUqG2vN7X-b9_lzy6o_4tbDYOgWo=.56656bc0-23e8-43e8-86a7-b109200d2964@github.com>
 <8l59_UF_KT6ObAk0RlUy7lGfcUOaz5-ZtjgxBUJc1-k=.272bd84a-ca36-415a-bca5-e06a929479d9@github.com>
 <9MPTj4QULx4u_fKWVv8HWU3Hg-sudcJOb4psoCXOogU=.9a04e03d-0390-4f0f-88bf-e169cc0368be@github.com>
Message-ID: <4a3F6_4B0ccxciZr84ADMIAqJ04XZKL6jzevigJngV0=.c4731592-e3f6-4ea5-bdbd-6ea54c556c9e@github.com>

On Thu, 28 Jul 2022 21:48:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> My feeling still remains.  I don't recall seeing a wording construction like this except for IFF, which is well-understood.  I think it could be said more compactly with:
>> 
>> `This implementation only updates the message digest with data actually read from the input stream when it is on. `
>> 
>> Just my $0.02.
>
> For your consideration, something like:
>  "... This implementation will update the message digest if and only if the stream is on ...."

I'll choose Brad's suggestion. The "if and only if" is for "data read from" which is a noun instead of a clause. Thanks all.

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

PR: https://git.openjdk.org/jdk/pull/9667

From weijun at openjdk.org  Thu Jul 28 22:38:34 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 28 Jul 2022 22:38:34 GMT
Subject: RFR: 6587699: Document DigestInputStream behavior when skip() or
 mark() / reset() is used [v2]
In-Reply-To: <8l59_UF_KT6ObAk0RlUy7lGfcUOaz5-ZtjgxBUJc1-k=.272bd84a-ca36-415a-bca5-e06a929479d9@github.com>
References: <5Rr8LpWgPXGH3WACAg_ha6cSlWTpJgDAIRzTna5XPew=.e6ae100d-2714-402d-b25c-1dacf9553941@github.com>
 <q6S6d0WFdOO-8XQulhNYJk07RO9NkKqGKa8oaIKv0GI=.69a9f785-d8b5-4dc4-b2dc-db209a170ae1@github.com>
 <py14buscs_MxG_izUqG2vN7X-b9_lzy6o_4tbDYOgWo=.56656bc0-23e8-43e8-86a7-b109200d2964@github.com>
 <8l59_UF_KT6ObAk0RlUy7lGfcUOaz5-ZtjgxBUJc1-k=.272bd84a-ca36-415a-bca5-e06a929479d9@github.com>
Message-ID: <oFj2Wp3xeYR7pOZze8aI29tRgX64NP9-R9vr4K1NOU8=.a452f890-be9a-4441-a07d-4aeddbcbc79a@github.com>

On Thu, 28 Jul 2022 17:40:30 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Maybe I should use "especially". This is not "additionally" because `skip` is not one of these "read"-methods.
>
> I meant additionally as in "here's an additional case to be aware of...", not "this is an additional read case..."

To me, "additionally" means the previous sentence has not covered this. Here, the previous sentence is already quite clear the message digest is only updated for the "read" methods. The extra "especially" and "on the other hand" sentences are just a clarification for those people wondering what other methods there are except for those "read" methods.

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

PR: https://git.openjdk.org/jdk/pull/9667

From weijun at openjdk.org  Thu Jul 28 22:38:37 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 28 Jul 2022 22:38:37 GMT
Subject: RFR: 6587699: Document DigestInputStream behavior when skip() or
 mark() / reset() is used [v2]
In-Reply-To: <yHufZW6743mb0TllPiWS12L8bYrMXJ0ZvAOlQy92OWk=.b9471fae-0cd7-4aee-8845-80058bb3c9d5@github.com>
References: <5Rr8LpWgPXGH3WACAg_ha6cSlWTpJgDAIRzTna5XPew=.e6ae100d-2714-402d-b25c-1dacf9553941@github.com>
 <SQOz3WH9qvo0msR74tjvQjaxqNOc67QfzuD95KHb9jE=.aca4d886-dc71-45ef-b977-4ebdde36b2af@github.com>
 <yHufZW6743mb0TllPiWS12L8bYrMXJ0ZvAOlQy92OWk=.b9471fae-0cd7-4aee-8845-80058bb3c9d5@github.com>
Message-ID: <r1f6MXvPN41OGYJ0So_0khqImEdFki5Oi1Y1U-p3Lbo=.68773c5d-eba6-4999-93f9-22fff6f7a56f@github.com>

On Thu, 28 Jul 2022 17:40:43 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Brad comment
>
> src/java.base/share/classes/java/security/DigestInputStream.java line 57:
> 
>> 55:  *      with data actually read from the input stream when it is turned on.
>> 56:  *      This includes the various {@code read} methods, {@code transferTo},
>> 57:  *      {@code readAllBytes}, and {@code readNBytes}. Especially, data
> 
> Maybe just "Note" instead of "Especially" (or just remove) as this doesn't seem to be an extra special situation.

My understanding of "especially" is not an extra situation, but I'll use "note".

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

PR: https://git.openjdk.org/jdk/pull/9667

From weijun at openjdk.org  Thu Jul 28 22:45:34 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 28 Jul 2022 22:45:34 GMT
Subject: RFR: 6587699: Document DigestInputStream behavior when skip() or
 mark() / reset() is used [v3]
In-Reply-To: <5Rr8LpWgPXGH3WACAg_ha6cSlWTpJgDAIRzTna5XPew=.e6ae100d-2714-402d-b25c-1dacf9553941@github.com>
References: <5Rr8LpWgPXGH3WACAg_ha6cSlWTpJgDAIRzTna5XPew=.e6ae100d-2714-402d-b25c-1dacf9553941@github.com>
Message-ID: <yKp6ATcrxgOgvDF8_QxP-z0nyZXZR3V-OJAhZFGULTM=.c2eec71e-b567-4434-9789-8f88a0388153@github.com>

> Add an `@implNote` to clarify the behavior when these methods are called. A new test is added.

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

  rewording

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9667/files
  - new: https://git.openjdk.org/jdk/pull/9667/files/a6304352..36e46dfe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9667&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9667&range=01-02

  Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/9667.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9667/head:pull/9667

PR: https://git.openjdk.org/jdk/pull/9667

From valeriep at openjdk.org  Thu Jul 28 22:58:07 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 28 Jul 2022 22:58:07 GMT
Subject: RFR: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0 [v2]
In-Reply-To: <wgnCwZCEHe_vq-ji1HgJa8TFNU75crpbX-NdyFfQGo0=.4d49ae08-d245-490c-9607-d66cc630a93d@github.com>
References: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
 <sNRUCmfD0J-YdmsTHSJE9LpJgRG9jmnK_vXpjcxxtfM=.ef8d33eb-0dbf-4810-bad6-b6a73121d62a@github.com>
 <7jPiscIzOR7HKGuxr9xmeFAj7XMQXNipqQw6N1e1qcw=.e3e4b00c-a3d2-48c0-ac3c-64c639b4fa7c@github.com>
 <5owFXYA5GNEkIYbiDmsWMy7Txq5_5SLTlwtYlOAMpro=.4910da95-7a56-46a3-a900-3560343b7d62@github.com>
 <OOeBubWfgkUfh8xScwgjMIhSLIvSXyU3i0zPampXXvs=.c5d33665-da1e-44ab-bedd-caaac441d23a@github.com>
 <ez47IQhXCbHxr6fMfcwAt1-LoNx3Ff_Nk9b40NyAtQ0=.7c32cee1-5920-46b7-bf46-7c89d3901cd7@github.com>
 <SABfPdBKbfwFilJLWBVJCVXQJkgNrrrv1bOsVoFUK1M=.0679ebe4-0760-497f-8df4-a9d48efde258@github.com>
 <wgnCwZCEHe_vq-ji1HgJa8TFNU75crpbX-NdyFfQGo0=.4d49ae08-d245-490c-9607-d66cc630a93d@github.com>
Message-ID: <-FlhIcAR28MJYugQD3gXotE99fXzti_hY5-dHLpXBHI=.2a1db077-8867-420d-916a-13b5680b8712@github.com>

On Thu, 28 Jul 2022 21:51:48 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>>> Needs regression tests.
>>> 
>>> Have you looked at the other Key(Pair)Generators? We've probably added more when this bug was filed. I took a quick look at some, and they were covered. (DES/DESede/Blowfish/AES/etc.)
>> 
>> @bradfordwetmore The bug mentions only the Hmac*KeyGenerators. I thought about this too, but you mentioned in your initial triage comment on the bug that it should be treated as only relevant to the classes I modified. Thoughts?
>
> What bug/Sean meant was that we wouldn't put in a check into java.security.* framework, but rather in sun.security.* implementation.  And that we don't need to put "SunJCE" in this particular throws message, as we'll know where it is from the stack trace.
> 
> My comment agrees that we have a problem in the JCE Hmac code, but there might be other locations where init's like this might allow for invalid 0 values.  It's just a general idea to check we didn't make the same issue elsewhere.

Other (newer) HmacXXX KeyGenerator enforces min key size to be 40. So, perhaps just enforce the same lower limit or just check for <0?

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

PR: https://git.openjdk.org/jdk/pull/9679

From valeriep at openjdk.org  Thu Jul 28 23:03:34 2022
From: valeriep at openjdk.org (Valerie Peng)
Date: Thu, 28 Jul 2022 23:03:34 GMT
Subject: RFR: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0 [v2]
In-Reply-To: <-FlhIcAR28MJYugQD3gXotE99fXzti_hY5-dHLpXBHI=.2a1db077-8867-420d-916a-13b5680b8712@github.com>
References: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
 <sNRUCmfD0J-YdmsTHSJE9LpJgRG9jmnK_vXpjcxxtfM=.ef8d33eb-0dbf-4810-bad6-b6a73121d62a@github.com>
 <7jPiscIzOR7HKGuxr9xmeFAj7XMQXNipqQw6N1e1qcw=.e3e4b00c-a3d2-48c0-ac3c-64c639b4fa7c@github.com>
 <5owFXYA5GNEkIYbiDmsWMy7Txq5_5SLTlwtYlOAMpro=.4910da95-7a56-46a3-a900-3560343b7d62@github.com>
 <OOeBubWfgkUfh8xScwgjMIhSLIvSXyU3i0zPampXXvs=.c5d33665-da1e-44ab-bedd-caaac441d23a@github.com>
 <ez47IQhXCbHxr6fMfcwAt1-LoNx3Ff_Nk9b40NyAtQ0=.7c32cee1-5920-46b7-bf46-7c89d3901cd7@github.com>
 <SABfPdBKbfwFilJLWBVJCVXQJkgNrrrv1bOsVoFUK1M=.0679ebe4-0760-497f-8df4-a9d48efde258@github.com>
 <wgnCwZCEHe_vq-ji1HgJa8TFNU75crpbX-NdyFfQGo0=.4d49ae08-d245-490c-9607-d66cc630a93d@github.com>
 <-FlhIcAR28MJYugQD3gXotE99fXzti_hY5-dHLpXBHI=.2a1db077-8867-420d-916a-13b5680b8712@github.com>
Message-ID: <4nqzz0ED89ecFnmUVrGE6OnL-ajw0wMgHoW9Vm7pw_8=.7e673801-f834-4bbd-9bf1-7611d9062050@github.com>

On Thu, 28 Jul 2022 22:55:55 GMT, Valerie Peng <valeriep at openjdk.org> wrote:

>> What bug/Sean meant was that we wouldn't put in a check into java.security.* framework, but rather in sun.security.* implementation.  And that we don't need to put "SunJCE" in this particular throws message, as we'll know where it is from the stack trace.
>> 
>> My comment agrees that we have a problem in the JCE Hmac code, but there might be other locations where init's like this might allow for invalid 0 values.  It's just a general idea to check we didn't make the same issue elsewhere.
>
> Other (newer) HmacXXX KeyGenerator enforces min key size to be 40. So, perhaps just enforce the same lower limit or just check for <0?

Also, it'd be nice to include HmacMD5 and HmacSHA1 to the bug synopsis as KeyGenerator covers many algorithms. Would be nice to add SunJCE provider to synopsis, so it's clear that this change/fix is provider-specific.

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

PR: https://git.openjdk.org/jdk/pull/9679

From weijun at openjdk.org  Thu Jul 28 23:15:33 2022
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 28 Jul 2022 23:15:33 GMT
Subject: RFR: 6587699: Document DigestInputStream behavior when skip() or
 mark() / reset() is used [v3]
In-Reply-To: <yKp6ATcrxgOgvDF8_QxP-z0nyZXZR3V-OJAhZFGULTM=.c2eec71e-b567-4434-9789-8f88a0388153@github.com>
References: <5Rr8LpWgPXGH3WACAg_ha6cSlWTpJgDAIRzTna5XPew=.e6ae100d-2714-402d-b25c-1dacf9553941@github.com>
 <yKp6ATcrxgOgvDF8_QxP-z0nyZXZR3V-OJAhZFGULTM=.c2eec71e-b567-4434-9789-8f88a0388153@github.com>
Message-ID: <3WZ9EwwIrnqg1dnkCUzVx9msplZrzM7ob0lx3djlpPE=.68d5b232-998f-4d6e-a28c-d3a5d0af32b6@github.com>

On Thu, 28 Jul 2022 22:45:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add an `@implNote` to clarify the behavior when these methods are called. A new test is added.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rewording

CSR is filed at https://bugs.openjdk.org/browse/JDK-8291516, please also take a review.

BTW, I assume there is no need for a release note.

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

PR: https://git.openjdk.org/jdk/pull/9667

From wetmore at openjdk.org  Fri Jul 29 00:37:32 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 29 Jul 2022 00:37:32 GMT
Subject: RFR: 6587699: Document DigestInputStream behavior when skip() or
 mark() / reset() is used [v3]
In-Reply-To: <yKp6ATcrxgOgvDF8_QxP-z0nyZXZR3V-OJAhZFGULTM=.c2eec71e-b567-4434-9789-8f88a0388153@github.com>
References: <5Rr8LpWgPXGH3WACAg_ha6cSlWTpJgDAIRzTna5XPew=.e6ae100d-2714-402d-b25c-1dacf9553941@github.com>
 <yKp6ATcrxgOgvDF8_QxP-z0nyZXZR3V-OJAhZFGULTM=.c2eec71e-b567-4434-9789-8f88a0388153@github.com>
Message-ID: <T-_0IvNYv71KNdsKRUGyF5xG4YcbC09aJPaHE_8M7YQ=.69c357e4-088c-4c24-8c5d-060759b6a077@github.com>

On Thu, 28 Jul 2022 22:45:34 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Add an `@implNote` to clarify the behavior when these methods are called. A new test is added.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rewording

I don't think a new release is needed.

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

PR: https://git.openjdk.org/jdk/pull/9667

From achung at openjdk.org  Fri Jul 29 18:13:25 2022
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 29 Jul 2022 18:13:25 GMT
Subject: [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource files update -
 msgdrop 10 [v4]
In-Reply-To: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
Message-ID: <vKXwAs-SGIVaskDopc7GE6LIGnafs2yZFLW3jG6q0zg=.1c432b6d-b66c-4419-8fb5-5d8863e6e51c@github.com>

> open l10n msg drop
> All tests passed.

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

  added comments in CurrencyNames root in base, moved US CurrencyNames back to base, readded original Chinese translation

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/154/files
  - new: https://git.openjdk.org/jdk19/pull/154/files/6776bd0f..737b253f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk19&pr=154&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=154&range=02-03

  Stats: 4 lines in 3 files changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk19/pull/154.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/154/head:pull/154

PR: https://git.openjdk.org/jdk19/pull/154

From kdriver at openjdk.org  Fri Jul 29 18:31:13 2022
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 29 Jul 2022 18:31:13 GMT
Subject: RFR: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0 [v5]
In-Reply-To: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
References: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
Message-ID: <CHF4faoaWnMrHn0rU7GsAiUD2KYZjCKU4yA-rTIXk0g=.492408b5-8bef-4f00-8cac-0d29e08aa802@github.com>

> As mentioned in the bug report, this issue *should not* be a framework-level issue, since potentially an individual provider could create a keysize of zero to have a certain significance. 
> 
> In the changes made here, the check is for `keysize <= 0` and this message indicates this is a check characteristic to the `SunJCE` provider.

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

  initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9679/files
  - new: https://git.openjdk.org/jdk/pull/9679/files/3a7367e8..9752981f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9679&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9679&range=03-04

  Stats: 65 lines in 1 file changed: 65 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9679.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9679/head:pull/9679

PR: https://git.openjdk.org/jdk/pull/9679

From kdriver at openjdk.org  Fri Jul 29 18:50:44 2022
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 29 Jul 2022 18:50:44 GMT
Subject: RFR: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0 [v2]
In-Reply-To: <7jPiscIzOR7HKGuxr9xmeFAj7XMQXNipqQw6N1e1qcw=.e3e4b00c-a3d2-48c0-ac3c-64c639b4fa7c@github.com>
References: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
 <sNRUCmfD0J-YdmsTHSJE9LpJgRG9jmnK_vXpjcxxtfM=.ef8d33eb-0dbf-4810-bad6-b6a73121d62a@github.com>
 <7jPiscIzOR7HKGuxr9xmeFAj7XMQXNipqQw6N1e1qcw=.e3e4b00c-a3d2-48c0-ac3c-64c639b4fa7c@github.com>
Message-ID: <mbmjJY7iHdr18360gk1kRfl9OPsbEvpPtLmyXVm0568=.5b57f66d-098f-47ed-9972-f9e49d1f67cf@github.com>

On Thu, 28 Jul 2022 20:32:58 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> Needs regression tests.
> 
> Have you looked at the other Key(Pair)Generators? We've probably added more when this bug was filed. I took a quick look at some, and they were covered. (DES/DESede/Blowfish/AES/etc.)

Yes, the others are covered.

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

PR: https://git.openjdk.org/jdk/pull/9679

From kdriver at openjdk.org  Fri Jul 29 18:50:47 2022
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 29 Jul 2022 18:50:47 GMT
Subject: RFR: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0 [v5]
In-Reply-To: <CHF4faoaWnMrHn0rU7GsAiUD2KYZjCKU4yA-rTIXk0g=.492408b5-8bef-4f00-8cac-0d29e08aa802@github.com>
References: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
 <CHF4faoaWnMrHn0rU7GsAiUD2KYZjCKU4yA-rTIXk0g=.492408b5-8bef-4f00-8cac-0d29e08aa802@github.com>
Message-ID: <JptK4wgPuLYZVh1hrS-2zaJjOw4zzxZkXMwZuwcd7H0=.1b06289b-4640-48c9-ab4d-55da4cd5df74@github.com>

On Fri, 29 Jul 2022 18:31:13 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> As mentioned in the bug report, this issue *should not* be a framework-level issue, since potentially an individual provider could create a keysize of zero to have a certain significance. 
>> 
>> In the changes made here for `HmacMD5`- and `HmacSHA1`- `KeyGenerator`s, the check is for `keysize <= 0` and this message indicates this is a check characteristic to the `SunJCE` provider.
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   initial commit

All review comments have been addressed.

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

PR: https://git.openjdk.org/jdk/pull/9679

From kdriver at openjdk.org  Fri Jul 29 19:29:42 2022
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 29 Jul 2022 19:29:42 GMT
Subject: RFR: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0 [v6]
In-Reply-To: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
References: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
Message-ID: <pMxMikXIHQn6nUkHTlP1q-TG73Ni6_CSSD9aiFOn00E=.bd13a539-ef29-42e7-8951-454abf903aa6@github.com>

> As mentioned in the bug report, this issue *should not* be a framework-level issue, since potentially an individual provider could create a keysize of zero to have a certain significance. 
> 
> In the changes made here for `HmacMD5`- and `HmacSHA1`- `KeyGenerator`s, the check is for `keysize <= 0` and this message indicates this is a check characteristic to the `SunJCE` provider.

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

  using jtreg helper

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9679/files
  - new: https://git.openjdk.org/jdk/pull/9679/files/9752981f..07de4cd1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9679&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9679&range=04-05

  Stats: 13 lines in 1 file changed: 3 ins; 8 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9679.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9679/head:pull/9679

PR: https://git.openjdk.org/jdk/pull/9679

From kdriver at openjdk.org  Fri Jul 29 19:49:22 2022
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 29 Jul 2022 19:49:22 GMT
Subject: RFR: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0 [v7]
In-Reply-To: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
References: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
Message-ID: <dh52CMuOHiR2twkSUXmrie2jpBf9Bm6YZsnx50RAgJA=.2441e818-9132-4203-9eb8-9df08bf12a15@github.com>

> As mentioned in the bug report, this issue *should not* be a framework-level issue, since potentially an individual provider could create a keysize of zero to have a certain significance. 
> 
> In the changes made here for `HmacMD5`- and `HmacSHA1`- `KeyGenerator`s, the check is for `keysize <= 0` and this message indicates this is a check characteristic to the `SunJCE` provider.

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

  optimizing test case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9679/files
  - new: https://git.openjdk.org/jdk/pull/9679/files/07de4cd1..94ccc3df

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9679&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9679&range=05-06

  Stats: 17 lines in 1 file changed: 5 ins; 4 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/9679.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9679/head:pull/9679

PR: https://git.openjdk.org/jdk/pull/9679

From wetmore at openjdk.org  Fri Jul 29 19:49:23 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 29 Jul 2022 19:49:23 GMT
Subject: RFR: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0 [v5]
In-Reply-To: <CHF4faoaWnMrHn0rU7GsAiUD2KYZjCKU4yA-rTIXk0g=.492408b5-8bef-4f00-8cac-0d29e08aa802@github.com>
References: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
 <CHF4faoaWnMrHn0rU7GsAiUD2KYZjCKU4yA-rTIXk0g=.492408b5-8bef-4f00-8cac-0d29e08aa802@github.com>
Message-ID: <E9lGU6rei2-C3j1ptS0-aHX09y63mhY89jKFcpu8Qwk=.21df251e-446f-405b-9d89-973f23b9c6f1@github.com>

On Fri, 29 Jul 2022 18:31:13 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> As mentioned in the bug report, this issue *should not* be a framework-level issue, since potentially an individual provider could create a keysize of zero to have a certain significance. 
>> 
>> In the changes made here for `HmacMD5`- and `HmacSHA1`- `KeyGenerator`s, the check is for `keysize <= 0` and this message indicates this is a check characteristic to the `SunJCE` provider.
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   initial commit

We are Slacking on some other test issues.  Will approve on next update.

test/jdk/com/sun/crypto/provider/KeyGenerator/Test6227536.java line 2:

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

As this is a new test, you'll just have the one date:

`...(c) 2022, Oracle and/or`

test/jdk/com/sun/crypto/provider/KeyGenerator/Test6227536.java line 28:

> 26:  * @bug 6227536
> 27:  * @summary Verify HmacSHA1 and HmacMD5 KeyGenerators throw an Exception when a keysize of zero is requested
> 28:  * @author Kevin Driver

We generally no longer include @author.

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

PR: https://git.openjdk.org/jdk/pull/9679

From kdriver at openjdk.org  Fri Jul 29 19:49:23 2022
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 29 Jul 2022 19:49:23 GMT
Subject: RFR: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0 [v5]
In-Reply-To: <E9lGU6rei2-C3j1ptS0-aHX09y63mhY89jKFcpu8Qwk=.21df251e-446f-405b-9d89-973f23b9c6f1@github.com>
References: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
 <CHF4faoaWnMrHn0rU7GsAiUD2KYZjCKU4yA-rTIXk0g=.492408b5-8bef-4f00-8cac-0d29e08aa802@github.com>
 <E9lGU6rei2-C3j1ptS0-aHX09y63mhY89jKFcpu8Qwk=.21df251e-446f-405b-9d89-973f23b9c6f1@github.com>
Message-ID: <p-BijNOrYb9q2t9FtniyQTSmC2eB4gv8NpBb8gVPB88=.ad68c435-0d38-42bb-8d8c-6065b0ad93e5@github.com>

On Fri, 29 Jul 2022 19:25:30 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   initial commit
>
> test/jdk/com/sun/crypto/provider/KeyGenerator/Test6227536.java line 28:
> 
>> 26:  * @bug 6227536
>> 27:  * @summary Verify HmacSHA1 and HmacMD5 KeyGenerators throw an Exception when a keysize of zero is requested
>> 28:  * @author Kevin Driver
> 
> We generally no longer include @author.

Copy that.

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

PR: https://git.openjdk.org/jdk/pull/9679

From kdriver at openjdk.org  Fri Jul 29 19:53:38 2022
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 29 Jul 2022 19:53:38 GMT
Subject: RFR: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0 [v8]
In-Reply-To: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
References: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
Message-ID: <C0EKb3ubaJAnAVXx7W8NOVOq9ACyZREixo6yY3vWD_Q=.1e17542d-8760-4546-a98a-336dcdd710da@github.com>

> As mentioned in the bug report, this issue *should not* be a framework-level issue, since potentially an individual provider could create a keysize of zero to have a certain significance. 
> 
> In the changes made here for `HmacMD5`- and `HmacSHA1`- `KeyGenerator`s, the check is for `keysize <= 0` and this message indicates this is a check characteristic to the `SunJCE` provider.

Kevin Driver has updated the pull request incrementally with two additional commits since the last revision:

 - update copyright
 - optimizing test case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9679/files
  - new: https://git.openjdk.org/jdk/pull/9679/files/94ccc3df..d7542111

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9679&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9679&range=06-07

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

PR: https://git.openjdk.org/jdk/pull/9679

From kdriver at openjdk.org  Fri Jul 29 19:53:42 2022
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 29 Jul 2022 19:53:42 GMT
Subject: RFR: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0 [v5]
In-Reply-To: <E9lGU6rei2-C3j1ptS0-aHX09y63mhY89jKFcpu8Qwk=.21df251e-446f-405b-9d89-973f23b9c6f1@github.com>
References: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
 <CHF4faoaWnMrHn0rU7GsAiUD2KYZjCKU4yA-rTIXk0g=.492408b5-8bef-4f00-8cac-0d29e08aa802@github.com>
 <E9lGU6rei2-C3j1ptS0-aHX09y63mhY89jKFcpu8Qwk=.21df251e-446f-405b-9d89-973f23b9c6f1@github.com>
Message-ID: <HdzPsikueLhZ3GSpRY8d--aWtil2Wdk5IZRQek8FwDw=.25a5d592-74a1-4240-a7fe-f83b02bbbce3@github.com>

On Fri, 29 Jul 2022 19:24:25 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   initial commit
>
> test/jdk/com/sun/crypto/provider/KeyGenerator/Test6227536.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2002, 2022, Oracle and/or its affiliates. All rights reserved.
> 
> As this is a new test, you'll just have the one date:
> 
> `...(c) 2022, Oracle and/or`

Fixed in: https://github.com/openjdk/jdk/pull/9679/commits/d754211103874b53daf7b8fa9eb276511b40a51b

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

PR: https://git.openjdk.org/jdk/pull/9679

From kdriver at openjdk.org  Fri Jul 29 19:53:44 2022
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 29 Jul 2022 19:53:44 GMT
Subject: RFR: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0 [v5]
In-Reply-To: <p-BijNOrYb9q2t9FtniyQTSmC2eB4gv8NpBb8gVPB88=.ad68c435-0d38-42bb-8d8c-6065b0ad93e5@github.com>
References: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
 <CHF4faoaWnMrHn0rU7GsAiUD2KYZjCKU4yA-rTIXk0g=.492408b5-8bef-4f00-8cac-0d29e08aa802@github.com>
 <E9lGU6rei2-C3j1ptS0-aHX09y63mhY89jKFcpu8Qwk=.21df251e-446f-405b-9d89-973f23b9c6f1@github.com>
 <p-BijNOrYb9q2t9FtniyQTSmC2eB4gv8NpBb8gVPB88=.ad68c435-0d38-42bb-8d8c-6065b0ad93e5@github.com>
Message-ID: <B4-sWydsi42KmvuRc3rjlb7MUxPXdoRJxXE8f3ew9Dc=.33cf6f1a-4cd5-46db-977e-477141e5f78e@github.com>

On Fri, 29 Jul 2022 19:45:57 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> test/jdk/com/sun/crypto/provider/KeyGenerator/Test6227536.java line 28:
>> 
>>> 26:  * @bug 6227536
>>> 27:  * @summary Verify HmacSHA1 and HmacMD5 KeyGenerators throw an Exception when a keysize of zero is requested
>>> 28:  * @author Kevin Driver
>> 
>> We generally no longer include @author.
>
> Copy that.

Fixed in: https://github.com/openjdk/jdk/pull/9679/commits/ae3e2546e4f83751f8912ad958ede4955ae1b9e1

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

PR: https://git.openjdk.org/jdk/pull/9679

From kdriver at openjdk.org  Fri Jul 29 20:01:56 2022
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 29 Jul 2022 20:01:56 GMT
Subject: RFR: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0 [v9]
In-Reply-To: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
References: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
Message-ID: <n3krX_bed8U7N313rEzGfKbDPBCVG209Wfw-SayT1J8=.e4195a42-3320-4555-a4df-b1f10ce2fa5d@github.com>

> As mentioned in the bug report, this issue *should not* be a framework-level issue, since potentially an individual provider could create a keysize of zero to have a certain significance. 
> 
> In the changes made here for `HmacMD5`- and `HmacSHA1`- `KeyGenerator`s, the check is for `keysize <= 0` and this message indicates this is a check characteristic to the `SunJCE` provider.

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

  put back standard if block, since we never hit the failure case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9679/files
  - new: https://git.openjdk.org/jdk/pull/9679/files/d7542111..921fb976

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9679&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9679&range=07-08

  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9679.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9679/head:pull/9679

PR: https://git.openjdk.org/jdk/pull/9679

From wetmore at openjdk.org  Fri Jul 29 20:09:57 2022
From: wetmore at openjdk.org (Bradford Wetmore)
Date: Fri, 29 Jul 2022 20:09:57 GMT
Subject: RFR: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0 [v9]
In-Reply-To: <n3krX_bed8U7N313rEzGfKbDPBCVG209Wfw-SayT1J8=.e4195a42-3320-4555-a4df-b1f10ce2fa5d@github.com>
References: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
 <n3krX_bed8U7N313rEzGfKbDPBCVG209Wfw-SayT1J8=.e4195a42-3320-4555-a4df-b1f10ce2fa5d@github.com>
Message-ID: <wnHt8etPyX6zAfkidXWuDbBXmUqKDPP-Lbd4JN1ykKw=.23f564bc-0793-4610-a0ba-e20372bf21db@github.com>

On Fri, 29 Jul 2022 20:01:56 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

>> As mentioned in the bug report, this issue *should not* be a framework-level issue, since potentially an individual provider could create a keysize of zero to have a certain significance. 
>> 
>> In the changes made here for `HmacMD5`- and `HmacSHA1`- `KeyGenerator`s, the check is for `keysize <= 0` and this message indicates this is a check characteristic to the `SunJCE` provider.
>
> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
> 
>   put back standard if block, since we never hit the failure case

Marked as reviewed by wetmore (Reviewer).

test/jdk/com/sun/crypto/provider/KeyGenerator/Test6227536.java line 50:

> 48: 
> 49:     public static void main(String[] args) throws Exception {
> 50:         Test6227536 test = new Test6227536();

Calling the constructor just to get the class name seems redundant, as the test name will appear in all of the jtreg test output.  I would probably pull it out, just my $0.02.

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

PR: https://git.openjdk.org/jdk/pull/9679

From kdriver at openjdk.org  Fri Jul 29 20:17:34 2022
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 29 Jul 2022 20:17:34 GMT
Subject: RFR: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0 [v9]
In-Reply-To: <wnHt8etPyX6zAfkidXWuDbBXmUqKDPP-Lbd4JN1ykKw=.23f564bc-0793-4610-a0ba-e20372bf21db@github.com>
References: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
 <n3krX_bed8U7N313rEzGfKbDPBCVG209Wfw-SayT1J8=.e4195a42-3320-4555-a4df-b1f10ce2fa5d@github.com>
 <wnHt8etPyX6zAfkidXWuDbBXmUqKDPP-Lbd4JN1ykKw=.23f564bc-0793-4610-a0ba-e20372bf21db@github.com>
Message-ID: <_avit1F7hEEHTV9ZDTgjDxbmk3VVeqKzFZ5gazlYUTo=.e1981a0f-6baa-4547-9b75-e66d56f4ec27@github.com>

On Fri, 29 Jul 2022 20:07:20 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Kevin Driver has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   put back standard if block, since we never hit the failure case
>
> test/jdk/com/sun/crypto/provider/KeyGenerator/Test6227536.java line 50:
> 
>> 48: 
>> 49:     public static void main(String[] args) throws Exception {
>> 50:         Test6227536 test = new Test6227536();
> 
> Calling the constructor just to get the class name seems redundant, as the test name will appear in all of the jtreg test output.  I would probably pull it out, just my $0.02.

Ack. It's also a nice pattern for avoiding issues with `main` being `static`.

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

PR: https://git.openjdk.org/jdk/pull/9679

From kdriver at openjdk.org  Fri Jul 29 20:33:04 2022
From: kdriver at openjdk.org (Kevin Driver)
Date: Fri, 29 Jul 2022 20:33:04 GMT
Subject: Integrated: 6227536: KeyGenerator.init() methods do not throw
 IllegalArgumentException for keysize == 0
In-Reply-To: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
References: <k3sHN5UxqtbQkblpaWegHcBNECS7AHnNBwBhv6kGmFw=.32e72a56-e5eb-462a-b191-704654325aa4@github.com>
Message-ID: <vqW6WVOMcS4EWdKlYE2UR_3f7u_yD3CbjUpcZVSLWcs=.8872f76d-46ff-40be-ab2f-0e6fd08b47d2@github.com>

On Thu, 28 Jul 2022 17:32:57 GMT, Kevin Driver <kdriver at openjdk.org> wrote:

> As mentioned in the bug report, this issue *should not* be a framework-level issue, since potentially an individual provider could create a keysize of zero to have a certain significance. 
> 
> In the changes made here for `HmacMD5`- and `HmacSHA1`- `KeyGenerator`s, the check is for `keysize <= 0` and this message indicates this is a check characteristic to the `SunJCE` provider.

This pull request has now been integrated.

Changeset: 0bcf1767
Author:    Kevin Driver <kdriver at openjdk.org>
Committer: Bradford Wetmore <wetmore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0bcf17674e1c8c07ede3aef6449e0631e526ba86
Stats:     76 lines in 3 files changed: 74 ins; 0 del; 2 mod

6227536: KeyGenerator.init() methods do not throw IllegalArgumentException for keysize == 0

Reviewed-by: wetmore

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

PR: https://git.openjdk.org/jdk/pull/9679