website

☕ Pulse on Java – June 2025 Edition

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

Welcome to the June 2025 edition of Pulse on Java, where we track the latest releases, innovations, and trends across the Java ecosystem. This month saw the GA release of Jakarta EE 11, significant framework updates (Spring Boot 3.5, Quarkus 3.24, Micronaut 4.8.3), and continued progress toward Java 25 (LTS). Many changes focus on performance optimizations, security enhancements, and powerful new features that are shaping how developers build modern Java applications. From enterprise data access simplification to AI-assisted development tools, June’s developments carry practical benefits for developers now and set the stage for what’s coming next12.

Targeted JDK 25 JEPs

18

Planned enhancements spanning language, performance, and VM improvements

Jakarta EE 11 GA

Jun 26 2025

Enterprise Java platform released with Java 21 support and new Jakarta Data spec

Spring Boot 3.5 Features

6+

Major improvements: structured logging, service SSL, env var config, async tasks, etc.

🔧 Framework Releases & Highlights

🌱 Spring Boot 3.5.0 (and 3.5.x)

Spring Boot 3.5.0 was released on May 22, 2025, ushering in a host of developer-centric improvements that were actively adopted through June3. Key new features in 3.5 include:

• Structured Logging – Built-in support for structured log output (e.g., JSON format), making logs more machine-parsable and easier to integrate with monitoring systems3. This improves observability and debugging in production.
• SSL for Service Connections – Simplified configuration to secure internal service connections with SSL3, enhancing security for applications that communicate with databases or message brokers.
• Load Properties from Environment – Ability to load configuration properties directly from environment variables3, streamlining deployment in containerized and cloud environments where config is often injected via env vars.
• Custom Async Task Executors – Support for plugging in a custom AsyncTaskExecutor to better control thread management for @Async methods3. This can improve performance by allowing optimal thread pool sizing or using virtual threads for asynchronous tasks.
• Background Initialization Auto-config – New auto-configuration to initialize beans in the background (on a separate thread) at startup3. This can reduce application startup time by parallelizing initialization of less critical beans.
• Filter/Servlet Registration Annotations – Developers can now use annotations to register Filter and Servlet beans3, simplifying configuration for web apps.

In addition, Spring Boot 3.5 brings dependency upgrades across the Spring ecosystem3 (e.g., Spring Framework, Spring Data, etc.) ensuring compatibility with the latest stable libraries. By late June, the Spring team had already released Spring Boot 3.5.3 with minor bug fixes, showing quick iteration to polish the 3.5 line3. Practical impact: Spring Boot 3.5’s enhancements mean easier ops (structured logs, env var config), better security defaults (SSL), and potential performance gains (faster startup, optimized async execution) – making it worthwhile for developers to upgrade and enjoy a smoother development and deployment experience.

🏢 Jakarta EE 11 (GA Release)

Jakarta EE 11 – the latest version of the enterprise Java platform – was officially released on June 26, 20251. This is a landmark update aligning enterprise Java with modern standards and JDK 21. Notable highlights:

• Java 21 Support & Concurrency – Jakarta EE 11 uses Java 21 as its baseline, enabling virtual threads and recent language features in the platform APIs1. For example, servers can utilize virtual threads for improved scalability with lower thread overhead1, and APIs can accept Record types or use pattern matching where applicable. This brings significant performance gains for enterprise apps, especially under high concurrency, thanks to Loom’s lightweight threads.
• New Jakarta Data specification – A brand-new spec, Jakarta Data, debuts in EE 11 to standardize the repository pattern for data access1. Much like Spring Data, it provides common interfaces (e.g. BasicRepository, CrudRepository) for CRUD operations1, pagination support, and a convention-based query mechanism. This simplifies persistence logic and reduces boilerplate for database interactions in a vendor-neutral way. Enterprise developers can now rely on Jakarta Data for database access abstraction, which improves productivity and portability across implementations.
• Streamlined APIs & Testing – Many existing specs were updated with an eye on simplification. The antiquated Security Manager is removed (following JDK deprecation) in favor of modern security practices1. Managed Beans (an older component model) are deprecated for removal, trimming fat from the programming model1. Jakarta EE’s Technology Compatibility Kit (TCK) was overhauled to use JUnit 5 and Maven, making it easier for implementers to test compliance1. These changes mean a leaner, more modern platform that’s easier to use and maintain.
• Specification Updates – Key Jakarta specs like RESTful Web Services (JAX-RS 4.0), CDI (Contexts and Dependency Injection), Security 4.0, Messaging, JSON Processing/Binding, and others received updates to align with Java 21 and fold in improvements from the past few years. For instance, JAX-RS 4.0 removes deprecated XML links and embraces newer JSON features, while Jakarta Security 4.0 integrates new authentication mechanisms. The overall theme is modernization without adding unnecessary new APIs – aside from Jakarta Data, the focus is on refining what exists.

