Java Code Geeks

Token-Oriented Object Notation (TOON) is a modern data serialization format designed to represent structured data in a compact, human-readable, and token-efficient way. It encodes the same data model as JSON but removes unnecessary syntax such as braces, quotes, and repeated field names. This makes TOON beneficial in Java applications that interact with APIs and Large Language Models (LLMs), where reducing token usage improves both performance and cost efficiency.

1. Understanding TOON Syntax

TOON represents structured data using indentation for objects and concise, CSV-like structures for arrays, combining YAML-style readability with tabular efficiency. By eliminating unnecessary punctuation while preserving the structure and meaning of the data, this approach enhances readability and maintains a strict, well-defined format that can be easily parsed.

product:
  id: 101
  name: Laptop
  price: 1500
  tags[2]: electronics,computing

One of the design goals of TOON is to reduce token consumption by eliminating repetitive structures like braces, quotes, and repeated field names, which are common in JSON.

In the example above, the object is defined using indentation, and the array explicitly specifies its size. This reduces ambiguity and simplifies parsing. The syntax replaces JSON braces and quotes with indentation and concise key-value pairs. Arrays explicitly include their size (e.g., [2]).

Example: JSON vs TOON

JSON

{
  "name": "Thomas",
  "age": 30,
  "city": "London"
}

TOON

name: Thomas
age: 30
city: London

TOON Data Structures

TOON supports the same core data structures as JSON: primitives, objects, and arrays.

Objects

Objects are represented using key: value pairs, one per line.

id: 101
name: Thomas
active: true

This structure is straightforward and avoids the need for braces, making it easier to read and write.

Nested Objects

Nested objects are represented through indentation.

user:
  id: 1
  name: John

Indentation defines hierarchy, similar to YAML, ensuring clarity in deeply nested structures.

Arrays

Arrays in TOON explicitly declare their size using [N].

colors[3]: red,green,blue

Tabular Arrays

One of TOON’s powerful features is its tabular representation for uniform arrays of objects.

users[2]{id,name,role}:
  1,Thomas,admin
  2,John,user

Here:

[2] indicates the number of elements
{id,name,role} defines the schema
Each row contains only values

This avoids repeating field names for every object, significantly reducing data size.

2. Setting Up TOON in a Java Project

To work with TOON in Java, we need a supporting library such as JToon or json-io, both of which provide encoding and decoding capabilities.

        <dependency>
            <groupId>dev.toonformat</groupId>
            <artifactId>jtoon</artifactId>
            <version>1.0.9</version>
        </dependency>

This configuration adds the JToon library, which provides APIs for encoding Java objects into TOON and decoding TOON into Java structures. It is designed to be lightweight and compatible with modern Java 17+ applications.

3. Parsing TOON Data in Java

Parsing TOON involves converting a TOON string into Java objects or generic structures.

public class ToonService {

    public Object parseToObject(String toon) {
        return JToon.decode(toon);
    }
}

The decode method parses TOON text into Java types such as Map, List, or primitives.

Parsing Arrays

TOON provides a structured way to represent arrays, including tabular arrays for objects.

public class ToonJavaDemo {

    public static void main(String[] args) {

        String toon = """
            products[2]{id,name,price}:
            101,Laptop,1500
            102,Phone,800
            """;

        Object result = JToon.decode(toon);   
        IO.println(result);
 
    }
}

In this format, [2] specifies the number of elements, and {id,name,price} defines the schema. Each row represents a product without repeating field names. The parser automatically converts this structure into a list of objects, making it efficient for handling large datasets.

Output

{products=[{id=101, name=Laptop, price=1500}, {id=102, name=Phone, price=800}]}

4. Converting Java Objects to TOON

Java objects can be easily converted into TOON strings. This process is essential when preparing structured data for storage, transmission, or integration with systems like APIs and LLMs. The library automatically handles formatting, ensuring the output adheres to TOON syntax, including indentation and compact array representation.

public record Product(int id, String name, double price, List<String> tags) {}

public class ToonService {
    
    public String generateToon(Product product) {
        return JToon.encode(product);
    }
}

The above code defines a Product record and a ToonService class responsible for converting the object into TOON format. The JToon.encode() method serializes the Java object into a TOON string, automatically applying the correct structure and formatting rules.

Example Usage

public class ToonJavaDemo {

    public static void main(String[] args) {

        Product product = new Product(101, "Laptop", 1500.00, List.of("electronics", "computing"));
        ToonService service = new ToonService();
        String toonOutput = service.generateToon(product);

        IO.println(toonOutput);
    }
}

This example creates a Product instance and uses the service to generate its TOON representation. The result is printed to the console, demonstrating how Java objects can be easily converted into TOON format.

Output

id: 101
name: Laptop
price: 1500
tags[2]: electronics,computing

The output shows the TOON representation of the Product object. The structure is clean and concise, with arrays represented using a compact format that specifies their size and values inline.

Converting Lists

TOON is highly efficient when working with lists of objects.

public class ToonJavaDemo {

    public static void main(String[] args) {

        List<Product> products = List.of(
                new Product(101, "Laptop", 1500, List.of("electronics")),
                new Product(102, "Phone", 800, List.of("mobile"))
        );

        String toon = JToon.encode(products);

        IO.println(toon);
    }
}

Output

[2]:
  - id: 101
    name: Laptop
    price: 1500
    tags[1]: electronics
  - id: 102
    name: Phone
    price: 800
    tags[1]: mobile

4. Reading and Writing TOON Files

Reading and writing TOON files in Java involves using standard file I/O operations. This allows applications to persist structured data in TOON format and later retrieve and parse it into Java objects.

public class FileExample {

    private static final String FILE_PATH = "product.toon";

    public static void main(String[] args) throws Exception {

        List<Product> products = List.of(
                new Product(101, "Laptop", 1500.00, List.of("electronics", "computing")),
                new Product(102, "Phone", 800, List.of("mobile"))
        );

        // Convert Java object to TOON
        String toonData = JToon.encode(products);

        // Write TOON data to file
        Files.writeString(Path.of(FILE_PATH), toonData);

        IO.println("TOON data written to file:");
        IO.println(toonData);

        // Read TOON data from file
        String readData = Files.readString(Path.of(FILE_PATH));

        // Convert TOON back to Java object
        Object parsedProduct = JToon.decode(readData);

        IO.println("\nParsed object from file:");
        IO.println("ID: " + parsedProduct);
    }
}

This example demonstrates the complete lifecycle of TOON data handling. A Product object is first created and serialized into TOON format using JToon.encode(). The resulting string is written to a file using Files.writeString(). The file is then read back into memory, and JToon.decode() is used to reconstruct the original Java object.

5. OpenAI API Integration

TOON format is highly effective when interacting with Large Language Models (LLMs) such as OpenAI because it reduces token usage while preserving structured data. In Java applications, TOON can be used to encode domain data before sending it as part of a prompt, improving efficiency and reducing API costs.

To integrate OpenAI with Java and use TOON, include the required dependencies:

        <dependency>
            <groupId>com.theokanning.openai-gpt3-java</groupId>
            <artifactId>service</artifactId>
            <version>0.18.2</version>
            <scope>compile</scope>
        </dependency>

This dependency provides the OpenAI Java client used to communicate with the OpenAI API. It includes the necessary classes for building requests, sending prompts, and handling responses from language models. By adding it to the project, the application can integrate AI capabilities alongside TOON data processing.

Example Code

public class ToonOpenAiExample {

    public static void main(String[] args) {

        // Create Product Data
        List<Product> products = List.of(
                new Product(101, "Laptop", 1500.00, List.of("electronics", "computing")),
                new Product(102, "Phone", 800.00, List.of("mobile"))
        );

        // Convert Java objects to TOON
        String toonData = JToon.encode(products);

        // Build Prompt
        String prompt = "Analyze the following product data and suggest pricing improvements:\n\n"
                + toonData;

        // Initialize OpenAI Service
        OpenAiService service = new OpenAiService("your-api-key");

        // Create Chat Request
        ChatCompletionRequest request = ChatCompletionRequest.builder()
                .model("gpt-4")
                .messages(List.of(
                        new ChatMessage("user", prompt)
                ))
                .build();

        // Execute Request
        String response = service.createChatCompletion(request)
                .getChoices()
                .get(0)
                .getMessage()
                .getContent();

        // Print Response
        IO.println("LLM Response:\n" + response);
    }
}

This example demonstrates a complete workflow for integrating TOON with the OpenAI API. First, a list of Product objects is created and converted into TOON format using JToon.encode(). The TOON data is then embedded into a prompt, which is sent to the OpenAI API using the Java client. Finally, the response from the model is retrieved and printed to the console.

Example TOON Sent to OpenAI

products[2]{id,name,price,tags}:
  101,Laptop,1500.0,electronics|computing
  102,Phone,800.0,mobile

This TOON representation is significantly more compact than JSON, as it avoids repeating field names and minimizes punctuation while still preserving structure.

Key Benefits of This Integration

Using TOON in OpenAI integrations provides several advantages:

Reduced token usage compared to JSON
Improved readability of structured prompts
Better performance and lower API costs

6. Conclusion

In this article, TOON format was introduced as a compact and efficient alternative to JSON for handling structured data in Java applications. The discussion covered its syntax, advantages, and practical implementation using JToon, including parsing, generating, and working with arrays and files. Additionally, the integration with the OpenAI API demonstrated how TOON can improve token efficiency when interacting with Large Language Models.

7. Download the Source Code

This article covered using TOON format in Java as an alternative approach to JSON for handling structured data.

Download
You can download the full source code of this example here: Java JSON TOON format libraries

Tags

Prompt Engineering Is Not Enough: How Java Developers Should Structure AI Agent Workflows Using Embabel or Koog

Eleftheria Drosopoulou — Thu, 30 Apr 2026 05:32:00 +0000

Core Java

Prompt Engineering Is Not Enough: How Java Developers Should Structure AI Agent Workflows Using Embabel or Koog

Goal-oriented planning, tool registration, and multi-step task execution — finally, on the JVM.

1. The Problem With Prompt-Only Thinking

If you have spent any real time building LLM-powered features in Java, you have almost certainly run into the same ceiling. At first, a clever prompt seems to solve everything. You craft a system message, shape the user turn, sprinkle in some examples, and — for a while — it works surprisingly well. Then, as soon as the task gets more complex, the cracks appear. The model forgets earlier steps. It invents data you did not give it. It confidently completes the wrong goal. Moreover, when it does fail, you have very little idea why.

This is not a model quality problem. It is an architectural problem. As Rod Johnson — the creator of the Spring Framework — put it when describing why he built Embabel: “Without agentic systems, we are more like alchemists than engineers, our prompts more like incantations.” That framing resonates with any developer who has spent an afternoon chasing a flaky prompt through staging logs.

Prompt engineering optimises a single LLM call. Agent frameworks orchestrate sequences of calls, tools, and decisions — and they do it in a way that is testable, explainable, and survives refactoring. These are entirely different problems.

For years, Java developers who wanted agent capabilities faced an uncomfortable choice: adopt Python frameworks like LangChain or CrewAI and maintain a polyglot stack, or build their own orchestration on top of Spring AI or LangChain4j — useful primitives, but not full agent planners. That gap has now closed, and it closed quickly.

2. The New JVM Agent Landscape

Two frameworks arrived within months of each other in 2025, and both came from credible, well-resourced teams. Embabel, launched by Rod Johnson in May 2025, built on Spring Boot and written in Kotlin with first-class Java interoperability. And Koog, open-sourced by JetBrains at KotlinConf 2025, built entirely on Kotlin coroutines with a graph-based strategy model that targets not just the JVM, but also Android, iOS, and WebAssembly via Kotlin Multiplatform.

By contrast, the earlier generation of JVM AI tooling — Spring AI and LangChain4j — deliberately sits lower in the stack. As the Java Code Geeks 2026 trends report summarises it: “Spring AI is the pragmatic entry point. Embabel and Koog are for teams building serious multi-step agent workflows on the JVM.” Think of the relationship the same way you think of servlets versus Spring MVC — the lower layer is still there, but most developers should not be coding directly against it.

The stack, visualisedLLM API → Spring AI / LangChain4j (primitives) →Embabel / Koog(agent orchestration) → your business application. The middle layer is where planning, tool registration, and multi-step execution actually live.

JVM AI Framework GitHub Stars — Comparative Growth (2025)

Approximate star counts at key milestones, based on public repository data and reported figures from InfoQ and The New Stack.

3. Embabel in Depth: GOAP Meets Spring

Embabel is, in essence, Rod Johnson’s answer to a question he believes the Python ecosystem has not answered well: how do you bring engineering discipline to agentic AI? The framework’s most distinctive idea is that it separates planning from execution. Rather than asking an LLM to decide what to do next, Embabel delegates that decision to a deterministic AI algorithm borrowed from video game development called Goal-Oriented Action Planning (GOAP).

