website

☕ Pulse on Java – July 2025 Edition

Your AI-generated monthly roundup of Java framework and platform updates.

Welcome to the July 2025 edition of Pulse on Java, where we cover the latest releases, innovations, and trends across the Java ecosystem. This month featured a major build tool release (Gradle 9.0), the ongoing refinement of Java 25 as it reached Release Candidate status, new leaps in Java’s AI integration (LangChain4j 1.2.0), and significant framework updates (Quarkus 3.25, Micronaut 4.9). Many of these changes continue to emphasize performance optimizations, developer experience improvements, and secure, cloud-ready practices that are highly relevant for Java developers right now. July’s updates show a mix of consolidation (polishing existing features) and forward-looking innovations (AI modules, virtual threads usage)11.

🔧 Framework Releases & Highlights

🔨 Gradle 9.0.0 – Major Build Tool Release

Gradle 9.0.0 was released on July 31, 2025, marking a significant update to one of Java’s most popular build tools1. Gradle 9 brings multiple improvements for build performance and modernization:

• Java 17+ required – Gradle 9 now requires JDK 17 or higher to run builds2. This aligns the build system with modern Java LTS versions and allows Gradle to leverage Java 17’s features internally. (Gradle will still compile and run project code on Java 8+ via toolchains, but the Gradle JVM itself must be 17+.)
• Configuration Cache by default – The configuration cache (which caches the result of the project configuration phase to speed up subsequent runs) is now the preferred execution mode21. Gradle 9 encourages adopting it, automatically falling back to non-cached mode only if unsupported features are used2. Many improvements were made to ease this transition: better error messages, auto-detection of incompatible tasks, and even prompting users to enable the config cache if their build is compatible22. For developers, this means much faster re-build times on multi-module and large projects – teams have reported up to 60% reduction in configuration time thanks to these caching enhancements (especially with Kotlin DSL builds)2.
• Kotlin 2.1 and Groovy 4 – Gradle’s build script engines were updated to Kotlin 2.1/2.2 and Groovy 4.012. This brings newer language features and performance improvements to writing Gradle scripts. For example, Kotlin DSL scripts benefit from the new K2 compiler and incremental compilation avoidance, making editing build.gradle.kts files snappier2. Gradle plugins can also now use the latest Kotlin APIs. Migrating from Gradle 8 requires checking for a few potential impacts (like stricter nullability from JSpecify annotations in the Gradle API, or removed deprecated methods), but most builds upgrade smoothly.
• Semantic Versioning & Cleanups – Starting now, Gradle versioning follows SemVer (MAJOR.MINOR.PATCH) for clarity (so it’s 9.0.0, not 9.0)2. As a major release, some deprecated APIs from the 7.x/8.x era were removed. The Gradle team provided a detailed upgrade guide listing these changes. On the plus side, there are build authoring improvements like reproducible archives by default and a new dependency graph feature for resolving project dependencies in detached configurations22. For most developers, the visible impact is Gradle 9 being more robust and user-friendly – e.g., error messages are more actionable, and the tool is clearly oriented toward performance and modern Java standards.
• Gradle 9.0 Impact – If you’re using an older JDK for CI, plan to update to JDK 17+ before adopting Gradle 9. Also, expect Gradle to suggest enabling the configuration cache if you haven’t already, as they move toward eventually making it mandatory. This is a good time to verify your custom plugins or build scripts are config-cache compatible. The payoff for upgrading is substantial in build speed gains and future-proofing your build process. Gradle 9’s release also signals that Maven isn’t the only one with a major update in the wings – (Maven 4.0 is still in RC as of July) – the Java build tooling space is evolving quickly to support modern development needs.

⚡ Quarkus 3.25.0

Red Hat released Quarkus 3.25.0 on July 30, 20253, continuing its fast-paced iteration on the Quarkus 3.x line. Although labeled a “point release,” Quarkus 3.25 brings notable enhancements:

• Virtual Threads for GraphQL – Quarkus has gradually been adding virtual thread support across its stack (starting with RESTEasy in 3.6, then Messaging, gRPC, etc.). In 3.25, the SmallRye GraphQL extension now supports running on virtual threads31. This means GraphQL resolvers in Quarkus can handle more concurrent requests with fewer OS threads, greatly simplifying scalability for GraphQL-based APIs. Developers can stick to a straightforward imperative programming style in GraphQL resolvers and still benefit from Loom’s massively concurrent model.
• Micrometer & Prometheus Upgrade – Micrometer metrics in Quarkus were updated to Micrometer 1.15 with a switch to the Prometheus Client v1 library3. This update aligns with Prometheus’ latest stable API and may involve minor breaking changes (documented in Quarkus’ migration guide), but it ensures better long-term support and improvements in metrics collection. For developers using Quarkus’ out-of-the-box metrics export, this means more robust and future-proof monitoring integration.
• New Security Features – Quarkus 3.25 introduces several security enhancements:
  • Fluent Authorization API: A new programmatic, fluent API for path-specific authorization was added3. Previously, securing different URL paths required quarkus.http.auth policy properties. Now you can configure it in code by observing HttpSecurity – for example, httpSecurity.get("/public/*").permit().path("/admin/*").roles("admin")... etc.33. This gives developers type-safe, flexible control over security rules, which can be easier to manage for dynamic scenarios. (The configuration properties method still works too.)
  • OIDC Token Refresh: The OIDC Client extension can now refresh tokens asynchronously in the background3. In earlier versions, if a bearer token expired, Quarkus would refresh it during a request – possibly adding latency. With 3.25, by setting quarkus.oidc-client.refresh-interval, token refresh can happen periodically on a dedicated thread, ensuring high-throughput applications don’t stall on token renewal3. This is a boon for performance and reliability when using Quarkus to call secure services with OAuth2 client credentials.
  • OAuth2 Resource Metadata: Initial support for OAuth2 Protected Resource Metadata (IETF RFC 9728) was added3. This allows a Quarkus service to advertise its own OAuth2 protection info (like accepted scopes, token introspection endpoints, etc.), improving interoperability in complex security architectures. It’s an advanced feature, but it shows Quarkus staying on the cutting edge of OAuth standards.
