On Wed, 7 Aug 2024 00:25:09 GMT, Valerie Peng <valer...@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/4fcf73db...dd2ee48f > > src/java.base/share/classes/javax/crypto/KDFSpi.java line 65: > >> 63: * @param kdfParameters >> 64: * the initialization parameters for the {@code KDF} algorithm >> (may be >> 65: * {@code null}) > > Should we further specify what {@code null} means or when it is > (not-)allowed? For KDF algorithms which does not use initialization > parameters, {@code null} should be specified, otherwise IAPE is thrown? > However, for KDF algorithms which use initialization parameters, can {@code > null} be specified? Is it ok for the provider to choose their own default > values when {@code null} is specified through {@code KDF.getInstance()} > calls? But then callers have to call {@code KDF.getKDFParameters()} to > check/find out? I would answer yes, yes, yes, yes, and YES. :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20301#discussion_r1707404257
