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

[Krushna948]

On Thu, 21 Aug 2025 20:47:09 GMT, Valerie Peng <valeriep at 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:
> 
>   Update to address Weijun's comment.

src/java.base/share/classes/javax/crypto/Cipher.java line 603:

> 601:      * @throws NoSuchAlgorithmException if {@code transformation}
> 602:      *         is {@code null}, empty, in an invalid format,
> 603:      *         or if a {@code CipherSpi} implementation from the specified

IMO, 
NoSuchAlgorithmException - if transformation is null, empty, in an invalid format, or if a CipherSpi implementation for the specified **transformation** is not available from the specified provider

The **transformation** can be linked to the class level mention 

A transformation is of the form:
"algorithm/mode/padding" or
"algorithm"

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

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