In a game engine, GOAP lets an NPC character work out a sequence of actions — pick up weapon, find cover, flank the enemy — given a set of preconditions and a desired goal state. Embabel applies exactly this algorithm to enterprise workflows. The developer defines actions (what the agent can do), conditions (what must be true before or after an action), and goals (the desired end state). The GOAP planner then computes an optimal path through those actions at runtime — and replans after every step, forming what Johnson calls an OODA loop (Observe, Orient, Decide, Act).

Furthermore, because the planner is a non-LLM algorithm, the decisions it makes are fully explainable. You can log exactly why the planner chose action B over action A, which is critical for any regulated or audited business process.

Key Embabel Concepts at a Glance

Concept	What it does	Familiar Spring analogy
@AgentComponent	Marks a class as an agent that the platform can discover	@Service / @Component
@Action	Declares a method as a step the planner can use	@RequestMapping (a route the framework can invoke)
Goal	Desired end state; the planner works backward from here	Return type of a controller endpoint
Condition	A typed boolean checked before/after each action	@PreAuthorize / guard clause
Blackboard	Shared typed state that all actions read and write	The model object passed through a request pipeline
AgentPlatform	Bootstraps and executes agent flows (Focused / Closed / Open)	DispatcherServlet

Beyond GOAP, Embabel’s 2025 year-end update added a Utility planner (for open-ended exploration without a fixed goal) and a Supervisor pattern that maps directly to the LangGraph supervisor-with-workers model — giving teams migrating from Python a familiar mental model while gaining type safety and testability that Python frameworks simply cannot match at the JVM level.

For a practical starting point, the Baeldung Embabel tutorial walks through building a quiz-generation agent, and the Dan Vega first-look guide covers tool registration and MCP server integration in detail. Both are solid starting points before you touch the official GitHub repository.

4. Koog in Depth: Coroutines Meet Agent Graphs

JetBrains took a different architectural path. Where Embabel delegates planning to a deterministic algorithm, Koog asks developers to define the agent’s strategy as an explicit directed graph of nodes. Each node performs one operation — calling an LLM, invoking a tool, summarising message history, routing to a subgraph — and edges between nodes define flow control including loops, branches, fallbacks, and parallel paths.

This node-edge model will feel immediately familiar to anyone who has worked with LangGraph. However, Koog’s implementation is considerably more idiomatic for JVM developers because it is built entirely on Kotlin coroutines, which means concurrency, streaming responses, and parallel tool calls all compose naturally without callback hell or thread management. Additionally, Koog ships with built-in history compression — an important practical detail when running long agentic sessions where raw message history would otherwise exhaust the model’s context window.

Arguably, Koog’s biggest differentiator is its multiplatform reach. Because it is built on Kotlin Multiplatform, the same agent logic can run on the JVM backend, on Android, on iOS, and even in the browser via WebAssembly — a capability no other JVM agent framework currently offers.

What Koog Ships Out of the Box

Feature	Details	Version introduced
Graph-based strategies	Nodes + edges with loops, branches, parallel paths	0.1.0 (initial)
Non-graph strategy API	Define strategies as Kotlin extension functions without explicit wiring	0.5.0
MCP integration	Native Model Context Protocol support via Kotlin MCP SDK	0.1.0
A2A protocol	Agent-to-Agent communication; agents discover and call each other	0.5.0 (Oct 2025)
Persistence & checkpointing	Snapshot agent state; resume exactly where execution paused	0.4.0
History compression	Intelligent summarisation to manage context window usage	0.1.0
OpenTelemetry observability	Built-in exporters for Langfuse and W&B Weave	0.3.0
AIAgentService	Manage multiple uniform running agents as state-managed services	0.5.0

The JetBrains team has also made it a point to publish a multi-part blog series building a real coding agent step by step — arguably the most readable practical onboarding content for any JVM agent framework available today. Koog’s documentation lives at docs.koog.ai.

5. Side-by-Side Comparison

Both frameworks solve the same high-level problem, but they optimise for different teams and different kinds of agents. Rather than declaring a winner, the table below lays out the architectural tradeoffs as clearly as possible so that you can make the choice that fits your stack.

Dimension	Embabel	Koog
Planning model	GOAP (deterministic, non-LLM)	Explicit graph / coroutines
Primary language	Kotlin + excellent Java interop	Kotlin (Java API available)
Spring integration	Deep — built on Spring Boot	Available (Spring Boot + Ktor adapters)
Multiplatform	JVM only	JVM, Android, iOS, JS, WASM
History / memory	Domain blackboard; conversation memory is app-level concern	Built-in history compression + RAG support
Observability	Spring Actuator; logging; prompt testing library	OpenTelemetry, Langfuse, W&B Weave out of the box
Fault tolerance	Replanning after each action (OODA loop)	Checkpointing, rollback tool side-effects, retries
License	Apache 2.0	Apache 2.0
Planner explainability	High — non-LLM algorithm, fully loggable	Medium — graph is explicit but LLM drives node decisions
Best fit for	Spring teams with complex domain models	Kotlin-first teams; multiplatform or mobile deployment

As Rod Johnson himself noted in the GitHub discussion comparing the two: “For Java developers, especially those using Spring, the choice is obviously Embabel. For Kotlin developers it probably comes down to whether Koog’s explicit node-edge wiring is what they’re looking for.”

6. Goal-Oriented Planning in Practice

Let us make goal-oriented planning concrete with a realistic scenario: an order-processing agent that needs to validate a customer order, check inventory, apply pricing rules, and then dispatch a fulfilment event. Without a framework, you would write this as a waterfall of chained LLM calls or hand-coded state machines. With Embabel, you instead declare the pieces and let the planner sequence them.

Here is a simplified view of how Embabel’s annotations map to the planner’s vocabulary. Notice that the code is idiomatic Java — no XML, no special runner, just annotated methods that Spring and Embabel pick up automatically:

Java · Embabel — Order Processing Agent (simplified)

import com.embabel.agent.api.annotation.*;
import com.embabel.agent.api.common.OperationContext;

@AgentComponent
public class OrderProcessingAgent {

    // Action 1 — validate the incoming order
    // Precondition: an unvalidated order exists on the blackboard
    // Effect: a ValidatedOrder object is placed on the blackboard
    @Action(
        pre  = "order.status == 'PENDING'",
        post = "validatedOrder != null"
    )
    public ValidatedOrder validateOrder(Order order, OperationContext ctx) {
        // The LLM prompt is focused: just validation rules, nothing else
        return ctx.promptForObject(
            "Validate this order for completeness and fraud signals: " + order,
            ValidatedOrder.class
        );
    }

    // Action 2 — check inventory (pure Java, no LLM involved)
    @Action(
        pre  = "validatedOrder != null",
        post = "inventoryResult != null"
    )
    public InventoryResult checkInventory(ValidatedOrder validatedOrder,
                                          InventoryService inventory) {
        return inventory.check(validatedOrder.items());
    }

    // Goal — what the planner is trying to reach
    @AchievesGoal
    @Action(
        pre = "inventoryResult.allInStock == true"
    )
    public FulfilmentEvent dispatch(ValidatedOrder order,
                                    InventoryResult inv) {
        return new FulfilmentEvent(order, inv.reservationId());
    }
}

There are several things worth noticing here. First, each action has a narrow, focused responsibility. The LLM in validateOrder is only asked about fraud and completeness — not inventory, not pricing. That focus makes the prompt far more reliable than one giant prompt trying to do everything at once. Second, checkInventory involves no LLM at all — it is plain Java calling a service. Embabel happily mixes LLM-powered and code-driven actions in the same plan. Third, you never write the sequence yourself; the GOAP planner infers it from the preconditions and postconditions at runtime.

Embabel’s planner evaluates preconditions as typed expressions against the blackboard. Keep them to data-presence checks (validatedOrder != null) rather than complex business rules. Move logic into the action methods themselves, where it is testable and debuggable.

The equivalent in Koog takes a graph-first approach. Instead of declaring preconditions, you wire nodes together explicitly. Here is a minimal Koog strategy for the same flow:

Kotlin · Koog — Order Processing Strategy (simplified)

import ai.koog.agents.core.agent.AIAgent
import ai.koog.agents.core.agent.config.AIAgentConfig
import ai.koog.agents.core.tools.ToolRegistry
import ai.koog.prompt.executor.clients.openai.OpenAIModels
import ai.koog.prompt.executor.llms.all.simpleOpenAIExecutor

// Step 1 — define tools as annotated functions
val toolRegistry = ToolRegistry {
    tool(::validateOrderTool)   // wraps your validation logic
    tool(::checkInventoryTool)  // wraps InventoryService.check()
    tool(::dispatchOrderTool)   // wraps FulfilmentEvent creation
}

// Step 2 — configure the agent
val config = AIAgentConfig(
    prompt = ai.koog.agents.core.agent.config.PromptConfig(
        systemPrompt = """
            You are an order processing agent. 
            Use the available tools in sequence to validate, check 
            inventory, and dispatch orders. Stop when dispatched.
        """.trimIndent()
    )
)

// Step 3 — create and run the agent
val agent = AIAgent(
    promptExecutor = simpleOpenAIExecutor(System.getenv("OPENAI_API_KEY")),
    llmModel       = OpenAIModels.Chat.GPT4o,
    toolRegistry   = toolRegistry,
    config         = config
)

// Step 4 — run with a specific order input
val result = agent.run("Process order: ${order.toJson()}")
println(result)

In Koog, the LLM itself decides which tool to call and in what order, guided by the system prompt and the tool descriptions. The graph-based strategy API adds more explicit control when you need branches or loops. This is a meaningful philosophical difference: Embabel’s planner is deterministic by design, while Koog’s default single-agent pattern trusts the model to sequence tools correctly — which is faster to prototype but harder to audit in regulated contexts.

7. Tool Registration and Multi-Step Execution

Tool registration is where both frameworks shine brightest, and where the contrast with raw prompt engineering is most visible. Instead of describing a capability in natural language and hoping the model extracts the right parameters, you register a typed function that the framework exposes to the model in a structured way. The model receives a JSON schema describing the tool’s inputs and outputs; it calls the tool by name with typed arguments; the framework validates the call, executes the function, and returns the result — all without you writing any serialisation code.

1. Define your tool as a typed function

In Embabel, any Spring bean method annotated with @Tool is automatically registered. In Koog, you pass a function reference to ToolRegistry. Both frameworks generate the JSON schema from the method signature using reflection — no manual schema writing required.

2. The planner or agent selects the tool

Embabel’s GOAP planner picks tools based on which action’s preconditions are currently satisfied. Koog’s LLM-driven agent selects tools by reasoning over the tool descriptions in the system prompt — the same pattern used by OpenAI’s function-calling API.

3. The framework validates and executes

Both frameworks deserialise the model’s tool-call arguments into your typed objects before execution. If the model provides malformed arguments, the framework catches that before your code ever sees it — a safety net that raw prompt-parsing utterly lacks.

4. Results flow back into the next step

In Embabel, the return value of an @Action is placed on the typed blackboard, making it available to subsequent actions. In Koog, it is appended to the message history as a tool result, and the agent reasons over it in the next iteration of its execution loop.

5. MCP servers extend your tool catalogue

Both frameworks support the Model Context Protocol. This means any MCP-compatible server — databases, APIs, file systems — can be connected as a tool source without writing custom integration code.

A common misconception is that MCP alone is enough to build agents. As Johnson has argued, MCP solves tool discoverability and invocation — but it does not solve planning, sequencing, error recovery, or explainability. That is precisely what Embabel and Koog add on top.

8. Adoption in Numbers

Both frameworks are young, but the signals from the developer community are already clear. Embabel crossed 3,000 GitHub stars within its first year, a trajectory that mirrors early Spring adoption in enterprise Java circles. Meanwhile, the JetBrains team reports that Koog is already used internally to power the AI stack behind Junie (their AI coding agent) and AI Assistant in IntelliJ IDEA — giving it an unusually large and demanding real-world workload for an open-source framework less than a year old.

Perceived Production-Readiness: JVM AI Frameworks (Developer Survey Proxy)

Composite score (0–10) based on InfoQ Java Trends 2025, The New Stack developer interviews, and GitHub issue/PR activity as of early 2026. Higher = more production-ready.

Interestingly, Deutsche Telekom has already built one of Europe’s largest LLM-powered customer-service chatbots on the Kotlin/JVM stack — an early signal that enterprise teams are not waiting for full framework maturity before shipping. As JetBrains’ tech lead Vadim Briliantov noted in an interview with The New Stack: “For many enterprises, Python is not considered a production-ready language, even though most modern AI tools are built on it.” That sentiment is increasingly shaping procurement decisions at the platform level.