Eclipse GlassFish 7.0.5 served as the reference implementation for the full EE 11 platform and Web Profile1, with WildFly and Open Liberty already acting as implementations of the new Core Profile (a subset of Jakarta EE)1. This means that as of release, multiple application servers (GlassFish, WildFly, Open Liberty, Payara, etc.) are or soon will be Jakarta EE 11 compatible1. Practical implications: Enterprise developers can start leveraging Java 21 features in a fully-supported way and use the new Jakarta Data to reduce the amount of boilerplate code in their repositories. The removal of legacy bits and alignment with modern testing ensures Jakarta EE remains a viable, efficient choice for cloud-native enterprise applications.

⚡ Quarkus 3.24.0

Red Hat’s Quarkus framework reached version 3.24.0 in late June (released June 25, 20252), bringing both new capabilities and important updates for developers targeting supersonic, subatomic Java. Highlights include:

• Dev UI Assistant – Quarkus 3.24 introduces a brand-new Dev UI Assistant feature3. This is an extension point that allows Quarkus extensions to provide interactive assistance in the Dev UI. For example, via the Assistant, extensions can offer guided workflows like generating OpenAPI clients, populating test data, or other common tasks2. Notably, the Assistant can even integrate AI-backed features (Quarkus has been experimenting with an “Chappie” AI assistant extension2). For developers, this means the Quarkus Dev UI (already a dev-time web interface for introspection) becomes even more powerful – potentially automating boilerplate and speeding up development by suggesting or generating code snippets.
• OIDC Health Check – Building on its robust security integration, Quarkus 3.24 adds a simple OpenID Connect health check for OIDC/OAuth2 clients3. This allows an application’s health endpoint to verify it can connect to the configured OIDC provider (useful in microservice scenarios to catch auth server connectivity issues early). It’s a small but handy addition for improving security and reliability, ensuring that authentication/authorization infrastructure is reachable and working.
• Major Dependency Upgrades – Quarkus aggressively stays up-to-date with key frameworks, and 3.24 is no exception. It bumps Hibernate ORM to 7.0 (Jakarta Persistence 3.2 API)2, Hibernate Validator to 9.0 (Jakarta Validation 3.1)2, and Apache Kafka Client to 4.03. These are significant updates: Hibernate ORM 7 brings improvements in JPA including better support for Java 17+ features and fixes, while Kafka 4.0 includes the latest protocol and client optimizations. By incorporating these, Quarkus ensures developers can use the newest JPA and validation features and stay compatible with the latest Kafka brokers.
• GraalVM 25 & JDK 21 – Although not a “feature” per se, it’s notable that Quarkus 3.24 is designed to run on Java 21 and even works with early builds of GraalVM 25 for native image generation2. Quarkus continues to position itself for the upcoming JDK 25 LTS, so these updates help test and guarantee that Quarkus apps will smoothly migrate to the new Java version and benefit from its improvements in performance.

Overall, Quarkus 3.24.0’s mix of developer tooling (Dev UI Assistant) and under-the-hood upgrades underscores its dual focus on developer productivity and runtime efficiency. Quarkus developers upgrading to 3.24 will get a head start on Jakarta EE 11 APIs (via Hibernate 7’s JPA 3.2) and can immediately leverage the Dev Assistant to automate common tasks, all while preparing their apps for the next-gen Java.

🌀 Micronaut 4.8.3

The Micronaut framework saw a maintenance release 4.8.3 on June 12, 2025. While a minor version, it rolled up improvements across many Micronaut modules:

• Micronaut Core & CLI – Contained performance tweaks and small bug fixes improving the reliability of the core inversion-of-control container and CLI commands. Startup times and memory usage saw incremental gains in certain scenarios (essential for Micronaut’s ahead-of-time compilation approach).
• Micronaut Security – Update in 4.8.3 includes patches and adjustments to the security module4. These likely address security bug fixes and alignment with latest OAuth/OIDC libs, ensuring developers using Micronaut’s security features have the latest protocols and fixes with minimal effort.
• Micronaut Data – The data access toolkit (an alternative to JPA/Hibernate) also received updates4, possibly including support for Jakarta Data (if aligning with EE 11) or general query improvements. This keeps Micronaut Data’s performance edge (compiling queries with AOT) sharp and up-to-date with new database capabilities.
• Cloud Integrations – Modules for Oracle Cloud services, Micronaut AWS and Azure might have been refreshed4. In particular, Micronaut 4.8.x expanded support for running in serverless functions (e.g., Azure Functions, AWS Lambda), and these updates continue that refinement, making it easier to deploy Micronaut apps in cloud serverless environments with minimal configuration.
• Micrometer Metrics & Observability – The Micrometer-based metrics module was likely updated (4.8.2 had improvements here). Micronaut 4.8.3 would carry forward any fixes, ensuring metrics and tracing work seamlessly out-of-the-box.

