JDK-8291414 : Fix the incorrect wording about delayed provider selection in the PKCS11 documentation
  • Type: Sub-task
  • Component: docs
  • Sub-Component: guides
  • Priority: P3
  • Status: Resolved
  • Resolution: Delivered
  • Submitted: 2022-07-27
  • Updated: 2022-08-04
  • Resolved: 2022-08-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 17 JDK 19 JDK 8
11.0.7-oracleResolved 17.0.5-oracleResolved 19Resolved 8u351Unresolved
Description
The PKCS11 provider document makes a statement about the delayed
selection mechanism which is inconsistent with the implementation.
It claims that for Cipher, KeyAgreement, Mac, etc.:

    If an application calls the initialization method multiple times
    (each time with a different key, for example), the proper provider
    for the given key is selected each time. In other words, a
    different provider may be selected for each initialization call.
Comments
[11u], [17u] Change to documentation, not applicable to these update projects.
04-08-2022
Changes look good~
01-08-2022
The paragraph which states: Furthermore, if an application calls the initialization method multiple times (each time with a different key, for example), the proper provider for the given key is selected each time. In other words, a different provider may be selected for each initialization call. Should be updated to: Note that once the provider is selected, e.g. after the first initialization call, it will not switch to a different provider for subsequent initialization calls. To re-select a provider based on the given key, the application should call getInstance() to get a fresh instance and then call initialization method with the desired key instead of reusing the prior already-initialized instance. Just my suggestion. Please feel free to make adjustments.
27-07-2022