9. Which Framework Should You Choose?

The honest answer is that neither framework is universally superior. They optimise for different team profiles and different agent architectures, so the right choice comes down to a few concrete questions.

Choose Embabel if…

Your team is deep in the Spring ecosystem and wants to add agent capabilities to existing Spring applications with minimum friction. Your domain is complex with rich typed objects that the planner can reason about. You need high explainability — regulatory, compliance, or audit requirements mean you must be able to trace every planning decision. You are not targeting mobile or browser runtimes.

Choose Koog if…

Your team is Kotlin-first and values coroutines as a native concurrency model. You need multiplatform deployment — backend and Android, or backend and browser via WASM. You want built-in history compression and out-of-the-box OpenTelemetry integration without writing adapters. You prefer the explicit control of graph-based wiring over automatic GOAP planning.

As the JCG deep-dive analysis from March 2026 concludes: “Spring-deep teams adding intelligence to existing services will likely reach for Embabel first; Kotlin-first teams building new agents or targeting mobile will likely reach for Koog.” That framing holds up well in practice.

In either case, before you start a new project, it is worth checking the Embabel releases page and the Koog releases page for the latest versions — both frameworks have been shipping patch releases weekly throughout early 2026, and APIs are still evolving.

10. What We Have Learned

This article has covered a lot of ground, so let us bring it together in one place before you move on.

Prompt engineering alone cannot deliver the reliability, testability, or explainability that enterprise Java applications require from AI workflows. Agent frameworks are not optional once complexity grows.
Embabel, from Spring creator Rod Johnson, introduces Goal-Oriented Action Planning — a deterministic, non-LLM algorithm that plans sequences of typed actions toward a declared goal. It is built on Spring Boot, offers excellent Java interoperability, and is the natural choice for Spring-heavy teams.
Koog, from JetBrains, takes a graph-based, coroutine-native approach that gives Kotlin developers explicit wiring control, built-in history compression, and Kotlin Multiplatform reach across backend, Android, iOS, and browser targets.
Both frameworks sit above Spring AI and LangChain4j in the stack, adding the planning and orchestration layer those lower-level libraries intentionally omit.
Tool registration in both frameworks is typed, schema-driven, and MCP-compatible — a significant step beyond raw function-calling or prompt-described capabilities.
The choice between them is primarily a team profile decision: Spring-first teams naturally gravitate to Embabel; Kotlin-first or multiplatform teams naturally gravitate to Koog. Neither is wrong.

Tags

Flex and Justify Items in Tailwind CSS

Yatin Batra — Wed, 29 Apr 2026 20:23:45 +0000

CSS

Flex and Justify Items in Tailwind CSS

Modern web layouts require flexibility, responsiveness, and simplicity, all of which can be achieved efficiently with Flexbox. When combined with Tailwind CSS, building such layouts becomes faster and more intuitive. Let us delve into understanding how to use flex in Tailwind CSS and justify flex items.

1. Flexbox Fundamentals with Tailwind CSS

Flexbox (Flexible Box Layout) is a modern CSS layout model designed to arrange elements efficiently within a container, even when their size is unknown or dynamic. It simplifies complex layouts by providing a flexible way to align, distribute, and reorder items. Unlike older layout techniques such as floats or inline-block, Flexbox gives you precise control over both the direction and alignment of elements, making it ideal for building responsive user interfaces.

One-dimensional layout system (row or column)
Handles dynamic sizing (grow, shrink, basis)
Controls spacing, alignment, and distribution
Supports vertical and horizontal centering easily
Responsive by design without complex media queries

Flexbox works with two main components:

Flex Container: The parent element that enables flex behavior using display: flex
Flex Items: The child elements inside the container that follow flex rules

Once a container is defined as flex, its children automatically become flexible items that can be aligned and distributed using various properties.

1.1 Simplifying Flexbox with Tailwind CSS

Tailwind CSS follows a utility-first approach, meaning you apply small, single-purpose classes directly in your HTML instead of writing custom CSS. This makes working with Flexbox significantly faster and more consistent. Each Tailwind class maps directly to a Flexbox property. For example:

flex → display: flex;
flex-col → flex-direction: column;
justify-center → justify-content: center;
items-center → align-items: center;

This eliminates the need to remember complex CSS syntax and reduces context switching between HTML and CSS files. Another major advantage is responsiveness. Tailwind allows you to apply Flexbox utilities conditionally using breakpoints: <div class="flex flex-col md:flex-row">. In this example, on small screens the items are stacked vertically, while on medium and larger screens the items are arranged horizontally.

1.2 Getting Started with Flex in Tailwind

To start using Flexbox in Tailwind, you simply add the flex class to a container element.

<div class="flex">
  <div>Item 1</div>
  <div>Item 2</div>
  <div>Item 3</div>
</div>

By default, the flex direction is set to row (horizontal), items are aligned at the start, and each item takes only the space it needs. You can further control the layout using additional utility classes such as flex-row or flex-col to set the direction, flex-wrap to allow items to wrap onto the next line, and gap-4 to add consistent spacing between items.

In summary, Tailwind CSS removes the complexity of Flexbox by giving you intuitive, reusable classes that make layout building faster, cleaner, and highly maintainable.

2. Practical Flexbox Implementation

Now that we have understood the core concepts of Flexbox and how Tailwind CSS simplifies its usage, let us look at a practical implementation. The following example demonstrates different Flexbox utilities in action to help you build responsive layouts efficiently.

<!DOCTYPE html>
<html lang="en">
   <head>
      <meta charset="UTF-8" />
      <meta name="viewport" content="width=device-width, initial-scale=1.0" />
      <title>Tailwind Flexbox Examples</title>
      <script src="https://cdn.tailwindcss.com"></script>
   </head>
   <body class="p-6 bg-gray-100">
      <div class="flex flex-col gap-6">
         <!-- Flex Direction Example -->
         <div class="flex flex-row gap-2 bg-gray-200 p-4">
            <div class="bg-blue-500 text-white p-4">Row 1</div>
            <div class="bg-blue-500 text-white p-4">Row 2</div>
         </div>

         <div class="flex flex-col gap-2 bg-gray-200 p-4">
            <div class="bg-green-500 text-white p-4">Column 1</div>
            <div class="bg-green-500 text-white p-4">Column 2</div>
         </div>

         <!-- Justify & Align Example -->
         <div class="flex justify-between items-center bg-gray-300 p-4 h-24">
            <div class="bg-red-500 text-white p-4">Left</div>
            <div class="bg-red-500 text-white p-4">Right</div>
         </div>

         <!-- Flex Sizing Example -->
         <div class="flex gap-2 bg-gray-200 p-4">
            <div class="basis-1/4 grow bg-purple-500 text-white p-4">Grow</div>
            <div class="basis-1/4 shrink bg-purple-700 text-white p-4">
               Shrink
            </div>
            <div class="basis-1/2 bg-purple-900 text-white p-4">Fixed</div>
         </div>

         <!-- Wrap Example -->

         <div class="flex flex-wrap gap-2 bg-gray-200 p-4">
            <div class="bg-indigo-500 text-white p-4 w-32">Item 1</div>
            <div class="bg-indigo-500 text-white p-4 w-32">Item 2</div>
            <div class="bg-indigo-500 text-white p-4 w-32">Item 3</div>
            <div class="bg-indigo-500 text-white p-4 w-32">Item 4</div>
            <div class="bg-indigo-500 text-white p-4 w-32">Item 5</div>
            <div class="bg-indigo-500 text-white p-4 w-32">Item 6</div>
            <div class="bg-indigo-500 text-white p-4 w-32">Item 7</div>
            <div class="bg-indigo-500 text-white p-4 w-32">Item 8</div>
            <div class="bg-indigo-500 text-white p-4 w-32">Item 9</div>
            <div class="bg-indigo-500 text-white p-4 w-32">Item 10</div>
         </div>

         <!-- Centering Example -->
         <div class="flex justify-center items-center bg-gray-300 p-4 h-24">
            <div class="bg-yellow-500 text-black p-4">Centered</div>
         </div>
      </div>
   </body>
</html>

2.1 Code Explanation

This example demonstrates how to use Tailwind CSS Flexbox utilities to create different layouts: the parent container uses flex flex-col gap-6 to stack sections vertically with spacing, the first section shows horizontal (flex-row) and vertical (flex-col) directions, the next demonstrates alignment using justify-between (space between items) and items-center (vertical centering), the sizing example uses basis, grow, and shrink to control how items resize within the container, the wrap example uses flex-wrap to move items onto the next line when space is limited, and finally the centering example combines justify-center and items-center to perfectly center content both horizontally and vertically.

2.2 Code Output

The above code renders a structured layout showcasing multiple Flexbox behaviors in action. You will first notice two sections demonstrating layout direction, where items are displayed horizontally in a row and vertically in a column, helping visualize how flex-row and flex-col impact flow. The next section highlights spacing and alignment, where elements are pushed to opposite ends using justify-between while remaining vertically centered with items-center. In the sizing example, items dynamically adjust their width based on basis, grow, and shrink, clearly showing how space is distributed among flexible elements. The wrap example demonstrates how Flexbox handles overflow by allowing items to move onto the next line when horizontal space is insufficient. This behavior is controlled using flex-wrap, ensuring that items do not shrink excessively or break the layout—instead they wrap cleanly into multiple rows, maintaining readability and structure across screen sizes. Finally, the centering example visually confirms how content can be perfectly aligned both horizontally and vertically using a combination of Flexbox utilities.

Fig. 1: Code Output

3. Conclusion

Flexbox is a powerful layout system, and Tailwind CSS makes it significantly easier to use through utility classes. By combining direction control, alignment utilities, and sizing options like basis, grow, and shrink, developers can build highly responsive and flexible layouts with minimal effort.

Tags

Real-Time Updates with MQTT and Express.js

Yatin Batra — Wed, 29 Apr 2026 20:19:58 +0000

Node.js

Real-Time Updates with MQTT and Express.js

Real-time systems are critical for modern applications such as live dashboards, chat apps, IoT systems, and monitoring platforms. Traditional HTTP-based systems rely on request-response cycles, which are inefficient for continuous updates. This is where MQTT (Message Queuing Telemetry Transport) combined with Express.js provides a lightweight and scalable solution for building real-time update systems. Let us delve into understanding how to build real-time update systems with Mosquitto and Express.js

1. Introduction to MQTT

1.1 What is MQTT?

MQTT (Message Queuing Telemetry Transport) is a lightweight, publish-subscribe messaging protocol designed for constrained devices and unreliable networks. It runs over TCP/IP and is optimized for scenarios where bandwidth, battery, and network reliability are limited. Originally created for oil pipeline monitoring, MQTT has become a standard protocol for IoT systems, real-time dashboards, event-driven architectures, and messaging between distributed services.

1.2 Why Use MQTT?

Lightweight protocol: Minimal packet overhead compared to HTTP
Efficient bandwidth usage: Ideal for mobile, IoT, and edge devices
Real-time communication: Low-latency message delivery over persistent TCP connections
Decoupled architecture: Producers and consumers do not need to know each other
Bi-directional communication: Supports both upstream and downstream data flow
Scalable: Handles thousands to millions of clients with proper broker setup
Reliable delivery: Supports multiple Quality of Service (QoS) levels

1.2.1 MQTT Quality of Service (QoS)

MQTT provides three levels of delivery guarantees:

QoS 0 (At most once): Message is delivered once with no guarantee
QoS 1 (At least once): Message is guaranteed but may be duplicated
QoS 2 (Exactly once): Message is delivered exactly once with higher overhead

1.2.2 MQTT Retained Messages & Last Will

Retained Messages: Broker stores the last message on a topic and sends it to new subscribers immediately
Last Will and Testament (LWT): Broker publishes a predefined message if a client disconnects unexpectedly

1.3 MQTT Architecture

MQTT follows a Publish-Subscribe Model where communication is mediated by a broker instead of direct client-to-client interaction.

Broker: Central server responsible for receiving, filtering, and distributing messages
Publisher: Sends messages to a topic without knowing who will receive them
Subscriber: Subscribes to one or more topics to receive messages
Topic: Hierarchical string (e.g., flights/delhi/arrivals) used to organize messages

1.3.1 MQTT vs HTTP vs WebSockets

HTTP: Request-response model, not suitable for continuous updates
WebSockets: Full-duplex but requires more complex connection handling
MQTT: Lightweight, event-driven, and optimized for pub-sub communication

MQTT is particularly effective when systems require decoupled communication and efficient message distribution across multiple consumers. Think of MQTT as an event bus where producers emit events and consumers react to them asynchronously.

1.4 Setting Up an MQTT Broker

