Update record detection for fixed JDK#12031
Conversation
JDK 25.0.4 fixes the Record with type annotation bug (JDK-8376185) so we are updating the detection to filter out for this JDK version and onward
|
Hi! 👋 Thanks for your pull request! 🎉 To help us review it, please make sure to:
If you need help, please check our contributing guidelines. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: aaf49a6e76
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| private static final boolean JAVA_AT_LEAST_25_0_4 = | ||
| JavaVirtualMachine.isJavaVersionAtLeast(25, 0, 4); |
There was a problem hiding this comment.
Gate the workaround by each JDK feature line
On JDK 26.0.1 this evaluates true because the major version is greater than 25, but JDK-8376185 is listed as fixed in the JDK 26.0.2 update, not 26.0.1 (Oracle release notes). That means both record-type-annotation safety checks are bypassed on unfixed JDK 26 builds, so a probe on a record with TYPE_USE annotations can be instrumented/retransformed again and re-expose the NoSuchFieldError/JVM-corruption path this guard is meant to avoid. Please make this a per-feature-line check, e.g. 25 >= 25.0.4 and 26 >= 26.0.2, instead of a single lower bound.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
True, but can ask to upgrade. so acceptable and marginal for JDK 26
There was a problem hiding this comment.
More details
Version comparison logic is correct across all edge cases: isAtLeast(25, 0, 4) returns false for JDK 25.0.0 GA ("25" parses to 25.0.0), false for "25-ea" and 25.0.3, and true for 25.0.4, 25.0.4+build, 25.1.x, and any major ≥ 26 — the guard condition !JAVA_AT_LEAST_16 || JAVA_AT_LEAST_25_0_4 correctly applies the workaround on JDK 16–25.0.3 and skips it everywhere else.
📊 Validated against 26 scenarios · Open Bits AI session
🤖 Datadog Autotest · Commit aaf49a6 · What is Autotest? · Any feedback? Reach out in #autotest
|
Bits Code status: ✅ Done Comment @DataDog to request changes |
This comment has been minimized.
This comment has been minimized.
Debugger benchmarksParameters
See matching parameters
SummaryFound 0 performance improvements and 0 performance regressions! Performance is the same for 10 metrics, 5 unstable metrics. See unchanged results
Request duration reports for reportsgantt
title reports - request duration [CI 0.99] : candidate=None, baseline=None
dateFormat X
axisFormat %s
section baseline
noprobe (331.875 µs) : 305, 359
. : milestone, 332,
basic (298.478 µs) : 292, 305
. : milestone, 298,
loop (8.982 ms) : 8976, 8988
. : milestone, 8982,
section candidate
noprobe (337.554 µs) : 302, 373
. : milestone, 338,
basic (296.31 µs) : 289, 304
. : milestone, 296,
loop (8.991 ms) : 8985, 8996
. : milestone, 8991,
|
🟢 Java Benchmark SLOs — All performance SLOs passed
PR vs. master results
Commit: Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion. |
|
/merge |
|
View all feedbacks in Devflow UI.
The expected merge time in
|
63e8a26
into
master
What Does This Do
JDK 25.0.4 fixes the Record with type annotation bug (JDK-8376185) so we are updating the detection to filter out for this JDK version and onward
Motivation
Additional Notes
Contributor Checklist
type:and (comp:orinst:) labels in addition to any other useful labelsclose,fix, or any linking keywords when referencing an issueUse
solvesinstead, and assign the PR milestone to the issueJira ticket: [PROJ-IDENT]