Test jvm constraints plugin now configures jmh plugin#12048
Conversation
|
@codex review |
|
Codex Review: Didn't find any major issues. Can't wait for the next one! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
This comment has been minimized.
This comment has been minimized.
🟢 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. |
There was a problem hiding this comment.
More details
The JMH configuration is now applied centrally without changing the existing testJvm semantics: Gradle's withPlugin callback handles either plugin application order, and an unset testJvm leaves the JMH JVM unset. Focused execution was blocked because this checkout requires a Java 25 Gradle daemon while the sandbox has only JDK 8, 11, 17, and 21.
🤖 Datadog Autotest · Commit 9f4b41d · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest
What Does This Do
Teach jmh plugin about the testJvm if present, without having to manually wire things in the build-file.
Motivation
This should be a convention. And avoids repetition. E.g. what's done in #11703
Additional Notes
Due to the way classloader works between
buildsrc/and regular projects, the plugin code has to use reflection.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]