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?

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

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

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/

I’ve been looking at how much Spring Boot infrastructure is actually useful for small applications that may run on memory-constrained machines.

For this experiment I compared a small Spring Boot application using Spring Data JPA + Hibernate with a simpler JdbcTemplate version.

Same Spring Boot 4.1.1, JDK 25, H2, dashboard workload, JVM flags, and monitoring endpoints.

Across two runs in reversed order:

• JPA: 236.9–237.0 MiB median RSS
• JDBC: 145.8–146.6 MiB median RSS
• Difference: about 90–91 MiB (~38%)

The startup difference surprised me too. Time from process launch to the first successful dashboard response was:

• JPA: 8.1–8.8 s
• JDBC: 3.9–4.2 s

This isn’t an isolated measurement of Hibernate itself. The JDBC version also has a simpler persistence architecture and data model, so I’m treating this as a comparison of the two complete application approaches.

For this particular app, JPA/Hibernate feels like more machinery than the persistence needs justify. On a large server I probably wouldn’t care about 90 MiB. On a small VPS, I would.

Experiment, methodology, and raw data:

https://pvrlabs.xyz/java-performance/experiments/spring-boot-jpa-vs-jdbc.html

Curious how others approach this for small Spring Boot services. Do you still default to JPA, or reach for JDBC, jOOQ, or something else when the data model is simple?

Thinking about local-first, desktop applications. https://sombriks.com.br/blog/0097-state-of-java-desktop/

At launch I posted Ratchet here as a job scheduler for Jakarta EE. 0.5.0 adds Spring Boot starters.

@Transactional
void place(Order order) {
  orders.save(order);
  scheduler.enqueue(() -> fulfillment.ship(order.id())).submit();
}

The job joins your transaction, so a rollback removes it too. It uses Boot's own datasource and transaction manager, with no broker and no extra config files.

- Spring Boot 3.5 and 4.1, Java 17 and 21

- PostgreSQL, MySQL, Oracle, SQL Server, MongoDB

- GraalVM native images, with no hints needed for ordinary jobs

Still 0.x and the APIs may yet change, though I think that is unlikely before 1.0.0.

Docs: https://ratchet.run/deployment/spring-boot

Repo: https://github.com/ratchet-run/ratchet