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

Kevin Driver kdriver at openjdk.org
Tue Aug 13 14:25:56 UTC 2024


On Mon, 5 Aug 2024 17:36:36 GMT, Sean Mullan <mullan 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/f258b719...dd2ee48f
>
> 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?

@seanjmullan: This text was added here at @wangweij's request, since he felt that it should be explicitly stated that null cannot be returned.

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

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



More information about the security-dev mailing list