This RFE enhances existing PBE algorithms with the "SHA512/224" and
"SHA512/256" support.
Current transformation parsing in javax.crypto.Cipher class is re-written to
handle the additional "/" in the "SHA512/224" and "SHA512/256" algorithm names.
Existing tests are updated with the additional n
Regarding mainline:
- I decided not to 'unroll' the top while loop (i.e. `engineUpdate(byte[]
input, int offset, int len)` is unrolled)
- It is debatable which version is easier to understand. If this version is
'too complex', I can unroll the top while loop.
- I do think this version is incr
On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons wrote:
>> Please review a "somewhat automated" change to insert `@spec` tags into doc
>> comments, as appropriate, to leverage the recent new javadoc feature to
>> generate a new page listing the references to all external specifications
>> li
On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons wrote:
>> Please review a "somewhat automated" change to insert `@spec` tags into doc
>> comments, as appropriate, to leverage the recent new javadoc feature to
>> generate a new page listing the references to all external specifications
>> li
On Wed, 23 Nov 2022 19:20:53 GMT, Daniel Fuchs wrote:
> The java.base/net/, java.http/, java.naming/ changes look reasonable to me -
> though like Alan I wonder if it wouldn't be better to have an inline `{@spec
> }` tag - similar to `{@systemProperty }`, rather than repeating all the
> refere
On Wed, 23 Nov 2022 05:22:10 GMT, Kim Barrett wrote:
>> It's to avoid redefining the linkage as static in os_windows.cpp (where it's
>> implemented) after an extern declaration (inside the class), which is
>> forbidden by C++11:
>>
>>> The linkages implied by successive declarations for a give
> This is mostly cleanup. Everything around `DerOutputStream` no longer throws
> an `IOException`. This includes:
>
> - Remove unnecessary `throws IOException` in code and spec
> - Remove `catch (IOException ioe)` blocks. If new exception is thrown, remove
> further `throws` in code and spec
> -
On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons wrote:
>> Please review a "somewhat automated" change to insert `@spec` tags into doc
>> comments, as appropriate, to leverage the recent new javadoc feature to
>> generate a new page listing the references to all external specifications
>> li
> Please review a "somewhat automated" change to insert `@spec` tags into doc
> comments, as appropriate, to leverage the recent new javadoc feature to
> generate a new page listing the references to all external specifications
> listed in the `@spec` tags.
>
> "Somewhat automated" means that I
On Wed, 23 Nov 2022 01:25:44 GMT, Valerie Peng wrote:
> Anyone can help reviewing this trivial RFE? Mostly just making clarifications
> on exception messages as submitter requested. Enhanced existing test case to
> check on this particular scenario.
This pull request has now been integrated.
On Wed, 23 Nov 2022 01:25:44 GMT, Valerie Peng wrote:
> Anyone can help reviewing this trivial RFE? Mostly just making clarifications
> on exception messages as submitter requested. Enhanced existing test case to
> check on this particular scenario.
Thanks for the review~
-
PR: h
I’m not very sure what the update public APIs may look like. If we are able to
collect the possible card exception reasons, the design of
CertPathValidatorException and CertPathValidatorException.BasicReason could be
a reference.
Xuelei
> On Nov 23, 2022, at 9:21 AM, Michael StJohns wrote:
>
On Wed, 23 Nov 2022 16:14:52 GMT, Maurizio Cimadamore
wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Cleanup
>
> src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 125:
>
>> 123: * @see
On 11/22/2022 10:24 PM, Xue-Lei Andrew Fan wrote:
On Wed, 23 Nov 2022 02:59:47 GMT, Michael StJohns wrote:
… CardException doesn't always pass through the details in a comprehensible way
from the underlying cause, …
Does it sound like a cause that the public APIs are not sufficient?
Alterna
On Wed, 23 Nov 2022 12:43:16 GMT, Daniel Fuchs wrote:
> Thanks for adding the RFC prefix to the RFC link. What is the purpose of
> editing non exported classes though, like those in the `sun.net` subpackages?
That was not intentional, and is a result of the scripted edit. I will look to
r
On Wed, 23 Nov 2022 12:39:40 GMT, Per Minborg wrote:
>> This PR proposes the introduction of **guarding** of the use of
>> `DirectBuffer::address` within the JDK. With the introduction of the Foreign
>> Function and Memory access, it is possible to derive Buffer instances that
>> are backed by
On Wed, 23 Nov 2022 12:35:17 GMT, Alan Bateman wrote:
>> With the introduction of Virtual Threads, the current subject is no longer
>> guaranteed to be inherited in a new thread. Remove this requirement until we
>> find another way to implement `Subject::current`.
>
> Just re-reading the javado
On Wed, 23 Nov 2022 01:25:44 GMT, Valerie Peng wrote:
> Anyone can help reviewing this trivial RFE? Mostly just making clarifications
> on exception messages as submitter requested. Enhanced existing test case to
> check on this particular scenario.
Marked as reviewed by weijun (Reviewer).
--
On Wed, 23 Nov 2022 12:40:45 GMT, Weijun Wang wrote:
>> src/java.base/share/classes/sun/security/x509/CRLExtensions.java line 151:
>>
>>> 149:
>>> 150: DerOutputStream tmp = new DerOutputStream();
>>> 151: if (isExplicit)
>>
>> Use curley braces.
>
> I'll do. This is new code.
> This PR proposes the introduction of **guarding** of the use of
> `DirectBuffer::address` within the JDK. With the introduction of the Foreign
> Function and Memory access, it is possible to derive Buffer instances that
> are backed by native memory that, in turn, can be closed asynchronously
On Tue, 22 Nov 2022 22:04:57 GMT, Jonathan Gibbons wrote:
>> Please review a "somewhat automated" change to insert `@spec` tags into doc
>> comments, as appropriate, to leverage the recent new javadoc feature to
>> generate a new page listing the references to all external specifications
>> li
On Wed, 23 Nov 2022 04:19:42 GMT, Mark Powers wrote:
>> src/java.base/share/classes/sun/security/x509/IssuingDistributionPointExtension.java
>> line 121:
>>
>>> 119: boolean hasOnlyUserCerts, boolean hasOnlyCACerts,
>>> 120: boolean hasOnlyAttributeCerts, boolean isIndirectCRL)
On Wed, 23 Nov 2022 02:28:44 GMT, Mark Powers wrote:
>> This is mostly cleanup. Everything around `DerOutputStream` no longer throws
>> an `IOException`. This includes:
>>
>> - Remove unnecessary `throws IOException` in code and spec
>> - Remove `catch (IOException ioe)` blocks. If new exceptio
On Tue, 22 Nov 2022 16:26:30 GMT, Weijun Wang wrote:
> With the introduction of Virtual Threads, the current subject is no longer
> guaranteed to be inherited in a new thread. Remove this requirement until we
> find another way to implement `Subject::current`.
Just re-reading the javadoc for S
> This PR proposes the introduction of **guarding** of the use of
> `DirectBuffer::address` within the JDK. With the introduction of the Foreign
> Function and Memory access, it is possible to derive Buffer instances that
> are backed by native memory that, in turn, can be closed asynchronously
On Wed, 23 Nov 2022 06:21:05 GMT, Xue-Lei Andrew Fan wrote:
>> Hi,
>>
>> May I have this update reviewed? With this update, the result will be
>> reduced if required in EC limbs operations in the JDK implementation.
>>
>> In the current implementation, the EC limbs addition and subtraction re
On Wed, 23 Nov 2022 06:21:05 GMT, Xue-Lei Andrew Fan wrote:
>> Hi,
>>
>> May I have this update reviewed? With this update, the result will be
>> reduced if required in EC limbs operations in the JDK implementation.
>>
>> In the current implementation, the EC limbs addition and subtraction re
On Mon, 21 Nov 2022 08:15:53 GMT, Xue-Lei Andrew Fan wrote:
> I may run it again after the integration of multiplicative inversion and
> point multiplication improvement.
After the integration of the improvement above, here is the benchmark numbers
with this patch:
Benchmark
28 matches
Mail list logo