RFR: 8360463: Ambiguity in Cipher.getInstance() specification between NoSuchAlgorithmException and NoSuchPaddingException [v6]

[Sean Mullan]

On Wed, 3 Sep 2025 18:55:57 GMT, Valerie Peng <valeriep at openjdk.org> 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