RFR: 8328119: Support HKDF in SunPKCS11 (Preview) [v10]

[Francisco Ferrari Bihurriet]

On Sat, 11 Jan 2025 04:13:14 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> This way, there is no need for the 3 XXXKeyMaterialMerger (where XXX: Any/Data/Key) and the merging code is in 1 method instead of handled over 4 different methods.
>
> May be a matter of taste and trade-offs, but I personally lean more towards the object-oriented/polymorphic design. While a bit more verbose, I like the separation of responsibilities, the closed-world type of transitions in the states machine and the potential for extensibility. The procedural approach bases transitions in the state of a record that is not self-explanatory, opens the world to the reader for meaningless instantiations/states (e.g. with a key and a byte array, or with `isBytes = false` and a byte array) and is less extensible. That type of aggregation could be just fields in the merger class, and I don't see the point of doing `keyMerger = keyMerger.merge(key);` for a method that can only return `this`. @franferrax ?

@martinuy: I agree and also acknowledge that it might be a matter of taste. In my view, the object-oriented/polymorphic design looks more idiomatic. Even if it spans a couple more classes/methods, each of them is shorter and simpler. Overall, it requires less control flow statements and clarifying comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22215#discussion_r1913532228