Unlike some larger releases, 4.8.3 didn’t introduce headline features but represents Micronaut’s steady commitment to optimization and third-party support. Developers on Micronaut 4.x should upgrade to 4.8.3 to benefit from these improvements (especially if using security or data modules)4. In short, Micronaut continues to polish performance and keep its extensive module ecosystem (from serialization to Coherence caching4) up-to-date, reinforcing its position as a fast, lightweight alternative for cloud-native Java.

🌐 Other Notable Updates in June

In addition to the big releases above, there were several smaller, but noteworthy, updates across the Java ecosystem in June 2025:

• WildFly 37 (Beta 1) – Red Hat’s Java EE application server entered beta for version 37. WildFly 37 is aligned with Jakarta EE 11, including updates to pass the new TCK and support the Jakarta Data spec. It also introduced a new Apache ActiveMQ Artemis commit-interval setting to fine-tune messaging performance (adjusting transaction sizes when moving messages to a backup broker)5. Furthermore, the WildFly management layer exposes new platform MXBeans and operations for monitoring, improving observability of the JVM’s performance inside the app server5. These changes prepare WildFly for full Jakarta EE 11 compliance and give administrators more knobs for performance tuning in production.
• Apache Maven 4.0 (Release Candidate 4) – The Maven build tool is inching toward its first major release in years. Maven 4.0 RC4 shipped in June with some exciting enhancements5: a new Maven Upgrade Tool (mvnup) to automate migration of projects to Maven 4 (it can auto-discover POMs and update them), a revamped dependency injection mechanism for extensions (allowing plugins to provide custom artifact handlers via DI, making the build system more modular), and even restoration of some previously removed APIs (like DefaultJavaToolChain.toString()) for better compatibility5. For developers, Maven 4 promises smoother upgrades and more flexible extension of the build process. The final GA of Maven 4.0 is expected soon; with RC4, it’s likely only bug fixes stand between developers and the Maven 4 era.
• Kotlin 2.2.0 – JetBrains released Kotlin 2.2.0 on June 23, 2025, bringing both new stable features and experimental previews for this popular JVM language. Notably, previously experimental language features like guard conditions in when statements, non-local break/continue (ability to break out of labeled loops from inside lambdas), and multi-dollar string interpolation (improved handling of $ in raw strings for templates) graduated to stable status5. These improvements make Kotlin even more expressive and convenient for developers – for example, multi-dollar interpolation simplifies generating code or regex patterns that include $ symbols. Kotlin 2.2 also introduced a new experimental feature: context parameters, which supersede the older context receivers approach5. Context parameters provide a way to pass implicit context into functions (useful for DSLs and dependency injection scenarios) while addressing some limitations of the previous design. Additionally, Kotlin 2.2 included performance optimizations on various platforms and fixes (such as for the @JsPlainObject annotation in Kotlin/JS)5. For Java developers, these advancements in Kotlin mean easier interop and more powerful Kotlin libraries, as Kotlin 2.2 remains 100% compatible with Java 17+ and can be used wherever Java is used.
• JobRunr 8.0.0 (RC & Beta) – JobRunr, a popular scheduling and background job processing library for Java, unveiled new features in its June betas/RC. The standout is Carbon Aware Job Processing5: the scheduler can now optimize for lower carbon emissions by timing jobs when the energy grid is cleaner. This innovation taps into a growing sustainability trend – enabling developers to reduce the carbon footprint of heavy batch jobs. Also new is an @AsyncJob annotation to easily schedule methods as background jobs, and a runStepOnce() method for one-time workflow steps5. These make JobRunr more declarative and convenient. The team has targeted GA for early July, making JobRunr one of the first Java job schedulers with built-in environmental awareness.

(Many other projects had routine updates – e.g., MicroProfile 7.1 came out with small improvements to the Telemetry and OpenAPI specs3; Open Liberty 25.0.0.6 added backport support for MicroProfile Health 4.0 to older Java EE apps3; Apache TomEE 10.1 aligned with MicroProfile 6.13; and even Log4j 2.25.0 brought native image metadata for GraalVM3. The Java ecosystem’s many parts are continuously evolving, but we’ve focused on the most impactful changes for typical Java developers.)

☕ Java Platform Update: JDK 25 in Focus