We can use Mosquitto, a popular open-source MQTT broker, for local development and testing.

# Install Mosquitto (Ubuntu/Debian)
sudo apt update
sudo apt install mosquitto mosquitto-clients

# Start the broker
sudo systemctl start mosquitto

# Enable auto-start on boot
sudo systemctl enable mosquitto

# Check broker logs
mosquitto -v

# Open Terminal 1 - Subscribe
mosquitto_sub -h localhost -t test/topic

# Open Terminal 2 - Publish
mosquitto_pub -h localhost -t test/topic -m "Hello MQTT"

The above commands demonstrate how to set up and test a local MQTT broker using Mosquitto on a Debian/Ubuntu system. First, the system packages are updated and Mosquitto along with its client utilities are installed. The broker is then started as a background service and enabled to automatically launch on system boot, ensuring availability without manual intervention. The mosquitto -v command runs the broker in verbose mode, allowing you to monitor logs and debug message flow. To validate the setup, one terminal acts as a subscriber using mosquitto_sub, listening to messages on a specific topic (test/topic), while another terminal acts as a publisher using mosquitto_pub, sending a test message (“Hello MQTT”) to the same topic. This verifies the core publish-subscribe mechanism, where the broker successfully routes messages from publishers to all active subscribers.

2. Complete Real-Time System with MQTT + Express.js + SSE

2.1 Server (Express + MQTT + SSE)

The following server implementation acts as the core of the system, connecting MQTT with Express and enabling real-time streaming using SSE. It handles message publishing, subscription, and broadcasting to connected clients.

// server.js
const express = require('express');
const mqtt = require('mqtt');
const bodyParser = require('body-parser');
const cors = require('cors');

const app = express();
app.use(cors());
app.use(bodyParser.json());

/* ================= MQTT SETUP ================= */
const client = mqtt.connect('mqtt://localhost:1883');

client.on('connect', () => {
  console.log('Connected to MQTT Broker');
  client.subscribe('matches/#'); // subscribe all match updates
});

/* ================= SSE CLIENTS ================= */
let clients = [];

app.get('/events', (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream');
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Connection', 'keep-alive');

  const clientId = Date.now();
  const newClient = { id: clientId, res };

  clients.push(newClient);

  req.on('close', () => {
    clients = clients.filter(c => c.id !== clientId);
  });
});

/* Broadcast to all SSE clients */
function broadcast(data) {
  clients.forEach(c => {
    c.res.write(`data: ${JSON.stringify(data)}\n\n`);
  });
}

/* MQTT → SSE bridge */
client.on('message', (topic, message) => {
  const payload = message.toString();
  console.log('MQTT:', topic, payload);

  broadcast({ topic, payload });
});

/* ================= MATCH ROUTES ================= */

// Create/Update match
app.post('/match', (req, res) => {
  const { matchId, score } = req.body;

  const topic = `matches/${matchId}`;
  client.publish(topic, JSON.stringify(score));

  res.json({ status: 'Match updated' });
});

// Get match (mock)
app.get('/match/:id', (req, res) => {
  res.json({ matchId: req.params.id, score: "Live data available via SSE" });
});

/* ================= STATIC FILES ================= */
app.use(express.static('public'));

app.listen(3000, () => console.log('Server running on 3000'));

2.1.1 Code Explanation

This Node.js server uses Express to create a real-time system by bridging MQTT messaging with browser clients via Server-Sent Events (SSE). It begins by importing required modules such as Express for HTTP handling, MQTT for broker communication, body-parser for parsing JSON requests, and CORS to allow cross-origin access. The MQTT client connects to a local broker and subscribes to all topics under matches/#, enabling it to receive updates for any match. For real-time streaming, the /events endpoint establishes an SSE connection by setting appropriate headers and storing each connected client’s response object in an in-memory array; when a client disconnects, it is removed to prevent memory leaks. A broadcast function iterates over all connected clients and pushes updates using the SSE protocol format. Whenever a message is received from MQTT, the server converts it to a string, logs it, and forwards it to all connected browsers via this broadcast mechanism—effectively acting as a bridge between MQTT and frontend clients. The /match POST route allows updating or creating a match by publishing the score to a topic like matches/{matchId}, which in turn triggers real-time updates to all subscribers, while a GET route returns a placeholder response, as real-time data is streamed via SSE. Finally, static files are served from a public directory, and the server listens on port 3000, making it a complete end-to-end system for publishing, consuming, and streaming live match data.

2.2 Admin Upload Interface

The admin interface allows users to push match updates into the system. It sends data to the backend API, which then publishes it to MQTT for real-time distribution.

<!-- public/admin.html -->
<!DOCTYPE html>
<html>
<body>
<h2>Admin Panel</h2>

<input id="matchId" placeholder="Match ID"/>
<input id="score" placeholder="Score"/>
<button onclick="send()">Update</button>

<script>
async function send() {
  const matchId = document.getElementById('matchId').value;
  const score = document.getElementById('score').value;

  await fetch('/match', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ matchId, score })
  });

  alert('Updated');
}
</script>
</body>
</html>

2.2.1 Code Explanation

This HTML file represents a simple admin interface that allows users to send live match updates to the backend server. It consists of two input fields for entering the match ID and the score, along with a button that triggers the send() JavaScript function when clicked. Inside this function, the values entered by the user are retrieved using document.getElementById, and an asynchronous HTTP POST request is made to the /match endpoint using the Fetch API. The request includes a JSON payload containing the match ID and score, with the appropriate Content-Type header set to application/json. Once the request is successfully sent, an alert notifies the user that the update has been processed. This action ultimately publishes the data to the MQTT broker via the backend, triggering real-time updates to all connected clients through the SSE stream.

2.3 Live Viewer Interface (SSE)

The viewer interface listens for real-time updates from the server using Server-Sent Events. It continuously receives and renders match updates without requiring page refreshes.

<!-- public/viewer.html -->
<!DOCTYPE html>
<html>
<body>
<h2>Live Match Updates</h2>

<div id="output"></div>

<script>
const eventSource = new EventSource('/events');

eventSource.onmessage = function(event) {
  const data = JSON.parse(event.data);

  const div = document.getElementById('output');
  div.innerHTML += "<p>" + data.topic + " : " + data.payload + "</p>";
};
</script>
</body>
</html>

2.3.1 Code Explanation

This HTML file acts as a live viewer interface that listens for real-time match updates from the server using Server-Sent Events (SSE). It establishes a persistent connection to the backend by creating a new EventSource instance pointing to the /events endpoint, which continuously streams updates without requiring repeated requests. Whenever the server pushes a new message, the onmessage handler is triggered, where the incoming event data is parsed from JSON format to extract the topic and payload sent via MQTT. The script then dynamically updates the DOM by selecting the output div and appending a new paragraph element containing the topic (e.g., match identifier) and its corresponding payload (e.g., score). This enables users to see live match updates instantly in the browser as they are published, without needing to refresh the page, effectively demonstrating a seamless real-time data flow from MQTT through the server to the frontend.

2.4 Home Page

The home page acts as a simple navigation layer, allowing users to access both the admin panel and the live viewer interface from a single entry point.

<!-- public/index.html -->
<!DOCTYPE html>
<html>
<body>
<h1>Real-Time Match System</h1>

<ul>
  <li><a href="/admin.html">Admin Panel</a></li>
  <li><a href="/viewer.html">Live Viewer</a></li>
</ul>

</body>
</html>

2.4.1 Code Explanation

This HTML file serves as the entry point or homepage of the real-time match system, providing simple navigation to the core functionalities of the application. It displays a title indicating the purpose of the system and includes an unordered list with two links: one directing users to the admin panel (/admin.html) where match data can be created or updated, and the other leading to the live viewer (/viewer.html) where real-time updates can be observed. By leveraging Express static file serving on the backend, these links directly load the corresponding HTML files from the public directory. Although minimal in structure, this page acts as a central hub that connects the user to both the data publishing interface and the real-time consumption interface, completing the overall flow of the system.

2.5 Code Output

When the complete system is run, it demonstrates a full real-time data flow from the admin interface to the viewer interface through MQTT and SSE. After starting the Node.js server and MQTT broker, opening the homepage (index.html) provides navigation to both the Admin Panel and Live Viewer. In the Admin Panel, entering a match ID and score and clicking “Update” sends a POST request to the backend, which publishes the data to the corresponding MQTT topic. The server, already subscribed to matches/#, receives this message and immediately broadcasts it to all connected SSE clients. On the Live Viewer page, the browser maintains an open connection to the server via EventSource, and as soon as the message is broadcast, it is received and rendered dynamically in the UI without any page refresh. This results in an instant update such as matches/123 : {"score":"120/3"} appearing on the screen. The system effectively showcases a seamless real-time pipeline where data flows from input to display with minimal latency, validating the integration of MQTT for messaging and SSE for frontend streaming.

3. Conclusion

Building real-time systems with MQTT and Express.js provides a powerful yet lightweight solution for modern applications. MQTT’s publish-subscribe model decouples systems and ensures efficient message delivery, while Express.js acts as a bridge between traditional HTTP APIs and real-time messaging. This architecture is especially useful in IoT, monitoring dashboards, notifications, and collaborative applications where instant updates are critical. By combining MQTT’s efficiency with Node.js flexibility, you can build scalable, real-time systems with minimal overhead.

Tags

Java 25 vs Java 21: The Upgrade Guide NobodyHas Written Yet

Eleftheria Drosopoulou — Wed, 29 Apr 2026 15:35:00 +0000

Core Java

Java 25 vs Java 21: The Upgrade Guide NobodyHas Written Yet

A practical, decision-driven comparison for enterprise teams on Java 21 — covering the three changes that actually matter for production.

Every four years or so, an enterprise Java team faces the same question: is it time to move to the next LTS? With Java 25 now available and Java 21’s free update window closing in September 2026, that question is becoming urgent for a lot of organisations. Fortunately, this is one of the most straightforward LTS transitions Java has ever asked you to make.

Between Java 21 and Java 25, there were four intermediate releases — JDK 22, 23, 24, and finally 25. Most teams skipped all of them entirely. So while individual features have been covered in isolation across many articles, there’s been no single guide that assembles the full picture from the perspective of a team currently running 21 in production. That’s exactly what this article is.

Rather than listing every JEP, we’ll focus on the changes that actually have a material effect on a running production system: concurrency behaviour, startup performance, and memory usage. Then we’ll walk through what a practical upgrade path actually looks like.

1. First: Understanding the Gap Between the Two Releases

Java 21 was released in September 2023 and quickly became the most widely adopted modern LTS. It delivered virtual threads as a stable feature, completed pattern matching, and brought records and sealed classes to production quality. For most teams, it represented Java finally feeling modern.

Java 25 arrived exactly two years later, in September 2025. Importantly, Oracle had already shifted to a two-year LTS cadence (down from three), which is why these two releases are closer together than Java 17 and Java 21 were. That shorter gap means less to absorb — but it also means more teams are still on 21 and asking whether they need to move.

Release	Date	LTS Until	Key themes
Java 21	Sept 2023	Sept 2031	Virtual threads, pattern matching, records/sealed stable
Java 22	Mar 2024	—	Unnamed variables, FFM API stable, stream gatherers
Java 23	Sept 2024	—	Markdown Javadoc, previews iterating
Java 24	Mar 2025	—	Virtual thread pinning fix, first Leyden AOT, 24 JEPs
Java 25	Sept 2025	Sept 2033	Compact headers, Leyden method profiling, Shenandoah generational

The practical implication: if you’re on Java 21 and upgrade directly to Java 25, you’re picking up all the JDK 22, 23, and 24 work in one shot. Crucially, that includes JEP 491 from JDK 24 — the virtual thread pinning fix — which many consider the most operationally significant improvement since virtual threads were introduced in the first place.

2. The Fix That Changes Everything: Virtual Thread Pinning

JEP 491 · JDK 24

When virtual threads landed in Java 21, they came with a well-known asterisk: blocking inside a synchronized block or method would “pin” the virtual thread to its carrier platform thread. Pinning meant the carrier couldn’t be reused for other virtual threads while it was waiting. In the worst case, all carrier threads could be pinned simultaneously, causing thread starvation or even deadlock.

The recommended workaround was to replace synchronized with ReentrantLock and similar constructs from java.util.concurrent.locks. Many popular frameworks — Spring, Hibernate, and others — scrambled to do exactly that ahead of Java 21’s release. However, that meant a lot of existing code still carried the risk.

“In JDK 21, when a virtual thread enters a synchronized block and blocks on I/O, the carrier platform thread is occupied the entire time. In JDK 24, the virtual thread unmounts from the carrier, which can then serve other virtual threads.”— Nicolai Parlog, Java Developer Advocate at Oracle, Inside Java Newscast #80