• Legacy Config Cleanup – With 3.25, Quarkus has fully deprecated legacy configuration classes for extension authors3. If anyone was still building Quarkus extensions using the old config model (pre-Arc era), they now must migrate to the newer configuration system. This is part of Quarkus preparing for a clean slate in its next long-term support release (more on that in What’s Next). For application developers, this has no impact except that it reflects Quarkus’ commitment to reduce technical debt.
• Platform & Extension Updates – Quarkus Platform picked up a few integrations: notably, Quarkus LangChain4j (an extension to easily use LangChain4j in Quarkus) is now included, starting at version 1.1.03. This means Quarkus developers can more easily add AI/LLM capabilities to their apps with a supported extension. Also, Camel Quarkus 3.25.0 is bundled3, aligning with Apache Camel’s latest release for seamless Camel integration. Numerous dependency upgrades and bug fixes are also part of 3.25 (e.g., improvements in RESTEasy Reactive, Kafka companion fixes, etc., as seen in the full changelog).
• Quarkus 3.25 Bottom Line: This release exemplifies Quarkus’ dual focus on modern features (like virtual threads and fluent APIs) and enterprise readiness (security, stability). Upgrading to 3.25 is especially attractive if you use GraphQL or advanced OIDC features. It’s backward-compatible with other Quarkus 3.x apps, so the update should be smooth. Importantly, Quarkus devs signaled that 3.25 is one of the last feature releases before an upcoming Quarkus 3.27 LTS (with 3.26 and 3.27 in August – see What’s Next). Therefore, 3.25 sets the stage for what will be stabilized in the LTS, making it a great time for developers to test these new features and give feedback before the LTS solidifies.

🧠 LangChain4j 1.2.0

The LangChain4j 1.2.0 release (finalized in mid-July 2025) significantly broadened the horizons for AI integration in Java. LangChain4j is the Java analog of the popular LangChain library, focusing on orchestrating LLMs, prompts, memory, and tool usage. In version 1.2.0:

• New Modules for AI Providers – A major theme of 1.2.0 is expanding support for various AI platforms out-of-the-box. The release added six new connector modules1 covering some of the most prominent AI providers and models:
  • Anthropic (Claude API)
  • Azure OpenAI (Microsoft’s hosted OpenAI service)
  • AWS Bedrock (Amazon’s managed LLM service)
  • Google AI Gemini (Google’s next-gen foundation model)
  • Mistral AI (open model from Mistral AI)
  • Ollama (for running local LLMs easily)
    These modules make it straightforward for Java developers to call those services by providing pre-built wrappers/clients following the LangChain4j interface conventions. For example, with langchain4j-azure-open-ai, you can use Azure OpenAI endpoints with just configuration, or with langchain4j-anthropic, call Claude models with proper formatting handled by the library. This breadth of integrations means Java shops can stay cloud-agnostic in their AI strategy – switching or combining LLM providers without leaving the LangChain4j abstraction.
• Agentic and A2A Foundations – Alongside 1.2.0, the LangChain4j team released some experimental modules (under a 1.2.0-beta8 tag) for more advanced “agent” behaviors1. Notably, langchain4j-agentic and langchain4j-agentic-a2a were mentioned in development discussions (though formal docs came with 1.3.0). These lay groundwork for building multi-step reasoning agents in Java and integrate with the emerging Agent-to-Agent (A2A) protocol. While not yet stable in 1.2, their existence hints at a future where Java applications can host autonomous AI agents that coordinate tasks or talk to each other, all within the LangChain4j framework. This aligns with broader trends (like Red Hat’s A2A SDK introduced in June) of enabling complex AI workflows in enterprise Java.
• Breaking Changes & Improvements – A few breaking API changes in 1.2.0: The VertexAiGeminiStreamingChatModel got a new Executor interface to improve async handling1, and some parameters like tokenCountEstimator were removed from Azure OpenAI model classes in favor of internal handling1. These are minor and mostly affect those who were on the 1.2.0 betas. Additionally, general stability improvements and bug fixes from 1.1 were included.
• Impact: For Java developers, LangChain4j 1.2.0 is a big step forward in making AI a first-class citizen in the application stack. You can now plug in a variety of top-tier models with minimal effort. For example, a fintech app could use Anthropic’s Claude for some tasks and fall back to an on-prem Mistral model for others, all through one library. The progress in agentic features also means that soon, beyond simple prompt chains, we’ll be able to implement more autonomous AI-driven features in Java (like an AI scheduling assistant that uses multiple tools to achieve a goal). The rapid cadence of LangChain4j (they hit 1.3.0 by early August) shows that AI in Java is evolving quickly, keeping pace with the Python world. It’s an exciting space to watch and start experimenting with in pilot projects.