June 2025 brought Java 25 one step closer to release. JDK 25, due for General Availability in September 2025, entered Rampdown Phase One on June 5 – meaning its feature set is now frozen and the emphasis has shifted to polishing and bug-fixing6. By late June, JDK 25 had reached Early-Access Build 29, with only minor fixes since build 282. This indicates the platform’s 18 targeted JEPs (JDK Enhancement Proposals) are all integrated and on track. The community and early adopters are encouraged to test these EA builds to catch any issues before final release.

• June 5, 2025: Rampdown Phase One

  Feature freeze for JDK 25; all targeted JEPs integrated, focus shifts to stabilization.

• July 17, 2025: Rampdown Phase Two

  Nearly final build; second freeze tightening scope to showstopper bugs only (no changes to specifications).

• August 21, 2025: Initial Release Candidate

  The first JDK 25 release candidate is published for broader testing before GA.

• September 16, 2025: GA Release (JDK 25)

  Official General Availability of Java 25 LTS – production-ready release available to all.

With Java 25 being an LTS release, it packs a wide array of improvements across the board. Here we provide an overview of the key JEPs (features) targeted for JDK 25, grouped by theme, and why they matter to developers:

🔄 Language & Developer Productivity: JDK 25 continues Java’s gradual evolution to be more expressive and convenient.

• JEP 507: Primitive Types in Patterns (3rd Preview) – Extends pattern matching (for instanceof and switch) to handle primitive types6. This means you can directly use patterns to match on int, long, etc., without boxing. For example, if (obj instanceof int i) becomes valid, making code dealing with mixed object/primitive values cleaner. It’s a preview, but once finalized will reduce boilerplate when working with primitives in pattern matching.
• JEP 511: Module Import Declarations (Preview) – Introduces a new syntax import module <name>; at the top of Java files to declare module dependencies in code6. This improves modular code readability by listing required modules alongside package imports. It doesn’t replace module-info.java but complements it, helping tooling and developers see module requirements in context. This is particularly helpful in large modular projects, and it enables grouping imports by module (you can import an entire module to avoid many single-class imports6).
• JEP 512: Compact Source Files & Instance Main (Preview) – Allows top-level statements and instance main methods in Java source files6. In other words, you can now write a Java file without a class declaration – just like a script – and even have public static void main as an instance method inside a class or record. This further simplifies writing small programs and scripting with Java (building on JDK 21’s single-file source execution). Developers gain a quicker way to prototype or write utility scripts in pure Java without ceremony6.
• JEP 513: Flexible Constructor Bodies (Final) – Lifts some long-standing restrictions in Java’s constructor rules. Previously, a constructor had to call super() or this() as its first statement. JEP 513 allows executing other code before that call or consolidating initialization logic in one place for multiple constructors6. For example, you might perform input validation at the start of a constructor and only then call super(). This change, now final in Java 25, makes it safer and easier to factor common initialization code and improves consistency with how other languages handle constructors.

🧵 Concurrency & Memory Management: Many improvements in Java 25 aim to simplify multi-threaded programming and optimize memory usage.

• JEP 505: Structured Concurrency (5th Preview) – Further refines the structured concurrency API that treats a set of threads as a single unit of work66. In this preview, the API is streamlined to use a single factory method (e.g., StructuredTaskScope.open()) and supports custom thread closing actions6. The idea is that when you spawn multiple concurrent tasks (say, to fetch data from two services in parallel), structured concurrency makes it easy to join results or cancel all tasks if one fails, with the Java runtime handling thread lifecycles. This leads to more reliable and readable concurrent code, preventing thread leaks and unhandled exceptions across threads6. As virtual threads encourage more concurrency, this feature (still in preview) provides the tools to manage that concurrency safely.
• JEP 506: Scoped Values (Final) – Introduces a lightweight alternative to thread-local variables, optimized for inheritable data across threads (especially virtual threads)6. Scoped values allow you to bind an immutable value in a scope and have it accessible by any threads spawned within that scope without the overhead and memory leakage risks of ThreadLocal6. They are designed to work neatly with structured concurrency and virtual threads. For example, you can set a scoped value for a transaction ID or user context and all tasks in that scope can read it. This feature is final in JDK 25, giving developers a powerful tool to maintain context in concurrent operations, improving both performance (lower overhead than ThreadLocal) and safety (no risk of forgetting to clear a ThreadLocal)66.
• JEP 519: Compact Object Headers (Preview) – Reduces the memory footprint of Java objects on 64-bit platforms by compressing object header metadata6. The object header (which stores identity hash, GC metadata, locks, etc.) is made more compact, potentially halving its size. The benefit is most pronounced for applications with lots of small objects – e.g., microservice workloads or big data applications – leading to lower heap usage and better cache efficiency6. If you’ve got millions of objects, this could yield a significant memory saving, indirectly boosting performance due to less GC pressure. It’s in preview, meaning it’s off by default in JDK 25, but signals a future direction of a leaner JVM memory model.

