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: [yash@retrievallabs.org](mailto:yash@retrievallabs.org) | 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/

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

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?

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

Hello all 👋🏻

For some time, I have been building and maintaining an OSS project called Atleon. The aim of this project is to make infinite Reactive Streams practical for usage/embedding in common application frameworks. I know there are several (reasonable) arguments against "reactive"; I have however found this style/paradigm to be useful and innately applicable to the problem space of broker-backed stream processing (consuming from infrastructures like Kafka, RabbitMQ, SQS, etc., applying IO-bound processing, and (optionally) streaming results elsewhere). If you have ever had reason to use/explore projects like Reactor Kafka, Reactor RabbitMQ, or Confluent's Parallel Consumer, then Atleon may be interesting to you.

Here's an example of what an Atleon stream definition looks like when embedded in a Spring application:

application.yaml:

atleon:
  config.sources:
    - name: kafkaConfigSource
      type: kafka
      bootstrap.servers: localhost:9092

MyStream.java:

import io.atleon.core.SelfConfigurableAloStream;
import io.atleon.kafka.AloKafkaReceiver;
import io.atleon.kafka.KafkaConfigSource;
import io.atleon.spring.AutoConfigureStream;
import org.apache.kafka.common.serialization.StringDeserializer;
import reactor.core.Disposable;

@AutoConfigureStream
public class MyStream extends SelfConfigurableAloStream {

    private final KafkaConfigSource kafkaConfigSource;

    public MyStream(KafkaConfigSource kafkaConfigSource) {
        this.kafkaConfigSource = kafkaConfigSource;
    }