JEP 491, delivered in JDK 24, solves this at the JVM level. The monitor mechanism was updated to track virtual thread identity rather than platform thread identity, which means virtual threads can now unmount freely even while holding a monitor. The result is that synchronized is no longer a performance hazard for virtual thread applications.

2.1 What Does This Mean in Practice?

A real benchmark from Dan Vega’s pinning demo makes the difference viscerally clear. Running 5,000 virtual threads on a single-carrier-thread configuration with synchronized blocking:

That’s a 70x speedup from a JVM upgrade alone — no code changes involved. Of course, this is a synthetic benchmark designed to stress pinning specifically. But it illustrates what was at stake for any service that had synchronized I/O paths under high concurrency.

What still pins after JEP 491
Two scenarios still cause pinning in Java 25: (1) blocking insidenative codethat calls back into blocking Java, including class loaders; and (2) class initializer execution. These cases are rare in most web services, but if your application makes heavy use of JNI, it’s worth profiling. The old -Djdk.tracePinnedThreads flag is removed; use JFR’s jdk.VirtualThreadPinned event instead.

2.2 Diagnostics Changed Too

The -Djdk.tracePinnedThreads=full system property, which was the primary tool for detecting pinning in Java 21, is gone in JDK 24 and beyond. You now use JDK Flight Recorder to observe the jdk.VirtualThreadPinned event. The event itself has been enhanced to explain both why the thread was pinned and which carrier thread was involved — which is actually more useful than the old approach.

Check for remaining pinning with JFR

java -XX:StartFlightRecording=filename=recording.jfr,duration=60s -jar your-app.jar
jfr print --events jdk.VirtualThreadPinned recording.jfr

Virtual Thread Throughput: Java 21 vs Java 25

Relative performance on synchronized-heavy workloads. JEP 491 eliminates the pinning bottleneck. Data based on benchmark results from the OpenJDK community.

3. Startup Time: Project Leyden’s First Real Payoff

JEP 483 (JDK 24) · JEP 514 + JEP 515 (JDK 25)

Java’s startup time has been a long-standing pain point, especially in the microservices and serverless era where applications may restart dozens of times a day. GraalVM’s Native Image addresses this aggressively, but at the cost of full JVM dynamism. Project Leyden is the OpenJDK community’s answer: ahead-of-time optimisations that preserve the full JVM while meaningfully cutting startup time.

Between JDK 24 and JDK 25, Leyden delivered three JEPs that together form a complete, usable workflow:

JEP	JDK	What It Does	Impact
JEP 483	24	Ahead-of-Time Class Loading & Linking — stores fully loaded/linked classes in an AOT cache	~41% faster startup
JEP 514	25	AOT Command-Line Ergonomics — collapses the training workflow from 3 commands to 2	Usability improvement
JEP 515	25	Ahead-of-Time Method Profiling — stores hot method profiles in the cache, so JIT starts warm	15–25% faster warmup

Together, the practical effect is striking. In a real-world test by Gholamzadreza’s Spring Boot 3.3+ project, startup time dropped from 4.9 seconds to 2.4 seconds using the AOT cache — a 51% reduction with three commands and no application code changes. InfoQ’s coverage of JEP 483 cited Spring PetClinic starting 40–41% faster on early builds.

3.1 How It Works (Without the Jargon)

Every time your Java application starts, the JVM reads, parses, verifies, loads, and links every class your code touches. For a typical Spring Boot application, that’s 15,000 to 25,000 classes. It’s the same work, done again and again, every single cold start.

The AOT cache captures all of that work during a training run and stores it in a compact file. On subsequent starts, the JVM picks up those already-linked classes directly. JEP 515 then goes a step further: it also records which methods were hot during the training run, so the JIT compiler knows immediately what to prioritise. The result is that your application reaches peak performance faster — which is the “warmup” improvement.

3.2 The Workflow on Java 25

Step 1 — Training run (records + builds the cache)

java -XX:AOTCacheOutput=app.aot -jar your-application.jar

Step 2 — Every production run after that

java -XX:AOTCache=app.aot -jar your-application.jar

That’s the entire workflow. In JDK 24, it required three separate commands (record, assemble, run). JEP 514 in JDK 25 collapsed training and assembly into one step. And crucially, unlike GraalVM Native Image, you don’t give anything up: full reflection, dynamic class loading, and all JVM features remain available.

Training run best practice
The AOT cache is only as good as the training run. Make sure your training run exercises the production code paths — ideally by sending representative traffic after startup. Avoid using test frameworks in training, as they load extra classes that inflate the cache. Also remember to regenerate the cache whenever you deploy a new application version; a stale cache won’t cause failures, but it won’t capture new hot paths either.

Spring Boot Startup Time: Java 21 vs Java 25 with AOT Cache

Measured startup times for a representative Spring Boot 3.x application. “Java 25 + AOT” uses -XX:AOTCacheOutput and -XX:AOTCache flags with a trained cache.

4. Memory: Compact Object Headers Give You a Free Heap Reduction

JEP 519 · JDK 25

We covered JEP 519 in depth in a dedicated article, but it deserves a prominent place in any upgrade guide. The short version: Java 25 ships with the ability to reduce every object’s header size from 12 bytes to 8 bytes. That’s a 33% reduction per object header, and it compounds dramatically at scale.

Unlike the Leyden AOT features, compact headers require a single JVM flag — no training run needed. The savings are invisible to application code and require no changes whatsoever to your codebase.

Enable Compact Object Headers

java -XX:+UseCompactObjectHeaders -jar your-application.jar

Compact headers require Compressed Class Pointers, which are enabled by default on 64-bit systems with heaps under 32 GB. If your heap exceeds 32 GB, compact headers are not available. Additionally, ZGC is not supported alongside compact headers in JDK 25 — you’d need to use G1 or Parallel GC. A future JDK release is expected to remove this limitation.

5. Garbage Collection: Two Notable GC Upgrades

Beyond compact headers, Java 25 brings two GC improvements that enterprise teams should be aware of — particularly if they already use or are considering low-latency collectors.

5.1 Generational Shenandoah (JEP 521) — Now Production-Ready

Shenandoah was always known for its ultra-low pause times, but its single-generation design meant it had to scan the entire heap to find garbage — losing efficiency compared to generational collectors like G1. The generational mode, which separates memory into young and old generations, was experimental in JDK 24. In Java 25, it’s promoted to a fully supported product feature.

If you’re currently using non-generational Shenandoah in production, this is a meaningful upgrade in sustainable throughput and memory utilisation. You can enable it without experimental flags:

Enable Generational Shenandoah

java -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -jar your-application.jar

5.2 ZGC Simplification: Non-Generational Mode Removed

If you’re using ZGC, there’s an important change to be aware of: Java 25 removes the non-generational mode of ZGC entirely. That means -XX:+UseZGC now always means generational ZGC. For most teams this is transparent — generational ZGC has been the default and recommended mode since JDK 21 via JEP 439. However, if you were explicitly running non-generational ZGC for some reason, you’ll need to retest your GC behaviour after the upgrade.

6. Language & API: What Graduated to Final in Java 25

Runtime performance aside, Java 25 also finalises several language features that were in preview during Java 21. These are stable enough to use in production code without any flags. Here’s a concise summary of what moved from “preview” to “final”:

Feature	JEP	Status in Java 21	Status in Java 25
Scoped Values	JEP 506	Preview	Final
Unnamed Variables (`_`)	JEP 456	Preview	Final
Flexible Constructor Bodies	JEP 513	Not available	Final
Module Import Declarations	JEP 511	Not available	Final
Instance Main Methods	JEP 512	Not available	Final
Structured Concurrency	JEP 505	Preview	Preview (5th)
Key Derivation Function API	JEP 518	Not available	Final

The most immediately useful of these for most teams is Scoped Values (JEP 506). They’re a cleaner, more efficient replacement for ThreadLocal — particularly in virtual-thread-heavy applications where ThreadLocal has known memory and performance issues. With Scoped Values now final, you can confidently migrate away from ThreadLocal for contextual data sharing in high-concurrency paths.

7. Breaking Changes and Removal Risks

Fortunately, the Java 21-to-25 migration has very few genuine breaking changes. Java’s commitment to backward compatibility means that the overwhelming majority of Java 21 applications will compile and run on Java 25 without modification. Nevertheless, there are a handful of things worth checking:

Change	Risk Level	What to Do
32-bit x86 port removed	Low	Check build agents and deployment images for any 32-bit JDK assumptions
Non-generational ZGC removed	Medium	If explicitly using non-generational ZGC, retest GC behaviour post-upgrade
`-Djdk.tracePinnedThreads` removed	Low	Switch monitoring to `jfr print --events jdk.VirtualThreadPinned`
Security Manager fully removed	Medium	If still using `java.security.manager`, this path must be migrated before 25
Preview API signature changes	Medium	StructuredTaskScope constructors changed to factory methods across previews; update call sites
Native code / fixed header layout	Opt-in	Compact headers only apply if you enable `-XX:+UseCompactObjectHeaders`; no risk unless opted in

Security Manager: Act Now If You Haven’t
The Java Security Manager was deprecated in Java 17, deprecated-for-removal in Java 18, and its enforcement was disabled in Java 24. By Java 25, the supporting infrastructure is being stripped out. If your codebase or any of its dependencies still references System.setSecurityManager() or similar APIs, this needs to be addressed before upgrading. Run javac -Xlint:deprecation on your full build to surface any remaining references.

8. Support Timelines: Why “Later” Has a Deadline

One of the most concrete reasons to plan your upgrade now rather than later is the support window. Java 21 free updates from Oracle expire in September 2026. That’s roughly 18 months from today. Java 25 extends that window to September 2033 — giving you an extra two years of support runway.

LTS Support Windows: Java 21 vs Java 25

Oracle Premier Support timelines. “Free updates” under the No-Fee Terms end one year after the next LTS release. Java 21 free updates end September 2026.

Furthermore, tooling support for Java 25 is already strong. Spring Boot 3.5+ supports it, Gradle 9.1+ supports it, and Maven’s compiler plugin 3.14.1+ supports it. The ecosystem matured quickly precisely because Java 25 is an LTS release — the kind that frameworks actively target.

9. Should You Upgrade? A Decision Matrix

Rather than a one-size-fits-all recommendation, here’s a straightforward way to think about timing based on your organisation’s profile:

Upgrade Decision Matrix: Java 21 → Java 25

Team / Workload Profile	Verdict	Recommended Action & Reason
Heavy virtual thread usageLoom-based services, high-concurrency APIs	Upgrade now	Upgrade promptly.JEP 491 removes a latent scalability risk. The pinning issue may not be visible under normal load but can cause thread starvation or deadlocks under traffic spikes.
Containerised microservicesFrequent cold starts, Kubernetes, serverless	Upgrade now	Upgrade and enable Leyden AOT.The AOT cache (JEPs 483 + 515) can cut startup time by up to 51% with two commands. Directly lowers cloud compute costs and improves deployment velocity.
Heap-heavy workloadsSpring Boot, ORM-heavy apps, in-memory caches	Upgrade now	Upgrade and benchmark compact headers.A single JVM flag (`-XX:+UseCompactObjectHeaders`) saves 10–22% heap with zero code changes. Almost always worth taking.
Stable batch / data processingLong-running jobs, pipelines, ETL workloads	Plan for 2026	Plan upgrade before Java 21 free-update expiry (Sept 2026).Lower urgency day-to-day, but compact headers and fewer GC cycles still provide meaningful efficiency gains. Don’t wait until the last minute.
Legacy enterprise monolithSlow release cycle, large codebase, many dependencies	Start now	Begin the upgrade process immediately.The migration itself is low-risk, but lead time matters. Allow 6–12 months for thorough testing across dependency chains before cutting over to production.
Greenfield new service or rewriteNew project, clean slate	Start on 25	Start on Java 25 directly.No reason to begin on an older LTS. Java 25 has a longer support window (until 2033), better performance defaults, and a complete, stable feature set.

10. Your Practical Upgrade Checklist

Finally, here’s a step-by-step path that should work for most teams moving from Java 21 to Java 25 on a production system:

Update your build toolchain first. Upgrade to Gradle 9.1+ or Maven compiler plugin 3.14.1+. Update your Docker base images to a Java 25 distribution (Eclipse Temurin, Azul Zulu, Amazon Corretto all have builds).
Compile and run tests on JDK 25 with no flags. The vast majority of Java 21 codebases compile clean. Use javac -Xlint:deprecation to surface any deprecated API usage. Fix any Security Manager references.
Remove any synchronized → ReentrantLock workarounds you added for Java 21. With JEP 491 in place, you can now choose between synchronized and j.u.c.locks based on what best fits the problem — not based on pinning avoidance.
Enable compact object headers on a canary tier first. Add -XX:+UseCompactObjectHeaders, run representative load, and compare heap metrics, GC frequency, and latency against your Java 21 baseline. If you use ZGC, plan to test on G1 or Parallel GC instead.
Run a Leyden AOT training session. Execute the two-command workflow (-XX:AOTCacheOutput then -XX:AOTCache), measure startup time and time-to-first-request against your baseline, and add cache file generation to your CI/CD pipeline as a build artifact.
Check for residual pinning with JFR. Even after JEP 491, native-code paths can still pin. Run jfr print --events jdk.VirtualThreadPinned recording.jfr on a production load test to confirm your services are pin-free.
Roll out gradually. Deploy Java 25 with compact headers and the AOT cache to one service tier at a time. Monitor RSS, GC pause times, throughput, and error rates. Keep the old JVM flags documented so you can disable features selectively if needed.
Update CI/CD images and documentation. Update any CI container images, Kubernetes base images, and runbooks to reflect the new JVM flags. Document which flags are enabled in each environment.

11. What We’ve Learned

In this guide, we walked through the most important differences between Java 21 and Java 25 from the perspective of a team running in production. We started with the virtual thread pinning fix (JEP 491), delivered in JDK 24, which eliminates the biggest scalability limitation that shipped with virtual threads in Java 21 — allowing synchronized blocks to be used freely without the risk of carrier thread exhaustion. We then explored Project Leyden’s AOT cache (JEP 483 + 514 + 515), which can cut Spring Boot startup times by up to 51% and improve warmup performance by 15–25%, all with two commands and zero code changes.

Next, we covered Compact Object Headers (JEP 519), which shave 4 bytes off every object and translate into 10–22% less heap usage on object-heavy workloads, enabled by a single JVM flag. We also touched on GC improvements — Generational Shenandoah reaching production status and ZGC simplification — and reviewed which language features moved from preview to final, including Scoped Values and Module Import Declarations.

Finally, we covered the handful of genuine breaking changes (Security Manager removal, non-generational ZGC removal, diagnostic flag changes) and provided a practical eight-step upgrade checklist. The overall message: the Java 21→25 migration is low-risk and high-reward, and with Java 21 free updates expiring in September 2026, now is exactly the right time to start.

Tags

[FREE EBOOKS] Pragmatic Software Testing, Employee Experience Design & Four More Best Selling Titles

Java Code Geeks — Wed, 29 Apr 2026 10:30:30 +0000

Meta JCG

[FREE EBOOKS] Pragmatic Software Testing, Employee Experience Design & Four More Best Selling Titles

Hello fellow geeks,

Fresh offers await you on our Information Technology Research Library, please have a look!

	Pragmatic Software Testing: Becoming an Effective and Efficient Test Professional ($55.00 Value) FREE for a Limited Time A hands-on guide to testing techniques that deliver reliable software and systems. Testing even a simple system can quickly turn into a potentially infinite task. Faced with tight costs and schedules, testers need to have a toolkit of practical techniques combined with hands-on experience and the right strategies in order to complete a successful project. World-renowned testing expert Rex Black provides you with the proven methods and concepts that test professionals must know. He presents you with the fundamental techniques for testing and clearly shows you how to select and apply successful strategies to test a system with budget and time constraints. Black begins by discussing the goals and tactics of effective and efficient testing. Next, he lays the foundation of his technique for risk-based testing, explaining how to analyze, prioritize, and document risks to the quality of the system using both informal and formal techniques. He then clearly describes how to design, develop, and, ultimately, document various kinds of tests. Because this is a hands-on activity, Black includes realistic, life-sized exercises that illustrate all of the major test techniques with detailed solutions. Get it FREE!
	Employee Experience Design: How to Co-create Work Where People and Organizations Thrive ($28.00 Value) FREE for a Limited Time How to harness Employee Experience Design to attract and retain the best talent. In Employee Experience Design: How to Co-create Work Where People and Organizations Thrive,three highly experienced leaders explain how businesses can use Employee Experience Design to create workplaces that deliver better business results by first focusing on meaningful employee experiences. Many leading organizations worldwide have successfully implemented Employee Experience Design, but until now, there has been no comprehensive book that outlines exactly how to do it.Employee Experience Design delivers a proven, step-by-step method that leads to more engaged and productive employees, which in turn leads to superior organizational performance. With inspiring stories from leading brands like Airbnb, Patagonia, and many others, this book addresses challenges businesses face, such as: We all know that the world of work is continuously evolving and unpredictable. Many leaders are not sure how to make changes to address new, unexpected challenges. Employee Experience Design is a system leaders can use to meet those challenges. Employee Experience Design is much more than a rebrand of traditional HR practices. It’s a shift in mindset that HR and the organization can use to navigate highly competitive markets and ones with thin profit margins. Many organizations are drowning in policies and initiatives. Employee Experience Design is a way to reduce that burden while delivering better results both for employees and for the bottom line. Employee Experience Design is a timely and practical guide for business leaders, executives, and managers who want to recruit the best talent, engage and retain those people, and deliver impressive business results. Offer Expires 5/5/2026. Get it FREE!
	Beyond Advertising: Creating Value Through All Customer Touchpoints ($30.00 Value) FREE for a Limited Time The fundamental relationships among brands, media, and people are being transformed, and just as we try to adapt, along comes a new disruption. Are you and your organization prepared to deal with today’s unprecedented speed and scope of technological change?. Beyond Advertising provides a business transformation road map for an aspirational future, based on the insights of more than 200 of the world’s most forward-thinking executives, innovators, and academics all grappling with today’s unique challenges and opportunities. This book offers a concrete set of principles, including The All Touchpoint Value Creation Model, designed to lift us out of reactive thinking and encourage the co-creation of a future better for business, better for people, and better for society. Actionable steps include: Holistically orchestrate and allocate resources across all touchpoints. Redefine expectations of success to align for multi-win outcomes. Provide every stakeholder at all touchpointsa R.A.V.E.S. standard of content: relevant and respectful, actionable, valuable, exceptional experiences, and a shareworthy story. Develop all touchpoints to maximize the M.A.D.E.s value of context: the complete person, the features of the delivery platform, the dynamic environment, and synergies with other touchpoints. Offer Expires 5/5/2026. Get it FREE!
	Ransomware Protection Playbook ($28.00 Value) FREE for a Limited Time Avoid becoming the next ransomware victim by taking practical steps today. Colonial Pipeline. CWT Global. Brenntag. Travelex. The list of ransomware victims is long, distinguished, and sophisticated. And it’s growing longer every day. In Ransomware Protection Playbook, computer security veteran and expert penetration tester Roger A. Grimes delivers an actionable blueprint for organizations seeking a robust defense against one of the most insidious and destructive IT threats currently in the wild. You’ll learn about concrete steps you can take now to protect yourself or your organization from ransomware attacks. In addition to walking you through the necessary technical preventative measures, this critical book will show you how to: Quickly detect an attack, limit the damage, and decide whether to pay the ransom. Implement a pre-set game plan in the event of a game-changing security breach to help limit the reputational and financial damage. Lay down a secure foundation of cybersecurity insurance and legal protection to mitigate the disruption to your life and business. A must-read for cyber and information security professionals, privacy leaders, risk managers, and CTOs, Ransomware Protection Playbook is an irreplaceable and timely resource for anyone concerned about the security of their, or their organization’s, data. Get it FREE!
	Job Architecture: Building a Language for Workforce Intelligence ($35.00 Value) FREE for a Limited Time Harness the power of taxonomies for better human capital management and employee wellbeing. In Job Architecture, economist and entrepreneur Ben Zweig offers a revolutionary approach to transforming human capital management through the power of taxonomies. The book follows the experience and ideas of key individuals-from the founders of Wall Street, to the original management consultant, to a young data scientist just out of grad school looking to make sense of the modern workforce-in order to illustrate why our current human capital infrastructure is not serving employees well and what we can do to change that. By categorizing and organizing workforce data, Zweig provides a practical roadmap for creating a more efficient and data-driven labor market. This book includes key insights on how to: Use AI and similar large language model technologies to support businesses with appropriate categorization and regimentation of data. Know whether or not a taxonomy can be useful and functional for an organization in their ability to be flexible, auditable, and adaptable. Build a taxonomy that meets the needs of a workforce or organization through clustering, labeling, and production. Combining storytelling with real-world examples, theoretical analysis, and a practical framework, Job Architecture is an essential guide for companies to manage a competitive, modern workforce that improves the working experience for all employees. Offer Expires 4/28/2026. Get it FREE!
	Coexisting with AI: Work, Love, and Play in a Changing World ($28.00 Value) FREE for a Limited Time Your comprehensive, easy-to-understand guide on AI’s impact in business and life. Coexisting with AI: Work, Love, and Play in a Changing Worldis an exploration of how AI can be used at each stage of our lives. It helps readers understand the positive impact of AI and where governance is needed from both an individual and business perspective. From childhood through to aging, this book delivers a holistic understanding of this exciting new technology in language that anyone can understand regardless of technical expertise. Written by Kay Firth-Butterfield, former inaugural Head of AI at the World Economic Forum and one of the most foremost experts in the world on the governance of AI, topics explored in this book include: An explanation of AI and Chatbots and their dependence on data. How to use AI wisely in business, with your children and in your life. How AI might be used in politics and war. The good, bad, and ugly of AI now and into the future. AI’s potential to solve some of humanity’s biggest problems, from human trafficking to disease. Essential governance considerations to make AI a beneficial technological development for all. Coexisting With AIearns a well-deserved spot on the bookshelves of all individuals, from tech executives to curious citizens, seeking expert insight on where AI can take us and how to plot the best path forward for your family and business. Offer Expires 4/28/2026. Get it FREE!

That’s it for now, we hope you found them insightful. Stay tuned for more!

Till next time, keep geeking!

Tags

Compact Object Headers: The Invisible JDK 25 FeatureWith the Biggest Memory Impact

Eleftheria Drosopoulou — Wed, 29 Apr 2026 07:21:00 +0000

Core Java

Compact Object Headers: The Invisible JDK 25 FeatureWith the Biggest Memory Impact

How four saved bytes per object can quietly transform your entire heap — and why you don’t have to change a single line of code.

Every so often, the Java platform ships a change that sits quietly in the release notes — no flashy syntax, no new API, no migration guide — and yet it carries one of the most meaningful real-world payoffs in years. JEP 519, Compact Object Headers, is precisely that kind of feature.

Promoted to a full product feature in JDK 25 (September 2025), this enhancement shrinks the memory overhead that the JVM attaches to every single Java object from 12 bytes down to just 8 bytes. That’s a 33% reduction in header size. And in applications that create millions of objects — which, as it turns out, describes almost every modern Java workload — those four bytes add up surprisingly fast.

In this article, we’ll walk through what object headers actually are, why they matter so much, what changed under the hood, and what the real benchmarks say. By the end, you’ll have everything you need to decide whether to flip the switch in your own services.

1. First Things First: What Is an Object Header?

Before we talk about making object headers smaller, it’s worth understanding what they actually are — because most developers never think about them at all.

In the HotSpot JVM, every Java object stored on the heap carries a small piece of hidden metadata right at the start of its memory layout. This metadata is called the object header, and it consists of two parts:

Header Component	Size (traditional)	Purpose
Mark Word	64 bits (8 bytes)	Locking state, GC age, identity hash code, biased-lock epoch
Class Pointer	32 bits (4 bytes, compressed)	Reference to the object’s class metadata in Metaspace
Array Length	32 bits (arrays only)	Length field appended for array objects

Together, that’s 96 bits (12 bytes) for regular objects on a 64-bit system with compressed class pointers enabled — and 128 bits (16 bytes) without compression. Now here’s the thing that should make you pause: most small Java objects themselves contain only 16–32 bytes of actual data. That means the header alone can account for 20% or more of a typical object’s total memory footprint. In a Spring Boot service with millions of tiny wrapper objects, DTO instances, and collection entries, that tax gets enormous.

Imagine every book in a library came packaged in a rigid plastic case labelled with metadata. Even if the book itself is a short pamphlet, the plastic case never changes size. That’s essentially what a traditional Java object header does — it’s a fixed-cost overhead regardless of how small the object inside is.

2. The Road to JEP 519: A Quick History Lesson

This feature didn’t appear overnight. It’s the result of several years of careful engineering inside the OpenJDK community, most of it driven by Project Lilliput — an initiative specifically focused on shrinking Java object headers. The project was originally kicked off by Roman Kennke at Red Hat, and the journey to production looked like this:

2022- Project Lilliput reaches its first milestone

The team demonstrates a working prototype reducing headers to 64 bits, setting the technical direction for what would follow.

JDK 22 · 2024- Object Monitor Tables infrastructure lands

