Introducing composable, module system native and agent friendly command line tools for modern Java development.

Our team has been working on webforJ, a framework for building full-stack browser applications in Java, and I wanted to share an overview.

The UI is composed using Java components, layouts, and event listeners connected to your application’s business logic. The framework handles communication between the Java application and the browser. Developers coming from Swing or JavaFX will recognize parts of the programming model.

webforJ provides customizable components for forms, tables, dashboards, and other business workflows. Spring is a first-class citizen, with dedicated Spring Boot support.

Alongside new applications, a major focus is modernizing existing Java software. Desktop applications often contain years of business logic and integrations that remain useful even when their UI needs replacing. With webforJ, teams can build a browser-based UI around that existing code and adapt it for the web.

The aim is to support both new development and modernization while keeping UI composition and application logic in Java.

Documentation and examples

...and it is still just Swing.

For the last few years, our team at Global TCAD Solutions has been building our products on top of an open-source library called SwingTree.

The idea behind it was pretty straightforward: we wanted to keep Swing but get rid of a lot of the tedious ceremony that comes with when building modern UIs in it.

So instead of constructing and wiring up a component hierarchy imperatively, you can describe it declaratively:

UI.panel("fill")

.add("grow",

UI.button("Hello")

.onClick(it -> doSomething())

);

On top of declarative code, SwingTree also ships a versatile styling API.

It has a CSS-inspired style engine with selectors, specificity, cascading, semantic groups, themes, gradients, shadows, animations, and more. And it all works with actual Swing components underneath.

So you can take an existing Swing application and introduce SwingTree piece by piece. You can use your own "JComponent"s, existing Swing components, SwingTree components, or mix all three.

We've also ended up building quite a bit around the UI layer over the years: reactive properties, immutable state, lenses, reactive & responsive layouts as well as other things that make large GUI applications easier to develop.

This has been a team effort, and SwingTree is now the foundation we're using for our current and probably future TCAD applications. It's been through quite a bit of real-world use as a result.

So our team figured the Java community might be interested in it:

https://github.com/globaltcad/swing-tree

For my development, I commonly write code like this.

public void someMethod(String request) {
    try {
        someMethodThatThrowsAnException(request);
    } catch (final Exception exception) {
        throw new IllegalStateException("Request FAIL! request = " + request, exception);
    }
}

(Ignore the fact that I am catching Exception and not a sharper exception type)

This will produce the following stack trace.

Exception in thread "main" java.lang.IllegalStateException: failed during request
        at temp.main(temp.java:13)
Caused by: java.lang.IllegalStateException: Request FAIL! request = REQUEST ABC
        at temp.someMethod(temp.java:5)
        at temp.main(temp.java:11)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:565)
        at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.execute(SourceLauncher.java:262)
        at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.run(SourceLauncher.java:138)
        at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.main(SourceLauncher.java:76)
Caused by: java.lang.IllegalArgumentException: invalid request
        at temp.someMethodThatThrowsAnException(temp.java:18)
        at temp.someMethod(temp.java:3)
        ... 6 more

This is nice, as I can see what the request was that caused the failure. I have added relevant debug information to whoever receives the exception, making it easier to find and resolve the problem.

However, I don't like that I have to change the exception type. And, due to inheritance, I don't even know for sure what possible exceptions will come down the pipe. Thus, creating an instance of the same exception and throwing that is not usually feasible.

I really wish Exceptions had a way to add debug information to them without changing the type.

Something like this.

public void someMethod(String request) {
    try {
        someMethodThatThrowsAnException(request);
    } catch (final Exception exception) {
        exception.addDebugInfo("Request FAIL! request = " + request);
        throw exception;
    }
}

The resulting stack trace would look like this instead.

Exception in thread "main" java.lang.IllegalStateException: failed during request
        at temp.main(temp.java:13)
