/r/java is not for programming help or learning Java

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.

While inspecting Maven multi-module builds performance I've figured out the fundamental limitation: for any two modules depending on each other (moduleB depends on moduleA, in any scope), Maven will first execute all phases and goals of moduleA, and only then schedule the building of moduleB. Independent dependency branches can be executed in parallel, but directly/transitively dependent - only sequential.

In real projects running tests is usually the most time-consuming part, so this significantly limits possible parallelism.

To address this problem I made an extension providing a custom scheduler (in Maven it's called "builder") https://github.com/maven-turbo-reactor/maven-turbo-builder . When it is enabled, Maven schedules downstream dependencies right after the our module JAR is packaged, and then runs tests of our module and downstream module build in parallel (this way utilizing the multi-core CPUs much more):

The extension also does two things:

• reorder package and test phases (run tests after package, not before as default), so we can schedule downstream dependencies earlier
• prioritize building modules with the highest number of downstream dependencies - this way reducing the chance of unloaded Maven worker threads

It's easy to set up - add to .mvn/extensions

<extensions>
    <extension>
        <groupId>com.github.seregamorph</groupId>
        <artifactId>maven-turbo-builder</artifactId>
        <version>1.3</version>
    </extension>
</extensions>

And then define on the CLI or .mvn/maven.config (to make it default):

-bturbo
-T1C

In real projects the boost is approximately 35% in clock time, also this extension is complementary with build caching.

I used this extension for more than a year in various mission-critical projects and received positive feedback from other organizations, so I believe it's quite stable.

I've always wanted a Maven + Thrift setup where the compiler binary is just figured out by Maven without me needing to install the thrift compiler on every machine or container image. There are already other Maven plugins that do Thrift generation, but most of the ones I've stumbled upon require you to bring your own compiler binaries. A lot of the approach here was inspired by ascopes' protobuf-maven-plugin, which provides this kind of thing for protoc.

Essentially, it figures out the right Maven artifact for the compiler binary based on your OS/arch, grabs it from Maven Central and invokes it during generate-sources.

Here's the code: https://github.com/anirbanmu/thriftc-maven-plugin

It supports Thrift versions 0.25.0 (latest as of now) down to 0.21.0. On the OS/arch side, it supports Linux/macOS/Windows on x86_64, plus Linux/macOS on arm64.

Wanted to share it out in case anyone else finds it useful.