A necessary stepping stone: locking state is moved out of the header into a side table, making header compression possible without breaking synchronization semantics.

JDK 24 · March 2025- JEP 450 — Compact Object Headers (Experimental)

Available behind -XX:+UnlockExperimentalVMOptions, the feature enters the wild for the first time. Amazon begins testing it in production services.

JDK 25 · September 2025- JEP 519 — Compact Object Headers (Product)

Promoted to a stable product feature. The experimental flag is gone. All it takes is -XX:+UseCompactObjectHeaders.

It’s also worth noting that Amazon and SAP both played key roles in validating this feature. Amazon ran compact headers across hundreds of production services — many using backports to JDK 17 and 21 — before a single production-ready release shipped. SAP went a step further and enabled compact object headers by default in their own JDK 25 fork (SapMachine). That level of real-world confidence is rare, and it tells you a lot about how thoroughly this feature was tested.

3. What Actually Changed Under the Hood

The key insight of Compact Object Headers is elegantly simple: instead of keeping the mark word and the class pointer as two separate fields, they are merged into a single 64-bit word. The class pointer is compressed from 32 bits down to just 22 bits — which still supports approximately 4 million unique classes, far beyond any realistic application requirement. The remaining bits accommodate GC metadata, lock state, hash codes, and four bits reserved for future use by Project Valhalla.

Layout	Mark Word	Class Pointer	Total Size	Status
Traditional (default)	64 bits	32 bits	96 bits / 12 bytes	Pre-JDK 25 default
Compact (JEP 519)	Merged into single 64-bit word (22-bit class ptr + GC + lock + hash + 4 reserved bits)		64 bits / 8 bytes	JDK 25 opt-in

The change requires Compressed Class Pointers to be enabled (which they are by default on 64-bit systems with heaps under 32 GB). Hash codes and monitor information that used to live directly in the header are now stored in lightweight side tables, indexed by object address — a technique that adds negligible overhead because very few objects actually need those features at any given time.

“Compact object headers eliminate the division between the mark word and the class pointer by subsuming the class pointer in compressed form into the mark word.”— Baeldung, JEP 519 Deep Dive

4. The Numbers: What the Benchmarks Actually Show

Now for the part everyone really wants to know — does this actually make a difference? The benchmarks, sourced directly from the official JEP 519 specification, give a clear and consistent answer: yes, significantly.

SPECjbb2015 Performance Gains with JEP 519

Real benchmark data from the official JEP 519 specification — comparing traditional vs. compact headers across key metrics.

Furthermore, JAVAPRO’s benchmark with 10 million Point objects on JDK 25 found up to 30% less committed memory and 12% less used memory with compact headers enabled. Meanwhile, Spring Boot and microservice workloads typically see 3–5% throughput improvements and 4–6% reductions in P99 latency, according to testing reported by Vinod Jagwani’s analysis.

Estimated Memory Savings by Workload Type

Object-heavy workloads with many small instances benefit the most. Large-object workloads see modest but still measurable gains.

It’s equally important to be honest about where the gains are smaller. If your application primarily deals with large arrays or a handful of long-lived persistent objects, the savings will be less dramatic. The four bytes per object only compound meaningfully when object count is high — and in modern Java, that threshold is crossed more often than not.

5. How to Enable It — and When to Hold Off

Even though JEP 519 is a product feature in JDK 25, it is not enabled by default (though a draft JEP proposing to make it default is already in progress). Enabling it is a single JVM flag

JVM Flag — Enable Compact Object Headers

java -XX:+UseCompactObjectHeaders -jar your-application.jar

If you want to verify the feature is active at startup, you can add the -XX:+PrintFlagsFinal flag and grep for the relevant setting:

Verify the flag is active

java -XX:+UseCompactObjectHeaders -XX:+PrintFlagsFinal -version 2>&1 | grep UseCompactObjectHeaders

You should see output like: bool UseCompactObjectHeaders = true.

Requirements checklist

To use JEP 519, you need:

(1)JDK 25 or later,

(2)a 64-bit system,

(3)Compressed Class Pointers enabled (default on heaps ≤ 32 GB). If your heap exceeds 32 GB, compact headers cannot be used since they depend on compressed class pointer encoding.

That said, there are legitimate reasons to hold off. Highly regulated environments with strict certification requirements, or teams with limited test coverage, may prefer to upgrade the JDK first and enable this feature in a later rollout. The JEP documentation is explicit that this is a conservative, not a correctness, concern — the feature itself is considered fully stable.

Some native code or tooling that relies on assumptions about fixed object layout may need updating to be header-aware. Additionally, ZGC is not currently supported with compact headers — workloads using ZGC will need to switch to G1 or Parallel collectors to take advantage of JEP 519.

6. Why This Matters Most in the Cloud

For on-premises applications running on dedicated hardware, a 22% heap reduction is nice to have. But in cloud and containerised environments, it translates directly into real, measurable cost savings.

Think about it this way: if each container instance needs 22% less heap, you can either run the same number of instances on smaller, cheaper VMs — or pack more instances onto your existing infrastructure. Either way, you’re paying less. As GCEasy’s FinOps analysis notes, this compounds particularly well across microservices architectures, where dozens of services benefit simultaneously.

Benefit	Mechanism	Typical Impact
Heap reduction	4 bytes saved per object × millions of objects	10–22% less heap used
CPU efficiency	Better CPU cache utilisation (more objects fit in L1/L2)	5–8% less CPU time
GC pressure	Smaller heap → fewer and shorter GC cycles	15% fewer GC runs
Container density	Lower memory per pod → more pods per node	Higher pod density
Latency (P99)	Shorter GC pauses → more consistent response times	4–6% P99 improvement

The bottom line: workloads that benefit most from JEP 519 are Spring Boot APIs, microservices with deep object graphs, caching layers, ORM-heavy applications, and data pipelines where thousands of small DTOs or records are processed in bulk. If your application fits any of those descriptions — and most production Java applications do — this feature is worth enabling and benchmarking.

7. Looking Ahead: What Comes Next for Project Lilliput?

JEP 519 is not the end of the story. The Project Lilliput wiki already outlines work on Lilliput 2, which aims to push object headers down to just 4 bytes. That would be a further 50% reduction on top of what JEP 519 delivers today.

Additionally, the four bits reserved in the current 64-bit header for Project Valhalla hint at deeper integration ahead — particularly around value types, which promise to eliminate object headers entirely for certain kinds of objects by flattening them inline into their containing structure.

Furthermore, a draft JEP is already circulating to make compact object headers the default in a future JDK release. When that happens, every Java application will benefit automatically, without any flag required.

8. What We’ve Learned

In this article, we explored JEP 519 — one of those rare JVM improvements that is completely invisible to your application code yet delivers some of the most tangible performance gains in recent Java history. We started by understanding what object headers are and why their 12-byte size had been a long-standing inefficiency. We then traced the multi-year journey from Project Lilliput through the experimental JEP 450 in JDK 24, all the way to the stable product feature in JDK 25.

We looked at the real benchmark numbers — 22% heap reduction, 15% fewer GC cycles, and 8% less CPU time on SPECjbb2015 — and we learned how a single JVM flag (-XX:+UseCompactObjectHeaders) is all it takes to unlock these gains. Finally, we discussed the cloud cost implications, the workloads that benefit most, and the road ahead with Lilliput 2 and Project Valhalla on the horizon.

Tags

Project Babylon: Code Reflection and What It Means for ML on the JVM

Eleftheria Drosopoulou — Tue, 28 Apr 2026 16:36:00 +0000

Core Java

Project Babylon: Code Reflection and What It Means for ML on the JVM

For most of its history, Java has sat on the sidelines of the machine learning conversation. Python dominated that space, and for understandable reasons: it had the libraries, the ecosystem, and direct pathways to GPU hardware. Java, by contrast, had none of that. If you wanted to train a model or run GPU-accelerated inference in Java, your choices were to call Python over HTTP, vendor-specific JNI bindings, or accept that some workloads just weren’t a Java problem.

Project Babylon, an active OpenJDK project led by Oracle Library Architect Paul Sandoz, is quietly dismantling that assumption. And in 2026, it’s doing so in a very concrete way.

The chart below frame both where we are today — in terms of real performance numbers from TornadoVM benchmarks — and where Project Babylon is heading on its development roadmap. Now let’s walk through the full story.

Project Babylon — key milestones & development status (2023–2027)

1. What Is Project Babylon, Really?

At its core, Babylon’s primary goal is to extend the reach of Java to foreign programming models such as SQL, differentiable programming, machine learning models, and GPUs. OpenJDK The mechanism it uses to achieve this is called code reflection — and it’s worth understanding what makes that different from the Java reflection you already know.

Standard Java reflection lets you inspect a class at runtime: what fields it has, what methods it exposes, what annotations are present. That’s useful, but it tells you nothing about what the code inside a method actually does. You can see that a method called computeGradient exists, but you can’t look inside it and see the mathematical operations it performs.

Code reflection changes that entirely. In the context of Babylon, a code model is a representation of a program — for example, a Java method — that is produced by the javac compiler and stored in the class file. Babylon’s enhanced reflection API empowers developers to access and manipulate these code models at runtime, enabling metaprogramming directly within Java.

In even plainer terms: Babylon lets Java see its own source-level intent — not just compiled bytecode — and use that symbolic description to do something completely new with it. Translate it to GPU kernel code. Differentiate it mathematically. Convert it to SQL. The same underlying mechanism serves all of those goals.

2. The Missing Piece: Why Bytecode Wasn’t Enough

To understand why this matters, it helps to know why existing approaches fell short. Java bytecode is a well-understood, stable format — but it’s an optimised representation. By the time the compiler is done, a lot of the original programmer intent has been erased. Variable names are gone, high-level constructs have been flattened, and the mathematical meaning of a computation is no longer visible.

Consequently, access to Java code in symbolic form has been currently limited to the use of non-standard APIs or to conventions at different points in the program’s life cycle, and the symbolic forms available — abstract syntax trees or bytecodes — are often ill-suited to analysis and transformation.

This is precisely the gap that code reflection fills. A method annotated with @CodeReflection produces a model that sits above bytecode — closer to what the programmer wrote, with the structural and type information that makes it amenable to transformation. A GPU backend can then walk that model, recognise the computational structure, and emit the appropriate GPU code. All from a Java library. No separate tools. No separate source files.

3. HAT: The GPU Layer Built on Top of Babylon

The most tangible demonstration of Babylon’s capabilities is the Heterogeneous Accelerator Toolkit (HAT), developed alongside the core project.

HAT is a parallel programming framework that allows Java developers to offload Java code and dispatch the generated code on modern hardware accelerators such as GPUs. HAT can be used to speed up massive parallel workloads such as deep learning, AI, big data analytics, and physics simulations by automatically offloading and running these workloads on specialized hardware. OpenJDK

The compilation pipeline is elegantly simple compared to what came before. A developer annotates a method with @CodeReflection. The javac compiler generates the code model and stores it in the class file. At runtime, HAT reads that model, lowers it through a series of transformation stages, and produces GPU-native code — OpenCL C, CUDA PTX, or SPIR-V — which the GPU driver then compiles to a final binary. No JNI. No C. No separate GPU source files to maintain. Java Code Geeks

As of early 2026, HAT supports OpenCL and CUDA backends with SPIR-V under active development.

4. The Use Cases: Far Wider Than Just GPUs

One of the most underappreciated aspects of Babylon is that GPU programming is actually just the proof of concept. The same code reflection mechanism unlocks several other use cases that enterprise Java teams will find immediately relevant.

Use Case	What Babylon Enables	Status
GPU kernel offload	Write parallel Java → compiled to OpenCL/CUDA	Active (HAT)
Automatic differentiation	Java methods mathematically differentiated for ML training	PoC demonstrated
LINQ-style queries	Lambda expressions translated to SQL/query languages	PoC demonstrated
ONNX/LLM inference	ONNX model graphs executed via Java code models	PoC demonstrated (Nov 2025)
Differentiable programming	Gradients computed from plain Java functions	Research prototype

The ONNX angle is particularly interesting for enterprise teams. A November 2025 inside.java article demonstrates using Babylon to run ONNX-based generative AI models in Java, with code models providing the bridge between Java’s type system and ONNX’s computational graph format. For organisations that want to run LLM inference inside their existing Java infrastructure — rather than spinning up a Python microservice — this is a genuinely new path.

Meanwhile, Project Babylon enables developers to build and run AI models such as LLMs, image classifiers, or object detection algorithms directly in Java. With code reflection, machine learning logic can be defined in plain Java code, eliminating the need for Python or external model files.

5. Where Things Stand in 2026

It’s important to be honest about the timeline here, because Babylon is genuinely exciting — and also genuinely not yet production-ready as a standard JDK feature.

