On Fri, 6 Sep 2024 13:31:07 GMT, Viktor Klang <vkl...@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 31 additional >> commits since the last revision: >> >> - 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. >> - several more review comments >> - change impl class to use byte arrays rather than SecretKey objects where >> possible >> - updated delayed provider selection javadoc >> - review comments >> - use a delegate record to hold the spi and provider >> - assorted review comment changes >> - another round of review comments >> - consistency with wording for addIKM and addSalt >> - another round of code review comments >> - ... and 21 more: https://git.openjdk.org/jdk/compare/82b8020a...a35e98c9 > > src/java.base/share/classes/com/sun/crypto/provider/HkdfKeyDerivation.java > line 259: > >> 257: os.writeBytes(CipherCore.getKeyBytes(workItem)); >> 258: } >> 259: return os.toByteArray(); > > I haven't found any specification indicating that flush is not required > before toByteArray(), but it can't hurt right? > > Suggestion: > > os.flush(); > return os.toByteArray(); `os.flush()` requires catching an `IOException`. Do you suggest wrapping it in the `InvalidKeyException` already thrown by the method if it should occur? As you mention, it doesn't appear to be strictly necessary, and the javadoc for `toByteArray()` contains the following: Creates a newly allocated byte array. Its size is the current size of this output stream and the valid contents of the buffer have been copied into it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20301#discussion_r1747548819
