RFR: 8331008: Implement JEP 478: Key Derivation Function API (Preview) [v10]

[Kevin Driver]

On Mon, 12 Aug 2024 23:12:55 GMT, Anthony Scarpino <ascarpino at openjdk.org> wrote:

>> Kevin Driver has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
>> 
>>  - update test to include Spi updates
>>  - Update with latest from master
>>    
>>    Merge remote-tracking branch 'origin/master' into kdf-jep-wip
>>    # Please enter a commit message to explain why this merge is necessary,
>>    # especially if it merges an updated upstream into a topic branch.
>>    #
>>    # Lines starting with '#' will be ignored, and an empty message aborts
>>    # the commit.
>>  - add engineGetKDFParameters to the KDFSpi
>>  - code review comment fix for javadoc specification
>>  - change course on null return values from derive methods
>>  - code review comments
>>  - threading refactor + code review comments
>>  - review comments
>>  - review comments
>>  - update code snippet type in KDF
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/2ab93316...dd2ee48f
>
> src/java.base/share/classes/com/sun/crypto/provider/HkdfKeyDerivation.java line 144:
> 
>> 142:                 salt = consolidateKeyMaterial(salts);
>> 143:             } catch (InvalidKeyException ike) {
>> 144:                 throw (InvalidAlgorithmParameterException) new InvalidAlgorithmParameterException(
> 
> Why are you using `initCause()` here when there is a [constructor](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/security/InvalidAlgorithmParameterException.html#%3Cinit%3E(java.lang.String,java.lang.Throwable)) is available and the following catch uses the `NSAE` version of the constructor?
> This isn't the only usage of `initCause()`

I believe these are left over from when the exception type was different and such a constructor was not available for the previous type. I think this qualifies as a nit, since the resultant behavior is equivalent. I'll leave as-is, since we have debated this exception type previously, and it is possible that it may change again in the preview cycle.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20301#discussion_r1720175757