8353578: Refactor existing usage of internal HKDF impl to use the KDF API by valeriepeng · Pull Request #24393 · openjdk/jdk

valeriepeng · 2025-04-02T21:43:19Z

This PR removes the internal JSSE HKDF impl and changes to use the KDF API for the HKDF support from JCA/JCE providers.

This is just code refactoring. Known-answer regression test for the internal JSSE HKDF impl is removed as the test vectors are already covered by the HKDF impl in SunJCE provider.

JPRT Tier1-3 result: https://mach5.us.oracle.com/mdash/jobs/vpeng-jdkOh3-20250512-2316-27739411

Thanks in advance for the review~

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8353578: Refactor existing usage of internal HKDF impl to use the KDF API (Enhancement - P3)

Reviewers

Daniel Jeliński (@djelinski - Reviewer)
Bradford Wetmore (@bradfordwetmore - Reviewer)
Weijun Wang (@wangweij - Reviewer) Review applies to cc7fd3a0
Sean Mullan (@seanjmullan - Reviewer)
Kevin Driver (@driverkt - Committer)

Contributors

Kevin Driver <kdriver@openjdk.org>

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/24393/head:pull/24393
$ git checkout pull/24393

Update a local copy of the PR:
$ git checkout pull/24393
$ git pull https://git.openjdk.org/jdk.git pull/24393/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 24393

View PR using the GUI difftool:
$ git pr show -t 24393

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/24393.diff

Using Webrev

Link to Webrev Comment

… API

bridgekeeper · 2025-04-02T21:44:00Z

👋 Welcome back valeriep! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2025-04-02T21:44:58Z

@valeriepeng This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8353578: Refactor existing usage of internal HKDF impl to use the KDF API

Co-authored-by: Kevin Driver <kdriver@openjdk.org>
Reviewed-by: djelinski, wetmore, mullan, kdriver, weijun

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 739 new commits pushed to the master branch:

b8c69df: 8356551: Javac rejects receiver parameter in constructor of local class in early construction context
64a858c: 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath
066477d: 8356080: Address post-integration comments for Stable Values
... and 736 more: https://git.openjdk.org/jdk/compare/6970cf6ac69864e7027138746361e7da1983c24d...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

openjdk · 2025-04-02T21:45:30Z

@valeriepeng The following label will be automatically applied to this pull request:

security

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

valeriepeng · 2025-04-02T21:45:54Z

/contributor driverkt

openjdk · 2025-04-02T21:46:25Z

@valeriepeng Syntax: /contributor (add|remove) [@user | openjdk-user | Full Name <email@address>]. For example:

/contributor add @openjdk-bot
/contributor add duke
/contributor add J. Duke <duke@openjdk.org>

User names can only be used for users in the census associated with this repository. For other contributors you need to supply the full name and email address.

valeriepeng · 2025-04-02T21:48:27Z

/contributor add driverkt

openjdk · 2025-04-02T21:49:00Z

@valeriepeng driverkt was not found in the census.

Syntax: /contributor (add|remove) [@user | openjdk-user | Full Name <email@address>]. For example:

/contributor add @openjdk-bot
/contributor add duke
/contributor add J. Duke <duke@openjdk.org>

User names can only be used for users in the census associated with this repository. For other contributors you need to supply the full name and email address.

mlbridge · 2025-04-02T21:52:03Z

Webrevs

valeriepeng · 2025-04-02T21:59:11Z

/contributor add kdriver

openjdk · 2025-04-02T21:59:32Z

@valeriepeng
Contributor Kevin Driver <kdriver@openjdk.org> successfully added.

wangweij · 2025-04-02T23:22:40Z

src/java.base/share/classes/sun/security/ssl/KAKeyDerivation.java

-                        = hkdf.extract(zeros, ikm, "TlsEarlySecret");
+                SecretKey earlySecret = hkdf.deriveKey("TlsEarlySecret",
+                        HKDFParameterSpec.ofExtract().addSalt(zeros)
+                        .addIKM(ikm).extractOnly());


