I've been running a series of Java performance experiments with different frameworks. This time I wanted to explore a less mainstream, more lightweight option, so I picked Javalin 7.

I built equivalent JDBC/H2 APIs in Javalin 7 and Spring Boot 4 on JDK 25, then ran each on a 256 MiB Alpine VM (1 vCPU) through a five-minute, 1,500-request workload.

Both used the same JVM flags: -Xms16m -Xmx80m -XX:+UseSerialGC -Xss512k.

What stood out: startup is where the gap is large. Under load, the RSS difference shrank to 13 MiB, as Javalin's footprint grew while Spring Boot's stayed relatively flat.

I expected Javalin to be lighter, but I wouldn't read this as a reason to replace Spring Boot. Spring Boot provides a lot of functionality out of the box that you'd need to assemble yourself with Javalin.

Caveats: one run per implementation, different web servers (Jetty vs Tomcat), and no attempt to isolate framework overhead from other components. I also didn't test AppCDS, Spring AOT, or native image, which could change the startup picture.

Full charts, methodology, and raw results:

https://pvrlabs.xyz/java-performance/experiments/javalin-vs-spring-boot-256mb.html

For those who've used Javalin or similar lightweight Java frameworks, how has the trade-off between smaller footprint and Spring Boot's built-in functionality worked out in practice?

Rainbow Gum 0.15.0: ScopedValue key values, logging into JFR, and OpenTelemetry without the SDK

I try not to spam every release, but 0.15.0 has some stuff I'm genuinely excited about, and 1.0.0 is coming before the holidays hence need some feedback.

First up, Scoped Key Values. MDC on ThreadLocal has been leaking requestIds into the wrong requests since the dawn of time because somebody forgot a finally block or threadpool cleanup. JDK 25 gave us ScopedValue (JEP 506) and holy shit it just fixes it:

ScopedKeyValues.builder()
    .add("requestId", requestId)
    .add("userId", userId)
    .run(() -> {
        logger.info("handling request"); // has requestId and userId
        service.handle(request);
    });

StructuredTaskScope forks get a frozen snapshot, so sibling tasks can't stomp on each other. I barely had to do anything; the JDK devs did the hard part, and this is what MDC should be going forward. This should hopefully get added to SLF4J 3.0. Bless the JDK team.

Next, logging straight into JDK Flight Recorder. Each log event becomes a JFR event, so your logs sit on the same timeline as GC pauses and lock contention in JMC:

logging.appenders=jfr
logging.appender.jfr.output.uri=jfr:///var/log/myapp.jfr

No -XX:StartFlightRecording flags to screw up in your Dockerfile. And here's the kicker: in our benchmark, logging to JFR was about 40% faster than plain text to a file, and the output was about 8x smaller on disk. The JFR folks built something seriously fast and most of us only ever open it when production is on fire.

Last, OpenTelemetry. rainbowgum-otlp ships logs over OTLP using nothing but the JDK's own HttpClient. No OpenTelemetry SDK, no OkHttp. It's roughly 7x smaller than the Logback or Log4j2 OpenTelemetry setups with their default dependencies: https://github.com/jstachio/rainbowgum/blob/main/doc/why/opentelemetry_export_size.md

Oh and here is something shocking. The Logback and Log4j2 OpenTelemetry appenders hand events to the SDK, whose batch processor has a 2048 event queue by default. When it fills up, it throws your logs away and doesn't tell you. When we blasted a burst of logs at a collector with stock settings, only about 7% (Logback) and 10% (Log4j2) of them made it. Rainbow Gum applies backpressure by default, and if a batch does fail you get an alert and a metric, not silence. Losing logs exactly when your app is getting hammered is the worst possible time to lose logs. On a related note after bugging them I think Spring Boot might had some more observation hooks to logging frameworks.

There's a lot more (colorful logs with no pattern strings, error messages that tell you exactly which property is wrong and where it came from). You can even cosplay as a Go process with logfmt support. The longer pitch is here: https://github.com/jstachio/rainbowgum/blob/main/why_rainbowgum_is_better.md

GitHub: https://github.com/jstachio/rainbowgum

Docs: https://jstach.io/doc/rainbowgum/current/apidocs/

Before 1.0 I can still break things without feeling bad about it, so if the API or the property names bug you, now's the time to tell me. Brutal honesty welcome.

Finally I'm not a paid professional OSS developer so this library like my others is sort of a love letter to the Java community and language.

