On Fri, 9 Aug 2024 01:59:46 GMT, Anthony Scarpino <ascarp...@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/48952c86...dd2ee48f > > src/java.base/share/classes/javax/crypto/KDF.java line 121: > >> 119: private Iterator<Service> serviceIterator; >> 120: >> 121: private final Object lock; > > Why are you using an `Object` as a lock instead of something like > `ReentrantLock`? I realize older implementations used this style, but does > this need to be mimicked? @valeriepeng: I did some research. Based upon what I have seen, no `volatile` keyword is required here. This is also consistent with the `Cipher` API, for example. @ascarpino: I looked up `ReentrantLock`s, and I’m not sure those make sense for the use-case. A simple mutex lock should suffice, since we will not be spinning for long. In addition, as mentioned above, we are consistent with the other JCE/JCA classes by using this paradigm. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20301#discussion_r1739506117
