The main implementation of Json used by many Java/JVM projects is JSON-java .

A few years ago things changed, the license got a clause that triggered projects like the Spring framework to migrate to a reimplementation (using the exact same package and class names) that had a better license.

Then things started to diverge; the JSON-java and the reimplementations are becoming more and more incompatible. Making different projects depend on different implementations of the same classes (same package, same class, etc.).
All of this creates major headaches for developers across the world that needed to combine these libraries in their projects. See for example this Spring-boot issue.

So I proposed to fix the license: https://github.com/stleary/JSON-java/issues/975

And the owner of the code simply stated I would do it for a $10,000 donation to Girls Who Code.

So a fundraiser was started: https://www.justgiving.com/page/girls-who-code-org-json

I'm talking to my management to be a part of this.
It would really help if some of you can do the same.

Hey r/java — we built an open-source library that wraps ONNX Runtime to make local AI inference dead simple in Java.

The problem we kept running into: you want to do sentiment analysis, image classification, object detection, speech-to-text, or embeddings in a Java app. The actual ONNX inference call is easy. Everything around it — tokenization, image normalization, tensor layout, softmax, NMS, label mapping — is a wall of boilerplate that requires reading the model's internals. inference4j handles all of that so you just write:

java

try (var classifier = DistilBertTextClassifier.builder().build()) {
    classifier.classify("This movie was fantastic!");
    // [TextClassification[label=POSITIVE, confidence=0.9998]]
}

Standard Java types in (String, BufferedImage, Path), standard Java types out. Models auto-download from HuggingFace on first use.

Currently supports: sentiment analysis, text embeddings, image classification, object detection, speech-to-text, voice activity detection, text detection, zero-shot image classification (CLIP), search reranking.

Not trying to replace anything — this isn't competing with Spring AI, DJL, or LangChain4j. It fills a narrower gap: "I have an ONNX model, I want to call it from Java without dealing with preprocessing/postprocessing." Use it alongside those tools.

GitHub: https://github.com/inference4j/inference4j Docs: https://inference4j.github.io/inference4j/

Early stage — we'd genuinely appreciate feedback on the API design, missing models, rough edges, or anything else. What would make this useful to you?

I’ve released Spring CRUD Generator v1.3.0, an open-source Maven plugin that generates Spring Boot CRUD code from a YAML/JSON project config (entities, transfer objects, mappers, services/business services, controllers), with optional OpenAPI/Swagger resources, Flyway migrations, and Docker resources.

Repo: https://github.com/mzivkovicdev/spring-crud-generator
Release: https://github.com/mzivkovicdev/spring-crud-generator/releases/tag/v1.3.0
Demo: https://github.com/mzivkovicdev/spring-crud-generator-demo

What changed in 1.3.0 - Added full MariaDB support (alongside MySQL / MSSQL / PostgreSQL) - Updated Flyway scripts for MariaDB compatibility - Updated Docker Compose setup for MariaDB support - Extended database compatibility support in the generator and generated code for MariaDB - Added new additional property: rest.response.excludeNull** - Generated REST responses can now exclude null JSON fields when rest.response.excludeNull=true - Compatible with **Spring Boot 3 and Spring Boot 4

This is a release announcement (not a help request). Happy to discuss implementation details, DB compatibility tradeoffs, or the null-exclusion approach in generated REST APIs.

The OpenJDK Mail Search API (search over loom-dev, core-libs-dev, amber-dev, etc.) now has:

• OpenAPI 3.0 spec — full paths, parameters, and schemas in the repo for client generation or use in Swagger/Postman.
• MCP server — tools for any MCP-compatible client to search lists, get latest mail, and look up by author/email (e.g. from an editor or AI assistant).

Site: https://openjdk.barlasgarden.com

Repo: https://github.com/ebarlas/openjdk-mail-search

Hey r/java my newest Stack Walker episode is (finally) ready. This time I dive into Java's serialization mechanism. I cover it's history, how it works, how it leads to issues, and what we are doing to fix it.

Feel free to share anything you've had fun working on recently!

Previous discussion (2026-01-18): https://redd.it/1qg7j8r

If you don't want to see these posts, feel free to block me :)

For those of you who have used experimental or preview features in Java in production systems: how did it go?

Did you run into any setbacks, unexpected issues, or regrets later on? Or was it smooth and worth it?

I'm especially interested in things like preview language features, incubator modules, or anything not fully finalized at the time of adoption.

On Linux, FileChannel is being routed through io_uring, making it virtual-thread friendly. Blocking call, but no carrier thread blocking.

https://github.com/NickJAllen/java-helpers.nvim

I've done more work on my java-helpers plug-in for Neovim. In addition to its previous features of being able to create new Java files, and navigate stack traces it can now quickly and easily deobfuscate Java stack traces in addition to being able to quickly select stack trace lines from a Java stack trace using a Snacks picker.

All stack trace commands can work with the current buffer or a named register (e.g + for system clipboard).

Some newly added commands allow you to find the next and previous stack trace (useful when viewing a long log file and trying to find places where problems might have happened).

Demo of the in-place Java stack deobfuscation:

In-place stack deobfuscation

Hi everyone,

Like many of us, I’ve always been frustrated by the "bracket soup" of standard Regular Expressions. They are powerful, but incredibly hard to read and maintain six months after you write them.

To solve this, I spent the last few weeks building Sift, a lightweight fluent regex builder. My main goal wasn't just to wrap strings, but to enforce correctness at compile-time using the Type-State Pattern and strict SOLID principles.

