Java Development Kit (JDK) 28, a non-LTS (Long-Term Support) or “feature release” of standard Java due in March 2027, has started to take shape. Features listed for JDK 28 now include a preview of value objects, switching the default mode of the Shenandoah garbage collector to generational mode, and a preview of strict field initialization in the Java Virtual Machine (JVM).

As a non-LTS release, JDK 28 will be backed by six months of support by Oracle.

The three features currently targeted to JDK 28 include the following:

• Introduce value objects, which are immutable and lack object identity. Value objects are distinguished by the values of their fields, and can be represented by the JVM in ways that improve performance. A goal of the feature is to give developers a programming model for immutable data in which the == operator, and all other operations, distinguish objects by the values of their fields rather than their identities. Value objects is a preview language and VM feature.
• Switch the default mode of the Shenandoah Garbage Collector (GC) to the generational mode and deprecate the non-generational mode, with the intent to remove it in a future release. Goals include signaling the intent that future development will focus on generational mode, and reducing the maintenance cost of supporting two different modes. However, it is not a goal to remove non-generational mode at this time.
• Introduce strictly-initialized fields in the JVM. Such fields must be initialized before they are read, thus default values such as 0 or null are never observed. For strictly-initialized fields that are final, the same value is always observed. A goal is offering designers of JVM-based programming languages a model for field initialization, which has stronger integrity guarantees than the present model. This is a preview VM feature.

The predecessor to JDK 28, JDK 27, is due September 15. JDK 27 also is a non-LTS release that will be backed by six months of support by Oracle.

Java Development Kit 27, an Oracle-driven, planned update to standard Java, is set to reach its initial release candidate (RC) stage on August 6. This update has features ranging from making the Garbage-First (G1) garbage collector the default collector and adding structured concurrency to simplify concurrent programming. JDK 27 is currently in rampdown phase 2, with the feature set now frozen.

Overall, there are nine features listed on what is described as a reference implementation of JDK 27. The first five features include making G1 the default garbage collector, post-quantum hybrid key exchange for TLS 1.3, lazy constants, structured concurrency, and primitive types in patterns, instanceof, and switch. The next four include compact object headers, JFR (JDK Flight Recorder) in-process data redaction, a vector API, and PEM (Privacy-Enhanced Mail) encodings for cryptographic objects.

The final release candidate stage for JDK 27 follows on August 20, with general availability scheduled for September 15. Early-access builds for JDK 27 can be found at jdk.java.net.

With JDK 27, G1 becomes the default garbage collector in all environments, rather than just in server environments. Goals are to ensure that the HotSpot JVM will always select G1 and that performance including throughput, latency, memory footprint, and startup time does not degrade significantly.

With post-quantum hybrid key exchange for TLS 1.3, the goal is to enhance the security of Java applications that require secure network communication by implementing hybrid key exchange algorithms. Such algorithms defend against future quantum computing attacks by combining a quantum-resistant algorithm with a traditional algorithm.

Lazy constants introduces an API for objects that hold unmodifiable data. Lazy constants are treated as true constants by the JVM, enabling the same performance optimizations that are enabled by declaring a field final. Compared to final fields, however, lazy constants offer greater flexibility in the timing of their initialization. This feature is in a third preview.

The goal of primitive types in patterns, instanceof, and switch is to enhance pattern matching by allowing primitive types in all pattern contexts, and to extend instanceof and switch to work with all primitive types. This feature is in a fifth preview.

Structured concurrency simplifies concurrent programming by introducing an API that treats groups of related tasks running in different threads as single units of work. Goals include streamlining error handling and cancellation, improving reliability, and enhancing observability. Structured concurrency is in its seventh preview.

JDK 27 makes compact object headers the default object header layout in the HotSpot JVM. Compact object headers reduce object headers from 96 bits down to 64 bits on 64-bit architectures, reducing heap size, improving deployment density, and increasing data locality.

JFR data in-process redaction allows users to redact command-line arguments and the initial values of environment variables and system properties in JFR recordings. JFR recording files may contain events that include sensitive data, such as secrets in command-line arguments, access tokens in environment variables, and passwords in system properties. This data is (optionally) redacted before it leaves the process, so that sensitive information does not leak.

The vector API introduces an API to express vector computations that reliably compile at run time to optimal vector instructions on supported CPUs, thus achieving better performance than equivalent scalar computations. This is an incubating API in its 12th incubation.

PEM encodings of cryptographic objects introduces an API for encoding objects that represent cryptographic keys, certificates, and certificate revocation lists in the PEM transport format, and for decoding from PEM back into objects. This is a preview API.

JDK 27 is a short-term feature release (non-LTS) that will receive six months of support from Oracle. Its predecessor, JDK 26, also a short-term release, became generally available on March 17.