For Project Babylon, 2026 plans include incubating code reflection, which allows third-party frameworks to reflect over Java code in a lambda expression and process it. The Babylon team is also working on proofs of concept for using code reflection to run machine learning models on the GPU.

The API lives in the jdk.incubator.code module. Compilation and execution of dependent code requires that this module be made visible by explicitly adding it to the list of modules, for example with the command line option --add-modules jdk.incubator.code. In other words, it’s available to experiment with today, but it requires opting in deliberately.

Babylon is not shipping in JDK 26 or 27. The project leadership has explicitly stated delivery will happen via a series of JEPs across multiple feature releases. This is a very deliberate approach — the team wants to get code reflection right before formalising it through the JEP process. Given that code reflection is a foundational primitive on which many future capabilities will be built, that caution is well justified.

6. TornadoVM: The Production Bridge Right Now

Because Babylon is still incubating, the practical question for teams that need GPU acceleration in Java today is: what do you use in the meantime?

The answer is TornadoVM, which reached version 2.0 in December 2025. TornadoVM automatically accelerates Java programs on multi-core CPUs, GPUs, and FPGAs. This release is of particular interest to teams developing LLM solutions on the JVM.

The performance numbers are striking. When running on GPUs, TornadoVM can achieve up to 39× and 270× speedup compared to sequential Java for Intel HD Graphics and NVIDIA GPUs respectively. InfoQ The chart below shows real benchmark figures from a matrix multiplication workload at the JVM Advent 2025.

TornadoVM — matrix multiply speedup vs. sequential Java (2048×8192, JVM Advent 2025 benchmarks)

TornadoVM offers two complementary ways to express parallelism: the Loop Parallel API, which uses Java annotations such as @Parallel and @Reduce to parallelize loops, and the Kernel API, which provides explicit GPU-style programming with concepts such as thread IDs, local memory, and barriers — similar to CUDA and OpenCL.

The relationship between TornadoVM and Babylon is complementary rather than competitive. TornadoVM, shipping today with up to 270× speedups over sequential Java and full LLM inference support, shows that Java GPU programming is already real — Babylon wants to make it standard platform infrastructure rather than a sophisticated plugin. Java Code Geeks TornadoVM solves the production problem now. Babylon solves it at the platform level, for every Java developer, without requiring a specialised framework.

7. What This Means for Enterprise Java Teams

The practical implication of all this research is something quite significant: the long-held assumption that Java is not a serious language for ML or GPU-accelerated workloads is starting to look outdated.

For teams building microservices in Java who currently call a Python ML service over HTTP, Babylon and TornadoVM together represent a realistic path to collapsing that boundary. Model inference could live in the same JVM process as the business logic that uses it. Gradients for on-device learning could be computed from plain Java methods. ONNX models could be loaded and run without a runtime language switch.

That said, it’s equally important to have realistic expectations. Babylon’s incubation is a genuine signal of forward momentum, but what exists today is a development branch that tracks mainline, active research prototypes, and a growing body of published demonstrations. Teams should watch the project closely — particularly the talks at JVMLS and JavaOne, which have consistently been the best windows into where the project is heading — but should not design production systems around Babylon APIs that are still evolving.

The right posture in 2026 is to experiment with Babylon today (using --add-modules jdk.incubator.code), run production GPU workloads on TornadoVM, and keep an eye on when the first formal JEPs from the Babylon project land.

8. What We’ve Learned

Project Babylon is one of the most architecturally ambitious things happening in the OpenJDK ecosystem today. Its core innovation — code reflection — gives Java the ability to reason about its own source-level intent for the first time in a standardised, platform-native way. Built on top of that foundation, the Heterogeneous Accelerator Toolkit (HAT) provides a pure-Java path to GPU kernel execution without C, JNI, or separate GPU source files, while ONNX-based ML inference prototypes demonstrate that running AI models natively in Java is no longer a thought experiment.

In 2026, the project is in active incubation, with GPU ML proof-of-concepts under development and a formal JEP process expected across multiple future releases. TornadoVM 2.0 bridges the gap for teams that need production-grade GPU acceleration today. Together, they paint a picture of a JVM platform that is seriously, methodically closing the gap with Python on machine learning — not by copying Python’s model, but by extending Java’s own strengths.

Tags

A Guide to Exporting and Backing Up H2 Databases

Omozegie Aziegbe — Tue, 28 Apr 2026 15:37:29 +0000

Core Java

A Guide to Exporting and Backing Up H2 Databases

Data protection is a critical aspect of application development. Applications that rely on embedded databases, such as the H2 Database Engine, must implement mechanisms to preserve and recover data. Export and backup strategies provide reliable approaches for maintaining data integrity and ensuring continuity in the event of unexpected failures. In this article, database backup and export concepts are examined with practical H2 implementations in Java.

1. Understanding Backups and Exports

Backups and exports are related concepts, but they serve different purposes in database management. A backup refers to a complete and consistent copy of the database at a specific point in time. It is primarily used for disaster recovery and system restoration. An export is the process of extracting database data into a portable format, such as SQL or CSV. It is commonly used for data migration, reporting, or integration with other systems.

The distinction between backups and exports lies in their structure and use cases. Backups typically preserve the entire database in a format that can be restored quickly with minimal transformation. Exports transform data into formats that are easier to read, transfer, or process externally. Backups prioritize recovery and consistency while exports prioritize portability and flexibility.

2. Backup Using `BACKUP TO` SQL Command

The H2 engine provides a BACKUP command that creates a compressed archive containing a consistent snapshot of the database.

public class BackupService {

    public static void backupDatabase(String backupPath) {
        try (Connection conn = DatabaseConfig.getConnection(); Statement stmt = conn.createStatement()) {

            String sql = "BACKUP TO '" + backupPath + "'";
            stmt.execute(sql);

            IO.println("Backup completed");

        } catch (Exception e) {
        }
    }
}

This implementation executes the BACKUP TO SQL command using a JDBC statement. The command generates a compressed archive file that represents a consistent snapshot of the database. This method can be executed while the database is running, which makes it suitable for production environments.

3. Export Table Data to CSV Using CSVWRITE

The H2 engine supports exporting query results directly to a CSV file using the CSVWRITE function.

public class CsvExportService {

    public static void exportToCsv(String filePath) {
        try (Connection conn = DatabaseConfig.getConnection(); Statement stmt = conn.createStatement()) {

            String sql = "CALL CSVWRITE('" + filePath + "', 'SELECT * FROM users')";
            stmt.execute(sql);

            IO.println("CSV export completed");

        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

This class uses the CSVWRITE function to export table data into a CSV file. The SQL query inside the function defines which data is written. The resulting file is suitable for reporting, data exchange, or external processing.

4. Export Schema and Data Using SCRIPT Command

When both schema and data are required, the SCRIPT command can be used to generate SQL statements.

public class ScriptExportService {

    public static void exportToSqlScript(String filePath) {
        try (Connection conn = DatabaseConfig.getConnection(); Statement stmt = conn.createStatement()) {

            String sql = "SCRIPT SIMPLE TO '" + filePath + "' TABLE PUBLIC.USERS";
            stmt.execute(sql);

            IO.println("SQL script export completed");

        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

This implementation generates a SQL script that includes both the table structure and its data. The SIMPLE option produces a clean and readable script. This format is useful for migration and version control purposes.

The main class below ties all components together and demonstrates the full workflow.

public class H2BackupDemo {

    public static void main(String[] args) {

        DataInitializer.initialize();

        BackupService.backupDatabase("./backup/database.zip");
        CsvExportService.exportToCsv("./backup/users.csv");
        ScriptExportService.exportToSqlScript("./backup/users.sql");
    }
}

This class initializes sample data and executes backup and export operations.

Database Configuration

public class DatabaseConfig {

    private static final String JDBC_URL = "jdbc:h2:./data/sampledb";
    private static final String USER = "sa";
    private static final String PASSWORD = "";

    public static Connection getConnection() throws SQLException {
        return DriverManager.getConnection(JDBC_URL, USER, PASSWORD);
    }
}

This class centralizes the database connection logic. The configuration uses a file-based H2 database stored locally.

Sample Table and Data

public class DataInitializer {

    public static void initialize() {
        try (Connection conn = DatabaseConfig.getConnection();
             Statement stmt = conn.createStatement()) {

            stmt.execute("CREATE TABLE IF NOT EXISTS users (id INT PRIMARY KEY, name VARCHAR(100))");
            stmt.execute("INSERT INTO users (id, name) VALUES (1, 'Thomas')");
            stmt.execute("INSERT INTO users (id, name) VALUES (2, 'Benjamin')");

            IO.println("Data created");

        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

This class creates a simple table and inserts sample records.

5. Conclusion

This article presented a guide to performing backups and exports in H2 databases. It explained the conceptual differences between backups and exports and demonstrated practical implementations using built-in H2 commands. By applying these techniques, developers can ensure data safety, improve recovery capabilities, and support seamless data migration.

6. Download the Source Code

This article explored how to perform data export and backup operations with H2 in Java applications.

Download
You can download the full source code of this example here: data export and backup operations with H2 in Java

Tags

Java Code Geeks

[DEALS] Surfshark VPN Starter Plan: 3-Yr Subscription (80% off) & Other Deals Up To 98% Off – Offers End Soon!

Thank you!

Getting Started with TOON Format in Java

1. Understanding TOON Syntax

2. Setting Up TOON in a Java Project

3. Parsing TOON Data in Java

4. Converting Java Objects to TOON

4. Reading and Writing TOON Files

5. OpenAI API Integration

Key Benefits of This Integration

6. Conclusion

7. Download the Source Code

Thank you!

Prompt Engineering Is Not Enough: How Java Developers Should Structure AI Agent Workflows Using Embabel or Koog

1. The Problem With Prompt-Only Thinking

2. The New JVM Agent Landscape

3. Embabel in Depth: GOAP Meets Spring

Key Embabel Concepts at a Glance

4. Koog in Depth: Coroutines Meet Agent Graphs

What Koog Ships Out of the Box

5. Side-by-Side Comparison

6. Goal-Oriented Planning in Practice

7. Tool Registration and Multi-Step Execution

8. Adoption in Numbers

9. Which Framework Should You Choose?

10. What We Have Learned

Thank you!

Flex and Justify Items in Tailwind CSS

1. Flexbox Fundamentals with Tailwind CSS

1.1 Simplifying Flexbox with Tailwind CSS

1.2 Getting Started with Flex in Tailwind

2. Practical Flexbox Implementation

2.1 Code Explanation

2.2 Code Output

3. Conclusion

Thank you!

Real-Time Updates with MQTT and Express.js

1. Introduction to MQTT

1.1 What is MQTT?

1.2 Why Use MQTT?

1.2.1 MQTT Quality of Service (QoS)

1.2.2 MQTT Retained Messages & Last Will

1.3 MQTT Architecture

1.3.1 MQTT vs HTTP vs WebSockets

1.4 Setting Up an MQTT Broker

2. Complete Real-Time System with MQTT + Express.js + SSE

2.1 Server (Express + MQTT + SSE)

2.1.1 Code Explanation

2.2 Admin Upload Interface

2.2.1 Code Explanation

2.3 Live Viewer Interface (SSE)

2.3.1 Code Explanation

2.4 Home Page

2.4.1 Code Explanation

2.5 Code Output

3. Conclusion

Thank you!

Java 25 vs Java 21: The Upgrade Guide NobodyHas Written Yet

1. First: Understanding the Gap Between the Two Releases

2. The Fix That Changes Everything: Virtual Thread Pinning

2.1 What Does This Mean in Practice?

2.2 Diagnostics Changed Too

3. Startup Time: Project Leyden’s First Real Payoff

3.1 How It Works (Without the Jargon)

3.2 The Workflow on Java 25

4. Memory: Compact Object Headers Give You a Free Heap Reduction

5. Garbage Collection: Two Notable GC Upgrades

5.1 Generational Shenandoah (JEP 521) — Now Production-Ready

5.2 ZGC Simplification: Non-Generational Mode Removed

6. Language & API: What Graduated to Final in Java 25

7. Breaking Changes and Removal Risks

8. Support Timelines: Why “Later” Has a Deadline

9. Should You Upgrade? A Decision Matrix

10. Your Practical Upgrade Checklist

11. What We’ve Learned

Thank you!

[FREE EBOOKS] Pragmatic Software Testing, Employee Experience Design & Four More Best Selling Titles

Pragmatic Software Testing: Becoming an Effective and Efficient Test Professional ($55.00 Value) FREE for a Limited Time

Employee Experience Design: How to Co-create Work Where People and Organizations Thrive ($28.00 Value) FREE for a Limited Time

2. Backup Using `BACKUP TO` SQL Command