🌀 Micronaut 4.9.2

The Micronaut Foundation released Micronaut 4.9.2 (a minor version update) in late July. While Micronaut 4.9.x doesn’t introduce headline-grabbing new features, it delivers a collection of important maintenance updates and improvements across the framework’s broad ecosystem:

• Module Patch Updates – Micronaut 4.9.2 includes patch releases for many of its modules and libraries. Key areas updated: Micronaut Security, Micronaut Serialization, Micronaut Data, Micronaut JAX-RS, Micronaut Tracing, and Micronaut Kubernetes1. These typically involve bug fixes, performance tweaks, and alignment with the latest external library versions. For example, Micronaut Security might have fixes for edge cases in JWT handling or OAuth flows; Micronaut Data could include query generation improvements or better Jakarta Data API alignment; and Micronaut Kubernetes likely updated for compatibility with recent Kubernetes client changes. Keeping these modules up-to-date is crucial as many Micronaut users rely on them for production apps – 4.9.2 ensures a smoother and safer experience out-of-the-box.
• Micronaut Core 4.9.x – The core of the Micronaut framework (dependency injection, AOP, etc.) is at the heart of these updates. Version 4.9.2 corresponds to Micronaut Core 4.9.9 internally1, which suggests multiple micro-increments were made rapidly (lots of fixes). Although not explicitly enumerated in the announcement, improvements likely include memory usage optimizations and further refinements to Micronaut’s startup analysis (Micronaut is known for its compile-time injection that yields fast startup; incremental versions often fine-tune this). The fact that core jumped to 4.9.9 indicates thorough testing and adjustments before declaring 4.9.2 stable.
• Stability for Cloud Deployments – Micronaut 4.9 continues the framework’s emphasis on being cloud-first and lightweight. Updates to Micronaut Kubernetes (for service discovery and config maps), and Micronaut Tracing (which integrates with OpenTelemetry/Zipkin) solidify its reliability in microservices environments. Essentially, version 4.9.2 is about polish and reliability: if you’re deploying serverless functions or containers with Micronaut, these patches ensure fewer surprises. For example, a Micronaut Azure Function can now run with even less cold-start overhead or an AWS Lambda may benefit from a smaller runtime footprint after these fixes.
• Upgrading – For Micronaut users on 4.8 or early 4.9, this update should be straightforward. The version suggests mostly compatible changes (no breaking API swings). Given Micronaut’s active community, it’s wise to stay current; minor version bumps often contain important security or correctness fixes. Indeed, just like Quarkus and Spring, Micronaut’s frequent point releases reflect their maturity in addressing issues quickly.
• Looking Forward – Micronaut’s slow and steady march hints that a possible Micronaut 5 might be on the horizon (especially with Java 21+ baseline likely in the next major). For now, 4.9.x is the workhorse for 2025, offering a very stable platform for JVM apps that require fast startup, low memory overhead, and a flexible range of modules. The July update reinforces that if you need a small, cloud-optimized Java framework, Micronaut remains a top contender. It may not have as many new features this month, but “no drama” maintenance releases are exactly what enterprise devs appreciate for production longevity.

🌟 Other Notable Updates in July

In addition to the major releases above, July 2025 saw a flurry of smaller—but noteworthy—updates across the Java landscape:

• JobRunr 8.0.0 GA – The GA release of JobRunr 8.0 (Java’s popular background job scheduling library) happened in early July4. Version 8.0 introduces Carbon Aware Scheduling – the ability to time job execution when the energy grid is clean, which is an innovative step towards green computing. It also added an @AsyncJob annotation to easily offload methods to the job queue, and improved the dashboard UI. By the end of July, they’d already issued 8.0.2 with bug fixes5. For Java shops, JobRunr 8 means easier and possibly more environmentally conscious job processing.
• Spring Ecosystem Milestones – The Spring team did not release major GA versions in July, but a lot of milestone (pre-release) activity took place4. Notably, Spring Framework 7.0.0-M7 was released (the 7th milestone for Spring 7)4, bringing it very close to a release candidate. Spring Boot had a milestone (likely 3.6.0-M1) and other projects like Spring Security, Spring Authorization Server, Spring for GraphQL, Spring Integration, Spring Batch, Spring Kafka, Spring Pulsar, etc., all cut milestones or RCs with new features and Java 21+ support4. This “flurry” suggests that the next generation of Spring (Spring Framework 7 and Boot 3.6/4.0) is on track for late 2025, aligning with the new Jakarta EE 11 and JDK 21 baseline. For developers, peeking at these milestones can provide insight into upcoming features like improved observability, new SSL configuration options, and more modularized Spring components.
• WildFly 37.0 Final – Red Hat’s application server WildFly 37 reached final release around the end of July (announcement made in early August)5. This version of WildFly (jakarta EE 10 based) largely focuses on bug fixes and technical debt cleanup5. One notable change is internal: WildFly’s governance was moved under the Commonhaus Foundation (a new umbrella for community-led Java EE projects)5. On the feature side, it included many dependency updates and a new broker setting for its integrated messaging (ActiveMQ Artemis) to better handle message redistribution during cluster shutdown, preventing potential OOM errors5. While no new major features were added, WildFly 37 lays groundwork for a Jakarta EE 11-aligned WildFly next year. Enterprises using WildFly should consider upgrading to benefit from the fixes and be ready for the forthcoming Jakarta EE 11 support in WildFly 38.
• Eclipse Piranha joins Eclipse Foundation – Piranha Cloud, a lightweight Jakarta EE runtime, was officially accepted as an Eclipse Foundation project1. Piranha has been an experimental EE container (started by Java EE veterans) that aims to be a simple, cloud-friendly runtime for Jakarta EE applications. By moving under Eclipse, it gains more visibility and collaboration. Piranha offers “containers” for running Jakarta EE services with minimal overhead and provides add-ons for things like JWT security and JAX-RS. Its move to Eclipse in July signals a continued interest in slim, modular Java servers that can complement or compete with heavier app servers in cloud deployments.
• EclipseStore 3.0.0 GA – The Eclipse Foundation released EclipseStore 3.0 in late July1. EclipseStore is not widely known in the broader community, but it’s essentially a data storage library under Eclipse’s umbrella. Version 3.0 introduced a new high-performance collection called GigaMap for optimized memory and speed in certain storage scenarios1, as well as Storage Graph Analysis APIs that allow exporting the internal object graph (sans data) for debugging or analyzing missing links1. This could be useful for developers using EclipseStore as an embedding persistence or caching mechanism when they need to ensure referential integrity or optimize memory usage.
• Hibernate Family Updates – The Hibernate ecosystem geared up for a refresh: in July, we saw the first Release Candidates for Hibernate ORM 7.1.0, Hibernate Reactive 3.1.0, and Hibernate Search 8.1.011. These RCs (which went final in early August) bring some nice additions: ORM 7.1 adds a new Pessimistic Locking API for more granular lock scopes and a Timeouts helper for query timeouts1, plus better support for running in plain Java SE (outside an EE container) which is useful for Spring apps or Micronaut data scenarios. Reactive 3.1 aligns with ORM 7.1 and updates to Vert.x 4.5 for non-blocking DB access1. Hibernate Search 8.1 upgrades to Elasticsearch 9.1 and adds more flexible aggregations (beyond just counts)1. The takeaway: Java’s primary JPA and search libraries are being updated to fully embrace Jakarta EE 10/11 and recent DB tech, so if you use them (directly or via Spring Data/Hibernate under the hood), expect improvements in the coming months.
• Groovy 5.0.0-Beta2 – Apache Groovy, the dynamic language for the JVM, made progress towards its next major version with a 5.0.0-beta-2 release in July4. Groovy 5 promises performance improvements and new features (possibly leveraging newer JVM features, though details are emerging). The fact that Beta2 is out suggests a GA might arrive later in 2025. Groovy remains important for Gradle (though Gradle 9 moved to Groovy 4, it could adopt 5 in the future) and for developers writing quick scripts or DSLs on the JVM.
• JHipster Lite 1.35.0 – The JHipster project (which provides blueprints to generate modern apps with Spring Boot + frontends) released JHipster Lite 1.35.0 in late July1. This version upgraded its baseline to Spring Boot 3.5.4 and made some UI tweaks (removing an unused feature, refactoring how the Vue.js module is structured)1. It’s a minor release but keeps JHipster Lite in sync with the latest Spring Boot, ensuring that developers using it to kickstart projects are up-to-date on dependencies.
• JDKUpdater 14 – Azul’s open-source tool JDKUpdater saw a version 14.0.83 release1. JDKUpdater is a utility for tracking and downloading new JDK and GraalVM builds – think of it as a helper for developers who need to keep multiple JDKs current. The July update improved the UI by disabling re-download if an artifact is already present and better sorting of available builds1. Small quality of life improvements, but it’s nice for those who manage their own JDK installations outside of package managers.
• Important Security Fixes – July being Oracle’s Critical Patch Update (CPU) month, we saw security updates in various places. For example, the Payara Platform July 2025 edition included a critical fix for a CVE (CVE-2025-22871) in its underlying Grizzly HTTP server, which could allow request smuggling5. Apache Tomcat also had a CVE patched (related to WAR file index handling)5. It’s a reminder that staying on top of the “point releases” (like Payara 6.2025.7 or Tomcat 10.1.44) isn’t just about new features, but about keeping your apps secure. Many popular stacks (Spring Boot, WildFly, etc.) pull these patches in quickly, so updating your frameworks in July/August is prudent to get those fixes.

☕ Java Platform Update: JDK 25 Nears the Finish Line