The evolution of Java is the subject of a just-released documentary about the programming language and development platform. “The Java Story: The Official Documentary” tells the story of Java through interviews with the engineers who created it and shepherded it through three decades.

Produced by CultRepo and sponsored by Oracle, JetBrains, IBM, and Azul, the documentary follows Java from its set-top box and browser-based origins at Sun Microsystems in the 1990s and through its rise to dominate server-side computing in the 2000s, the “dark ages” and resurgence with Java 8 under Oracle in the 2010s, and its continuing modernization and promising role in AI today. “From its humble beginnings as a project code-named ‘Oak’ at Sun Microsystems to becoming a global standard for enterprise software and billions of devices, Java’s journey is one of radical innovation, strategic pivots, and enduring community strength,” said Cult.Repo.

The documentary also delves into Sun’s bitter Java licensing dispute with Microsoft, Oracle’s suit of Google over its use of Java APIs Android (Google won), the creation of the Java Community Process, Sun’s open-sourcing of Java, and Oracle’s switch to the six-month release cycle. Technical enhancements such as lambda expressions in Java 8, virtual threads in Java 21 (Project Loom), and the ongoing refactor to bring value objects to the Java object model (Project Valhalla) also get attention.

Technical experts and other Java figures interviewed in the documentary include James Gosling, creator of Java; Kim Polese, Java’s first product manager; Carla Schroer, director of Java compatibility at Sun Microsystems; James Duncan Davidson, creator of Apache Tomcat; Mark Reinhold, chief architect of the Java Platform Group at Oracle; Brian Goetz, Java language architect in the Java Platform Group at Oracle; Rod Johnson, creator of Spring; and Gavin King, creator of Hibernate.

Between 2029 and 2032, every currently supported long-term support (LTS) version of Java will reach end-of-support within a single three-year window: Java 17 in 2029, Java 8 in 2030, Java 21 in 2031, and Java 11 in 2032.

On paper, this looks like a manageable upgrade cycle. In practice, it creates a collision of timelines that most enterprises have failed to forecast. Organizations attempting to modernize incrementally—moving application by application, version by version—are operating on a model that the calendar has already rendered obsolete.

The primary danger here is the illusion of time. Traditional modernization plans rely on sequential upgrades and controlled pacing. However, when every major Java version expires in the same compressed window, sequential planning collapses. By the time this becomes obvious, organizations will be forced into reactive mode, making rushed decisions under extreme pressure.

The modernization illusion

For organizations planning traditional stepwise upgrades—Java 8 to Java 11 to Java 17 to Java 21—this convergence elevates a routine maintenance task into a structural crisis. Enterprises with large Java estates will be forced to upgrade multiple applications across multiple versions simultaneously to maintain security compliance and business continuity. Waiting until the late 2020s to act guarantees a modernization process under emergency conditions.

While modern Java versions maintain strong backward compatibility, they cannot offset the drag of what enterprises are carrying forward: decades of accumulated technical debt.

In large Java environments, technical debt is pervasive. It exists as unused libraries, obsolete logic, forgotten dependencies, and dormant features—quietly inflating the size, risk, and complexity of every modernization effort. In many organizations, a significant portion of the codebase no longer executes in production, yet it still consumes developer attention, security oversight, and planning effort.

As codebases grow older and larger, this drag compounds. What looks like a simple version upgrade on a roadmap becomes a massive operational burden in practice.

Why incremental planning fails

Most modernization strategies assume that upgrades can be sequenced and absorbed gradually. That assumption is now dangerous. When multiple Java versions reach end-of-support in the same narrow window, enterprises don’t face a single modernization project—they face parallel modernization across their entire estate.

This shifts the challenge from engineering complexity to organizational capacity.

Consider a typical enterprise with 100 developers. If even a fraction of their time is spent maintaining, investigating, or working around unused and obsolete code, the organization burns meaningful engineering capacity on work that delivers no business value. Multiply that across dozens or hundreds of applications, and the bottleneck becomes clear: modernization is limited by people, not frameworks.

Parallel modernization requires parallel capacity—something most organizations haven’t budgeted for.

This explains why traditional approaches struggle to scale. Tools that analyze code in isolation cannot distinguish what actually matters in production. Without clear visibility into what code is relevant, organizations default to caution, effectively converting their timelines into risk.

The real bottleneck: developer capacity

The Java modernization crunch is a crisis of resource allocation, not a technology problem.

Every hour developers spend maintaining obsolete code or investigating unused dependencies is an hour lost to modernization. When organizations face simultaneous upgrades across multiple applications, human capacity becomes the limiting factor. Sequential planning and parallel modernization require the time and capacity most enterprises no longer have.

Organizations that delay action are consuming their flexibility rather than preserving it. Each year of inaction increases the volume of code that must be moved, reviewed, secured, and modernized within the same fixed window. By the time deadlines become unavoidable, the only remaining options are compression, shortcuts, and uncomfortable trade-offs.