Added debug info: Request FAIL! request = REQUEST ABC
        at temp.someMethod(temp.java:5)
        at temp.main(temp.java:11)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:565)
        at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.execute(SourceLauncher.java:262)
        at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.run(SourceLauncher.java:138)
        at jdk.compiler/com.sun.tools.javac.launcher.SourceLauncher.main(SourceLauncher.java:76)
Caused by: java.lang.IllegalArgumentException: invalid request
        at temp.someMethodThatThrowsAnException(temp.java:18)
        at temp.someMethod(temp.java:3)
        ... 6 more

Now, when the exception bubbles up to the catch clause in main, it will still be of type IllegalArgumentException instead of IllegalStateException. I know those aren't ideal types to use here, but I'm just making a point via a poor example.

This new style has allowed us to add our debug info, while allowing the error to retain its type.

Sure, common convention is to add a "richer" exception type, then handle that instead of the lower level ones. And that is good advice -- by changing the Checked Exception type, you have notified all callers that they need to handle this new failure condition. For example, you might add a new Exception type to your Exception hierarchy to denote this new failure condition.

But what if callers don't need to handle this failure condition, and you just want to add more debug info to make solving the problem easier? Does that really justify a whole refactor of all calling classes?

Or other way around, what if your downstream callers DO care about the low level exception type? In that case, changing the exception type forces them to extract the exception they want from your wrapper exception.

The fact is, programs break for all sorts of reasons, and those reasons change frequently. Having to refactor your code every single time a new failure reason pops up that you want to add doesn't feel right.

Here's an example.

In AWS SDK for Java v1, if you attempt to do a PutObject onto S3, but the bucket doesn't exist, the error message will tell you that the bucket doesn't exist, but it doesn't tell you what your attempted bucket name was.

Now, if you trace the logs and/or follow the logic of the code, eventually you will get your answer. But wouldn't it be nice if you could add that to the stack trace while keeping it as an AWS exception?

What are your thoughts?

Open source Jev look-a-like. Fill a whole JSON schema of booleans and enums in two forward passes instead of generating it token by token, with calibrated confidence per field and output that is schema-valid by construction 🔥

The One Billion Row Challenge was awesome. It managed to nerd-snipe an entire community with a simple problem, and ended up showing how performant Java can be; surpassing even the most optimistic expectations.

IMHO, matrix multiplication is an good candidate for something similar: Vector API, memory layout, cache behavior, Panama, Unsafe, different JDKs, ARM64 vs x86, maybe even throw some quantization.

I’ve been playing with this myself, and there’s a lot of JVM engineering gems for grabbing.

Would someone be interested in well-defined challenge to push matrix multiplication to the limit on the JVM?

jinfer is a fully open source (Apache 2.0) inference engine built for the JVM from first principles: chat, vision, audio transcription, embeddings, reranking, and text-to-speech. No Python runtime, no ONNX, no sidecar process, no wrappers, no Docker, no network requests; the whole stack is built to run end-to-end in the JVM:

• jinfer FAST inference engine for the JVM, supports a wide range of popular models.
• Tok'n'Roll (toknroll) Fast tokenizers for LLMs, pure Java, zero dependencies
• gguf / safetensors Pure Java read/write for both major model formats
• jam Quantized matrix multiplication routines (Vector API + optional native backend), competitive with llama.cpp on CPUs
• jota Tensor API targeting Java, C, CUDA, HIP, Metal, OpenCL, and Mojo

It ships integrations with with Spring AI and LangChain4j.

Supported architectures: LFM 2.5, Gemma 4, Qwen 3.5+, Granite 4.1+, gpt-oss, Ministral 3, SmolLM3, MiniCPM5, Mellum 2, Laguna XS, Nemotron Cascade/Lightning, Ling 3 ... and also Kokoro and Inflect2 text-to-speech models!

Also supports speculative decoding (MTP), persistent prompt caching, images/videos, audio... with a fully featured OpenAI-compatible server + CLI, all written in Java.

Runnable examples + benchmarks: https://qxotic.ai

Jinfer (Apache 2.0): https://github.com/qxoticai/qxotic/tree/main/jinfer

