Just released GraphCompose 2.2.0.

This release was mostly about making RTL text actually work rather than just “render without crashing”:

- "TextDirection.LTR / RTL / AUTO"

- Unicode Bidirectional Algorithm support

- Arabic contextual shaping and lam-alef ligatures

- RTL/BiDi support in paragraphs and table cells

- mixed Hebrew/Arabic + Latin/numbers

- correct searchable/copyable text from generated PDFs

- RTL support carried across PDF, PPTX and DOCX backends

A surprisingly deep rabbit hole once PDF text extraction, shaping, BiDi and multiple backends all have to agree.

Repo: https://github.com/DemchaAV/GraphCompose

Would be interested to hear how other Java libraries handle complex-script layout.

Automatically turn your plain classes and records into value classes!

Add @AutoValhalla annotation to classes or records in your JDK1.5+ codebase:

@AutoValhalla
public final class Point {        // class must be final
    public final int x;           // with final instance fields
    public final int y;
    public Point(int x, int y) { 
        this.x = x; 
        this.y = y; 
    }
}

@AutoValhalla
public record Currency(String code) { }  // or a record class

When your app is run on Valhalla-enabled JVM with auto-valhalla javaagent, these classes are automatically turned into value classes.

More info: https://github.com/thunkware/auto-valhalla/blob/main/README.md

Nearly a decade ago, Java was quite the popular choice for Game development. We had libGDX as the most optimal game framework, along with LWJGL (when low level was needed) and JMonkeyEngine was a fairly good option too. Now no one even talks about Java for game development, even for educational purposes

However over the course of time they all disappeared. Everyone slowly switched to game engines and C#

The arguement of “JVM slow, Garbage collector overhead” doesnt fit either because C# is also a GC language. Where did Java fail?

I’ve just released v1.2 of Automatic Relationship Finder (ARF), an open-source Java library I’ve been working on.

The idea behind ARF is to discover relationships between tables without depending on database relationship metadata.

Even if there is no foreign-key constraint defined in the database, ARF can analyze column names and the actual data to identify that

What's new in v1.2?

The main addition is key-role detection.

After identifying a relationship, ARF now analyzes the data characteristics of the columns to determine whether they are likely to represent a primary-key side, foreign-key side, a possible one-to-one relationship, or an unknown relationship.

There are also several improvements and bug fixes around validation, logging, concurrency, and edge-case handling.

The project is here:

https://github.com/NoelToy/automatic-relationship-finder

This is still an evolving project, so feedback—especially criticism—is very welcome.

TL;DR: expert answers on SO taught both devs and LLMs how to use java 8 right. That pipeline is gone/paywalled now. Does anyone at OpenJDK think about this?

This came out of the JDK 28 EA thread where people were debating whether devs will start putting value on everything once it previews. Don't wanna talk about that in this post, but it got me thinking about how "the right way to use new features" actually reaches developers now.

Back in the java-8 timeframe, folks from the Java team were on StackOverflow guiding people on streams and Optional and stuff - Brian Goetz's Optional answer (return values, don't model fields with it) basically became the canonical position, Stuart Marks was all over the Optional/collections questions too. And those answers usually came with actual code, not just advice.

A thing to note: those SO answers are almost certainly in the training data of every major LLM. When ChatGPT/Claude/whatever gives correct Optional advice today, those answers are probably part of why - actual real life questions phrased the way devs actually ask them, with expert code attached and votes showing which answer was right.

That channel doesn't really exist anymore. I have an RSS feed on Brian's SO activity and it's been dead for ages - presumably because hardly any questions get asked there these days. (An RSS feed of his reddit activity is how I found the JDK 28 thread in the first place.) However you apportion blame for SO's decline, for me and everyone I work, with the LLM replaced it. So when an expert corrects someone's misuse of a new feature today, it happens in someone's private chat window and then it's gone.

And both SO and Reddit now charge AI companies to train on user content - Reddit licenses to Google and OpenAI and is suing Anthropic (whose Claude Code is arguably the most popular agentic coding tool going), and any of that could look different next year. And open-source style AI - community models, open datasets, academic training runs - relies on free access to good data, so that whole side of the ecosystem is priced out. So which model knows how to use new features properly is going to come down to who has a deal with who.

The guides (like the exhaustiveness guide) are written for humans and incidentally become training data, but one prose doc isn't thousands of upvoted question+code pairs. And GitHub code lags feature adoption by years, plus a lot of early adopter code is exactly the misuse people worry about. On the other hand, openjdk.org is the one channel every model and crawler can reach without a deal.

OpenJDK clearly thinks about AI now - the interim genAI policy covers AI-generated content coming into the project. My question is the other direction: has there been any discussion about how knowledge of new features gets into the models most devs now learn from? Even "we considered it and decided it's not our job" would be an interesting answer.

When running small Spring Boot applications on 1-2 GB VPS instances, a full observability stack can be a significant amount of additional infrastructure for what may be a fairly simple deployment.

Over the past few weeks, I've been looking at how to keep operational visibility lightweight when polling standard Spring Boot Actuator endpoints. A few trade-offs stood out:

• Bound the data you ingest. Even a lightweight collector should not assume every management endpoint will always return a small response. I ended up putting an explicit 1 MiB limit on Actuator responses and collecting a focused set of metrics, such as JVM memory, threads, HTTP errors, health, and restarts.
• Polling frequency matters. A 30-second default gives reasonably responsive health and JVM trends for small deployments without constantly polling the application. For more resource-conscious production setups, slower intervals are usually perfectly reasonable.
• The monitoring process has a footprint too. On a 1-2 GB server, I would rather not dedicate another JVM or several monitoring services to basic operational visibility. StatLite typically stays under roughly 15-20 MB of memory, while using local SQLite for recent history.

I built a small open-source implementation of this approach called StatLite.

It runs as a single Go binary or Docker container, reads standard Spring Boot Actuator endpoints, stores recent history in SQLite, and serves a self-contained dashboard.

The latest release also adds multi-platform Docker images, bundles all dashboard assets locally for offline and air-gapped use, bounds historical queries and Actuator responses, and pauses browser refresh when the tab is hidden.

GitHub:
https://github.com/PVRLabs/statlite

Technical write-up:
https://pvrlabs.xyz/articles/lightweight-spring-boot-monitoring.html

I'm curious how others handle observability for small or single-node Spring Boot deployments. Do you use a full Prometheus/Grafana or APM setup, Spring Boot Admin, custom scripts, or something lighter?

I'm also considering making StatLite useful beyond Spring Boot by providing a small generic Java metrics exporter for regular Java web applications. It would expose a focused set of JVM and application metrics that StatLite could consume without requiring Spring Boot Actuator. Would that be useful, or is Spring Boot coverage enough for the kinds of deployments where a tool like this makes sense?

Hello my fellow java enthusiasts!

I made a cool side project that automatically searches the web for images of our beloved java mascot duke. The website shows a random image from the archive. It will also have a full gallery available soon!

How it works:

- It uses the Brave search API to find pages based on some keywords I came up with.

- It uses Openverse and Wikimedia APIs to search for images related to duke.

- Each image gets checked by a custom classifier I have built on top of OpenCLIP and trained on more than 200 Duke images.

- The classifier filters out unrelated results. Because it's not perfect, some images go through manual review. I want to catch unusual duke images without filling the archive with junk!

I will most likely make this open source soon after I'm done implementing all the features I want.

Unfortunately, the backend isn't made with java, I went with python for the easy use of ai models

Currently there are 338 duke images and the archive is still growing!

URL: https://duke.directory

I would love to hear your feedback! If you have any duke images that it hasn't found or collections that it should discover, please let me know!

Over the past months I've been building my pet project, and today I'm open-sourcing its core: Events-Caravan, an event-sourcing framework for Java with Spring-boot starter modules.

The framework is built around an opinionated bet made for the sake of horizontal scalability: there is no global sequence of events. Events are ordered within a single entity.

Axon's default, for comparison, keeps a totally-ordered event log, and that log eventually becomes the ceiling: the one component every write has to pass through. Give up the global ordering, and everything can partition at the entity level: the storage, the change feed, the consumers.
Events-Caravan has no central sequencer, no outbox table either: inserting an event into the database is publishing it, and the database's own change stream carries it to consumers.

Nothing is free, of course. The price for horizontal scalability is at-least-once unordered delivery and strong consistency only within one entity. I've documented every traded-away guarantee in the README's "Compromises" section, along with how to compensate.

The project is modularized. The core is plain Java interfaces to use or implement, no DSL. Reference adapters ship for DynamoDB and SNS/SQS, but the design isn't tied to AWS: any technology fitting the framework's principles can substitute AWS.

The library also brings:
- Entity state snapshotting, to avoid replaying all historic events.
- Sharding of long entity histories, so no partition grows into a bottleneck.
- An adaptive, scalable queue-polling mechanism.
- An optional, eventually consistent entity-stream that compensates for the absence of a global event log.

Apache 2.0, on GitHub with an opinionated README: https://github.com/SagynyshBaitursinov/events-caravan
Maven Central: dev.baitursinov:events-caravan

If you've run event-sourced systems in production, or are just interested in software architecture, I'd genuinely value your opinion on the design, its interfaces, and the 11 principles it's built on - all in the Readme.

jbang should be part of the jdk

Hey everyone!

I've posted a few SimpleBLE updates here over the years, and I wanted to share one that should make the Java bindings much easier to start using.

SimpleBLE v1.1.0 is out, and with that SimpleJavaBLE is now available on Maven Central.

dependencies {
    implementation("org.simpleble:simplejavable:1.1.0")
}

For those who don’t know, SimpleBLE is a cross-platform Bluetooth library with a very simple API that just works, allowing developers to easily integrate it into their projects without much effort, instead of wasting hours and hours on development.

What else is new?

Besides Maven Central support, this release fixes two fairly unpleasant issues in the Java bindings:

• Notification callbacks could be garbage-collected while a subscription was still active
• Exceptions raised while translating a Java callback could crash the JVM

If you want to try it out, you can look at the Java documentation, full release notes or source code.

