On Fri, 2 Aug 2024 19:19:54 GMT, Kevin Driver <kdri...@openjdk.org> wrote:
>> Introduce an API for Key Derivation Functions (KDFs), which are >> cryptographic algorithms for deriving additional keys from a secret key and >> other data. See [JEP 478](https://openjdk.org/jeps/478). >> >> Work was begun in [another PR](https://github.com/openjdk/jdk/pull/18924). > > 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/4742c70e...dd2ee48f Changes requested by mullan (Reviewer). src/java.base/share/classes/javax/crypto/KDF.java line 458: > 456: * @param alg > 457: * the algorithm of the resultant {@code SecretKey} object > 458: * @param kdfParameterSpec I think this parameter should be renamed to `derivationParameterSpec` (or something similar) to avoid confusion with the `kdfParameterSpec` variable passed to `getInstance`. src/java.base/share/classes/javax/crypto/KDF.java line 465: > 463: * permitting a {@code null} return value here, implementations > will > 464: * handle cases where a value cannot be returned by throwing an > 465: * appropriate {@code Exception}. We don't need to specify that `null` is not a valid return value in APIs, it is assumed *unless* you specify that `null` is a valid return value. Otherwise, applications would have to defensively check for `null` for every method where it is not specified, which would be impractical. I think the text above is in the wrong place. If there are situations where an implementation should throw an exception, then it should be specified in the @throws blocks. Is this a case where something has gone seriously wrong and a `ProviderException` should be thrown? ------------- PR Review: https://git.openjdk.org/jdk/pull/20301#pullrequestreview-2219520257 PR Review Comment: https://git.openjdk.org/jdk/pull/20301#discussion_r1704428295 PR Review Comment: https://git.openjdk.org/jdk/pull/20301#discussion_r1704440267