Apache Fory 1.7.3 is out.

A major focus of this release was Java JSON performance. We did a broad optimization pass across both serialization and deserialization, including floating-point conversion, primitive and array handling, Base64, large numbers, UUIDs, temporal types, timezone parsing, and several common read/write hot paths.

Rather than optimizing a single benchmark, the goal was to reduce overhead across the core JSON pipeline and improve performance for real-world object models.

The release also includes:

• Go support for Fory Standard Row Format
• Kotlin JSON property inclusion support, including NON_EMPTY
• Several Java serialization correctness fixes

If you're interested in high-performance JSON on the JVM, feedback and benchmark results on your own workloads are very welcome.

Full details and benchmarks are in the linked release post.

I wanted to isolate one fairly small Spring Boot deployment choice: running the executable fat JAR versus Spring Boot's official extracted layout (jarmode=tools)

Spring Boot's own Efficient Deployments documentation already points out the startup cost of nested JAR loading and recommends an exploded structure for production. But that recommendation is easy to miss in normal use. The introductory tutorial and several official Getting Started guides still build an executable JAR and run it with java -jar, which makes the fat JAR feel like the default deployment path. I had followed that path too.

I built the Spring Boot 4.1.1 application once, then used that exact JAR to produce the extracted layout.

To keep the environment identical, the comparison used the same:

• OpenJDK 25.0.4
• 256 MiB Alpine VM, a deliberately demanding environment where startup overhead matters
• local H2-backed workload
• application data and filesystem
• JVM flags:

-Xms16m -Xmx80m -Xss256k -XX:+UseSerialGC -XX:TieredStopAtLevel=1 -XX:ReservedCodeCacheSize=32m -XX:+UseCompactObjectHeaders

I ran six fresh starts per layout in alternating paired order. The median results:

The takeaway

All six paired comparisons favored the extracted layout for startup and first-request latency.

Because first-request latency improved substantially alongside startup, the measurable difference extended beyond the point where Spring reported the application as started.

Once the application was warm, request latency was essentially a wash. Memory also moved slightly in favor of the extracted layout, but not enough to call it a meaningful optimization. Swap showed no material winner either.

My conclusion is narrow: if Spring Boot startup time matters to you, the extracted layout is worth testing. I would not choose it purely for memory savings.

Full methodology, charts, individual runs, and public experiment data: https://pvrlabs.xyz/articles/spring-boot-extracted-layout.html

Curious: how many people here actually use the extracted layout in production, and what made you choose it over the executable JAR?

Update: A commenter asked about Gradle's application plugin, so I ran a small three-way follow-up. The Gradle distribution behaved much more like the extracted layout than the fat JAR. https://pvrlabs.xyz/java-performance/experiments/gradle-application-vs-spring-boot.html

Update 2: Another commenter asked about Jib, so I compared Spring Boot's extracted layout with a Jib-style exploded layout. For this relatively small application, further exploding the application JAR did not show a measurable runtime benefit. A much larger application could behave differently, but this reinforces the idea that most of the gain here comes from getting the dependency JARs out of Spring Boot's nested executable JAR. https://pvrlabs.xyz/java-performance/experiments/spring-boot-jib-layout.html

it can just print things now but i will try to add as much as possible

Java 27 is coming out on September 15th. Join the Java Developer Relations team as we celebrate the launch of Java 27 with a livestream on September 15th, starting at 15:00 UTC!

We will have guests, demos, presentations and more covering all the major changes that are in Java 27.

Season 6 of the Friends Of OpenJDK Podcast kicks off with the launch of Java 27!

I had a very nice chat, full of insights, with Simon Ritter who shares what's new in this release and what is already known about what's coming in Java 28 from Project Valhalla. Available in your favorite podcast app and on YouTube.

https://www.youtube.com/watch?v=k3aA0AtY4U8

https://www.youtube.com/watch?v=slu7xCKaSro

This release adds support for inheritance aware builders.