🧪 Performance & Profiling Tools: JDK 25 brings numerous enhancements to help developers understand and improve the performance of their code, as well as some security-related API updates.

• JEP 509: JFR CPU-Time Profiling (Experimental) – Enhances Java Flight Recorder (JFR) with the ability to profile CPU time (not just wall-clock time) per thread and method6. This is crucial on modern systems where a thread might be runnable but not actually on CPU due to concurrency. With CPU-time profiling, you can find methods that are truly consuming CPU cycles versus those waiting or blocked. This feature, though experimental, means better insight into CPU hotspots in multi-threaded applications, helping pinpoint threads that hog the processor6. It’s especially useful for performance tuning in cloud environments where CPU is a paid resource.
• JEP 510: Key Derivation Function API (Final) – Introduces a standard API for cryptographic key derivation functions (KDFs)66. KDFs (like PBKDF2, scrypt, Argon2) are used to derive secure encryption keys from passwords or shared secrets. Before, developers often pulled in third-party libraries or wrote considerable code to do this safely. Now, Java provides built-in utilities: e.g., you can use SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256") directly with a PBEKeySpec6. This improves security by reducing the likelihood of ad-hoc or weak KDF implementations and makes it easier to follow best practices for password hashing and key generation. In short, Java 25 out-of-the-box is more security-friendly for developers writing encryption or password storage logic.
• JEP 514: Ahead-of-Time Command-Line Ergonomics (Final) – Simplifies the usage of jaotc (Java’s ahead-of-time compiler) and related GraalVM AOT compilation via better defaults and ergonomics6. In practice, this means the JVM will have smarter heuristics for AOT, possibly auto-enabling certain flags or choosing optimal code paths when you compile Java code ahead-of-time. For developers, it lowers the barrier to try AOT compilation for faster startup. Combined with the growing use of native images, this JEP helps ensure that even JIT-compiled applications can start faster by pre-compiling some methods. It’s a smaller quality-of-life improvement but part of the broader push to make Java more cloud-native (fast startup).
• JEP 515: Ahead-of-Time Method Profiling (Final) – Allows the AOT compiler to utilize profiling information about method usage frequencies6. Essentially, if you have data (from test runs or previous runs) showing which methods are hot, the AOT compilation can use that to make better decisions (like which methods to inline or optimize) ahead of time6. This bridges the gap between JIT, which profiles as it runs, and AOT, which was static – now AOT can be profile-guided. The result is potentially higher performance from AOT-compiled code because it focuses optimization effort on the right parts of the code. This is particularly relevant for applications compiled to native images, as it could improve their throughput by incorporating runtime knowledge into the build process.
• JEP 518: JFR Cooperative Sampling (Experimental) – Introduces a mechanism for the JVM and application to cooperate on where to sample execution for profiles6. With cooperative sampling, the application or library can mark “safe points” for sampling, reducing the overhead of collecting profiles by avoiding sampling at inopportune moments. This leads to more accurate and lower-overhead profiling in production systems6. Although an experimental feature, it’s geared towards power users who run always-on profiling and want to minimize its impact.
• JEP 520: JFR Method Timing & Tracing (Experimental) – Extends Flight Recorder to collect detailed per-method execution timing and call traces6. Essentially, JFR can record every method entry/exit along with timestamps, giving an exact trace of execution flow. This was possible before with external profilers, but now can be done with JFR with potentially less overhead and more integration. It’s a boon for debugging complex performance issues – you could see, for instance, the exact sequence of method calls leading to a slow request and how long each took. While experimental (and one must be cautious of the overhead and huge volume of data), it’s a powerful introspection tool for those hard-to-diagnose problems6.
• (Also noteworthy): While not directly about performance, another JEP under this umbrella is JEP 470: PEM Encoding for Keys (Preview) – it adds official support for reading/writing PEM-formatted cryptographic keys and certificates in Java’s standard API6. Many security tools and cloud services use PEM files (the “—–BEGIN KEY—–” format). Before JDK 25, developers often resorted to BouncyCastle or manual parsing for PEM. Now Java can handle PEM natively, making it easier to load SSL certificates or keys from files in a secure manner6. This streamlines security coding and eliminates some common pitfalls or external dependencies.

🧬 JVM Platform & Internals: JDK 25 also includes changes that affect the JVM itself and native integration, some of which developers will feel indirectly:

• JEP 502: Stable Values (Preview) – Introduces an API for creating stable value references that the JIT can treat as constant within a certain scope6. This is quite technical, but essentially it allows optimizations when you have values that don’t change once set (similar to final variables but with more flexibility). For example, if you have a configuration value that loads once and then remains stable, you could wrap it in a StableValue so the JIT knows it can optimize assuming it won’t change6. It’s part of ongoing efforts to give the JIT more hints for optimization, which can improve performance in tight loops or frequently accessed config without sacrificing the ability to change that config in controlled ways.
• JEP 508: Vector API (10th Incubator) – The Vector API gets its tenth incubating release in JDK 2566. This API allows developers to write SIMD (single instruction, multiple data) operations in Java, leveraging CPU vector instructions for math and data processing tasks. Each incubator iteration expands its capabilities or adapts to newer hardware. By now, the Vector API supports a range of vector sizes and operations, enabling performance comparable to C++ intrinsics for things like image processing, cryptography, and machine learning inference directly in Java6. It remains incubating, meaning you need --add-modules jdk.incubator.vector to use it6, but it’s edging closer to maturity. If you work in a field needing heavy number crunching, the Vector API is worth exploring as it can dramatically speed up data-parallel computations by utilizing AVX/NEON instructions on supported CPUs6.
• JEP 521: Generational Shenandoah GC (Final) – Shenandoah, a low-pause garbage collector introduced in JDK 12, gets a major upgrade by becoming generational66. This means Shenandoah will treat young (new) objects differently from old objects, similar to other GCs like G1, to optimize collection frequency. Generational GC is proven to improve throughput because young objects (which often die quickly) are collected more often, while long-lived objects are collected less frequently. Shenandoah’s goal is to keep pause times short; with generational mode, it can do so more efficiently, boosting overall GC performance and throughput for applications that choose Shenandoah6. For Java workloads requiring low latency, Shenandoah now becomes an even more attractive option in JDK 25.
• JEP 503: Remove 32-bit x86 Port (Final) – JDK 25 bids farewell to the 32-bit x86 architecture support6. Going forward, Java will only officially support 64-bit builds on x86 (and of course Arm, etc.). This streamlines the JDK codebase by removing a lot of legacy code and testing overhead that yielded diminishing returns – practically no one deploys server Java on 32-bit x86 anymore. For most developers, this has no impact (since 64-bit OSes are standard), but it’s a sign of the times and allows the JVM team to focus on modern architectures.

To summarize these JEPs in context, here’s a high-level view of what’s coming in Java 25:

Category	Key JEPs (JDK 25)	Developer Benefits & Highlights
Language & Productivity	JEP 507 (Primitive patterns, Preview) JEP 511 (Module import, Preview) JEP 512 (Compact files & scripts, Preview) JEP 513 (Flexible constructors, Final)	More expressive code (pattern-match primitives)6; clearer module dependencies in source6; quicker scripting without class boilerplate6; safer object construction with pre-super() logic.
Concurrency & Memory	JEP 505 (Structured concurrency, Preview) JEP 506 (Scoped values, Final) JEP 519 (Compact object headers, Preview)	Easier and safer thread management (scoped task groups)66; leak-free context passing across threads6; lower memory overhead per object for higher density and better cache utilization6.
Performance & Profiling	JEP 509 (JFR CPU profiling, Exp.) JEP 510 (Key derivation API, Final) JEP 514 (AOT ergonomics, Final) JEP 515 (AOT profiling, Final) JEP 518 (JFR coop. sampling, Exp.) JEP 520 (JFR method tracing, Exp.)	Deeper insight into performance: CPU-time analysis in Flight Recorder6, low-overhead sampling6, full method trace records6. Better startup and throughput via profile-guided AOT compilation6. Stronger security practices with built-in password hashing utilities6.
JVM & Platform	JEP 470 (PEM key support, Preview) JEP 502 (Stable values, Preview) JEP 508 (Vector API, Incubator) JEP 521 (Gen Shenandoah GC, Final) JEP 503 (Drop 32-bit x86, Final)	Smoother integration with standard crypto tools (PEM file handling)6; new optimization opportunities via stable-value hints6; GPU-like speedups for math-heavy workloads in pure Java6; improved GC throughput with Shenandoah for latency-sensitive apps6; a leaner JDK focusing on modern 64-bit systems.

As we can see, Java 25 is a comprehensive upgrade. Many features are still in preview/incubator, indicating Java is carefully evolving – giving developers early access to try new capabilities without forcing them to be used before they’re ready. For most devs, the big wins on day one of Java 25 will be quality-of-life improvements (like simpler patterns and constructors), performance gains from the platform (faster startup, less memory, better profiling), and out-of-the-box support for modern cryptography and concurrency patterns. It’s advisable to start testing applications on JDK 25 EA builds now, especially if you plan to migrate soon after its LTS release; this helps ensure any subtle incompatibilities or performance changes are identified early2.

🧠 Developer Trends

AI-First Java Development

Java frameworks are increasingly integrating AI capabilities, from LLM orchestration (LangChain4j) to multi-agent systems (Google’s A2A via Red Hat).

Virtual Threads: New Normal

