On Wed, 3 Sep 2025 18:55:57 GMT, Valerie Peng <[email protected]> wrote:
>> test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/unittest/ChaCha20CipherUnitTest.java
>> line 91:
>>
>>> 89: System.out.println("Expected transformation: " +
>>> transformation);
>>> 90: }
>>> 91: } catch (NoSuchAlgorithmException | NoSuchPaddingException e) {
>>
>> I think it would be good to enhance this test to distinguish between the
>> expected exceptions for each transformation.
>
> Well, which exception is thrown depends on which provider is used and how it
> registers its implementations. Pinpointing the exact Exception would require
> running the test against a specific provider which we know how the
> implementations are registered. Without tying the test to a specific
> provider, existing transformations in this test may lead to either NSAE or
> NSPE, thus I just add NSPE to the catch clause. I can add more
> transformations which would lead to only NSAE assuming this is what you want
> to see?
I think it is ok to assume the JDK provider configuration has not been changed.
Wouldn't "ChaCha20/None/PKCS5Padding" and
""ChaCha20-Poly1305/None/PKCS5Padding"" always throw `NoSuchPaddingException`,
assuming the current JDK configuration is not changed? Maybe instead of passing
a boolean expected parameter, you could pass the expected Exception, or null if
none expected.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26489#discussion_r2319968739