July 2025 was the final full month of development for Java 25 (JDK 25), and the project hit a major milestone: Release Candidate. On July 17, JDK 25 entered Rampdown Phase Two (RDP2), meaning all targeted features were frozen and only showstopper bugs could be fixed4. Shortly thereafter, with no open P1 (priority one) bugs remaining, Mark Reinhold announced the first Release Candidate build of JDK 255. This indicates that the team is confident in the feature set and quality, and barring any last-minute critical issues, the General Availability (GA) release is set for September 16, 20255.

To recap, JDK 25 is an LTS release that will bring 18 JEPs (proposed features) to production5. We extensively covered these in the June edition, but to summarize the highlights one more time in context:

• Language Improvements: JDK 25 finalizes or previews several Java language enhancements:
  • Flexible Library Loading/Linking: JEP 511’s module import declarations (preview) and JEP 513’s flexible constructor bodies (final) make Java source code more flexible and readable22. For instance, being able to perform validation logic before calling super() in a constructor (thanks to JEP 513) can prevent errors at object init time without clunky static factories.
  • Pattern Matching & Instance main: Pattern matching for primitives in switch (JEP 507, 3rd preview) extends the nice pattern matching syntax to int/long/etc., which cleans up code that previously had to box values. And JEP 512’s “compact source files” (preview) lets you write small programs script-style, even allowing an instance main method in records for quick tests4. These might seem small, but they reduce verbosity and friction for everyday coding and scripting.
• Concurrency & Memory: Project Loom and other efforts deliver big:
  • Structured Concurrency: In JDK 25, structured concurrency APIs (JEP 505, now 5th preview) are near final form4. They let you handle a batch of threads/futures as a unit, simplifying multi-threaded code for tasks like parallel fetches or time-limited operations. Combined with virtual threads (from Java 21), this is changing how we write concurrent code – for the better.
  • Scoped Values: These are now final (no longer preview) in JDK 254. Think of them as inheritable, immutable thread-local variables that work great with virtual threads. Instead of clunky ThreadLocal, you can share context (like an auth token or request ID) easily across threads in a structured task. This both improves performance (lower overhead than ThreadLocal) and avoids pitfalls of memory leaks since the scope is bound.
  • Memory Efficiency: Compact Object Headers (JEP 519, preview) reduces the per-object overhead on 64-bit JVMs11. Early testing (including by cloud providers) suggests noticeable memory savings and even CPU throughput improvements (up to ~30% in certain object-heavy workloads)4, simply by enabling a flag. This is great news for high-scale services and memory-intensive apps – essentially a free optimization once the feature is stable.
• Performance & Tools: JDK 25 arms developers with better tools to tune and understand performance:
  • Profile-Guided Start-up: JEP 514 and 515 bring ahead-of-time (AOT) execution improvements. The JVM can use collected profiling data to optimize code at launch (reducing warm-up time), and the jaotc tooling gets more ergonomic. This inching towards profile-guided optimization means even traditional JVMs (not using GraalVM native images) will start up faster and hit peak performance sooner – important for cloud functions and scaling microservices.
  • Flight Recorder Enhancements: Several JEPs (509, 518, 520) extend Java Flight Recorder for deeper insights5. CPU-time profiling (JEP 509) distinguishes actual CPU usage from wait time, cooperative sampling (518) reduces overhead by syncing sampling points, and method tracing (520) can log every method call entry/exit. These are mostly experimental in 25, but they lay a path for low-overhead, always-on profiling in production. Essentially, the JVM is becoming even more observable – performance engineers will love the granularity these bring when chasing down issues in test or prod.
  • Security and Crypto: A small but useful addition – Key Derivation Function API (JEP 510) is finalized, so developers have a standard way to derive cryptographic keys (e.g., from passwords) without third-party libs. Also, PEM file support (JEP 470, preview) means no more writing your own Base64 parsers for certificates/keys – Java will read those “—–BEGIN CERT—–” files natively. These changes make it easier to follow security best practices and integrate with common devops workflows (since PEM is the lingua franca of TLS).
• JVM & Platform Internals:
  • Vector API & GPU Acceleration: The Vector API (JEP 508) enters its 10th incubator, supporting more operations and hardware. Each release brings it closer to stable; Java 25’s version is quite powerful, enabling explicit SIMD parallelism for things like image processing or cryptography. Some projects (e.g., a new GPULlama3.java from June that uses TornadoVM4) are even leveraging this in combination with GPU offload to run AI models on the JVM. It’s cutting-edge, but potentially revolutionary for high-performance Java numerics.
  • Stable Values (JEP 502): A preview that allows marking certain values as essentially constant for the JIT. This could let the JVM optimize assumptions on configurations that don’t change, leading to better inlining and code generation. It’s yet another piece of giving more hints to the optimizer, which ultimately means faster code with no effort from developers once it matures.
  • Generational Shenandoah: Shenandoah GC (low-pause collector) becomes generational (JEP 521), improving throughput by collecting young objects separately. This makes Shenandoah more competitive as a production GC, potentially giving G1 a run for its money for latency-sensitive apps.
  • Farewell 32-bit: Lastly, Java 25 drops support for 32-bit x86 (JEP 503). Almost all servers are 64-bit now, so it streamlines the codebase. If anyone was still on 32-bit JVMs, they’ll need to stick to older versions or move up – but for the vast majority, this has zero impact beyond a leaner JDK build.

Bottom line: As of end of July, Java 25 is essentially ready. It’s undergone extensive testing through early-access builds and now the community is kicking the tires on the RC. The final set of features is locked, and they collectively make Java 25 a compelling upgrade: more productivity in coding, better performance in execution, and enhanced insight in monitoring. Now is the time to test your applications on JDK 25 if you haven’t – ensure your libraries (Spring, Hibernate, etc.) are compatible (most major ones have been adding support in recent versions) and report any issues. The payoff is that come September, you can migrate to Java 25 smoothly and take advantage of these improvements for the long run (remember, as an LTS, Java 25 will be supported for many years).

Also, for those curious, JDK 26 development has already started in parallel (Build 10 was out by early August)5, but no big announcements yet – that version will primarily incubate whatever didn’t make 25. For now, all eyes are on JDK 25’s GA, less than two months away.

🧠 Developer Trends

• AI Integration Accelerates – The theme of “AI-first Java” we noted in previous months has only grown stronger in July. With LangChain4j 1.2 adding multiple LLM connectors1, Java developers can now seamlessly integrate with all major AI cloud providers. This means writing a Java app that calls OpenAI, Anthropic, or Google’s models is just a matter of configuring an API key and using a high-level API – no need to wrestle with HTTP calls or Python wrappers. Additionally, Spring AI 1.0.1 was released (a maintenance update to Spring’s AI integration) with improvements like better function calling (@Tool annotation) and retry logic for local models5. We also saw the introduction of the Agent2Agent (A2A) Java SDK by Red Hat in late June (for building multi-agent systems), and LangChain4j’s experimental agent modules aligning with that. The trend is clear: Java is not sitting out the AI revolution. In fact, Java’s strong enterprise footprint combined with these new AI libraries could bring LLM capabilities into large-scale, mission-critical systems (where Java reigns) more quickly. We expect upcoming releases of these libraries to continue focusing on reliability, testing, and security (e.g., vault integration for API keys, safe prompt templates) so that enterprises can trust AI in production. If you haven’t yet dabbled, now is a good time to explore something like a simple chatbot or AI-powered feature in Java – the barrier to entry is getting lower every month.
• Virtual Threads Go Mainstream – It’s been almost a year since virtual threads (Project Loom) debuted in Java 21, and we’re seeing an inflection point in adoption. In July, Quarkus extended virtual threads support to GraphQL endpoints3, and even frameworks with long histories are onboard: the upcoming Grails 7 will let you enable Spring Boot’s virtual thread executor in new projects5. This piggybacks on things like Tomcat and Jetty adding virtual thread modes for serving HTTP, and database drivers like JDBC getting tested extensively under virtual concurrency. The fact that Jakarta EE 11 (released last month) officially supports virtual threads for all its APIs means the entire Java ecosystem got a green light to embrace this paradigm (no spec says “you must use thread pools” anymore). The outcome for developers is significant: we can write simple, sequential code and still handle tens of thousands of concurrent requests or operations. Many are already reporting drastically simpler code after replacing complex reactive/non-blocking patterns with straightforward loops and blocking calls, all running on virtual threads. The trend now is frameworks race to eliminate any internal thread-pinching. For example, an issue was discovered with token refresh in Quarkus – now fixed by doing it asynchronously3 so as not to tie up a virtual thread. Expect more of these adjustments as frameworks become fully Loom-optimized. Bottom line: virtual threads are becoming the new normal for Java concurrency. If you’re on Java 21+, it’s worth exploring switching your executors and thread pools over to using Thread.ofVirtual().factory(). By the time Java 25 LTS lands, virtually every major library (DB drivers, HTTP clients, etc.) will have been vetted for Loom. This could herald a renaissance of simpler concurrency in Java, boosting developer productivity and app scalability hand in hand.
• Developer Experience & DX Tools – Another trend in July is the strong focus on developer experience (DX). We see it in Gradle 9’s improvements – making the build tool smarter (auto enabling config cache, clearer errors) so developers spend less time waiting or fighting builds22. We also see it in Quarkus’ realm: while Quarkus 3.24 (June) introduced a Dev UI “Assistant” with potential AI integration to guide devs, Quarkus 3.25 and 3.26 are polishing the development workflow (like warning extension authors of deprecated configs)3. The Spring ecosystem, too, with Spring Boot 3.5’s additions (like background initialization to speed startup) and upcoming Spring Tool Suite updates, is all about smoothing out the developer journey from coding to testing to deploying. Even smaller tooling, such as JDKUpdater simplifying JDK management, play into this trend1. The rationale is clear: in a world where Java is competing with “simpler” stacks (Node, Python) for new projects, making Java development as frictionless as possible is key. And it’s working – modern Java dev has never been so efficient. Another angle of DX is observability and debugging – the fact that JFR is being supercharged with new abilities means developers can get answers to “why is this slow?” or “what threads are doing” quickly, often in production-safe ways. This focus on developer experience lowers the cost of maintaining complex systems. We foresee continued investment here: e.g., Maven 4’s upcoming features to modernize Maven, more Visual Studio Code integrations for Java, and cloud IDE support from AWS and others for Java projects. All aiming to keep Java as a top choice by virtue of not just its runtime benefits, but also its ergonomics for developers.
• Standardization & Interoperability – A quieter but important trend is the Java ecosystem’s push towards standardization and interoperability. With Jakarta EE 11 now final, projects like Eclipse JNoSQL (which implements Jakarta NoSQL and the new Jakarta Data spec) are gaining attention1. In July, Eclipse JNoSQL 1.1.9 brought improvements in how it implements the Jakarta Data annotations1. Why does this matter? It shows a commitment to making sure different frameworks can speak the same language when it comes to data access. Spring Data, for instance, while not Jakarta Data yet, shares many concepts – and we might see convergence or at least easier migration between Spring Data and Jakarta Data in the future. Another area: MicroProfile and Jakarta EE alignment continues (MicroProfile 7.1 came in June with Telemetry updates to align with OpenTelemetry standard4). Even something like Piranha moving to Eclipse is about ensuring open collaboration on cloud-native Java runtimes. The benefit to developers is reduced lock-in and learning curve – skills and code become more portable across different Java stacks. You could take a DAO interface using @Repository and @Delete in one framework and move it to another with minimal changes because of these specs. Interop also extends to polyglot: with Kotlin 2.2 now stable (as of late June) and on track to be fully supported in Spring 7, Java and Kotlin are more aligned than ever, sharing features like record classes (Kotlin data classes interop) and more. In summary, the Java world is acknowledging its diversity (Spring, Java EE, MicroProfile, various cloud platforms) and working on common standards where it benefits everyone. This trend means your expertise in one Java tech is increasingly transferable to others, and your applications will be less siloed by framework choices.

