Skip to content

POC of using Java 15+ sugar for tests.#11537

Open
AlexeyKuznetsov-DD wants to merge 4 commits into
masterfrom
alexeyk/sugar-for-tests
Open

POC of using Java 15+ sugar for tests.#11537
AlexeyKuznetsov-DD wants to merge 4 commits into
masterfrom
alexeyk/sugar-for-tests

Conversation

@AlexeyKuznetsov-DD
Copy link
Copy Markdown
Contributor

@AlexeyKuznetsov-DD AlexeyKuznetsov-DD commented Jun 2, 2026

What Does This Do

POC to investigate if we can improve readability of tests by using syntax sugar from modern Java while still compiling
test classes to Java 8 bytecode using https://frgaal.org.

Only ONE test updated to show how it will be.

Motivation

Many tests contain payload-heavy setup code, string concatenation for JSON/XML, simple dispatch switches, and casts that are harder to read than the behavior being tested. This POC explores using Frgaal for test sources only, so tests can use selected modern Java syntax while keeping the bytecode target compatible with Java 8.

Feature Java Java 8 safe? Worth using in tests?
Text blocks 15 Yes Yes, high value for JSON, SQL, XML, HTML payloads.
Switch expressions / case -> 14 Yes Yes, useful for compact mappings/assertion setup.
instanceof pattern variables 16 Yes Yes, removes noisy casts.
Local var 10 Yes Yes, but restrained. Good when RHS is obvious; avoid hiding fixture types.

Additional Notes

This is intentionally very limited: it is literally syntax sugar for test readability. Advanced modern Java features are
not part of this POC and should not be treated as generally available, especially features with runtime semantics such
as records, sealed classes, record patterns, preview features, module imports, or compact source files.

@AlexeyKuznetsov-DD AlexeyKuznetsov-DD self-assigned this Jun 2, 2026
@AlexeyKuznetsov-DD AlexeyKuznetsov-DD added tag: no release notes Changes to exclude from release notes type: refactoring comp: tooling Build & Tooling labels Jun 2, 2026
@AlexeyKuznetsov-DD AlexeyKuznetsov-DD marked this pull request as ready for review June 2, 2026 19:59
@AlexeyKuznetsov-DD AlexeyKuznetsov-DD requested a review from a team as a code owner June 2, 2026 19:59
@datadog-datadog-prod-us1-2

This comment has been minimized.

Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 751eba6cd6

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

@dd-octo-sts
Copy link
Copy Markdown
Contributor

dd-octo-sts Bot commented Jun 2, 2026

🟢 Java Benchmark SLOs — All performance SLOs passed

Suite Status
Startup 🟢 pass

SLO thresholds are defined here based on automatically generated metrics. A warning is raised when results are within 5% of the threshold.

PR vs. master results
Scenario Candidate master Δ (95% CI of mean)
startup:insecure-bank:iast:Agent 13.93 s 13.97 s [-1.0%; +0.5%] (no difference)
startup:insecure-bank:tracing:Agent 12.96 s 12.97 s [-1.6%; +1.5%] (no difference)
startup:petclinic:appsec:Agent 16.57 s 16.37 s [-0.2%; +2.7%] (no difference)
startup:petclinic:iast:Agent 16.60 s 16.58 s [-0.9%; +1.1%] (no difference)
startup:petclinic:profiling:Agent 16.45 s 16.53 s [-1.8%; +0.8%] (no difference)
startup:petclinic:tracing:Agent 15.74 s 15.83 s [-2.1%; +1.0%] (no difference)

Commit: 2b8b01e7 · CI Pipeline · Benchmarking Platform UI


Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion.

Comment thread buildSrc/src/main/kotlin/datadog/gradle/plugin/frgaal/FrgaalCompilerPlugin.kt Outdated
Copy link
Copy Markdown
Member

@jpbempel jpbempel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

goood idea let's try this while waiting for dropping JDK8 😁

// gradle/java_no_deps.gradle (which sets options.release in its own configureEach). configureEach
// actions run at task realization in registration order, so registering last lets us win and
// clear the release flag — Frgaal needs source > target, which --release forbids.
project.afterEvaluate {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue: project.afterEvaluate looks wrong, at this point I'm not sure if there's a better approach with frgaal.

Comment on lines +90 to +103
/**
* Tell IntelliJ (via its Gradle import) that the module accepts Java 17 source while still
* targeting Java 8 bytecode, matching what Frgaal does for the test compile tasks. Without this
* the IDE imports the module's language level/SDK from the `java` extension (Java 8) and flags
* text blocks and other modern syntax as errors.
*/
private fun configureIdeaLanguageLevel(project: Project) {
project.pluginManager.apply("idea")
project.extensions.configure<IdeaModel>("idea") {
module.jdkName = SOURCE_VERSION.majorVersion
module.languageLevel = IdeaLanguageLevel("JDK_${SOURCE_VERSION.majorVersion}")
module.targetBytecodeVersion = TARGET_VERSION
}
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue: Wouldn;t this bump the language level of the main source set as well ?

}

private fun isTestJavaCompileTask(taskName: String): Boolean {
return taskName == "compileTestJava" ||
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note: this is covered by the check below

Comment on lines +25 to +27
* - **No incremental compilation.** Forking with a custom `javac` executable opts out of Gradle's
* incremental Java compiler, so affected test source sets always recompile in full. Acceptable for
* a handful of modules; measure before applying repo-wide.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue: Given the number of tests we have, this could be a noticeable performance regression.

Copy link
Copy Markdown
Contributor

@bric3 bric3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It certainly seems like an interesting thing to look at, but I believe that in it's current form, using frgaal has quite a few drawbacks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp: tooling Build & Tooling tag: no release notes Changes to exclude from release notes type: refactoring

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants