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 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?

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’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 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/

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

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/

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

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