Your AI-generated monthly roundup of Java platform, framework, and community updates.
August 2026 was a month when Java’s near-term release train met several longer-term shifts. JDK 27 reached its first release candidate after an unusual schedule adjustment tied to Java’s faster security-update cadence, while attention turned to testing Project Valhalla’s value objects in JDK 28 early-access builds and to a small standard JSON API.
Across the wider ecosystem, Jakarta EE 12 continued to take shape, Spring opened its 4.2 development line, Quarkus prepared its next LTS release, Apache Camel shipped a new LTS, and both JetBrains and Gradle made notable moves around AI-assisted development.
Security was also unusually prominent. The August JDK security update affected the JDK 27 release schedule, while Jenkins, GlassFish, Spring, and Micrometer all published fixes worth reviewing.
And perhaps the biggest theme running through the month was AI. The conversation is moving beyond simply calling an LLM. Java projects are increasingly working on agents, tools, workflows, permissions, observability, and the infrastructure needed to make those systems dependable.
Let’s take a look.
| Category | August 2026 highlights |
|---|---|
| Java SE & OpenJDK | JDK 27 entered release-candidate status on August 20 with nine JEPs. Project Valhalla called for testing Value Objects and Strict Field Initialization in JDK 28 early-access builds, while the Simple JSON API was proposed for that release. |
| Security & JDK Operations | OpenJDK and Oracle published coordinated August security updates across supported Java lines. The security-update schedule also caused JDK 27’s first release candidate to move from August 6 to August 20. |
| Jakarta EE | Jakarta CDI 5.0 became the first Jakarta EE 12 specification to file for release review. A Jakarta Agentic AI preview reached Azul Payara Community 7.2026.8. |
| Frameworks & Integration | Spring Boot 4.2.0-M1, Quarkus 3.39, Quarkus Flow 1.0, and Apache Camel 4.22 LTS advanced messaging, workflows, post-quantum readiness, and agent-oriented integration. |
| Developer Tools | JetBrains exposed IntelliJ’s Java and Kotlin intelligence through an LSP-based preview for VS Code and Cursor. Gradle 9.7 advanced Isolated Projects and resilient IDE synchronization, while Gradle launched an agent-focused initiative. |
| Java & AI | The GitHub Copilot SDK for Java received an enterprise-oriented introduction, while multiple projects converged on Java-native tools, agent workflows, MCP, and framework-neutral AI integration. |
| Community | August’s quieter conference calendar shifted some attention toward local Java User Groups, including a multi-city JVM startup and warmup tour across the northeastern United States and eastern Canada. |
JDK 27 reached its first release candidate on August 20 with nine JEPs making up the release.
The feature set includes:
There are a couple of changes here that deserve more attention than their relatively small surface area might suggest.
Making G1 the universal default removes the remaining situations where HotSpot would automatically select Serial GC.
Compact Object Headers, meanwhile, reduce 64-bit object headers from 96 bits to 64 bits. That continues the JVM’s long-running effort to improve memory efficiency without requiring application developers to redesign their applications.
JDK 27 also continues Java’s preparation for post-quantum cryptography with hybrid key exchange for TLS 1.3.
Another interesting operational improvement is JFR in-process data redaction. It limits the exposure of potentially sensitive information such as command-line arguments, initial environment values, and system properties before recording data leaves the process.
The release-candidate schedule itself was noteworthy.
RC1 had originally been planned for August 6, but OpenJDK delayed it until after the August 18 security update so that important security fixes could be incorporated.
OpenJDK explicitly connected the changing security-update environment to faster vulnerability discovery, including acceleration from generative-AI tools. One consequence was that JDK 27 effectively lost two weeks of its normal release-candidate feedback period.
That is a useful reminder that the Java release process itself is adapting to a world where vulnerabilities can be discovered—and potentially exploited—more quickly.
JDK 27 subsequently reached general availability on September 15, but that is a story for the next Pulse.
Project Valhalla’s August update invited developers to try value objects in ordinary JDK 28 early-access builds.
Those builds include two major preview features:
Value Objects introduce objects that do not have identity in the traditional Java sense.
That gives the JVM considerably more freedom in how those objects are represented and stored.
The long-term goal is familiar to anyone who has followed Valhalla: allow developers to model small data values using normal Java abstractions without necessarily paying all of the memory and indirection costs associated with traditional objects.
Strict Field Initialization complements that work at the JVM level by allowing participating fields to be protected from reads before initialization. That prevents code from observing default values such as null or zero before the field has received its intended value.
This is still preview territory, so nobody should start redesigning production domain models around value objects just yet.
What has changed is accessibility.
Valhalla is no longer something developers can only watch from specialized project repositories and mailing-list discussions. With these features available in JDK 28, library authors, framework developers, language implementers, serialization projects, performance-tool authors, and curious Java developers can begin experimenting with it in ordinary early-access JDK builds.
After many years of development, that is a significant milestone.
August also brought a proposal to target JEP 540, Simple JSON API, to JDK 28.
The proposal does exactly what the name suggests.
It provides a small API for:
Importantly, the proposal is deliberately limited.
It is not intended to replace Jackson, Gson, Jakarta JSON Processing, or other mature JSON libraries.
It does not attempt to provide a comprehensive object-mapping framework, support every JSON-like syntax, expose a streaming API, or provide a huge collection of parser configuration options.
That restraint may be its strongest feature.
There are plenty of situations where pulling in a complete JSON framework feels excessive: command-line utilities, small configuration files, tests, JShell experiments, build tools, and simple HTTP clients are obvious examples.
A small standard API could cover those cases while leaving sophisticated serialization and data binding to the existing ecosystem.
The August discussion also highlighted some of the areas where feedback is likely to concentrate, including construction ergonomics, strict parsing behavior, and whether lightweight record-oriented binding should eventually be addressed separately.
JEP 540 was only proposed during August, so it should not yet be treated as a committed JDK 28 feature.
Its later progress belongs to September’s story.
Still, after decades of Java applications depending on external libraries for even basic JSON handling, this is one proposal worth watching.
August also brought another round of JDK security updates.
The August 18 OpenJDK advisory addressed vulnerabilities including:
java.netjavax.net.sslDepending on the vulnerability, affected baselines included releases at or below:
Oracle’s corresponding security update delivered releases including:
The interesting part is not simply that vulnerabilities were fixed. Security updates happen regularly.
What is changing is the cadence.
The August security update was important enough that OpenJDK adjusted the JDK 27 release-candidate schedule around it.
For organizations operating large Java estates, that makes automated JDK inventory and patching increasingly important.
And remember that the JDK installed on a developer workstation is only part of the picture.
Java runtimes can also be hiding inside:
A fleet-level version check is increasingly not enough.
JDK 27’s post-quantum TLS work is not going to remain limited to the newest JDK.
Oracle published a roadmap on August 6 for bringing standardized post-quantum cryptographic capabilities to supported LTS releases.
The roadmap includes technologies such as:
Oracle plans to bring JDK 27-equivalent post-quantum functionality to JDK 25 beginning with the October 2026 update.
JDK 21 and JDK 17 are expected to follow during the first half of 2027, with JDK 11 and JDK 8 following later in 2027.
That is important for enterprise Java.
Most organizations are not going to migrate thousands of applications to JDK 27 simply to gain access to new cryptographic primitives. Backporting the functionality gives those applications a more realistic migration path.
Of course, adding algorithms to the JDK does not magically make an application post-quantum ready.
Certificates, protocols, infrastructure, interoperability, configuration, and operational practices all still need to be considered.
The platform can provide the cryptography.
It cannot automatically make an organization’s complete trust infrastructure post-quantum ready.
But the foundation is being put in place.
Oracle also clarified an upcoming licensing transition for Oracle JDK 21.
Oracle JDK 21 updates through September 2026 remain available under the No-Fee Terms and Conditions.
Beginning with the October 2026 CPU, Oracle plans to provide JDK 21 updates under the Java SE OTN license.
Oracle JDK 25 is now the current LTS release, and Oracle has said its NFTC update window is planned to continue until October 2028.
It is worth emphasizing that this is an Oracle JDK licensing transition.
It is not a change to:
If your organization uses Oracle JDK 21, however, now would be a good time to verify what happens when the October update arrives.
If you use another OpenJDK distribution, check that vendor’s lifecycle rather than assuming Oracle’s dates apply universally.
Jakarta EE 12 continued moving forward during August.
One particularly important milestone came from Jakarta CDI 5.0, which became the first specification targeting Jakarta EE 12 to file for release review.
Other Jakarta specifications remained at various stages of milestone development, including work around:
This does not mean Jakarta EE 12 was released in August.
Instead, it is a sign that the individual pieces of the platform are beginning to move from development toward formal review.
That distinction matters.
Specification progress is not the same thing as a completed platform release, and application-server compatibility still has to follow.
CDI is foundational to much of the Jakarta EE programming model, however, so seeing CDI 5.0 reach this stage is a meaningful indicator that the Jakarta EE 12 specification train is beginning to assemble.
Jakarta EE is also exploring what a standardized programming model for AI agents might look like.
August’s Azul Payara Community 7.2026.8 release integrated a preview of Jakarta Agentic AI 1.0.0-M1 into a Jakarta EE 11 runtime, giving developers a place to try the draft API and provide feedback.
The early specification introduces concepts around:
LargeLanguageModel facadeJava SE 17 is the minimum Java version for the milestone.
The interesting part is what Jakarta Agentic AI is not trying to standardize.
It is not attempting to define the underlying AI model or force applications onto a particular model provider.
Instead, the project is looking at lifecycle and integration concepts needed to build agent-oriented applications that can compose with technologies such as CDI and the rest of the Jakarta ecosystem.
It is very early work.
Milestone 1 is not a final specification and had not completed a release review during August.
But it gives Jakarta EE an interesting position in the rapidly expanding Java AI ecosystem.
Spring, Quarkus, LangChain4j, and vendor SDKs can innovate quickly around implementations.
Jakarta Agentic AI can potentially focus on something different: portability.
Spring Boot 4.2.0-M1 arrived on August 20.
Among the additions were:
The release was part of a broader first-milestone wave that included:
For most production users, however, August’s Spring security advisories may be more immediately relevant than the milestone releases.
Spring AI 2.0.0 was affected by two particularly interesting issues.
One involved semantic-cache isolation.
Another involved RediSearch query injection.
Depending on application configuration, the vulnerabilities could result in chat information crossing conversation boundaries and becoming visible where it should not be.
Both issues were fixed in Spring AI 2.0.1.
These are worth paying attention to because AI applications introduce some unusual data-isolation problems.
A cache hit is normally considered a performance success.
In an AI application, however, a cache that does not correctly incorporate tenant, user, conversation, or authorization boundaries can become an information-disclosure mechanism.
As AI frameworks mature, traditional application-security concepts such as isolation and authorization are going to matter just as much as model quality.
Spring AI was not the only Spring project receiving security attention during August.
Additional advisories affected specialized configurations involving:
Spring Cloud Config’s SVN backend, for example, received a high-severity fix for a time-of-check/time-of-use issue.
The breadth of the advisories makes dependency review more useful than reacting to a single headline CVE.
If you maintain a substantial Spring application, August is a good month to compare your actual dependency tree and configuration against the official Spring security advisory list.
Quarkus 3.39 arrived on August 27 and serves as the planned foundation for the following 3.40 LTS line.
One notable addition is post-quantum key-exchange configuration through the Quarkus TLS registry.
That configuration can be applied across several parts of an application, including:
That makes the JDK’s emerging post-quantum capabilities easier to consume consistently at the framework level.
Quarkus also made an interesting stability decision around its reflection-free Jackson serializers.
The optimization had previously been enabled by default, but remaining issues caused the project to move it back to opt-in before establishing the next LTS baseline.
That is exactly the kind of conservative decision you want to see before an LTS release.
Performance improvements are useful.
Predictable behavior is more important.
A day before Quarkus 3.39, Quarkus Flow 1.0.0 reached its first stable release.
Quarkus Flow is an embedded workflow engine based on the CNCF sandbox Open Workflow Specification.
It supports capabilities including:
The key word here is embedded.
Rather than requiring developers to deploy and operate a separate workflow service, Quarkus Flow runs as part of the Quarkus application.
That could be particularly interesting for AI applications.
Once an agent needs:
a simple chain of model calls stops being enough.
Workflow engines provide a way to make those processes explicit and manageable.
Quarkus Flow is therefore interesting not just as another workflow engine, but as part of a broader shift toward treating agentic applications as ordinary distributed systems that need ordinary operational discipline.
Apache Camel 4.22.0 was announced on August 11 as a new LTS release supporting Java 17, 21, and 25.
The release contains a large collection of improvements, but several AI-related additions stand out.
Camel now has a more unified AI-tool abstraction and can expose routes as tools through an MCP server using streamable HTTP.
Camel JBang also gained additional MCP capabilities.
Other work included:
This is an interesting evolution for an integration framework.
Camel routes have traditionally connected applications, protocols, queues, APIs, and data sources.
Increasingly, those same integrations can now be exposed to AI agents as tools.
That makes Camel’s attention to the less glamorous parts of the story particularly important.
Connecting an LLM to enterprise systems is easy to demonstrate.
Making that connection safe and operable is considerably harder.
JetBrains made one of the more surprising tooling announcements of the month.
On August 4, JetBrains announced a preview that exposes IntelliJ IDEA’s Java and Kotlin language intelligence through LSP to editors including Visual Studio Code and Cursor, along with compatible forks.
The extension provides capabilities such as:
JetBrains also discussed experiments using the same capabilities from terminal-based AI-agent workflows.
That last point may ultimately be more significant than editor support.
Language servers provide a structured way for agents to understand source code, navigate symbols, inspect diagnostics, and perform changes using the same semantic information available to developers.
The preview is free to evaluate, with preview builds limited to a 30-day evaluation period.
JetBrains has said continued use after the preview will require an IntelliJ IDEA Ultimate subscription.
Developers testing it alongside existing Red Hat or Oracle Java extensions were also advised to disable overlapping analysis extensions.
This is therefore both an interoperability move and a commercial one.
But it meaningfully expands where IntelliJ’s Java analysis can operate.
Gradle 9.7 continued the project’s work on improving performance and reliability for large builds.
Isolated Projects moved from experimental to incubating status.
Gradle reported that its own roughly 300-subproject build saw median IDE synchronization time fall from around 84 seconds to 47 seconds with the feature enabled.
The release also introduced Resilient Sync, allowing an IDE to receive a partial project model even when part of a build fails.
There were additional improvements around:
These may not be flashy features, but they address problems that become increasingly painful as Java repositories grow into hundreds of modules.
For developers working in large monorepos or complex multi-project builds, IDE synchronization and configuration time can easily become part of the inner development loop.
Cutting that overhead matters.
Gradle followed the 9.7 release with another announcement on August 19: Agentic Gradle.
The initiative includes official skills intended to teach AI agents how to interpret and operate Gradle builds.
It also includes repeatable benchmarks for measuring whether those instructions actually improve agent performance.
Gradle is investigating ways to make its command-line interface easier for agents to operate as well.
There was an interesting roadmap consequence.
The plan to make Configuration Cache the default moved from Gradle 10 to Gradle 11, allowing engineering resources to be directed toward agent-oriented work.
Whether that tradeoff proves worthwhile remains to be seen.
But the benchmarking aspect of Agentic Gradle is particularly interesting.
The industry needs more reproducible measurements of whether agent-specific instructions and tooling actually improve software-engineering tasks.
“AI makes developers faster” is not a particularly useful engineering metric.
“Providing this build skill increases the success rate for these reproducible Gradle tasks” is much more interesting.
The GitHub Copilot SDK for Java also received attention in August.
The preview SDK allows server-side Java applications to create agent sessions and work with:
The API uses familiar Java constructs such as:
CompletableFutureAn accompanying example demonstrated the SDK with Jakarta EE 11 and Open Liberty, although the SDK itself is framework-neutral and can also compose with environments such as Spring.
Bring-your-own-key support allows applications to work with direct model providers or compatible endpoints, reducing the coupling between the Java application API and a single model service.
Perhaps the most important lesson from the examples is around permissions.
Giving an agent unrestricted approval to execute every available tool may be convenient for a demonstration.
Production applications should expose only the tools required for a particular session or task.
As agents gain access to real application capabilities, tool authorization becomes application security.
Jenkins published an important security advisory on August 5.
Among the issues was CVE-2026-70426, a critical Remoting deserialization-filter bypass.
Affected versions included Jenkins weekly releases through 2.575 and LTS releases through 2.568.1.
Under the affected configurations, code running on an agent—or an attacker with sufficient Agent/Connect permission—could bypass the JEP-200 deserialization filter for classes available on the Jenkins controller classpath.
That could potentially lead to code execution on the controller.
The issue was fixed in:
The same advisory included several additional vulnerabilities involving areas such as:
Some plugin vulnerabilities did not have fixes available when the advisory was published.
Organizations running Jenkins should therefore review the complete advisory, particularly if they operate large or semi-trusted agent fleets.
CI infrastructure is an especially sensitive security boundary because build agents routinely process untrusted or partially trusted source code while controllers often hold credentials capable of publishing software.
Eclipse GlassFish also received an important security fix.
GlassFish 8.0.x versions before 8.0.4 were affected by CVE-2026-12605, a CSRF combined with SSRF issue involving the Admin Console.
Under the required conditions, an attacker could cause an authenticated administrator’s gfresttoken to be sent to an attacker-controlled host.
The Eclipse Foundation CNA assigned the vulnerability a 9.6 critical severity score.
The attack does require interaction involving a user already authenticated to the GlassFish Admin Console.
That limits the breadth of the scenario, but not necessarily its potential impact.
Administrators running affected GlassFish 8 versions should ensure they have moved to 8.0.4 or later.
Micrometer also published a security fix in August involving newline handling in StatsD and logging meter output.
Applications that allowed untrusted values to become meter names or tags could potentially allow those values to inject additional lines into metric or log output.
This is a good example of a vulnerability that may look minor until telemetry crosses a trust boundary.
Metrics and logs increasingly feed:
Treating telemetry as trusted simply because it originated inside an application is becoming a dangerous assumption.
Looking across August’s announcements, a pattern emerges.
Jakarta Agentic AI is exploring portable agent abstractions.
Quarkus Flow is providing durable workflows.
Apache Camel is exposing integrations as agent tools.
Gradle is teaching agents how to operate builds.
JetBrains is exposing semantic code intelligence through LSP.
Spring AI continues building application-level AI infrastructure.
And the GitHub Copilot SDK gives Java applications direct access to agent sessions and tools.
These projects are solving very different problems, but they are converging on the same realization:
Calling an LLM is the easy part.
Real applications need:
That is where Java’s existing strengths become particularly relevant.
The ecosystem has spent decades building abstractions for exactly those kinds of enterprise concerns.
The interesting question is therefore becoming less:
How do I call an AI model from Java?
And more:
How do I build a reliable software system in which an AI model is one of the participants?
That is a much more interesting problem for the Java ecosystem to solve.
August was relatively quiet on the major-conference calendar.
The JVM Language Summit, for example, did not hold its traditional U.S. summer event in 2026.
Java User Groups, however, remained active.
One notable series of community events focused on JVM startup and warmup, with discussions covering technologies such as:
Related meetings appeared across Java communities in:
The subject is timely.
Startup time and memory consumption have become increasingly important as Java expands further into:
GraalVM, Leyden, CRaC, Compact Object Headers, and continuing JVM improvements approach the problem from different directions.
But they all reflect the same pressure.
Developers increasingly expect Java applications to start quickly and consume fewer resources without giving up the JVM’s adaptability and runtime optimization.
That makes August’s various JVM developments more interesting when viewed together.
Compact Object Headers attack memory overhead.
G1 everywhere simplifies and modernizes the default garbage-collection story.
Project Valhalla aims to reduce the representational cost of data-heavy object models.
Project Leyden is exploring ways to shift work from application startup to earlier phases.
Project CRaC approaches startup by restoring previously initialized application state.
GraalVM Native Image moves substantial work ahead of runtime entirely.
These technologies are not interchangeable.
They make different tradeoffs and solve different parts of the problem.
But together they show how much attention the Java ecosystem is placing on the economics of running Java applications.
For a platform once routinely criticized for startup time and memory consumption, that is an important evolution.
There is another connection worth making across the August announcements.
JetBrains exposing semantic Java intelligence through LSP, Gradle creating agent-specific build skills, and GitHub providing a Java SDK for Copilot all point toward a development environment where AI agents increasingly interact with structured developer tools rather than simply reading files and executing shell commands.
That distinction matters.
An agent that understands:
has considerably more reliable information than an agent trying to infer everything from source text.
The Java ecosystem already has mature compilers, build systems, IDEs, static-analysis tools, test frameworks, and runtime instrumentation.
Making those capabilities accessible to agents may ultimately be more important than improving the models themselves.
August’s security news also intersects with the AI theme.
Spring AI’s cache-isolation issues demonstrate that AI applications still need ordinary tenant and conversation boundaries.
Camel’s work around tool filtering and authentication shows that exposing enterprise integrations to agents requires explicit controls.
The Copilot SDK examples emphasize permission handling.
Quarkus Flow provides a place to make agent execution and state observable.
And Gradle’s agent work raises similar questions for build infrastructure, where an agent may eventually have the ability to execute arbitrary build tasks or modify project configuration.
The lesson is familiar:
Agents do not eliminate application-security boundaries. They create new ones.
Java’s mature security, identity, observability, and integration ecosystems may therefore become an important advantage as agentic applications move from experiments into production.
August was less about one enormous Java announcement and more about several long-running efforts becoming tangible.
JDK 27 stabilized ahead of its September release.
Project Valhalla encouraged developers to experiment with value objects in JDK 28 early-access builds.
A small standard JSON API was proposed for JDK 28.
Jakarta EE 12 specifications started moving toward release review.
Post-quantum cryptography continued moving from research into practical Java deployments.
And across Spring, Quarkus, Camel, Gradle, JetBrains, Jakarta EE, and GitHub, AI development increasingly became a question of infrastructure rather than simply model access.
There are also some immediate housekeeping items.
If you operate Java in production, review the August JDK security updates and the relevant Jenkins, GlassFish, Spring, and Micrometer advisories.
Oracle JDK 21 users should also understand the licensing transition coming with the October update.
If you are preparing for JDK 27, pay particular attention to changes in defaults such as G1 and Compact Object Headers and test them against representative workloads rather than assuming that a successful compilation is sufficient validation.
For those looking further ahead, JDK 28 early-access builds are becoming particularly interesting.
After years of watching Project Valhalla from a distance, Java developers can finally start getting their hands on value objects.
And the proposed Simple JSON API gives us another reason to watch JDK 28 closely.
Perhaps the most interesting development, though, is happening outside any single project.
Java’s AI ecosystem is beginning to mature from model wrappers into infrastructure.
Agents are gaining tools.
Tools are gaining permissions.
Applications are gaining workflows.
Build systems and IDEs are becoming agent-aware.
And frameworks are starting to think seriously about observability, security, state, and failure handling.
Those are exactly the kinds of problems the Java ecosystem has spent decades learning how to solve.
August was about the ecosystem reorganizing around dependable Java infrastructure.
Security is moving faster, value objects are available for early-access testing, and AI development is becoming less about isolated prompts and more about governed tools, durable workflows, and dependable Java infrastructure.
Until next time, keep coding, keep learning, and keep the Java community moving forward.