← Back to all briefings
Developer 5 min read Published Updated Credibility 40/100

Developer Briefing — Java 12 general availability

Oracle released Java 12 (JDK 12) on 19 March 2019 with preview switch expressions, an incubating Shenandoah low-pause garbage collector, and CDS defaults that change startup and memory profiles for microservices fleets.

Zeph Tech Research Lead

Research lead, Zeph Tech

Horizontal bar chart of credibility scores per cited source.
Credibility scores for every source cited in this briefing. Source data (JSON)

Java 12 shipped on 19 March 2019 as the second release on the six-month cadence, bringing preview switch expressions, the incubating Shenandoah low-pause garbage collector, and class-data sharing (CDS) defaults that affect startup budgets for JVM-based services. Engineering leads need to assess bytecode compatibility, garbage-collection tuning, and build pipelines because the new tools and defaults change memory profiles and CI stability compared to Java 11 LTS.

What changed in the runtime

Switch expressions (JEP 325) entered preview, letting developers return values directly from switch blocks and use the -> arrow form to avoid fallthrough. That simplifies state-machine and feature-flag code, but it requires enabling --enable-preview at compile and runtime. Shenandoah GC arrived as an experimental low-pause collector targeted at large heaps; it reduces pause times by doing concurrent compaction, but it is not production-default and must be enabled with -XX:+UseShenandoahGC. G1 received abortable mixed collections to reduce pause spikes and a default max pause-time goal of 200ms, which shifts tuning baselines for services that previously targeted 100ms.

Class data sharing is now enabled by default for the server VM, creating a shared archive during installation and at first execution. That reduces startup by tens of milliseconds on containerized services but introduces new artifacts in container layers that need to be captured in image builds. The JVM Constants API (JEP 334) and the microbenchmark harness updates are included, making it easier to introspect bytecode constants and build JMH-based microbenchmarks directly from the JDK without external plugins.

Impact on build, testing, and operations

Build pipelines must pass --enable-preview to both javac and java when compiling switch expressions; otherwise CI will fail or silently ignore preview codepaths. IDEs that do not propagate preview flags will mis-highlight code, so teams should update IntelliJ and VS Code Java extensions to their March 2019 releases. Because CDS archives are generated during installation, reproducible builds that layer JDK images should capture the archive creation step inside Dockerfiles to avoid runtime cache misses in production containers. Teams running in Alpine-based images need to validate musl compatibility for Shenandoah before testing; upstream only documents glibc environments.

Operations teams should treat Shenandoah as an opt-in experiment for services with heap sizes above 20 GB and strict p99 latency targets. Rollouts should include GC log comparisons versus tuned G1 settings, watching for evacuation failure and mixed-collection pacing changes. The abortable mixed-collection change in G1 may slightly increase CPU consumption during concurrent cycles; capacity models that were calibrated on Java 11 should be refreshed using JDK 12 telemetry before production cutover.

Migrations and platform governance

Organizations standardizing on LTS releases can adopt Java 12 selectively for workloads that benefit from switch expressions or Shenandoah while keeping the main fleet on Java 11. Platform teams should publish guardrails: enable preview flags only in targeted services, require code review for new switch-expressions patterns to prevent regressions when the feature evolves in Java 13, and block promotion of Shenandoah-enabled workloads to production until GC logs show stable pause distributions over multi-day runs.

Security baselines must be updated to cover JDK 12 default CDS archives. SRE and compliance reviewers should confirm that build pipelines sign or checksum generated archives the same way they verify JDK binaries. Third-party dependencies compiled for Java 8 or 11 remain compatible because bytecode version 56 (Java 12) is backward-compatible for consumers, but teams need to ensure that build artifacts produced with --release 12 are not deployed to Java 11 runtimes in mixed fleets.

Next steps for engineering teams

  • Update build images to include JDK 12 and add --enable-preview flags in Gradle/Maven profiles dedicated to switch-expression pilots.
  • Run GC bakeoffs comparing G1 tuned for pause targets versus Shenandoah on at least two representative services with 48-hour production-like traffic.
  • Capture CDS archive generation in Docker layers and document rollback instructions if archive corruption is observed during container startup.
  • Refresh runbooks and dashboards with JDK 12 GC and class-loading metrics, ensuring alert thresholds reflect the updated pause-time defaults.

Application teams should validate how preview switch expressions interact with static analysis and coverage tooling. Older SpotBugs and Checkstyle rulesets may treat the arrow syntax as invalid unless updated to the April 2019 rule versions. JaCoCo prior to 0.8.4 misreports coverage for switch expressions compiled with preview flags, which can hide untested branches. Build maintainers need to pin plugin versions and add explicit CI steps that fail fast if preview bytecode is compiled without the matching runtime flag.

Performance engineers should benchmark warmup behavior because CDS archives shift class-loading times earlier in the lifecycle. Services using tiered compilation with short-lived containers may see higher CPU in the first minute as the archive is loaded and profiled data is collected. To avoid noisy results, profile with container limits that mirror production and disable CPU throttling during the warmup phase. JVM flight recordings should be captured during Shenandoah experiments to confirm pause times and identify evacuation regions that create back-pressure under concurrent compaction.

Risk teams and architects need to document the support window: Java 12 reached end of public updates six months after release, so production use requires commercial Java support or a transition to Java 13/17. If developers use switch expressions in shared libraries, downstream teams stuck on Java 11 will have to backport or fork the code. A central registry of language-level features in shared components can prevent incompatible upgrades from shipping into conservative services that stay on the prior LTS.

For ecosystems built on Gradle, enable the toolchain support to isolate JDK 12 builds from default agents running JDK 11. Maven users should lock maven-toolchains-plugin and configure maven-surefire-plugin with the preview flag so integration tests run under the correct bytecode interpreter. Container registries should store SBOM updates reflecting the Java version bump, especially when FIPS-validated crypto providers or custom trust stores are bundled with the runtime.

Document compatibility gates in internal catalogs so service owners know whether Java 12 is permitted for production workloads or restricted to experimentation sandboxes.

Teams that complete these actions can safely evaluate Java 12’s productivity features without destabilizing Java 11 LTS baselines, while collecting evidence for broader adoption in later LTS releases.

Horizontal bar chart of credibility scores per cited source.
Credibility scores for every source cited in this briefing. Source data (JSON)

Related briefings

Curated signals from the same pillar or overlapping topics.

Continue in the Developer pillar

Return to the hub for curated research and deep-dive guides.

Visit pillar hub

Latest guides

  • Java
  • JDK
  • Garbage Collection
  • Runtime Lifecycle
  • Performance
Back to curated briefings