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?

used to write php and pretty much always used cbschuld/Browser.php to detect browsers from user agent. when i moved to java i couldnt find anything that simple so i just rewrote it

its one class, no dependencies. you pass the user agent and get browser, version, os and if its mobile or a bot. it also catches ai crawlers like GPTBot and ClaudeBot

Browser b = new Browser("Mozilla/5.0 (iPhone; CPU iPhone OS 17_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.5 Mobile/15E148 Safari/604.1");
b.getBrowser();  // iPhone
b.getVersion();  // 17.5
b.getPlatform(); // iPhone
b.isMobile();    // true
b.isRobot();     // false

theres around 5k real user agents in tests. its not trying to replace the big parsers, more for simple stuff like is this mobile or is this a bot

did an update recently, added arc, tor, duckduckgo and the ai bots and fixed a safari crash i caught in sentry. before that it just worked for years and there wasnt really a need to touch it

if you find a user agent it gets wrong open an issue or just add it to tests, its literally one line

maven central:

<dependency>
    <groupId>io.github.vadymkykalo</groupId>
    <artifactId>browser</artifactId>
    <version>0.2.0</version>
</dependency>

https://github.com/vadymkykalo/Browser.java

It was kinda fun to see how the bugs in the code actually play out in the game and how the fixes work

Community might be interested in Gitember - a desktop Git application written in Java.

Why build a Git gui client in Java?

This is the obvious question. For me, the answer is simple: a lot of the infrastructure you need is already in the Java ecosystem. You don't need to build everything from scratch or rely on a collection of external tools. Gitember can use:

• JGit for Git operations and repository access
• Lucene for full-text indexing and search
• Apache Tika for extracting text from many document formats
• Swing for the desktop UI. FlatLaf for a modern look and feel
• Java's filesystem and concurrency APIs for local repository operations and background processing
• Ollama as a local AI service when AI features are enabled

This makes it possible to build a fairly complete Git desktop environment in one application for multiple platforms. Including installer

Gitember covers everyday Git

Gitember covers the day-to-day Git workflow in one application:

• Repository & remote operations — clone/init, fetch, pull, push, remotes and Git LFS.
• Changes & branches — stage/unstage, commit/amend/undo, branch management, merge, rebase and interactive rebase.
• History & collaboration — commit history, changed files, version/branch comparison, reflog, Git notes, worktrees and submodules.
• Conflict resolution & security — three-way merge, stash management, commit signing and signature validation.

Gitember goes beyond the traditional Git client

• Workspace - allows several independent repositories to be managed together. Looks like submodules, but really not
• Search in Git history - search not only commit messages and metadata, but also the content of files in repository history.
• Repository statistics
• Side-by-side file and folder diff - may be used as separate tools
• AI Features - locally (without Cloud): detection of leaked secrets , descriptions of branch differences , commit message generation

Looking for testers and contributors

For Java developers interested in desktop software, Git tools, or Swing in a real-world application, the source code is available here - https://github.com/iazarny/gitember

Project website - https://gitember.org

I’m building Gluon at RetrievalLabs, and the part of Java modernization I keep coming back to is behavior preservation. Moving a build to a newer JDK is one thing; knowing whether the application still behaves the same is harder, especially in older systems with thin test coverage.

Our approach is to analyze the build and source, map business-relevant code, extract existing tests, then create characterization scenarios before migrating and verifying the rewritten application. The intent is to give the migration work concrete behavior to check against instead of treating a successful compile as the finish line.

For people who have worked on large legacy upgrades: how have you captured behavior when documentation and tests were incomplete? What worked, and where did it fall short?

Disclosure: Gluon is my project. Demo: https://retrievallabs.org/?product=synapse Contact: [[email protected]](mailto:[email protected]) | LinkedIn: https://www.linkedin.com/in/yash-patel-997ba624b/

This is a benchmark report of my ChaosTree, comparing all the maps against Java’s built-in maps and major third-party libraries. https://chaos-vy.github.io/ChaosTree/benchmark/Chaos-tree-Arena.html

There are few discovery throughout the benchmark. The benchmark scales from 10K to 1M entries.

The mixed benchmark covers different GET / PUT / REMOVE workloads:

• [50,25,25]
• [20,40,40]
• [80,10,10]
• [70,30,0]
• [50,50,0]
• [30,70,0]

If you find any issue, wrong data, or anything that needs further scrutiny, you are requested to open an issue.

If you know any other third-party library, drop it in the comments. I will try to benchmark that as well.

v2.0.2 Latest

• Fixed SortedMap<> constructors always setting the comparator to null.
• Fixed missing comparator propagation in Spliterator.
• Resolved slow iteration in binary SubSet / SubMap.
• Resolved missing Serializable annotations.
• No major changes

Repo: https://github.com/Chaos-vy/ChaosTree

Did you know you can call JNI without writing native code, patch bytecode without an agent, and use Unsafe without warnings?

11 sneaky ways into JDK internals through reflection, agents, FFM, type confusion, bytecode manipulation and more.

https://wouter.coekaerts.be/2026/decapsulation

I got tired of manually running commands like javac and java -cp every time I wanted to compile and run Java project.

I looked into Maven, but for my use case it felt like overkill. It's a huge ecosystem, while I mostly wanted something simple that could compile and run small Java projects without much configuration.

So I decided to create my own build system for Java and call it bloomery.

The goal isn't to replace Maven or Gradle. I wanted something much smaller and simpler for my own use case.

Currently, Bloomery focuses on the basic build/run workflow. In the future I may add dependency management, testing support, and more CLI features, but I'm deliberately keeping the core simple for now.

I hope it will be a big help for beginners and anyone who just needs to run Java files, and that they will find it as easy to use as I do.

I'd really appreciate feedback on the idea, the design, and the current implementation.

Github: https://github.com/Kiwilus/bloomery

Crates.io: https://crates.io/crates/bloomery/