Should CI Test JDK 28 Preview Features in Both Modes?

An unchanged Java codebase may encounter changed runtime behavior when it runs on JDK 28 with preview features enabled. That makes a narrow CI decision more useful than a broad platform reaction: should a project build and test in both preview modes before adopting the release?

The supplied evidence supports testing this question, not declaring a migration outcome. JEP 401 introduces value classes as a preview feature in JDK 28. The OpenJDK Quality Outreach note specifically recommends that projects with sufficiently flexible continuous integration setups test with previews disabled and enabled. OpenJDK Quality Outreach

This is not a pricing or cloud-capacity decision. The supplied material contains no provider, region, plan, unit, storage, egress, retention, or support prices. Any cost discussion would therefore be an assumption or a project-specific calculation, not a verified list price.

The JDK 28 CI testing decision is about execution modes

A project can treat “JDK 28” as one test target. That is incomplete when preview behavior is part of the compatibility surface.

With preview features disabled—the default—the expected behavior should remain as-is. The source still advises projects to watch for unexpected behavior because changes of this depth could unintentionally affect behavior even with previews disabled. OpenJDK Quality Outreach

With preview features enabled, the situation changes. Thirty JDK classes become value classes. The listed examples include primitive wrapper classes such as Integer and Double, Optional variants, date and time types, Number, and Record. This can affect code that was not changed and may even have been compiled with previews disabled or on an earlier version.

The decision is therefore straightforward to state:

If the project can support it, make JDK 28 a two-mode CI target: preview disabled and preview enabled.

That recommendation is an interpretation of the supplied Quality Outreach guidance, not a claim that every project must immediately enable previews or that every project will observe a failure.

Why value classes create an unusual compatibility surface

The source identifies three categories of possible consequences when preview features are enabled:

1. Expected behavioral differences between regular classes and value classes.
2. Expected changes involving record constructors.
3. Unexpected JDK misbehavior that should be reported to the Valhalla development mailing list.

The important mechanism is identity. Value classes lack identity—the property that distinguishes two otherwise indistinguishable instances. The source illustrates this with two equal LocalDate values and an identity comparison using ==; with value classes, the result depends on the new behavior. OpenJDK Quality Outreach

That does not prove that a particular application is broken. It does identify a class of assumptions worth testing: code that relies on object identity, behavior associated with record construction, or interactions with the affected JDK classes.

This distinction matters for engineering leaders and budget owners. The required response is not automatically a platform redesign, a new cluster, or a wholesale rewrite. It may be a bounded expansion of the test matrix, followed by classification of any failures.

A small, reusable CI architecture decision

The reusable pattern is a two-lane compatibility matrix:

Both lanes should build the same codebase and run the same relevant tests. This keeps the comparison meaningful. The source does not provide a required CI provider, runner size, execution time, or test count, so those details must remain project-specific assumptions rather than invented facts.

A useful result record should separate observation from interpretation:

• Observed result: the exact test, exception, or behavior produced by a lane.
• Expected compatibility difference: a failure that follows from the documented change in class behavior.
• Potential JDK misbehavior: behavior that does not match the expected model and may warrant a report.
• Unrelated failure: an issue that is not connected to the JDK 28 mode under test.

Do not collapse all failures into “JDK 28 is incompatible.” The evidence supports a more disciplined classification process.

Operational checklist for the two-mode test

Before adding the matrix, write down the assumptions that determine whether it is practical:

• Which Java versions are already supported?
• Can the CI system invoke JDK 28 with preview features disabled and enabled separately?
• Which test suites exercise wrappers, Optional, date/time classes, records, or identity-sensitive code?
• Which failures are release-blocking, and which are diagnostic only?
• Who owns triage when behavior differs between the two lanes?
• What evidence will accompany a report of suspected JDK misbehavior?

Then run the smallest reliable sequence:

1. Build and test with JDK 28 and previews disabled.
2. Build and test with JDK 28 and previews enabled.
3. Compare failures against the affected class categories.
4. Reproduce a suspected issue with the smallest useful test case.
5. Report unexpected JDK behavior through the channel identified by the OpenJDK guidance.
6. Record whether the project will support, defer, or investigate JDK 28 further.

This checklist is intentionally narrower than a migration program. It protects delivery decisions from two opposite errors: ignoring a meaningful compatibility change, or treating every new failure as proof that the entire application needs redesign.

What the surrounding sources do—and do not—establish

The supplied sources include material about cloud platform selection, the CNCF governing board, and JavaScript learning resources. They provide context about the broader technology landscape, but they do not establish JDK 28 compatibility behavior.

The CNCF page describes governing-board responsibilities such as business oversight and budget decisions, while distinguishing those from most technical decisions. CNCF Governing Board That is relevant only as organizational context: governance and technical compatibility are different decision layers.

The AWS page presents an AWS-hosted summary of a 2026 Gartner Magic Quadrant report and includes Gartner’s caution that the publication reflects Gartner’s opinions and should not be treated as a directive to select a provider. AWS-hosted Gartner report It does not provide evidence about JDK 28, Java value classes, CI behavior, or infrastructure cost.

The web.dev JavaScript page discusses JavaScript learning, browser features, and responsiveness topics. web.dev JavaScript It does not support claims about Java or JDK 28. Keeping these boundaries explicit prevents a cloud or web-development source from being used as accidental evidence for a Java compatibility decision.

A practical decision path for engineering leaders

Use the two-mode test when the project has a sufficiently flexible CI setup and when its supported Java surface makes the question material. Start with the affected categories rather than trying to predict every consequence from the feature name.

Defer or narrow the test when the project cannot yet run JDK 28 reproducibly, but document that as an operational constraint—not as evidence that the compatibility question is irrelevant. If the enabled-preview lane produces no relevant failures, that is an observed result for the tested code and suite, not a universal guarantee.

If the lane produces failures, classify them before deciding. A documented behavioral difference may require code adaptation. A suspected JDK defect needs a minimal reproduction and appropriate report. An unrelated failure belongs to the project’s normal triage path.

The smallest reliable solution is not “enable every preview feature everywhere.” It is a controlled comparison that makes the compatibility question visible before a release decision.

Conclusion: make preview behavior testable before making it strategic

JDK 28 value classes create an unusual compatibility surface because unchanged code can encounter changed behavior when previews are enabled. The supplied OpenJDK guidance supports a focused response: test with previews disabled and enabled when the CI setup allows it, inspect identity and record-related assumptions, and separate expected differences from possible JDK misbehavior.

That gives teams a concrete decision without inventing cost, availability, or migration outcomes. If your Java delivery path needs a second opinion on CI scope, compatibility triage, or the smallest reliable test plan, get in touch through the portfolio.

Official sources

• CNCF Governing Board
• AWS-hosted Gartner report
• OpenJDK Quality Outreach: JDK 28 Value Classes
• web.dev JavaScript