On Fri, 12 Sep 2025 19:10:04 GMT, Anthony Scarpino <ascarp...@openjdk.org> wrote:
>> Weijun Wang has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 58 commits: >> >> - Merge branch 'master' into 8325448 >> - about transformation >> - cannot reset with withMethods >> - algorithm identifier >> - withMethods >> - duplicated "value" words >> - receiver to recipient; different to specified >> - use different exception type >> - more spec change >> - address Sean's comments >> - ... and 48 more: https://git.openjdk.org/jdk/compare/7fcce270...1ec31cf5 > > src/java.base/share/classes/javax/crypto/spec/HPKEParameterSpec.java line 154: > >> 152: /** >> 153: * KEM algorithm identifier for DHKEM(P-256, HKDF-SHA256) as >> defined in >> 154: * <a >> href="https://www.rfc-editor.org/rfc/rfc9180.html#name-key-encapsulation-mechanism";>Section >> 7.1 of RFC 9180</a>. > > Suggestion: It has been my impression that `@spec` was for things like this. > Might it be cleaner to remove the "as defined in <link>" and just list the > RFC in an `@spec`? It also seems overkill to refer to the RFC sections for > each entry as you mention that the id's are in in Section 7 in the class > javadoc. Both `PBEParameterSpec` and `HKDFParameterSpec` have RFC links appears in the javadoc text and as a `@spec`. I know `PEMEncoder` has not. For links into RFC sections, I was trying to be as helpful as possible. There are quite some concept here like modes and algorithm identifiers. Maybe those in the constants are too much. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18411#discussion_r2345594111