Maybe no need for addSalt(zeros). I remember salt is by default zeros for HKDF.

Yes, I am on the fence about this. Given the specified value is the same as the default, it can be removed. I kept it there so the new code matches the original code completely. Not much difference either way I think.

I like having it there to communicate that is really the intent.

djelinski

LGTM. Thanks!

bradfordwetmore

The rest looks good.

Nice to get this done finally!

bradfordwetmore · 2025-04-04T22:18:31Z

src/java.base/share/classes/sun/security/ssl/Utilities.java

+    static String digest2HKDF(String digestAlg) throws SSLHandshakeException {
+        String sanitizedAlg = digestAlg.replace("-", "");
+        return switch (sanitizedAlg) {
+            case "SHA256", "SHA384", "SHA512" -> "HKDF-" + sanitizedAlg;


This is a nit, but currently we don't have SHA512 in CipherSuite.HashAlg. You can leave it for any future enhancements.

You could also consider storing the HKDF algorithm names in the HashAlg enum. Not sure if it would make much difference, performance wise.

Yes, this sounds better for overall consistency. Will adopt the HashAlg enum suggestion.

bradfordwetmore · 2025-04-04T23:05:01Z

src/java.base/share/classes/sun/security/ssl/KAKeyDerivation.java

-                        = hkdf.extract(zeros, ikm, "TlsEarlySecret");
+                SecretKey earlySecret = hkdf.deriveKey("TlsEarlySecret",
+                        HKDFParameterSpec.ofExtract().addSalt(zeros)
+                        .addIKM(ikm).extractOnly());


I like having it there to communicate that is really the intent.

refactored code to remove unused AlgorithmParameterSpec argument.

seanjmullan · 2025-04-07T16:42:14Z

src/java.base/share/classes/sun/security/ssl/RSAKeyExchange.java

            @Override
-            public SecretKey deriveKey(String algorithm,
-                    AlgorithmParameterSpec params) throws IOException {
+            public SecretKey deriveKey(String type) throws IOException {


How about changing the variable name to typeNotUsed like SSLKeyDerivation.LegacyMasterKeyDerivation?

Yes, missed this one.

seanjmullan · 2025-04-07T16:44:58Z

src/java.base/share/classes/sun/security/ssl/SSLKeyDerivation.java

-            AlgorithmParameterSpec params) throws IOException;
+    SecretKey deriveKey(String purpose) throws IOException;
+
+    default byte[] deriveData(String purpose) throws IOException {


This is an internal interface, so I don't think you need to make this a default method.

I didn't add deriveData(String) impl to all the existing impls of SSLKeyDerivation. Only impls used for deriving IVs are updated to add impl for deriveData(String), so the default method is necessary.

djelinski

Still looks good.

The changes here are not enough to get the NSS-FIPS library to complete TLS1.3 handshake, but it's a big step in the right direction. I think we can fix the remaining issues separately.

cleanup interim security values changed PKCS11 HKDF impl to allow key algorithms starting with "Tls" as generic keys

djelinski

still LGTM.

djelinski · 2025-04-25T10:40:47Z

src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java

+            } finally {
+                if (eae_prk instanceof SecretKeySpec s) {
+                    SharedSecrets.getJavaxCryptoSpecAccess()
+                            .clearSecretKeySpec(s);


I wish we could use s.destroy() here instead.

Yes, it'd be nice. I reopened https://bugs.openjdk.org/browse/JDK-8160206 and we can address this separately.

Or in the meantime:

} finally { // Best effort if (eae_prk instanceof SecretKeySpec s) { SharedSecrets.getJavaxCryptoSpecAccess() .clearSecretKeySpec(s); } else { try { eae_prk.destroy(); } catch (DestroyFailedException e) { // swallow } } }

Sounds good, thanks for the suggestion.

This is what I did in my Exporter code. Assuming you go in first, I'll update mine to use your Util method.

wangweij · 2025-04-25T15:36:26Z

src/java.base/share/classes/sun/security/ssl/KAKeyDerivation.java


            // derive handshake secret
-            return hkdf.extract(saltSecret, sharedSecret, algorithm);
+            return hkdf.deriveKey(type, HKDFParameterSpec.ofExtract()


The line above may fail because the hkdf object has been used once on line 121 with zero-valued salt and IKM, which selected the software-based HKDF from SunJCE. At this point, however, sharedSecret is the result of ECDH and may be non-extractable if produced by an HSM, making it incompatible with the SunJCE implementation. To avoid this issue, get a new hkdf by calling hkdf = KDF.getInstance(hashAlg.hkdfAlgorithm) before this line.

Hmm, ok, interesting scenario. I add another KDF.getInstance() call as you suggested just to be safe.

I think that deserves a code comment; it's far from obvious why we do that. Also, we will make P11 work with zero-valued salt soon.

wangweij · 2025-04-25T15:41:09Z

src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java

-                    hkdfInfo, hashAlg.hashLength, "TlsBinderKey");
+            return hkdf.deriveKey("TlsBinderKey",
+                    HKDFParameterSpec.expandOnly(earlySecret, hkdfInfo,
+                    hashAlg.hashLength));


Is it possible to combine the 2 deriveKey calls above into a single Extract-Then-Expand call? Then you don't need to clean up earlySecret.

Should be possible, let me give it a try. Thanks~

seanjmullan · 2025-04-30T14:58:39Z

src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java


    private static SecretKey deriveBinderKey(HandshakeContext context,
            SecretKey psk, SSLSessionImpl session) throws IOException {
+        SecretKey earlySecret = null;


unused variable, can delete.

seanjmullan · 2025-04-30T15:04:52Z

src/java.base/share/classes/sun/security/ssl/Finished.java

@@ -35,9 +35,11 @@
 import java.security.spec.AlgorithmParameterSpec;


Can remove import now.

seanjmullan · 2025-04-30T15:49:16Z

src/java.base/share/classes/sun/security/ssl/ServerHello.java

@@ -620,7 +622,7 @@ public byte[] produce(ConnectionContext context,

            SSLKeyDerivation handshakeKD = ke.createKeyDerivation(shc);
            SecretKey handshakeSecret = handshakeKD.deriveKey(


It looks like this can be cleared after it is used to derive the key. Similar comment on line 1310.

Well, I am not sure if clearing handshakeSecret is ok - this handshakeSecret is passed to kd on line 636 and stored internally without cloning. Then kd is stored into shc which suggests that it may be used later. Clearing it will likely cause problems for subsequent key derivations? Same goes for line 1310. Is there something that I missed?

Ah, yes you are right.

bradfordwetmore · 2025-04-30T22:37:54Z

Missing test plan in the PR Description. (i.e. tier1/tier2/JCK?)

valeriepeng · 2025-05-01T18:49:53Z

Missing test plan in the PR Description. (i.e. tier1/tier2/JCK?)

I always run tier 1-3 tests for all of my PRs. Don't anticipate that this would affect JCK, but will give it a try just in case.
Thanks for the suggestion~

bradfordwetmore

Just a few comments to think about, and one copyright nit.

bradfordwetmore · 2025-05-06T04:40:02Z

src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java

+        try {
+            HKDFParameterSpec spec =
+                    HKDFParameterSpec.ofExtract().addIKM(s).extractOnly();
+            return hkdf.deriveKey("Generic", spec);


I haven't done much with DHKEM yet, but should the returned key have algorithm name of "Generic," or something more descriptive like the previous "HKDF-PRK"?

Me neither. However, given HKDF-PRK is not a standard algorithm and also not recognized by the SunPKCS11 provider, I changed it to Generic. Existing HKDF impl in the SunPKCS11 provider is quite strict about the derived key algorithms and it will error out unless we add HKDF-PRK to be a recognized key algorithm for key derivation. Given these reasons, it seems Generic is the better choice here.

Is any specific salt needed here like in TLS?

We should chat next week about an issue Weijun raised and the algorithm names in the Exporters.

bradfordwetmore · 2025-05-06T04:40:40Z

src/java.base/share/classes/sun/security/ssl/CipherSuite.java

Copyright update.

bradfordwetmore · 2025-05-06T04:58:41Z

src/java.base/share/classes/sun/security/ssl/ServerHello.java

-            byte[] zeros = new byte[hashAlg.hashLength];
-            SecretKey earlySecret = hkdf.extract(zeros, psk, "TlsEarlySecret");
+            KDF hkdf = KDF.getInstance(hashAlg.hkdfAlgorithm);
+            SecretKey earlySecret = hkdf.deriveKey("TlsEarlySecret",


I'm a little worried that the proper number of salt zeros are now expected to be known in the KDF deriveKey code instead of specified specifically here (and in other similar places). Should we consider specifying them here and the other places instead to play it safe?

I just found that we had talked about this previously. What was your reasoning for pulling it?

Call me paranoid, but I'm not seeing where the JDK 24 javadocs discuss what happens if salt is not supplied. RFC 8446/Section 7.1 states:

- "0" indicates a string of Hash.length bytes set to zero.

Ok, I will add it back just to be safe.

I thought there were other locations, but maybe I was just imagining it! ;)

bradfordwetmore · 2025-05-10T02:06:43Z

src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java

+        try {
+            HKDFParameterSpec spec =
+                    HKDFParameterSpec.ofExtract().addIKM(s).extractOnly();
+            return hkdf.deriveKey("Generic", spec);


Is any specific salt needed here like in TLS?

bradfordwetmore · 2025-05-10T02:10:14Z

src/java.base/share/classes/sun/security/util/KeyUtil.java

        return alg.equalsIgnoreCase("TlsPremasterSecret")
                || alg.equalsIgnoreCase("Generic");
    }
+


As you know, I've been working on the TLS Exporters change which will use the same KDF APIs. I've already updated that to use your style.

Looks like I've now got one more thing to change! ;)

This is a reply to the comment above. I don't know why GitHub does not show a reply box there.

Is any specific salt needed here like in TLS?

In DHKEM, the salt used is always empty.

So, no need to explicitly set it I assume? As this is a refactoring, I prefer to minimize changes unless consensus is different.

bradfordwetmore · 2025-05-10T02:12:38Z

src/java.base/share/classes/sun/security/ssl/ServerHello.java

-            byte[] zeros = new byte[hashAlg.hashLength];
-            SecretKey earlySecret = hkdf.extract(zeros, psk, "TlsEarlySecret");
+            KDF hkdf = KDF.getInstance(hashAlg.hkdfAlgorithm);
+            SecretKey earlySecret = hkdf.deriveKey("TlsEarlySecret",


I thought there were other locations, but maybe I was just imagining it! ;)

bradfordwetmore · 2025-05-10T02:15:10Z

src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java

+            } finally {
+                if (eae_prk instanceof SecretKeySpec s) {
+                    SharedSecrets.getJavaxCryptoSpecAccess()
+                            .clearSecretKeySpec(s);


This is what I did in my Exporter code. Assuming you go in first, I'll update mine to use your Util method.

bradfordwetmore · 2025-05-10T02:18:26Z

src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java

+        try {
+            HKDFParameterSpec spec =
+                    HKDFParameterSpec.ofExtract().addIKM(s).extractOnly();
+            return hkdf.deriveKey("Generic", spec);


We should chat next week about an issue Weijun raised and the algorithm names in the Exporters.

bradfordwetmore · 2025-05-10T02:22:05Z

You're probably good to go, but might check with Weijun/Sean/DJ in case there's anything last minute.

driverkt · 2025-05-12T16:48:47Z

I'll be looking too, but don't hold up integration to wait for my review.

driverkt · 2025-05-12T19:33:09Z

src/java.base/share/classes/sun/security/ssl/KAKeyDerivation.java


            // derive handshake secret
-            return hkdf.extract(saltSecret, sharedSecret, algorithm);
+            // NOTE: do not reuse the HKDF object for "TlsEarlySecret" for


Nit: There is no longer an "HKDF object". Might be worth updating this comment.

It actually means the "KDF object w/ HKDF algorithm", I can see how that may look confusing. I can change it to "KDF object", but then it'd require everyone to re-review again. Given this is just a nit, can we leave it for later?

driverkt · 2025-05-12T19:38:59Z

src/java.base/share/classes/sun/security/ssl/SSLBasicKeyDerivation.java

+        this.hkdfInfo = createHkdfInfo(label, context, hashAlg.hashLength);
+        this.keyLen = hashAlg.hashLength;


Very minor nit: might be worth accessing this field once and passing this.keyLen to createHkdfInfo instead.

Hmm, I like to match the ordering in the constructor with the ordering of fields. Since this is relatively minor, I am inclined to leave it as is...

driverkt · 2025-05-12T19:45:47Z

src/java.base/share/classes/sun/security/ssl/SSLBasicKeyDerivation.java

-                    ((SecretSizeSpec)keySpec).length, algorithm);
+            KDF hkdf = KDF.getInstance(hkdfAlg);
+            return hkdf.deriveKey(type,
+                    HKDFParameterSpec.expandOnly(secret, hkdfInfo, keyLen));


I noticed we have done away with the AlgorithmParameterSpec parameter to this method. While the new implementation makes sense in light of the new parameter set, I wonder whether there was a deliberate use-case lost here...

In the previous implementation, presumably, if the keySpec's length was shorter than the expanded value, only a portion of the value would be used. With the new implementation, the hash algorithm's length of bytes is always used.

I'm not sure how relevant this is, but it could be worth noting. If we had kept the old parameter, I suppose we could have used deriveData and truncated the result to ((SecretSizeSpec)keySpec).length before returning a SecretKey.

Searching among the JSSE code base, it looks that SSLBasicKeyDerivation class is only used in Finished class and the particular SecretSizeSpec value is always same as the current keyLen field. There is no other usage as far as I can tell. If we ended up using SSLBasicKeyDerivation class with a shorter key length, we can add an explicit keyLen argument to the SSLBasicKeyDerivation constructor. I see no need for the SecretSizeSpec class given the code flow in Finished class.

driverkt

See inline.

driverkt

Approving based on above discussion.

valeriepeng · 2025-05-13T22:42:58Z

/integrate

openjdk · 2025-05-13T22:43:32Z

Going to push as commit 4c0a0ab.
Since your change was applied there have been 748 commits pushed to the master branch:

10dcdf1: 8347606: Optimize Java implementation of ML-DSA
1bded71: 8356605: JRSUIControl.hashCode and JRSUIState.hashCode can use Long.hashCode
89242ee: 8356885: Don't emit C1 profiling for casts if TypeProfileCasts is off
... and 745 more: https://git.openjdk.org/jdk/compare/6970cf6ac69864e7027138746361e7da1983c24d...master

Your commit was automatically rebased without conflicts.

openjdk · 2025-05-13T22:43:38Z

@valeriepeng Pushed as commit 4c0a0ab.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

8353578: Refactor existing usage of internal HKDF impl to use the KDF…

cfa422e

… API

openjdk bot added the rfr Pull request is ready for review label Apr 2, 2025

openjdk bot added the security security-dev@openjdk.org label Apr 2, 2025

wangweij reviewed Apr 2, 2025

View reviewed changes

djelinski approved these changes Apr 3, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Apr 3, 2025

bradfordwetmore approved these changes Apr 4, 2025

View reviewed changes

added default deriveData method to SSLKeyDerivation interface and

320c49a

refactored code to remove unused AlgorithmParameterSpec argument.

openjdk bot removed the ready Pull request is ready to be integrated label Apr 5, 2025

seanjmullan reviewed Apr 7, 2025

View reviewed changes

djelinski approved these changes Apr 7, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Apr 7, 2025

valeriepeng mentioned this pull request Apr 10, 2025

8350661: PKCS11 HKDF throws ProviderException when requesting a 31-byte AES key #24526

Closed

3 tasks

address review feedbacks

eaa0737

cleanup interim security values changed PKCS11 HKDF impl to allow key algorithms starting with "Tls" as generic keys

openjdk bot removed the ready Pull request is ready to be integrated label Apr 11, 2025

Undo the special workaround for JSSE in PKCS11 HKDF impl.

38b2da7

djelinski approved these changes Apr 25, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Apr 25, 2025

wangweij reviewed Apr 25, 2025

View reviewed changes

seanjmullan reviewed Apr 30, 2025

View reviewed changes

Address review comments from Sean.

825aa22

openjdk bot removed the ready Pull request is ready to be integrated label May 1, 2025

bradfordwetmore reviewed May 6, 2025

View reviewed changes

Address review feedbacks from Brad.

5693ede

driverkt mentioned this pull request May 9, 2025

8145255: Refactor TLS 1.3 impl to use KDF API for HMAC-based Extract-and-Expand Key Derivation Function (HKDF) #23974

Closed

3 tasks

bradfordwetmore approved these changes May 10, 2025

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label May 10, 2025

seanjmullan approved these changes May 12, 2025

View reviewed changes

djelinski approved these changes May 12, 2025

View reviewed changes

driverkt reviewed May 12, 2025

View reviewed changes

driverkt approved these changes May 13, 2025

View reviewed changes

openjdk bot added the integrated Pull request has been integrated label May 13, 2025

openjdk bot closed this May 13, 2025

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels May 13, 2025

valeriepeng deleted the JDK-8353578 branch May 13, 2025 22:44

jovanstevanovic mentioned this pull request May 28, 2025

[GR-65391] Add reflection metadata for HKDF. oracle/graal#11274

Merged

		@@ -35,9 +35,11 @@
		import java.security.spec.AlgorithmParameterSpec;

		@@ -620,7 +622,7 @@ public byte[] produce(ConnectionContext context,

		SSLKeyDerivation handshakeKD = ke.createKeyDerivation(shc);
		SecretKey handshakeSecret = handshakeKD.deriveKey(

		this.hkdfInfo = createHkdfInfo(label, context, hashAlg.hashLength);
		this.keyLen = hashAlg.hashLength;

Conversation

valeriepeng commented Apr 2, 2025 • edited by openjdk bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Progress

Issue

Reviewers

Contributors

Reviewing

Uh oh!

bridgekeeper bot commented Apr 2, 2025

Uh oh!

openjdk bot commented Apr 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openjdk bot commented Apr 2, 2025

Uh oh!

valeriepeng commented Apr 2, 2025

Uh oh!

openjdk bot commented Apr 2, 2025

Uh oh!

valeriepeng commented Apr 2, 2025

Uh oh!

openjdk bot commented Apr 2, 2025

Uh oh!

mlbridge bot commented Apr 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Webrevs

Uh oh!

valeriepeng commented Apr 2, 2025

Uh oh!

openjdk bot commented Apr 2, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

djelinski left a comment

Choose a reason for hiding this comment

Uh oh!

bradfordwetmore left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

djelinski left a comment

Choose a reason for hiding this comment

Uh oh!

djelinski left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bradfordwetmore May 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

valeriepeng commented Apr 2, 2025 •

edited by openjdk bot

Loading

openjdk bot commented Apr 2, 2025 •

edited

Loading

mlbridge bot commented Apr 2, 2025 •

edited

Loading

bradfordwetmore May 7, 2025 •

edited

Loading

bradfordwetmore commented Apr 30, 2025 •

edited

Loading

valeriepeng May 8, 2025 •

edited

Loading