8360463: Ambiguity in Cipher.getInstance() specification between NoSuchAlgorithmException and NoSuchPaddingException

[valeriepeng]

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

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change requires CSR request JDK-8364134 to be approved

Issues

• JDK-8360463: Ambiguity in Cipher.getInstance() specification between NoSuchAlgorithmException and NoSuchPaddingException (Bug - P3)
• JDK-8364134: Ambiguity in Cipher.getInstance() specification between NoSuchAlgorithmException and NoSuchPaddingException (CSR)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/26489/head:pull/26489
$ git checkout pull/26489

Update a local copy of the PR:
$ git checkout pull/26489
$ git pull https://git.openjdk.org/jdk.git pull/26489/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 26489

View PR using the GUI difftool:
$ git pr show -t 26489

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/26489.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back valeriep! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@valeriepeng The following label will be automatically applied to this pull request:

• security

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[valeriepeng]

/csr

[openjdk]

@valeriepeng has indicated that a compatibility and specification (CSR) request is needed for this pull request.

@valeriepeng please create a CSR request for issue JDK-8360463 with the correct fix version. This pull request cannot be integrated until the CSR request is approved.

[mlbridge]

Webrevs

• 02: Full - Incremental (92ae5bce)
• 01: Full - Incremental (aa992966)
• 00: Full (2bedc41d)

[haimaychao]

Changes look good with minor suggestions.

[haimaychao]

suggest to s/{@code CipherSpi} object/{@code CipherSpi} implementation, consistent with other places.

[valeriepeng]

Sure, will change~

[haimaychao]

Suggest to s/from the/from the specified, and to make the same changes in this method at lines #567 and #568, s/the specified provider/the specified {@code provider}.

[valeriepeng]

Sure, will change~

[haimaychao]

same suggestion as above.

[valeriepeng]

Yes

[haimaychao]

same suggestion as above.

[valeriepeng]

Yes

[wangweij]

Is it worth demonstrating the different behaviors with a test?

[valeriepeng]

Is it worth demonstrating the different behaviors with a test?

This is covered by existing TCK test and thus the request for clarification. This is provider-specific, i.e. depending on how provider registers its implementation, it may leads to different exceptions. Given that the difference is only the type of exception, e.g. NoSuchAlgorithmException vs NoSuchPaddingException, I don't feel it's that critical to add a regression test in addition to the existing TCK test.