📅 What’s Next?

As we move beyond July 2025, the stage is set for some major events and releases in the Java world:

• Java 25 GA & Post-GA – The GA of JDK 25 is on track for September 16, 20255. In August, we’ll see maybe a second RC and final testing (developers are already hammering away at RC1 now). Once 25 is out, attention will briefly turn to JDK 26 development (some early EA builds are out, but feature development for 26 will ramp up after 25 GA). However, expect a quieter period as far as language changes – most of the big ones are in 25, so 26 might incubate a few new things (perhaps early work on Project Valhalla? Or enhancements to Loom and Panama). Another thing to watch: the JavaOne 2025 conference (likely in fall) where Oracle might announce the next wave of projects or solidify plans for the future (Project Valhalla for value types is one to watch, as is Project Panama for native interop – maybe we’ll hear more on those for Java 26/27).
• Jakarta EE 11 Adoption & EE 12 Plans – Now that Jakarta EE 11 is out (as of end of June), the rest of 2025 will be about adopting EE 11 in the ecosystem. We can anticipate Spring Framework 7 to GA perhaps by late 2025, which will internally use Jakarta EE 11 APIs (meaning Spring 7 will require Java 21 and align with EE 11). Application servers like WildFly, Open Liberty, Payara, Tomcat etc. will issue updates declaring full EE 11 support – WildFly 38 (or a feature pack) for EE 11, Open Liberty has monthly drops and will incorporate EE 11 features probably by year’s end, etc. At the same time, early discussions for Jakarta EE 12 are likely to progress. Since EE 12 is targeted for 2026 and expected to baseline on Java 25, we might hear proposals for new specifications or updates. For example, there’s community interest in a Jakarta RPC or gRPC integration, revisiting older specs like Jakarta MVC or even new graph-based APIs. One concrete thing already mentioned is the possible revival of Jakarta Portlet under EE 124 – it might sound old-school, but modernizing it could help with building dashboard apps. If you’re involved in enterprise Java, it’s a good time to provide input on EE 12 wishlists.
• Framework Releases (Late Q3/Q4) – Several frameworks have big releases on the horizon:
  • Quarkus 3.27 LTS – As noted in the Quarkus 3.25 blog, Quarkus 3.27 is planned to be a Long-Term Support release, and its feature freeze is mid-August3. So we expect Quarkus 3.26 (with final new features) in late August, and 3.27 as a polished LTS in September. This will be significant for Quarkus users, as an LTS gives a stable base for the next 6-12 months. Quarkus 3.27 will likely include everything up to 3.26 plus extra hardening. The fact they’re doing an LTS implies Quarkus 4 (with major changes like Arc 2.0 or dropping Java 17 perhaps) might be planned for 2026. Keep an eye on Quarkus announcements around that timeframe.
  • Spring Boot 3.6 / Spring 7 – The Spring team’s milestones in July indicate that Spring Boot 3.6 and Spring Framework 7.0 are on the way. Historically, Spring releases often coincide with or shortly follow a new Java LTS release. We might see Spring Framework 7.0 GA by late fall 2025 (if M7 was in July, an RC in Aug/Sept, GA could be Nov). Spring Boot 3.6 will likely bring support for Jakarta EE 11 (upgrading its Tomcat/Jetty, etc.), and might be one of the last in the 3.x line unless they decide to go to Boot 4 to coincide with Spring 7. Key things to watch: Spring 7 could include improvements to AOT native image support (making it more transparent), perhaps experimental virtual threads support in WebFlux, and definitely the removal of deprecated stuff from Spring 6 (it’s a major version bump). By early 2026, we’ll likely have Spring Boot 4.0 as well, which might drop older Jakarta EE 10 compatibility and fully embrace EE 11 and Java 21+.
  • Micronaut 5? – Micronaut has been iterating on 4.x for a while; with Java 25 coming, they may choose to jump to Micronaut 5 to raise baselines and introduce new features. If so, a Micronaut 5 announcement could come toward the end of 2025. Micronaut 5 would likely require Java 21 or 25, and could integrate virtual threads in its scheduling and servers more deeply, as well as possibly unify its AOT approach with the growing standards in that space. This is speculative, but given Micronaut 4 was released when Java 17 came out, a new major might align with the new LTS too.
  • Hibernate 7.1 / 8.0 – We saw RCs for Hibernate ORM 7.1 in July; the final should drop in August. Hibernate 7.1 is a minor update (still Java 17 / Jakarta EE 10 baseline), but looking beyond, Hibernate ORM 8.0 is expected to target Jakarta EE 11 and Java 21, possibly by early 2026. The team might start hinting at plans for Hiberate 8 once 7.1 is out. If you’re a JPA user, these versions matter as they eventually flow into Spring Data and Jakarata EE implementations.