Project Loom’s virtual threads are rapidly being adopted across the ecosystem – even enterprise specs like Jakarta EE 11 support them for huge scalability gains.

Cloud-Native Java Maturity

Java frameworks are embracing cloud-native needs – GraalVM native images, Micrometer metrics, and fast-startup tools are now standard offerings in Spring, Quarkus, Micronaut, Helidon, etc..

• AI-First Java Development – The trend of integrating AI into Java applications intensified. On top of May’s releases of Spring AI and LangChain4j 1.0, June saw further momentum: LangChain4j 1.1.0 reached release candidate, adding built-in connectors for more AI providers (Anthropic, Azure OpenAI, Amazon Bedrock, Google Gemini, Mistral, Ollama, etc.)3. This means Java developers can easily tap into a variety of LLM services with out-of-the-box modules, reflecting a push toward polyglot AI support. Moreover, Red Hat and Google jointly announced the Agent2Agent (A2A) Java SDK, enabling the development of multi-agent systems in Java using the open A2A protocol5. This SDK provides components to create and run “agents” that can communicate and coordinate – hinting at a future where Java backends might host swarms of intelligent agents performing tasks. In practice, Java shops are beginning to experiment beyond just calling AI APIs: they’re embedding AI deeper into apps (for instance, Quarkus’s Dev Assistant can leverage AI2). As tooling and libraries mature, expect AI and Java to become a routine combo, with Java’s strong enterprise integration playing well to deploy AI solutions at scale.
• Virtual Threads Becoming the New Normal – Since Java 21 introduced virtual threads, their adoption has been accelerating, and June’s developments cement this as a lasting shift. Jakarta EE 11’s explicit support for virtual threads1 means that enterprise Java developers can use them for handling requests, messaging, and other container-managed tasks, reaping scalability benefits without complex reactive programming. Many Java servers (like Helidon, mentioned last month, and now likely Open Liberty and others) either run on virtual threads by default or support an option to do so5. In the Spring ecosystem, Spring Framework 6 and Spring Boot 3 already ensure compatibility, so as more of the community moves to Java 21+, we’ll see widespread use of Thread.startVirtualThread(...) in place of traditional pools. The structured concurrency API (JEP 505), now in its 5th preview6, complements this by offering a high-level way to manage these threads. For developers, the continued trend means writing concurrent code that is simpler (you can often write straightforward blocking code and let the runtime handle scaling) and potentially more efficient (no more “thread-per-request” limits in servers — millions of concurrent tasks are now feasible5). Companies are already reporting that switching to virtual threads for I/O-heavy workloads greatly improved throughput and simplified code, confirming that Loom’s paradigm shift is paying off in real-world usage.
• Cloud-Native Java Maturity – Java’s evolution to embrace cloud-native requirements is largely complete, and June 2025 highlights that it’s now about refinement. All major frameworks (Quarkus, Micronaut, Spring, Helidon, etc.) have solid support for GraalVM native images, letting developers compile apps to native executables for instant start and low memory. For example, Spring Boot 3.5 and Spring Native make it easier than ever to build AOT-optimized native images; Quarkus 3.24 works with the upcoming GraalVM 25 for Java 212; Helidon has first-class tooling for native images. At the same time, observability and management are built in: Micrometer metrics and OpenTelemetry tracing are standard in these frameworks. MicroProfile 7.1’s updates to Telemetry and OpenAPI specs3 show the microservice-focused side of Java is iterating on making apps more observable and integrable. We’re also seeing Kubernetes-specific features (Spring Boot’s Kubernetes client, Micronaut’s distributed config and service discovery, etc.) stabilizing after these last few years of development. In essence, Java in 2025 is cloud-ready out of the box. The frameworks handle graceful shutdown, health checks, and externalized config uniformly. Build tools like Maven and Gradle are also catching up – e.g., Gradle 9 RC1 enables configuration cache by default for faster builds3, and Maven 4’s improvements will help in CI pipelines. All of this means Java developers can focus on business logic, with less worry about the mechanics of containers and cloud deployment – the ecosystem provides strong support for running Java at scale with minimal fuss.

📅 What’s Next?

As we move beyond June 2025, here are some things Java developers can look forward to on the horizon:

• Java 25 Final Preparations – With feature freeze in place, the next couple of months will see release candidates for JDK 25 and lots of testing by the community. The initial RC build is due in late August and final GA on September 16, 20256. Tool vendors (IDEs, build tools, analyzers) will also rush updates to support Java 25 on day one. If you haven’t yet, it’s a great time to try your projects on JDK 25 EA builds – not only to catch issues early but also to gauge performance improvements from all those JEPs. Early reports suggest some workloads see nice memory savings with compact object headers and slightly faster start times with the AOT tweaks, but your mileage may vary. By the next quarter, we’ll have a brand-new LTS Java release in our hands, ready to power the next wave of enterprise applications.
• Adoption of Jakarta EE 11 – Now that EE 11 is out, expect to see updates from all major Java EE implementations. WildFly 37 will likely go final with full EE 11 support (the beta is already out as noted) and then Jakarta EE 11 features can be used in production on WildFly, Open Liberty, Payara, and eventually Oracle’s WebLogic and Red Hat’s JBoss EAP. This also means Spring Framework will align: Spring Boot 3.6 or 4.0 (whichever comes next) might base on Jakarta EE 11 APIs, as Spring has done when EE 10 came out. For enterprise developers, the coming months will be about adopting Jakarta EE 11 – learning Jakarta Data, updating imports to jakarta.* if coming from older versions, and leveraging Java 21 in enterprise apps. The Jakarta EE Working Group has also begun discussing Jakarta EE 12, which is targeted for 2026 to incorporate Java 25 features1. Notably, Jakarta EE 12 is planned to support the upcoming JDK 25 (meaning Java 25 API features could surface in EE 12 specs)1. So the cycle of modernization continues, and input from the community will shape what new specs or improvements EE 12 should include – now’s a good time to get involved if there’s an API you’d like to see standardized.
• Spring Framework 7.0 & Boot 3.6 – The Spring team has been hard at work on the next generation of Spring. Spring Framework 7.0 is in development (milestone releases have been happening through 2025) and is expected to fully embrace Java 21+ (perhaps making Java 21 the minimum). We anticipate Spring 7 will bring improvements like compile-time AOT refinements (building on the Ahead-of-Time processing introduced in Spring 6), possibly a reactive streams overhaul to integrate structured concurrency, and deeper integration of virtual threads in Spring’s task executors and scheduling. Meanwhile, Spring Boot 3.6 (or possibly a Spring Boot 4.0 if they choose to bump major) will build on that, likely updating underlying dependencies (maybe Jakarta EE 11, maybe migrating from Microshed Testing to something new for tests, etc.). No official dates yet, but historically Spring Framework major releases follow a year or so after an LTS Java release, so late 2025 or early 2026 is plausible for Spring 7. Keep an eye on the Spring blog for milestone announcements in the coming months.
• AI and Agents in Java – The AI integration trend is far from over. Coming soon we have LangChain4j 1.1.0 GA (the RC in June suggests a GA in July) which will make those new provider modules official and possibly introduce easier “agent” constructs on top of the chains. There’s also active development in the ecosystem around model-serving in Java – tools like Deep Java Library (DJL) and JCoChart (Java Cognitive APIs) might see new releases enabling on-prem runs of LLMs or integration with AI services. The Agent2Agent Java SDK introduced by Red Hat is one to watch – as A2A (now under the Linux Foundation) gains traction, Java could become a leading platform for building complex AI agent systems that communicate over a standard protocol5. This could open up possibilities for Java-based automation and AI orchestration in enterprise settings (imagine a Java app coordinating multiple AI services securely on-prem). We expect more libraries and frameworks aimed at making Java a top choice for AI backends.
• Modernization of Build and Dev Tools – As mentioned, Maven 4.0 is nearly here, and by the end of the summer we might have the final release. That will kick off a wave of plugin updates and community adaptation (Maven 3 has been the staple for over a decade). Gradle 9.0 is also on the way (with RC1 already out introducing configuration cache by default and requiring JDK 17+3). These tool updates will modernize Java project builds – e.g., faster builds with caching, better support for version catalogs, and improved dependency management. It’s advisable to start planning migrations (especially for Maven 4 if your build relies on plugins that might need updates). Additionally, we might see new versions of popular libraries in the next months: for instance, Hibernate ORM 7.0 is now out (bundled in Quarkus 3.24) and could prompt Spring/Hibernate users to move up later this year; Micronaut 4.9 or 5.0 could be around the corner with further AOT optimizations; Apache Tomcat 11 (for Jakarta EE 11 compatibility) should finalize, affecting all Tomcat-based Spring deployments when they update to Servlet 6.1. In short, the latter half of 2025 will be a period of many upgrades as the ecosystem aligns with Java 21/Jakarta 11 and prepares for Java 25.

Finally, community events in the Java world (like JavaOne 2025 or regional JVM conferences later this year) will no doubt elaborate on these trends and perhaps unveil even newer initiatives (could there be early talk of Java 26 features beyond what’s in the pipeline for Java 25? Possibly!). With so much happening, it’s an exciting time to be a Java developer. Java’s renaissance in performance, cloud, and now AI integration is in full swing, and staying on top of these updates will ensure you can leverage Java’s best in your projects. Here’s to the next month of innovations! 12