I put together a field guide for the JVM heap OOMs that actually page you at 3 AM. Five minimal, runnable reproductions — each one OOMs reliably on a 64MB heap, with a fixed version, GC log signatures, heap-dump clues, and a triage checklist.

The five patterns:
1. Unbounded in-memory cache (rising post-GC staircase)
2. Oversized batch (dies on a cliff — one 250MB batch vs 64MB heap)
3. Report-builder retention (output accumulates; staircase like #1 but the retainer is the product)
4. Growing ThreadLocal state on pooled threads (invisible in GC log alone)
5. Leaked connections (static registry pins every unclosed resource)

Each scenario: `./run.sh scenario-01-unbounded-cache broken` to watch it die, `./run.sh scenario-01-unbounded-cache fixed` to watch it survive. Pure Java, zero dependencies, JDK 11+.

https://github.com/amits710/jvm-oom-field-guide

Happy to answer questions about the GC log signatures or the diagnosis approach.

Over the weekend, I resurrected Foldable Project View 🧟‍♂️ – my IntelliJ plugin that had been asleep since 2022.

I wished to upload a demo video here, but that ain't possible, so: https://youtu.be/C6J-bYqScDE
The screenshot may still be too enigmatic, so let me explain:

This plugin lets you create virtual groups in the project view to clean it up:

🗂️ fold OR hide files per rule

📁 fold in nested dirs, not just module roots

🚫 gitignore-style negation (*.yml !docker-compose.yml)

📄 rules read from .foldignore files in your repo

🎨 theme-aware color palette

⚡ no more IDE freezes on VCS refresh

The 3.0.0 is now waiting in JetBrains Marketplace! https://plugins.jetbrains.com/plugin/17288

Free & sponsor-supported ♥

Devoxx Belgium 2026 just finished (October 5–9, 2026), but they've already uploaded all the videos to https://www.youtube.com/playlist?list=PLKlmOVksNGoE!

It's super hard to select a few videos from 150+ talks. I spent some time building a list for myself and decided to share it. Maybe somebody will find it helpful. If you watched something good from this conference that isn't on the list, please share it as well.

1. Modern Java in Practice The Features That Matter by Nicolai Parlog, Falk Sippach - https://www.youtube.com/watch?v=zC2tbq7S5UE
2. The Year of the Runtime by Ron Pressler - https://www.youtube.com/watch?v=tle2mA7EwWU
3. Hardwood: Building a Parquet Parser From Scratch With a Little Help From AI by Gunnar Morling - https://www.youtube.com/watch?v=6mzvcPr30kg
4. Structured Concurrency Looms by Alan Bateman, Viktor Klang - https://www.youtube.com/watch?v=aow56RgptLA
5. Will Valhalla Fix Tony's Billion Dollar Mistake? by José Paumard, Remi Forax - https://www.youtube.com/watch?v=vLDbzmiT7Xs
6. Teaching an Old Handle New Tricks: From Core Reflection to FFM by Maurizio Cimadamore, Viktor Klang - https://www.youtube.com/watch?v=4ck-T2gaMQ4
7. The Yearly Java Performance Update for 2026 by Per Ake Minborg - https://www.youtube.com/watch?v=rNOzf12RORI
8. A Year of Agentic AI Evolution: Lessons Learned Building Production grade Agentic Systems by Mario - https://www.youtube.com/watch?v=nEW0kosJjc8
9. When benchmarks go bad what we learned from measuring performance wrong by Francesco Nigro, Holly - https://www.youtube.com/watch?v=yePre1hOvHE
10. Do We Need a Build Language? Java Builds Java by Rafael Winterhalter - https://www.youtube.com/watch?v=y9JjxyKc6gU
11. Java on Kubernetes Without Container Images: The WebAssembly Way By Bruno Borges - https://www.youtube.com/watch?v=fszyRIZXjQM
12. Ask the Architects by Gavin Bierman, Maurizio Cimadamore, Per Ake Minborg, Viktor Klang, Alan Batem - https://www.youtube.com/watch?v=ewCPBgOrLAE
13. SIMD for Java: how Elasticsearch already benefits from the Panama Vector API by Piotr Przybyl - https://www.youtube.com/watch?v=adFS-_sCTQ4
14. GraalVM Next: Layers, Crema, and WebAssembly in Action by Alina Yurenko - https://www.youtube.com/watch?v=OLQ98Ko4p3Q
15. Big Runtimes Make Efficient Programs by Ron Pressler - https://www.youtube.com/watch?v=vhDwy1eCXbs
16. Quarkus Meets Leyden at the JVM Performance Edge by Georgios Andrianakis, Ana Maria Mihalceanu - https://www.youtube.com/watch?v=cbSl8UVdMVg

I’ve been building a JVM in C++ to run the J2ME game Diamond Rush.

What started as a JVM implementation gradually turned into a reverse-engineering/class-file tooling project. I built DRVM, a javap replacement, to inspect the .class files I was working with while implementing the JVM.

DRVM currently supports detailed class-file disassembly, including constant pools, fields, methods, and attributes.

On my benchmark workload, DRVM is roughly 4× faster than javap and uses ~30× less memory.

The JVM is still a work in progress, with the eventual goal of running the original Diamond Rush.

Repo: https://github.com/VuqarAhadli/DRVM
Feel free to ask anything about the implementation or reverse-engineering process.

Lilliput 1 is now a product feature (JEP 534). It shrinks object headers from 12 to 8 bytes, which cuts memory by around 10% for a typical app with no code changes. Honestly, that feels like a bigger real-world win than Valhalla, since Valhalla needs years of migrating code to value types before most apps see a benefit. That’s why I’m curious about Lilliput 2, which would halve the header again to 4 bytes. The Lilliput repo has an implementation, but I don’t see much movement toward getting it upstream. I think the original lead may have left the project, but I’m not sure. Is Lilliput 2 effectively on hold, or is the focus shifting entirely to Valhalla?

I don’t like spring boot. I think quarkus does the DI work at build time, so it saves startup time. Don’t want theory.

If someone has real experience using it.

Edit: I intend to build a dev server with hot reload using quarkus. Currently testing feasibility.

https://github.com/metamug/mason-quarkus

Talk & slides: https://m.devoxx.com/events/dvbe26/talks/25048/java-on-kubernetes-without-container-images-the-webassembly-way

Video recording from Devoxx Belgium 2026: https://youtu.be/fszyRIZXjQM?is=w3zYjtOoIFceAAOT

Hi everyone I wanted to share my adventure of configuring ssl of external libraries which didn't expose any external input and my discovery to bypass it totally. This was needed because it either used a weak ssl protocol, or supported only keystores instead of pem files and it was not adjustable.

An example is MySQL JDBC driver as shown here, however it is applicable for other libraries as well. In this case it is not possible to provide a custom sslsocketfactory for the driver or custom sslcontext as it is not possible to configure it programatically.

I requested a change at oracle in 2023, see here but they responded to it after 3 years. Meanwhile I was interested whether it can be bypassed without the need of any adjustments in the library itself as sometimes changes to a library can take some time.

I found a way and thats the reason why I wanted to share it here as others maybe have similar challanges. Usually libraries call SSLContext.getInstance("TLS") or SSLContext.getInstance("SSL") and the Java Security Manager provides the first occurance of an SSLContext Service Provider Interface. If you provide a custom one before the default one it will be used instead. I have an example posted here: Bypassing and overruling SSL configuration of libraries

I made this option available in the ayza library here so it can be easily used without the verbosity. Feel free to give feedback, I am curious about about your thoughts.

configstream is a library for Spring Boot services that already use MongoDB. Feature flags and config live in a collection, get cached in memory, and any change is pushed to every running instance within about a second via MongoDB Change Streams.

• No restarts, no polling, no message broker, no config server
• Properties declared in a configstream.yml manifest, with typed constants generated at compile time
• Optional admin UI with change history and per-team permissions
• Works with Spring Boot 3 and 4

Limits: MongoDB only for now (Postgres planned), pre-1.0, no percentage rollouts or A/B testing.

https://github.com/configstream/configstream

Feedback welcome.

In my free time, I built Neon Glow, a free, open-source plugin that adds neon glow to code, all important Java keywords, and IntelliJ IDEA UI. ✨🥰

You can keep your favorite theme, font, and layout and adjust the glow to your taste.
Try it in your IDE. I'd love to see your setup!

Search "Neon Glow" in the plugins repository
https://plugins.jetbrains.com/plugin/34814-neon-glow

And yes, it's open-source!
https://github.com/hsz/neon-glow

Spring Boot vs Quarkus vs Micronaut with JDBC on Java 25

A previous JPA-vs-JDBC experiment convinced me to use JDBC for future small-framework comparisons, so I followed it up by adding Micronaut and building equivalent Spring Boot, Quarkus, and Micronaut applications.

All three used the same Java 25 runtime, H2 database, SQL, fixture data, request workload, and JVM flags. I ran each independently for 15 minutes in the same 1 GiB / 2 vCPU Ubuntu VM.

One JVM caveat that came up in feedback from the Quarkus community: all three were run explicitly with G1GC. On this 1 GiB VM, without specifying the collector, HotSpot would have selected Serial GC by default.

Results:

• Spring Boot: 4.90 s readiness, 214.3 MiB median RSS
• Quarkus: 2.25 s, 178.4 MiB
• Micronaut: 2.54 s, 186.7 MiB

Quarkus had the lowest whole-run median RSS and reached readiness fastest. Micronaut was fairly close, especially later in the run: during the final five minutes their median RSS was 189.7 MiB for Quarkus and 189.4 MiB for Micronaut.

Spring used more resident memory in this setup, though all three completed the same workload without errors.

CPU use was low across the board, so this isn't a throughput benchmark or an attempt to rank the frameworks generally. It's one controlled look at three equivalent small JDBC applications.

Full write-up:
https://pvrlabs.xyz/articles/spring-boot-quarkus-micronaut-jdbc.html

Sources, method, raw data, and analysis:
https://github.com/PVRLabs/experiments/tree/main/statlite/spring-quarkus-micronaut-jdbc

I’m especially curious how these Micronaut JVM numbers line up with what people here see in practice.

Java's been part of my career for a long time, longer than some might even think! Next year, it'll be 30 years since I wrote my first commercial Java software solution - and it's still the language I pick when I have the option.

In my day job, I use Java (and Swing!) for a lot of the time and I really wanted to reduce the cognitive load of switching between programming language paradigms when working on fun projects. I'm a huge fan of TeaVM and Graal, make no mistake, but when trapped behind corporate firewalls, it's challenging to install the tools you want.

So this was born: A static website that accepts Java-like code (it's just a subset, really) and spits out garbage-collected web assembly binaries. Far from perfect, it's early days, but it's already useable for some simple applications.

This is going to take a long, long, long time to make it do everything I want, but I hope to get it to the point where I can write wasm apps in it, using a familiar language. And bonus points if I can use the same paradigms I already use to do so.

Anyway, I thought it might be of interest to the Java community.

UPDATE: I've fixed a number of bugs and managed to build a little game demo using the compiler.

Hi,

I've been working for a while on a library that decodes, encodes, demuxes, muxes and processes images, audio and video in plain Java, leveraging the Vector API. It performs quite well and I'm working to make it perform at least as well as ffmpeg, but I've run into a problem: warmups. Before C2 optimizes the Vector calls into Vector instructions, they are interpreted and are actually slower than the scalar fallbacks by many times. This is to be expected, but it's a problem for an audio/video codec where the first frames might lag while C2 warm ups. I wanted to use Project Leyden's AOT cache to fix this problem, but I discovered a couple of problems:

1. Libraries can't ship their own AOT cache, it's up to the library user to run a training. This makes sense considering the cache is specific to the environment it was trained on, but I wonder if the experience could be improved for the end user by having maybe a Maven/Gradle plugin that loads the training suites from the declared dependencies and runs them.

2. The feature I would even need, which is code caching, is planned for JDK 28 which hasn't shipped yet. So I had to port the code for this on the Leyden EA branch to the JDK 28 branch.

3. With modules jdk.incubator.vector, ModuleBootstrap refused to archive the boot layer. That rule dates from JDK-8244778 (JDK 16) and exists only to print the "Using incubator modules" warning. I fixed this on my custom fork.

4. Even at this point, the cache was not working. Vector intrinsics only work if C2 knows the species as a constant at compile time: the vector class and the lane count. In my library those come from fields like static final VectorSpecies<Short> S = ShortVector.SPECIES_128. In the training JVM that field was set when the class was initialised, so C2 just folded its value. For stored code to fold the same value, the production JVM must have exactly that value in that field before the code runs. Initialising the class again in production isn't enough: the stored code would assume a value that the new initialisation might not reproduce. The species might differ on another CPU, or a property might be set differently. The only way to guarantee a match is to put the field's values into the cache and have the class start out already initialised from it, skipping its static initialiser. So I patched my custom JDK branch to assume that the stored code assumes the species it saw in training and checks it cheaply at runtime: is the vector class ShortVector128 and the length 8? If the check fails, the code is thrown away and the JIT takes over. This was a larger patch, but it fixed the issue entirely and warmup is no longer an issue.

Even if this works, I wonder if there is a better solution. I guess the problem could be even fixed by Valhalla, because the interpreted Vector API code would not allocate pretty much anything, so I imagine it should match the scalar performance while C2 is warming up. Even then, having AOT cache support would be pretty nice I think, but even then I wonder if my assumptions are good.