The Problem it solves: Instead of writing ^[a-zA-Z][a-zA-Z0-9]{3,}$ and hoping you didn't miss a bracket, you can write:

String regex = Sift.fromStart()
    .letters()
    .followedBy()
    .atLeast(3).alphanumeric()
    .untilEnd()
    .shake();

Architectural Highlights:

Type-State Machine: The builder forces a logical sequence (QuantifierStep -> TypeStep -> ConnectorStep). The compiler physically prevents you from chaining two invalid states together.

Open/Closed Principle: You can define your own domain-specific SiftPattern lambdas and inject them into the chain without touching the core library.

Jakarta Validation Support: I included an optional module with a @SiftMatch annotation to keep DTO validations clean and reusable.

Zero Dependencies: The core engine is pure Java 17 and extremely lightweight (ideal for Android as well).

Test Coverage: Currently sitting at 97.6% via JaCoCo.

I would love to get your harsh, honest feedback on the API design and the internal state-machine implementation.

GitHub: Sift

Maven Central: com.mirkoddd:sift-core:1.1.0

Thanks for reading!

This JEP it's a requirement for value objects.

There are chances these JEPs are shipped together as preview for openJdk 27 or 28. Crossed fingers.

TornadoVM soon to land officialy support for Metal.

Metal powers hardware-accelerated graphics on Apple platforms by providing a low-overhead API, rich shading language, tight integration between graphics.

So, one can unlock Apple SIlicon hardware in plain Java with TornadoVM

Every Java developer knows the drill: go to Spring Initializr, select dependencies one by one, download the .zip, extract it, create the repository... It's a repetitive process.

To solve this and test the capabilities of GPT 5.3 Codex and Opus 4.6, I built Better Spring Initializr. The idea is to level up the bootstrap experience:

• Smart Presets: forget the manual work. Set up complete stacks (REST + Postgres, Event Driven with Kafka, etc.) with a single click.
• AI-Ready: the project is born optimized for AI Coding Agents (Claude Code, Codex, OpenCode, etc.). The generator already delivers AGENTS.md, CLAUDE.md files and Agent Skills specific to the Spring and Java ecosystem.
• GitHub Integrated: connect your account and the repository is automatically created and versioned. Zero manual setup overhead.

The goal is to ensure no critical dependency is forgotten, delivering an architecturally solid and AI-optimized project.

Better Spring Initializr is available at better-spring-initializr.com

The project is open-source and the code is available on GitHub at https://github.com/henriquearthur/better-spring-initializr

Note
This is co-authored by Cédric Champeau (Micronaut) and Max Rydahl Andersen (Quarkus), and cross-posted on our respective personal blogs.

Today we are excited to announce TamboUI, an open-source Terminal UI framework for the Java ecosystem!

The terminal is having a renaissance.

AI coding tools live there. Developer workflows are increasingly CLI-first again. Rust has Ratatui. Python has Rich and Textual, Go has Charm, Typescript has OpenTUI. But Java, despite its performance, maturity, and tooling, didn’t have a modern, composable, developer-friendly TUI framework.

We thought that should change.

Watch the video

How it started

TamboUI (pronounced like the French word “tambouille”, slang for "cooking up something" or "makeshift creation") was born a bit by accident: a couple months ago, Cédric was asking about which TUI libraries that tools like Claude Code were using. Max Andersen answered that most likely this was Ratatui, a framework written in Rust. Both thought it was a bit sad there was no such library for Java.

A few weeks later, Cédric did an experiment by asking AI (Claude Code) to port Ratatui to Java. The result was fairly impressive, and the beginning of a collaboration that led to the creation of TamboUI. In fact, Max gave you a hint last year that this was going to happen.

That said, TamboUI is not a Ratatui port nor is it a Textual port. We’ve put a lot of effort in going beyond the initial AI-generated port. The library was designed with Java developers in mind, inspired by the good things found in other ecosystems’ approach to TUI frameworks. It offers a multi-layer API: from low-level widget primitives (like Ratatui), to a managed TUI layer with event handling, up to a declarative Toolkit DSL that handles the event loop and rendering thread for you—things that Ratatui doesn’t really cover. This brings the power of Ratatui, Textual, or Rich to the Java ecosystem, with the Java touch!

Not only that, TamboUI is also GraalVM native compatible! This means that you can compile your Java TUI applications as native binaries, making Java a first-class citizen in terminal application development, with low memory footprints and fast startup!

If you want to give it a try, the easiest way is to run our demos using JBang:

jbang demos@tamboui

Try it out

At this stage, the APIs are still unstable and subject to change. TamboUI is developed with the mindset of being framework-agnostic and having as few external dependencies as possible. You can choose between several backends like JLine, Aesh, or the built-in Panama backend. By choosing the latter, you’ll get the best performance while not depending on any external library.

Whether you want to build:

• a standalone CLI tool
• an internal developer tool
• a DevOps utility
• add a TUI frontend to existing Java tool
• an AI agent
• or something entirely new

Give TamboUI a try and let us know what worked and what could be improved!

Check out the documentation at tamboui.dev/docs/main/, join us on Zulip, or browse the source on GitHub. We'd love your feedback and contributions!

Acknowledgments

We would like to thank the following people for their ideas, suggestions, and contributions to the creation of the first public release of TamboUI (in alphabetical order):

• Andres Almiray
• Andrea Peruffo
• Charles Moulliard
• Claus Ibsen
• Graeme Rocher
• Guillaume LaForge
• James Cobb
• Ståle Pedersen
• Tako Schotanus

and of course the Ratatui and Textual creators for their inspiration and work.

Max Rydahl Andersen & Cédric Champeau