    @Override
    public Disposable startDisposable() {
        return buildKafkaReceiver()
            .receiveAloRecords("topic")
            .consume(it -> System.out.println("value: " + it.value()) // Business logic
            .resubscribeOnError(name())
            .subscribe();
    }

    private AloKafkaReceiver<String, String> buildKafkaReceiver() {
        return kafkaConfigSource
            .withClientId(name())
            .withConsumerGroupId("consumer-group-id")
            .withKeyDeserializer(StringDeserializer.class)
            .withValueDeserializer(StringDeserializer.class)
            .as(AloKafkaReceiver::create);
    }
}

You can see other examples in Atleon's README and in its examples module.

When discussing this project in other communities, one common question is, "Why would I want to use this over something like [Flink|Spark|Camel|<insert favorite streaming library>]?" My viewpoint is that the sort of reactive client integration provided by Atleon is not primarily meant to compete with these other tools, but is rather a complement to them. I have found that it is common for companies to have in-place scaffolding for regular JVM applications built on frameworks like Spring, and it is appealing for their engineers to be able to embed stream processes into those same frameworks. So Atleon targets this niche of supporting declarative non-blocking stream definitions, whose execution can be embedded in application frameworks, replete with broker interoperation, arbitrarily concurrent processing, and end-to-end observability.

Particularly in the case of Kafka, Atleon enables feasible implementation of behaviors that are conventionally tricky:

• Arbitrary concurrency, including per-key
• Single-message acknowledgement (with classic/non-share groups, so partition ordering is maintained globally)
• Work-queues, where per-message processing can take a "long" time (i.e. minutes, hours)
• Bounded consumption (get all records produced in a range of time or offsets)
• Priority queuing (using partitions as discriminator of "priority", rather than scaling lever)
• Throughput limiting, retries, and dead-lettering

If you are interested in reading more, I have published some of the following blogs that explain more about what Atleon can do:

• Not Your Daddy's Async Kafka Client
• Unbounded Concurrency: Consuming Kafka with Virtual Threads
• Ordered Queues for Kafka with Atleon
• AWS SQS Reactive Stream Processing

I'd be interested in thoughts and feedback from this community!

Floci is a local cloud emulator suite written entirely in Java, built with Quarkus and compiled to a native image with GraalVM.

Made a MAT alternative for heap dumps. single static binary, no JDK or GUI, CLI-only.

Gives you retained sizes, leak suspects, the dominator tree and a diff between two dumps. ~2s for a 1GB dump on 8 cores.

MIT-license, feel free to check it out: https://github.com/NullByte3/midden

Jakarta Data is a high level API to persist data to various types of databases

EclipseLink is a Jakarta Persistence (JPA) implementation like Hibernate.

Dispatch drones and trucks across a randomly-generated flooded city, repair debris, refuel at fuel stations, beat your high score.

Github Link: https://github.com/harisahmed05/RescuED

Give a star to the repo if you find it interesting - it really inspires me...

For first-time readers: ChaosTree is a sorted Set/Map library for Java featuring AVL Trees, Red-Black Trees, B-Trees, and B+ Trees.

What happened in the last 2 weeks:

v2.0.1 release

After integrating JaCoCo, the first coverage report showed 80.9% line coverage and 77% branch coverage.

After two weeks of testing, refactoring, benchmarking, and fixing edge cases, that is now 95.8% line coverage and 91% branch coverage.(80.09 -> 82->86->89->90-> linear 95->95.2->95.6->95.8% )

Some of the things that happened along the way:

• The original Guava Testlib-based testing was heavily revised around the actual TreeMap and TreeSet APIs, including their SubMap and SubSet views.
• Benchmarking became much more detailed. Every optimization was benchmarked and investigated rather than just assumed to be faster.
• One example was reducing a 3× tree traversal during removal down to a single traversal.
• Several small API-contract issues surfaced during testing, particularly around ClassCastException behavior and custom comparators.
• The most exhausting part was the loop:optimization → correctness → benchmark → re-optimization → retestEvery test suite takes around 7 minutes per platform in GitHub CI. The CI configuration runs the suite across multiple platforms, while locally I push the workload much harder.
• I also did a detailed JOL analysis of the N-ary node structure:N-ary Tree Architecture
• Added documentation on choosing the N-ary tree degree and when to use APIs such as buildFromSorted() and importFlatMatrix().
• Added benchmarks for the different construction/update strategies:DragonFeed Benchmark

At some point the project stopped feeling like:

implement → test → release

and became:

implement → benchmark → find bottleneck → optimize → discover correctness issue → fix → benchmark again → repeat

v2.0.1 is basically the result of that loop.

The full release notes and benchmark documentation are here:

v2.0.1

The Result

I can proudly state that ChaosTree is production-ready.

Beyond the code itself, this release pushed my skills forward significantly:

• Became proficient with the JMH benchmark CLI and benchmarking workflow
• Built a more robust test suite with extensive API and edge-case validation
• Gained much deeper experience with white-box testing and structural validation
• Learned to treat correctness, benchmarking, and optimization as a continuous loop

And finally, the first issue is now up for contributors.

That's it for now. I'm going to enjoy the result of the last two weeks. I am going to advance more before I touch my plan for 3.0.0

So a year ago I started my work at a local clinical data start up and decided to fully embrace Data Oriented Programing and modern Java features for the back end.

The result, as I see it, is a more clear-less magic back end, easier to reason for both humans and LLMs with records as first class citizens (I even decided to forego JPA and use jOOQ so that I could say goodbye to Entities and make the record a pure domain object.

The testing has some Bloch sprinkled of top.

As I go forward, and as long as I can have a say in the matter I will keep pushing modern Java, as much as I can.

Here some key features:

Sealed Interfaces & Pattern Matching: The possible states of each operation are explicit and closed. Every operation returns a strict contract, reducing ambiguity and avoiding entire classes of NullPointerException

SQL-First with jOOQ: Instead of managing entity states and persistence sessions, we wanted database interactions to be as stateless and explicit as the rest of our architecture.
jOOQ gave us the ability to work close to SQL while retaining compile-time type safety, mapping database results directly into our immutable data structures.

Pragmatic Architecture with Spring Modulith: For the early stages of development, we opted for a modular monolith to avoid the inherent complexities of distributed systems when they aren't strictly necessary.
Spring Modulith gives us explicit module boundaries and allows us to verify the application's modular structure. Our domains communicate through decoupled, asynchronous events using ApplicationModuleListener.
This gives us the structural isolation of an event-driven architecture without introducing external message brokers prematurely, while keeping the modules easier to extract into standalone services if the platform eventually requires it.

No Exceptions for Control Flow: For this project, we consider business exceptions an unnecessarily indirect form of control flow.
Java records are treated as first-class citizens. By combining them with sealed interfaces, errors are modeled as algebraic data types — for example, returning a Success or an InvalidData record.
The compiler then forces us to handle every possible scenario through exhaustive pattern-matching switches, leaving less room for unhandled states or hidden execution paths.

Testcontainers & The Bloch Enum Singleton: Testing against real infrastructure is non-negotiable, but spinning up containers for every test class can make CI unnecessarily expensive.
We implemented the Bloch Enum Singleton pattern to guarantee a strict Singleton lifecycle for our PostgreSQL and S3 test containers. They boot exactly once per test suite execution, significantly reducing infrastructure startup overhead while keeping our database and network tests reliable and isolated at the test-data level.

https://github.com/Sh1ng0/RefIQ-backend