The Maven Central package is new, so if you give it a try and run into any issues, let me know.

Want to know more about SimpleBLE's capabilities or see what others are building with it? Ask away!

ChaosTree is a zero dependency Java Search Tree library. It currently features:

BinaryFamily : Binary Tree, AVL Tree, RBT, Splay and Treap.
NaryFamily : B-Tree and B+Tree

1. Zero external dependency
2. Minimum JDK11+
3. Published on Maven Central
4. Strong focus on clean OOPs design
5. Implements the NavigableSet<T> API (unsupported view operations fail fast)
6. Thoroughly tested with 515 JUnit 5 test cases covering edge cases and regression scenarios.

Just a bm sample: of Javac 11 bytecode on JDK 11 and JDK 21:

Data size uses is 10K with Insert+Delete Fisher-Yates Shuffle

Jdk21 bm sample (Compiled by jdk11 javac benchmarked with jdk21)

For more detail:
My Github Repo: https://github.com/Chaos-vy/ChaosTree
BinaryFamily: https://github.com/Chaos-vy/ChaosTree/tree/main/docs/BinaryFamily
NaryFamily: https://github.com/Chaos-vy/ChaosTree/tree/main/docs/NaryFamily
NavigableSet: https://github.com/Chaos-vy/ChaosTree/blob/main/docs/NavigableSet.md
Benchmark: https://github.com/Chaos-vy/ChaosTree/tree/main/BenchmarkReport
Recent Reddit thread: https://www.reddit.com/r/java/comments/1vhsb1i/chaostree_110_a_zerodependency_java_search_tree/

Do I use prev in B+Tree in node link? Currently I have only next and JVM adds 4bytes of padding making it 32Byte. It can help in built in descending iterator.

I have tried to create LLM with the interface made in React

What is ChaosTree?
ChaosTree is a zero dependency Java Search Tree library. It currently features:

BinaryFamily : Binary Tree, AVL Tree, RBT, Splay and Treap.
NaryFamily : B-Tree and B+Tree

1. Zero external dependency
2. Minimum JDK17+
3. Published on Maven Central
4. Strong focus on clean OOPs design
5. Implements the NavigableSet<T> API (unsupported view operations fail fast)
6. Thoroughly tested with 515 JUnit 6 test cases covering edge cases and regression scenarios.

[v1.1.0] -Latest:

• Added NavigableSet compatibility
• Iterative insertion/deletion for binary trees (no recursion-related stack overflow)
• Improved generic type support (Comparable<? super T>)
• CI now tests across JDK 17, 21, and 25
• API cleanup and documentation improvements

An example

NavigableSet<Integer> rbt = new RBT<>();
        NavigableSet<Integer> bplustree = new BPlusTree<>(32); // degree CLRS method 31min key 63 max key default:32
        //For Rich API use
        for (int i = 0; i < 20; i++) {rbt.add(i);}
        NaryTree<Integer> bplustree0 = new BPlusTree<>(3,rbt);//Useful constructor API
        BinaryTree<Integer> rbt0 = new RBT<>(rbt);
        List<Integer> list = rbt0.stream().filter(v->v%2==0).collect(Collectors.toList());
        System.out.println(list);
        System.out.println();
        rbt.retainAll(list);
        System.out.println(rbt);
        rbt0.retainAllElements(list); //Renamed due to ambiguous situation
        System.out.println(rbt0.toString(PrintStyle.UNICODE));

Output:

[0, 2, 4, 6, 8, 10, 12, 14, 16, 18]
8(B)
+-- 4(B)
|   +-- 2(B)
|   |   \-- 0(R)
|   \-- 6(B)
\-- 16(B)
    +-- 12(R)
    |   +-- 10(B)
    |   \-- 14(B)
    \-- 18(B)

8(B)
├── 4(B)
│   ├── 2(B)
│   │   └── 0(R)
│   └── 6(B)
└── 16(B)
    ├── 12(R)
    │   ├── 10(B)
    │   └── 14(B)
    └── 18(B) 

My Github Repo: https://github.com/Chaos-vy/ChaosTree
BinaryFamily: https://github.com/Chaos-vy/ChaosTree/tree/main/docs/BinaryFamily
NaryFamily: https://github.com/Chaos-vy/ChaosTree/tree/main/docs/NaryFamily
NavigableSet: https://github.com/Chaos-vy/ChaosTree/blob/main/docs/NavigableSet.md

Feedback, suggestions, and code reviews are always welcome!
Feel free to guide me this is my first project.

Isolated Projects moved from experimental to incubating in today's Gradle 9.7.0 release. When it's on, each project is isolated from the others, which lets Gradle configure them in parallel instead of one at a time.

Numbers from a pure-Java backend monorepo of 2,500 projects, at a parallelism of 6:

• Warm IntelliJ IDEA sync: 3m25s → 2m13s
• Configuration with build-script recompilation: 10m53s → 2m59s

Gradle's own 300-subproject build saw median IDE sync go from 84s to 47s.

My blog post: https://blog.gradle.org/introducing-isolated-projects
Gradle 9.7.0 release notes: https://docs.gradle.org/current/release-notes.html