• Maven 4.0 Final – Maven 4 has been in RC through 2025 (RC3 in March, RC4 in June). It’s highly likely that the final Maven 4.0.0 release will occur in Q3 2025. This is a huge deal because Maven 3 has been the standard for over a decade. Maven 4 brings modern quality-of-life improvements: a new plugin execution model, support for Java 17 bytecode in plugins, and a migration of internal code to use a DI container, among other things4. It should remain largely compatible for end users, but plugin developers might need to update. Once Maven 4 is out, expect many plugin updates and a general push in the community to upgrade (especially as Maven 3.x reaches end of life). Build engineers should stay tuned – some companies will take it slow before jumping to Maven 4, but it offers enough improvements (and likely performance gains) that it will be appealing sooner rather than later.
• Grails 7 and Groovy 5 – The Grails framework (Groovy-based web framework) is nearing a major release 7.0 (RC1 was in early August)5. Grails 7 upgrades the underpinnings to Spring Boot 3 and possibly adds better virtual thread support (as noted, Grails Forge now can set up Boot with virtual threads)5. This will modernize Grails for those still using it in legacy apps, bringing it into the Java 17+ world. Meanwhile, Groovy 5 might reach RC or GA by end of 2025, which will be important for projects using Groovy DSLs (Gradle, Jenkins pipelines, etc.) as they’ll eventually move to that. Groovy 5 is expected to require Java 17+ as well and improve performance/parsing.
• Continued AI and ML Ecosystem Growth – We foresee that the Java AI libraries will continue their rapid evolution. Coming soon after 1.2, LangChain4j 1.3.0 (actually released in early August) introduced experimental “agentic” capabilities (the LangChain4j-agentic module)5. By the fall, we might see LangChain4j 1.4 or 2.0 with those agents stabilized, and possibly integration with streaming data or image processing. Spring AI might also expand – perhaps integration with Spring Batch for AI pipelines, or Spring Cloud streams for real-time AI inference. Also worth noting is Deep Java Library (DJL) – an AWS-led project – which supports running many deep learning models on the JVM (with GPU support). DJL and other model-serving frameworks (like Oracle’s Tribuo or Flyte) could see updates piggybacking on Java 21’s improved performance and JFR tooling to better monitor models. In short, if you’re interested in AI on Java, keep watching this space; it’s one of the most dynamic parts of the ecosystem right now, with both open-source and commercial tools pushing new releases frequently.
• Cloud and Container Tooling – Lastly, on the cloud front, Java’s container story is strong and likely to get stronger. Features like CRaC (Coordinated Restore at Checkpoint), which allows snapshotting a running JVM for super-fast startup, are being experimented with in OpenJDK (possibly ready by Java 26 or via OpenJDK labs). We might hear more about that later this year – it’s highly relevant for serverless Java. Also, frameworks will keep improving native image support: for example, Spring Boot 3.5 already made native compilation easier, and by Spring Boot 4, they might have one-step GraalVM builds quite streamlined. Kubernetes-native Java operators (like the new Eclipse EclipseStore might integrate with K8s CRDs? Or JDK Operator by vendors) could appear, making it easier to manage Java apps on clusters.

In summary, as we wrap up July 2025, the Java ecosystem is in one of its healthiest and most energetic states in years. Performance is up (thanks to Loom and JDK improvements), productivity is up (modern frameworks and tools focusing on developer experience), and new horizons are opening (AI, cloud-native paradigms, etc.). The releases this month, from Gradle to Quarkus to LangChain4j, all point to a Java that is both modernizing and thriving. Whether you’re maintaining a large enterprise system or kicking off a new startup project, it’s a great time to be a Java developer – the platform is evolving to meet developers wherever they need it, without losing the strengths that have sustained it for decades.11 Happy coding, and see you in the next edition for what August brings!