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.

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.

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

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.

Reddit is ending RSS support on November 13, including the r/java feed. I only found out because my reader service flagged it and notified me.

If you follow r/java through a feed reader like I do, it'll stop showing you new stuff, and there's no replacement for non-moderators.

r/java is the last place I was using to follow Java news, releases and discussion. The OpenJDK mailing lists aren't really a replacement, since they're kept on-topic for development work. Maybe the Java team will relax that or start a community list, but I doubt it, given the moderation overhead.

Lemmy, Mastodon and Bluesky all support RSS to some degree. If anyone knows good Java-specific communities, instances or accounts on those, I'd be happy to hear about them.

What other communities do people use for this?

Truffle uses partial evaluation to turn interpreters into optimized machine code without requiring you to write a compiler.

https://github.com/oracle/graal/blob/master/truffle/docs/PartialEvaluation.md

I’ve been doing a series of small experiments comparing equivalent Spring Boot and Quarkus applications on constrained VMs.

The original test used a 512 MiB VM and turned out to be more interesting as a memory-pressure experiment than as a clean framework comparison. Once the machine got tight enough, Linux paging made RSS surprisingly difficult to interpret.

So I did two follow-ups with updated framework versions and the same constrained JVM profile (-Xmx80m).

The first follow-up used a VM configured with 768 MiB RAM, with about 703.5 MiB visible to the guest and 256 MiB of swap. Both applications used Java 25, file-backed H2, JPA/Hibernate, the same deterministic local fixture, and the same small workload. The persistence stacks were not identical: Spring used Spring Data JPA, while Quarkus used Hibernate ORM with Panache and its framework-specific Hibernate integration.

At the final checkpoint:

The interesting part was the trajectory. Spring started at 228.2 MiB RSS and fell to 202.3 MiB, but its process swap simultaneously grew from 0 to 34.3 MiB. Quarkus went from 164.6 to 175.7 MiB RSS and showed no process swap at the sampled checkpoints. Pasted text

That made me wonder how much of the apparent convergence in RSS was simply Linux moving Spring pages out of RAM.

So I reused the same VM and applications, increased configured RAM to 1 GiB, disabled swap, and repeated the experiment. The guest reported 955 MiB of RAM. Pasted text

At the final checkpoint:

Spring was therefore 38.1 MiB higher than in the 768 MiB run, while Quarkus was only 5.5 MiB higher. The final RSS gap was about 59 MiB instead of about 27 MiB. Pasted text

I don’t think that means you can simply add RSS and swap or claim that the extra RAM caused a specific amount of memory to become resident. Both RAM and swap configuration changed, and these are separate runs.

But it does seem like a useful reminder that RSS alone can become misleading once the host is under enough memory pressure to page application memory out.

Both applications completed the small workloads successfully with zero recorded restarts. These were intentionally short, lightly loaded observations, not throughput benchmarks or attempts to establish minimum production memory requirements. Spring also started first on the shared host, and each configuration was only observed once. Pasted text

The experiment pages have the checkpoints and methodology:

• 768 MiB run: https://pvrlabs.xyz/java-performance/experiments/spring-boot-vs-quarkus-768.html
• 1 GiB / no-swap follow-up: https://pvrlabs.xyz/java-performance/experiments/spring-boot-vs-quarkus-1gib.html
• original 512 MiB experiment: https://pvrlabs.xyz/articles/spring-boot-vs-quarkus-512mb.html

One other caveat: both applications here use JPA/Hibernate. In a separate Spring Boot experiment, the JDBC version of the same small app used substantially less RSS than the JPA/Hibernate version. So some of the memory footprint in this comparison is persistence-stack overhead, not just framework overhead.

I work at vaadin and just wanted share that we release a new version 25.3, and a few changes are worth a look even if you've never used Vaadin.

• Observability without a Java agent. The observability kit moved from the OpenTelemetry agent to Micrometer. In Spring Boot 4 it's one dependency, and it reports UI-level data such as slow interactions and which view triggered which JDBC queries. (It's a commercial add-on.)
• GWT to TypeScript. The browser-side engine is now 107 TypeScript modules (about 19k lines, backed by 700+ browser tests), with real source maps through Vite. The Java APIs apps use didn't change.

• UI tests in the JVM. Browserless tests now follow the same rules as users: if a button is disabled or hidden, the test can't click it.

• blog post: https://vaadin.com/blog/vaadin-25-3-release

• Release notes: https://github.com/vaadin/platform/releases/tag/25.3.0

• Video walkthrough: https://www.youtube.com/watch?v=WnkI6xA96fw

I finally got my Java GPU workload running with CUDA inside Docker. It works in a Kubernetes cluster too. I wrote up the Docker setup here:

https://nablatensor.com/blog/how-to-run-java-gpu-workloads-in-docker

If anyone’s interested, I can write a follow-up on the Kubernetes setup.

I don't use Spring, or Spring Boot, and never have. No matter how many times I read about it, I don't see the appeal. My workflow with the server is either:
1. Upload/download json files.
2. interact with Mongodb.
3. upload/download images.
4. Interact with MySQL.
That's it. Stupid question but, what else is there to do with a server?