October: The Rest of the Story - JVM Weekly vol. 151
I’ve gathered many interesting links in October that didn’t make it into previous issues. Many aren’t extensive enough for a full section, but they still seem compelling enough to share.
1. Missed in October
Let’s start with an important announcement — Project Valhalla and JEP 401 (Value Classes) are gaining momentum. The official project page on jdk.java.net has been updated with the latest builds and documentation.
The OpenJDK team is actively encouraging the community to test things out. The article Try Out JEP 401 Value Classes and Objects on inside.java shows how to start experimenting with JEP 401 (Value Classes and Value Records) in practice — including how to test early builds that contain Valhalla-related changes and a few additional use cases. For those who want to see code in action without installing anything, there’s also an interactive runner (run.mccue.dev), which lets you run Valhalla code directly in your browser.
Vaadin announced an important strategic decision: the Hilla and Flow frameworks will be merged into a single, unified platform. Until now, Hilla was a “TypeScript-first” framework with a Java backend, while Flow offered a pure “Java-first” approach to building user interfaces.
The goal of the merger is to create a cohesive developer experience that combines the best of both worlds. Developers will be able to switch seamlessly between the Java-based and TypeScript approaches, and even mix them within a single project. This is meant to make it easier to build complex, reactive web applications while giving teams more flexibility.
In Koog × A2A: Building Connected AI Agents in Kotlin, Andrey Bragin shows how to do this in practice in Kotlin using the Koog framework - from defining agent cards, sending messages, and handling longer-running tasks to security and observability. The article walks through an A2A implementation on JVM/Android/WebAssembly, leveraging Kotlin’s strengths (coroutines, concise syntax, multiplatform).
A2A (Agent-to-Agent) is a Google-created communication standard that allows AI agents to discover each other and exchange messages without bespoke integrations. It provides shared “agent cards” (capability declarations), a unified message format, and a task lifecycle (from submission to result), making it easier to compose orchestrations of many agents and scale the ecosystem without a tangle of APIs.
Staying with Google-related tech - the company announced a key update to its ADK (Agent Development Kit) for Java. The tool is opening up to third-party language models (LLMs) thanks to direct integration with the popular LangChain4j.
As described on the Google Developers and Google Cloud blogs, this integration makes it easier to combine Google models (like Gemini) with any other models supported by LangChain4j. Developers can now use LangChain4j’s API to build agents within the ADK ecosystem, simplifying management across different model providers.
Finally, Spring announces two projects under the Spring AI Community: Spring AI Agents and Spring AI Bench.
Spring AI Agents provides a lightweight, portable AgentClient interface and a set of abstractions: Goals (objectives, e.g., raising coverage, labeling issues, reviewing/merging PRs), Context (data and working environment), Tools (typically via MCP), Judges (deterministic or LLM-as-Judge) and Sandbox (local or Docker). This makes it possible to invoke different agent tools in a unified way without being tied to a single vendor.
On the other hand, Spring AI Bench is a companion harness/benchmark that evaluates agents on enterprise-style goal tasks (e.g., issue classification, automatic PR merging, test coverage). Mark Pollack criticizes current benchmarks (for example, divergence between SWE-bench and SWE-bench-Live results and a large Python–Java gap) and presents preliminary findings: successful classification of hundreds of labels, hundreds of processed PRs with reports, and differences in code quality despite similar coverage across models. The projects are in incubation (snapshots on Maven Central) and cooperate with the Developer Productivity AI Arena (DPAIA) on modern, transparent measurement of agent productivity.
Welcome to the new wave, people
There have been reports in the Apache community about a possible end of development for the Apache Derby database, with a formal proposal to move the project to the Apache Software Foundation “Attic” (the foundation’s project archive), which in practice means the end of active support.
The topic sparked discussion, including on Reddit. Derby - a fully Java-based, embeddable SQL database - was once a very popular choice (for a time it was even bundled with the JDK as Java DB). While not yet finalized, the decision reflects changing trends and declining interest in the project in recent years in favor of newer solutions.
Vlad Mihalcea , one of the most recognized figures in the Java community and an expert in data persistence, is celebrating the twelfth anniversary of his blog. Over the years, his site has become a foundational source of knowledge on Hibernate, JPA, and SQL query optimization.
In his anniversary post, Twelve years of blogging, Vlad shares reflections on his journey as a blogger, his motivation to share knowledge, and the evolution of the Java ecosystem he has observed over the last 12 years. It’s a great read not only about technology but also about perseverance, passion, and building a personal brand (how I hate that phrase) in the IT world.
And to wrap up, something that warmed my patriotic heart — a story about… the Polish flag in IntelliJ IDEA. In Vibe coding an IntelliJ IDEA progress bar plugin for fun, 👩🏻💻 Marit van Dijk describes how, at Devoxx Poland , she put together a tongue-in-cheek progress bar with a white-and-red stripe and “#PolishSmile,” building a one-off plugin using the “vibe coding” method with help from Junie (JetBrains’s assistant). She started from a ready-made plugin template, ran it quickly via runIDE, and then iterated with prompts: from “make it like Nyan Progress Bar, but Polish” to refinements that ultimately required… providing sample code from Nyan Progress Bar so Junie could reproduce a continuous, smooth bar. The result: it works, though the icon had to be added and adjusted manually.
The plugin didn’t make it to the Marketplace, but the code is publicly available. It’s a chance to learn how IntelliJ plugins work and, at the same time, the perfect excuse to wave the white-and-red on an IntelliJ IDEA progress bar.
And now it is time for the radar!
2. Release Radar
Koog 0.5.0
JetBrains keeps up the pace in AI tooling. The new release, Koog 0.5.0, brings several key changes that materially simplify building agents in Kotlin.
The biggest addition is a non-graph API for strategy design - you can define and modify agent behaviors directly in Kotlin without working with graphs, while retaining state management and history-compression mechanisms; this speeds up prototyping and, when you need stronger reliability, you can still “scale up” to a graph-based workflow with full persistence and deep event tracing. At the same time state durability and checkpointing were improved: a RollbackToolRegistry appeared to undo side effects of tool calls (rollbacks no longer leave the environment in a broken state), and there’s a toggle between persisting the whole state machine or only the message history.
Tool API was improved too - tool descriptions for classes are auto-generated across platforms and subgraph structure is better organized. New building blocks arrived: AIAgentService to run multiple agents as managed-state services, an LLM-as-a-Judge component for evaluations/selection, and streaming with tool calls (the frontend can stream partial responses while the agent concurrently uses tools). Rounding this out is the previously mentioned full Agent-to-Agent (A2A) protocol support, which makes building systems of cooperating agents easier.
Grails 7.0
Originally known as “Groovy on Rails,” Grails was born in 2005 as the JVM’s answer to Rails: a full stack, conventions-over-configuration, fast CRUDs and GORM on top of Hibernate, all glued with Spring - with Groovy as the “productivity language” on the Java VM. The project matured quickly (0.1 in 2006, 1.0 in 2008) and over the years evolved into a “framework of frameworks,” relying on Spring Framework/Jakarta EE/Hibernate. Ideologically it still pursues the same goal: high velocity development with minimal boilerplate using DRY and Convention-over-Configuration.
Recently Grails reached a major milestone: it officially finished incubation (previously under the Apache Groovy umbrella) and graduated to a Top-Level Project at the Apache Software Foundation. Behind the scenes this meant a huge amount of work: consolidating code into a monorepo (over 325 artifacts), changing Maven coordinates to org.apache.grails, implementing verifiable builds per ASF policy, automating releases and tidying up licensing (SBOM). It also closes the transition phase from stewardship by e.g. Object Computing/Grails Foundation to a fully community-driven “Apache Way” model.
In Grails 7 itself the foundations were updated (Groovy 4.0.28, Spring Framework 6.2.11, Spring Boot 3.5.6) and the Asset Pipeline was refreshed, plus a number of developer-focused improvements: reproducible builds and SBOMs for all JARs, multiproject reloading, an option to disable Micronaut integration via a plugin, and consistent JSON date rendering (ISO-8601). GORM got fixes (e.g., support for entities with the same name in different packages) and Groovy Server Pages (GSP) were optimized.
Async-profiler 4.2
The latest 4.2 release directly addresses several hot topics in the ecosystem: a method tracing mode (--trace) that measures latency per call (handy when sampling “blurs” rare paths), system-wide process sampling on Linux (--proc) to diagnose noisy neighbors, and the default stack walking switched to VMStructs, removing the crash risks known from AsyncGetCallTrace. Together these changes increase profile reliability and reduce the adoption cost in CI/CD. Additionally, the JFR converter supports an experimental CPU time event (JEP 509 / CPUTimeSample), allowing creation of flamegraphs/heatmaps straight from JFR — including thread-level breakdowns.
The team announced a move to a three-month “release train”, which should deliver faster patches and safer, smaller upgrades (the next release is slated for January 2026). Meanwhile async-profiler was added to official Amazon Corretto builds (Linux/macOS), so asprof/jfrconv are now “available out of the box” alongside the JDK. That materially lowers the barrier to entry.
(I’m kind of waiting for async-profiler to finally show up in the JDK’s /bin directory.)
Helidon 4.3
Oracle released Helidon 4.3, continuing the development of their lightweight, native-oriented Java framework.
Helidon 4.3 focuses on a real “DX uplift”: besides dependency updates it brings building blocks for agent/AI use cases (official support for the Model Context Protocol with server and client based on Helidon WebServer on virtual threads) and solid improvements in observability and RPC. Notable additions include Helidon Declarative (an annotation-driven model for endpoints, scheduler and fault-tolerance), Helidon Data (repository pattern), Eureka Discovery integration for better Spring interoperability, OpenTelemetry extensions and gRPC enhancements (metrics, tracing, reflection, optional compression).
Helidon 4.3 also bumps LangChain4j to 1.5 and introduces build-time generated “bindings” to APIs so that AI-annotated classes can be injected without reflection. There’s an adapter from TokenStream → Java Stream (easier blocking error handling), official OCI Generative AI support, and Jlama (in-JVM LLM inference, MoE, tool-calling, quantizations).
There’s more detail in the Release Notes.
Quarkus 3.29
Quarkus 3.29 is a relatively small release, but it adds support for multiple cache backends in a single application (e.g., Caffeine and Redis simultaneously), Debug Adapter Protocol support for Qute templates (template debugging in IDEs), and keeps Hibernate ORM/Reactive extensions active even when no entities are defined.
WildFly 38
WildFly 38 advances the platform with MicroProfile 7.1 (updated OpenAPI 4.1 and Telemetry 2.1) and tidies the operational foundations: feature packs automatically generate detailed documentation of their layers and resources via the Management API, and there’s a web catalog of feature-packs and layers with a model preview for management and Galleon features. The team also refreshed the admin documentation — the old “wildscribe” was replaced by a fuller description of what the main WildFly 38 feature pack provides. The standard distribution remains compliant with Jakarta EE 10 (Full/Web/Core Profiles) on Java SE 17 and 21; certification artifacts and full supported-spec lists (including those beyond MicroProfile Platform) are available in the cert repository and Getting Started guide.
At the same time WildFly Preview delivers more Jakarta EE 11 items — chiefly JPA + CDI integration (injection of EntityManager/EntityManagerFactory with @Inject) and updates to Jakarta Authorization. Some areas still use EE 10 variants, but the plan is to shift them to EE 11 in Preview 39.
Mandrel 25
The Quarkus team announced Mandrel 25 - a specialized GraalVM CE distribution optimized for building native images of Quarkus apps. This release is based on the latest upstream GraalVM changes.
Mandrel is a “slimmed” GraalVM CE distribution focused solely on native-image for Java (without the polyglot parts: no Truffle, no embedded Python/JS/Ruby). It’s built on OpenJDK/HotSpot using Red Hat–style builds (or possibly IBM builds today) and is rigorously tested with that environment to provide predictable, repeatable, production-grade pipelines for RHEL/UBI. In short:
Does Mandrel 25 “differ” from regular GraalVM? At the native-image compiler level — not much: Mandrel 25 tracks upstream GraalVM CE, so the produced binaries and behavior are practically equivalent. Differences are mainly scope (no polyglot features), packaging, supported platforms, and default build flags tuned for Quarkus. If you use Quarkus and build native images on Linux, Mandrel gives a more predictable, “production” experience.
A little oasis of stability in turbulent times.
Liberica Native Image Kit 25.0.0
Speaking of native-image distributions - BellSoft also ships its take: Liberica Native Image Kit 25.0.0+1 - basically “GraalVM CE, BellSoft style.”
NIK follows upstream GraalVM/OpenJDK, bringing fresh fixes and improvements (smaller footprint, better compatibility) and BellSoft offers commercial support - a plus for teams targeting production with SLA requirements. If Mandrel fits Quarkus well, then in broader scenarios (various frameworks, platforms, container images) NIK is a solid, enterprise-friendly alternative.
JUnit 6.0
The JUnit team has officially released JUnit 6 - the successor to JUnit 5 (Jupiter), consolidating the project and refreshing the foundations of JVM testing.
JUnit started in 1997 and became the de facto standard for unit testing; milestones include JUnit 4 (2006) which used Java 5 annotations, and JUnit 5 (2017) which split the project into Platform/Jupiter/Vintage and opened the platform to multiple test engines. That modular architecture allowed running JUnit 3/4 (Vintage) and 5 (Jupiter) tests side-by-side, easing migration and IDE/build-tool integration.
In JUnit 6.0 the baseline Java is 17, minimal Kotlin is 2.2; Platform, Jupiter and Vintage move to a single unified version number. The project adopted JSpecify annotations for expressing nullability; junit-platform-launcher now directly supports Java Flight Recorder (JFR); ordering of @Nested classes was made consistent and MethodOrderer.Default / ClassOrderer.Default were added; CSV handling for @CsvSource / @CsvFileSource switched to FastCSV; native support for Kotlin suspend test methods was added. Tooling additions include a --fail-fast option in the ConsoleLauncher and a CancellationToken that can abort runs and propagate to registered engines (e.g., Jupiter, Spock, Cucumber). Several deprecated APIs and modules were removed (e.g., junit-platform-runner, junit-platform-jfr moved into the launcher).
What’s the practical effect? The JUnit ecosystem stays aligned with the JUnit 5 paradigm (Platform/Jupiter/Vintage), but 6.0.0 tidies APIs and tools for modern JVMs and Kotlin, strengthens observability (JFR), improves execution determinism (ordered @Nested), and adds control over execution flow (fail-fast / cancellation).
And continuing the testing topic…
Testcontainers for Java 2.0
One of the month’s significant releases: Testcontainers for Java reached 2.0.0. For those who need a reminder — this library has long enabled writing integration tests against “real” services in containers (Postgres, Kafka, Elasticsearch, etc.) instead of mocks or in-memory substitutes — it went through a substantial API cleanup and module reorganization to make maintaining large codebases easier and to prepare the project for future growth. They were acquired by Docker some time ago, but development continued.
Practically, 2.0.0 brings several important changes: an official farewell to JUnit 4 (the project and examples have migrated to JUnit Jupiter), unified artifact naming with the testcontainers prefix, and relocation of container classes to packages matching modules. Other improvements include new container helper methods (e.g., getHttpUrl() in ClickHouse), gRPC support in the BigQuery emulator, and various dependency updates. Side effect: some breaking changes may appear in existing tests (imports and Maven/Gradle coordinates changed), but we get a cleaner API and a sturdier foundation for future iterations.
Interestingly, several ecosystems (like Spring Boot) are still adapting to 2.0, so when migrating it’s worth checking your stack’s compatibility.
3. GitHub All-Stars
UnknownJoe796/super-mario-bros-kotlin
UnknownJoe796 published an amazing project: a full reimplementation of Super Mario Bros in the style of the NES console, written entirely in Kotlin. This project demonstrates Kotlin’s power not only for backend or mobile apps, but also for game development.
The repository is gaining traction for its fidelity to the original, attention to detail and interesting goals - create extreme moddability for the game, enabling access of resources beyond the NES. It’s an excellent educational resource for anyone who wants to see how to manage game state, render 2D graphics, and implement physics in a modern JVM language.
Darn - I’m starting to question the need for my own NES emulator in Kotlin - time for a new stunt… already prepping one 😁. In your face, UnknownJoe796... Good job man
scf37/spacemonger1
SpaceMonger One is a cross-platform reincarnation of the classic disk-usage visualization tool — it shows the file structure as rectangles whose sizes correspond to disk usage, making it quick to find the “heavy” directories.
The project is released under the MIT license and includes binaries for Windows and Linux (macOS users can use a cross-platform version that requires Java 24+).
tanin47/embeddable-java-web-framework
Okay, time to step away from games and look at something more practical. embeddable-java-web-framework is a new minimalist web framework for Java designed to be embeddable. Its main selling points are zero configuration and a minimal dependency footprint, making it ideal for small microservices, admin panels, or adding an HTTP API to existing applications.
javelit/javelit
Cyril de Catheu showcased his project Javelit, positioned as an alternative to the popular Python library Streamlit, but for the Java ecosystem. Streamlit enables quick creation of interactive web apps (dashboards) directly from data-analysis code.
Javelit aims to fill that niche for Java, allowing developers and data analysts to rapidly build visual interfaces for their tools and scripts without diving into complex front-end frameworks. The project received a warm welcome on r/java.
Fun fact: the project was originally named Jeamlit, but apparently Streamlit wasn’t too happy 😁. That’s We remember, leftPad.probably a sign of success - moves like that can even get you a Wikipedia page.
potjerodekool/nabu
Now we are going into nerdy territory.
Nabu is a polyglot compiler that translates source code to Java bytecode for the JVM, designed to be easily extensible so language authors can add support for their own languages without building a compiler from scratch. It currently compiles the Nabu language (whose syntax is inspired by Java and Kotlin) and interoperates with Java - Nabu and Java can coexist in the same project and call each other, with Java 20 supported.
Nabu supports compiler plugins for creating domain-specific languages (DSLs) (for example, a JPA DSL that enables joins, casts and operator overloading), and integrates into Maven builds via the nabu-maven-plugin, which must run before the maven-compiler-plugin so both Nabu and Java sources compile correctly.
DanielLiu1123/json4j
The Java ecosystem already has many JSON libraries, but json4j tries to find its niche. It’s another offering: a simple, lightweight, and fast JSON parser/serializer that boasts minimal overhead and an easy API.... with only one single file!
The project seems aimed at users for whom full-featured libraries like Jackson or Gson are overkill, or where every kilobyte of binary size matters (e.g., IoT apps or very small microservices).
blazmrak/veles
Veles is an opinionated, lightweight JDK-first CLI that lets you run, compile and package small-to-medium Java apps without the ceremony of Maven/Gradle. It autodetects entry points, keeps resources next to sources, and exposes a lot of useful commands.
It targets fast iteration and editor friendliness for developers using JDK 24+, helps with native builds via reachability/AOT flows, and deliberately avoids being a full build system or supporting Windows/other JVM languages.
I particlulary love the name - Veles is one of the OG Slavic Gods... the evil one 😉
And that’s all for today! Thanks for reading and see you next week!