On Wed, 13 Aug 2025 00:13:25 GMT, Valerie Peng <valer...@openjdk.org> wrote:
>> This PR is for clarifying the `NoSuchAlgorithmException` and >> `NoSuchPaddingException` for the `Cipher.getInstance(String transformation, >> Provider provider)` and `Cipher.getInstance(String transformation, String >> provider)` methods. >> >> As stated in `javax.crypto.CipherSpi` class, provider has the flexibility to >> register their implementations through various sub-transformations. As a >> result, depending on how the providers register the implementation, it may >> lead to `NoSuchAlgorithmException` or `NoSuchPaddingException`. For example, >> the provider A registers to support "AES/CBC/PKCS5Padding" vs provider B >> registers to support "AES" (but would only accept "CBC" and "PKCS5Padding" >> as the valid input for setting mode and padding). Calling >> `Cipher.getInstance(...)` with "AES/CBC/NoPadding" against provider A and B >> would lead to `NoSuchAlgorithmException` and `NoSuchPaddingException`. This >> javadoc update hope to make it clear. >> >> Thanks in advance for the review~ >> Valerie > > Valerie Peng has updated the pull request incrementally with one additional > commit since the last revision: > > Added a missing "specified" for consistency. I wonder if we should list NSPE before NSAE, since NSAE refers to it. Or, can we just say NSAE is thrown when the specified algorithm and mode are not supported? Also, is this consistent among other security providers? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26489#issuecomment-3203201824 PR Comment: https://git.openjdk.org/jdk/pull/26489#issuecomment-3203215399
