Apache Grails 7.1.0 General Availability
Apache Grails 7.1.0 has reached general availability, graduating from the RC1 milestone that shipped earlier in April. The GA release consolidates developer-visible improvements across the templating engine, testing integration, and the Gradle plugin for Groovy's invokedynamic bytecode instruction.
The most visible addition for frontend-oriented Grails developers is the new <g:flashMessages /> tag, which streamlines rendering Bootstrap-styled flash messages in views. Previously, teams had to write boilerplate markup or roll their own tag to pick up and display flash scope entries with appropriate Bootstrap alert classes. The built-in tag handles this consistently, reducing view layer duplication across application layouts.
Testing improvements arrive through Geb integration context path support. Applications deployed under a non-root context path—common in containerized environments behind a reverse proxy—previously required manual workarounds when running Geb functional tests. The 7.1.0 release makes the context path automatically available to the Geb integration, so test specs correctly construct URLs without additional configuration. This is particularly valuable for teams running Grails applications in Kubernetes where a path-based ingress is the standard deployment pattern.
The Gradle Plugin centralisation of Groovy invokedynamic handling, introduced in RC1, remains in place. This change consolidates the invokedynamic compiler flag management into the plugin rather than requiring individual build files to manage it, reducing the chance of subtle compilation differences between projects.
Read more — InfoQ
Micrometer Metrics 1.17.0-RC1
Micrometer Metrics 1.17.0-RC1 introduces two new metrics that surface behaviour specific to JDK 25 and JDK 26 runtime environments. Teams operating on modern JDK releases will find these additions useful for identifying previously invisible performance characteristics.
The executor.delayed gauge targets the new DelayedTaskCount API in JDK 25's ForkJoinPool implementation. Delayed tasks in a ForkJoinPool—those waiting to be scheduled rather than actively executing—were not previously observable through Micrometer's standard executor metrics. The new gauge makes this count visible, giving operators early warning when task scheduling is backed up in fork-join workloads, such as those used by virtual thread executors and parallel stream operations.
The GC CPU time function counter uses JDK 26's expanded MemoryMXBean capabilities to expose the cumulative CPU time spent in garbage collection. Traditional JVM GC metrics focus on pause duration and collection frequency, but CPU time provides a complementary view—particularly relevant for concurrent collectors like ZGC and Shenandoah where the "stop the world" pause is short but background GC work can still consume meaningful CPU budget. This counter enables dashboards and alerts that track GC CPU overhead independently of pause time.
Release candidate 1 status indicates the API is stable and these metrics are ready for production evaluation. Teams upgrading Spring Boot to 4.1.0-RC1 will see Micrometer 1.17.0-RC1 pulled in transitively.
Read more — InfoQ
JBang 0.138.0: WAR File Execution Support
JBang 0.138.0 adds the ability to execute WAR files directly alongside the existing JAR file support. This extends JBang's "run anything Java" philosophy to the web application archive format, which remains common in enterprise Java shops and in projects that target servlet container deployment.
Running a WAR directly via JBang (jbang myapp.war) provides a scripting-friendly path to inspect or test WAR content without requiring a full servlet container installation. While WAR execution semantics differ from JAR main-class execution—JBang invokes an embedded lightweight runtime to handle the archive—the user experience remains consistent with the rest of the JBang tooling.
This addition is particularly useful for developers who maintain legacy applications distributed as WARs and want to use JBang-based scripting or CI automation to validate those artifacts. Combined with JBang's dependency resolution and its integration with the JDK management ecosystem, the WAR support further positions JBang as a versatile tool for Java automation beyond its scripting origins.
Read more — InfoQ
Eclipse Store/Serializer 4.1.0 Beta1
Eclipse Store 4.1.0 and Eclipse Serializer 4.1.0 have entered beta with two developer-focused API additions. Eclipse Store is a Java-native object persistence framework that stores object graphs directly without requiring ORM or SQL mappings.
The new BatchStorer interface provides a dedicated abstraction for persisting multiple objects in a single batch operation. Previously, storing a collection of objects required either chaining individual store calls or working around the API to achieve batching. The BatchStorer makes bulk persistence a first-class operation, which matters for workflows that modify many objects in a single transaction, such as bulk data imports or ETL pipelines using EclipseStore as the persistence backend.
Enhanced generic typing in root methods improves compile-time safety when working with EclipseStore's storage root. The root object in an EclipseStore graph serves as the entry point for all persistent data. With the improved generics, the root's type parameters propagate through the API correctly, eliminating unchecked casts that were previously required when retrieving typed data from the root in generic-heavy domain models.
Beta status indicates the API is stable for evaluation. Both Eclipse Store and Eclipse Serializer 4.1.0 target Jakarta EE 11 compatibility and require Java 21 as a minimum runtime.
Read more — InfoQ
Links & Sources
You May Also Enjoy