A different way to think about readiness

The organizations that navigate this transition successfully will prioritize clarity over immediate upgrades.

Modernization at scale requires an accurate understanding of what actually matters in production before attempting to move it forward. Without that visibility, every upgrade effort inherits unnecessary complexity, consumes excess capacity, and introduces avoidable risk.

The goal is not simply adopting better tools, but reducing the structural load enterprises carry into modernization. Leaner systems modernize faster. Simpler estates scale better. Complexity compounds under time pressure.

The timeline is already set

The Java modernization crunch is a timing problem that is already locked in.

Enterprises that treat the next few years as business-as-usual will discover that sequential plans cannot survive compressed timelines. Those that confront technical debt now—before the pressure hits—will find the coming transition difficult but manageable. Those that don’t will face rushed decisions and permanent trade-offs.

By the time 2029 arrives, the window for gradual modernization will have closed. The calendar won’t wait for us to be ready.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

Broadcom today announced multiple security investments in its Spring and Java ecosystems that aim to help protect users from AI-enabled threats.

The company said that, first, it is releasing what it called the largest set of Spring security updates to open source in the product’s history, and, for customers, it is extending its clean-room build architecture to build the Java dependencies for the entire Spring ecosystem.

“Spring is one of the most widely adopted application development frameworks in the world, and as its steward, we have a deep responsibility for its security,” said Purnima Padmanabhan, vice president and general manager of Broadcom’s Tanzu Division. “Because we maintain Spring and are the sole committers, we can better secure it at the source for everyone who depends on it. This investment is about two things we will never separate: the health of the Spring community and the security of our customers who trust Spring to run their business.”

The company also announced that, as the number of security advisories reported by the community has exploded, its engineering team has “significantly scaled” its use of AI tools to help it identify vulnerabilities, assess remediation paths, and validate fixes across the dependency ecosystem. Although Broadcom declined to specify the AI models it’s using in its bug hunting, it is a member of Anthropic’s Project Glasswing, so Claude Mythos is likely part of the effort.

For paying customers only

One perk available only to Tanzu Spring enterprise customers is zero-day access to validated CVE patch-only releases through the Spring Enterprise Repository, before they are released to open source. These patches isolate the security fix from any other changes to let customers remediate more quickly.

“By utilizing Tanzu Spring’s private artifact repositories, customers can be confident that the artifacts are the official, validated patches from Broadcom, the steward of Spring,” Broadcom said in its announcement, adding that it will continue to issue CVEs for all versions of every Spring project under open source support, as well as older versions under Tanzu Spring enterprise support.

Broadcom’s Tanzu Spring enterprise support includes:

• Certified source for secure spring libraries 
• Commercial-first release of patches for both current and older, enterprise supported versions
• Access to dependent Java binaries
• Automated, deterministic upgrades with Spring Application Advisor
• Exclusive Tanzu Spring components for governance and security
• 24×7 support, hands-on expertise and access to the Spring team.

In addition, Broadcom said, it has now added:

• Secured, SLSA Level 3–validated software supply chain for Java dependencies.
• Coverage that spans the full transitive dependency graph managed by the Spring Boot bill of materials.
• Thousands of secured dependencies, built and tested across every supported Spring version. Spring Boot 4.0 alone manages 1,768 of them; across the full supported portfolio, that totals more than 100,000 validated dependency builds.

“This capability gives customers validated dependencies across both current and end-of-life Spring versions, helping customers reduce software supply chain risk while continuing to benefit from the productivity and consistency of Spring Boot’s dependency management model,” the announcement noted.

Security fixes for sale

Seva Ioussoufovitch, senior research analyst at Info-Tech Research Group, sees these moves as mostly positive.

“It’s encouraging to see Broadcom take proactive steps towards dealing with the increase in AI-detected vulnerabilities that many organizations have had to contend with in recent months,” he said. “Announcements like Mythos have made it clear that the industry needs to re-think traditional approaches to security patching.”

Ioussoufovitch isn’t surprised at the size of the update release either, noting that it’s consistent with the result of AI scanning and remediation that has been occurring, and will likely continue.

“More meaningful is the provision of validated and secured dependencies,” he said. “This is a critical move in the right direction, especially with the endlessly growing list of supply chain vulnerabilities the industry has been managing in recent months.”

Ioussoufovitch is less happy with the restriction of zero-day patches to paying customers.

“Putting security fixes behind a paywall isn’t new, but when there are no drop-in alternatives for an ecosystem as critical as Spring, it just looks like a power move to force more of the open-source community onto the monetization track,” he noted. “Another approach might’ve been to release the CVE fixes to everyone while charging for enterprise-grade packaging, validation, and support, but, given Broadcom’s track record of aggressive monetization in recent years, what they’ve chosen here doesn’t necessarily come as a shock.”