RFR: 8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange [v9]
Hai-May Chao
hchao at openjdk.org
Mon Dec 8 16:04:20 UTC 2025
On Mon, 8 Dec 2025 15:46:36 GMT, Sean Mullan <mullan at openjdk.org> wrote:
>> It turns out this is a mistake. By having both this line and 48 with the same algorithm names, the benchmark runs them twice. Our benchmarks tend to be organized either with the main class as a baseline benchmark with subclasses for all other types, or an abstract base class with an empty @param tag and subclasses for each actual benchmark. `KeyAgreementBench.java` is done that way, and I personally like that approach better and changed this class to follow that model. Either way is just fine though. The important thing is that if you have parameters in the parent class, it should not match any parameter sets in the child classes or you just end up running the same benchmark twice.
>
> Thanks for fixing these comments on KEMBench. @haimaychao you can resolve this and the other 2 KEMBench related conversations now.
Done.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27614#discussion_r2599190737
More information about the security-dev
mailing list