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

[Valerie Peng]

On Wed, 3 Sep 2025 19:24:46 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> 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.

Yes, I have adopted your suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26489#discussion_r2357056150