Looks good.
--Sean
On 5/7/18 11:18 PM, sha.ji...@oracle.com wrote:
Hi Sean,
Thanks for your comments.
Please review at this updated webrev:
http://cr.openjdk.java.net/~jjiang/8199388/webrev.01/
Best regards,
John Jiang
On 08/05/2018 03:58, Sean Mullan wrote:
- test/lib/jdk/test/lib/Utils.j
- ChaCha20ParameterSpec.java
The methods don't need to be final now that the class is final.
- ChaCha20Poly1305Parameters.java
122 if (decodingMethod.equalsIgnoreCase(DEFAULT_FMT)) {
123 engineInit(encoded);
The spec for engineInit() says if decodingMethod is null, the de
I'll make those fixes. One question with respect to the final methods:
the CSR had those methods in the description and they were marked as
final. That CSR is now complete. Will removing the final qualifier in
the methods be an issue? In terms of effect on the code it doesn't
matter. It's
On 5/8/18 1:52 PM, Jamil Nimeh wrote:
I'll make those fixes. One question with respect to the final methods:
the CSR had those methods in the description and they were marked as
final. That CSR is now complete. Will removing the final qualifier in
the methods be an issue? In terms of effect
Hi,
"final" is a important modifier of the method signature and if the CSR
and the implementation are
different it might raise a question about which is the correct signature
when the JCK folks write tests.
It is pretty lightweight process to return the CSR to draft and update
it and finaliz
To clarify, both the impl and the CSR mark the ChaCha20ParameterSpec
class as final, but the CSR also (accidentally) marked the methods of
the class as final. If that qualifies as an API change, then we should
fix the CSR, but I don't know for sure. It's an odd case.
--Sean
On 5/8/18 2:03 PM,
Okay, let me fix the code and the CSR and make them match. I'll put the
CSR back in draft and make a note in the comments about what is
changing. This is an innocuous change, but if Sean feels that code-wise
the final class should not have final methods, then making the CSR match
the fixed co
test/jdk/sun/security/tools/jarsigner/JarSigning.keystore is still using
512-bit DSA and it's disabled in jar signing now.
I just updated it and added a README.
diff --git a/test/jdk/sun/security/tools/jarsigner/JarSigning.keystore.README
b/test/jdk/sun/security/tools/jarsigner/JarSigning.keyst
Looks fine to me.
BTW, does it make sense to support more signature algorithms other than
DSA and RSA?
Thanks,
Xuelei
On 5/8/2018 5:29 PM, Weijun Wang wrote:
test/jdk/sun/security/tools/jarsigner/JarSigning.keystore is still using
512-bit DSA and it's disabled in jar signing now.
I just up
> On May 9, 2018, at 8:36 AM, Xuelei Fan wrote:
>
> Looks fine to me.
>
> BTW, does it make sense to support more signature algorithms other than DSA
> and RSA?
Most modern tests generate key/cert pairs inside the test (because we don't
like binary files). This file is used by old tests and
On 5/8/2018 5:39 PM, Weijun Wang wrote:
On May 9, 2018, at 8:36 AM, Xuelei Fan wrote:
Looks fine to me.
BTW, does it make sense to support more signature algorithms other than DSA and
RSA?
Most modern tests generate key/cert pairs inside the test (because we don't
like binary files). Th
11 matches
Mail list logo
