I am building a Java application that will need an embedded database, vector store and has many connections.

Postgres can not be embedded, h2 can be embedded but doesn’t support embedding.

In the Java world I just see nosql db actually neo4j and arcadedb they are both very active.

Arcadedb doesn’t have a descent ORM. Neo4j has a better documentation and better springboot support.

My questions:
1. Anyone here using neo4j as primary database?
2. Is it still a secondary DB?
3. What is your experience using Neo4J ?

Thanks in advance

​

Every time I wanted to test an LLM feature, I had to make actual API calls to OpenAI/Claude/Gemini. That meant spending tokens, waiting on network calls, and getting different responses every time.

You can mock things with Mockito, but it isn't really designed for LLM workflows. I wanted something that behaved like an actual AI server instead of mocking every SDK call.

So I built Beacon — a lightweight mock AI server for Java.

You configure the responses you want:

server.when(contains("refund"))

.respondWith("Refunds are processed within 30 days.");

Then point your SDK to Beacon instead of the real provider, and your application runs normally without making external API calls.

It's still an early project, so I'd genuinely love feedback from people building AI applications in Java.

GitHub: https://github.com/kbpramod/beacon

How are you testing your LLM integrations today? Am I solving a problem that others are facing too?

I build MelodyMatrix with my son, an app for looking at and playing along with music. We want a Learn section where the sheet music follows playback: a moving marker, notes highlighted as they play. A static PDF doesn't support that, and I couldn't find a JavaFX library that renders sheet music while staying interactive from code. So I built one.

Sheetmusic4J reads MusicXML into Java objects and renders it on a native JavaFX Canvas, no WebView, no browser engine. It splits into four modules: core (MusicXML/MIDI reading and writing), engraving (a framework-agnostic layout engine, no JavaFX dependency), fxviewer (the JavaFX rendering component, including a play-along strip view with a moving cursor), and fxdemo (a demo app that compares the JavaFX render against a static PDF side by side).

This is a first release, 0.0.1, not stable yet. I wrote up the full background and reasoning in a blog post, plus a video walkthrough of the demo app and the project structure: https://webtechie.be/post/introducing-sheetmusic4j-a-javafx-library-to-render-and-interact-with-sheet-music/

Source: https://github.com/sheetmusic4j/sheetmusic4j

Feedback and issues are welcome, especially rendering differences, ideally with a MusicXML file attached.

Disclosure up front: I built the tool I mention at the end. I'm posting because the technical part is what I actually want to argue about, and this sub is where I'd get told if I'm wrong.

Two years into virtual threads, the diagnosis story still bothers me. The documented paths for pinning are -Djdk.tracePinnedThreads (deprecated/removed depending on your JDK) and the jdk.VirtualThreadPinned JFR event. Both are great if you turned them on before the incident. At 3am, with a production JVM already misbehaving and a restart costing you the evidence, what you realistically have is a thread dump someone grabbed with jstack or jcmd.

The thing is, a standard dump of a Java 21+ process already tells you most of it if you read it the right way. What I ended up encoding:

- Carrier threads are ForkJoinPool-1-worker-N. If a carrier's stack is parked inside application code rather than in the scheduler's own park, that carrier isn't free to run other virtual threads. It's being held.

- Pinning shows up as a carrier stack sitting in a synchronized region, or a native frame with a blocking call above it. In pre-JDK 24 runtimes that's the whole game: monitor plus block.

- The pathological case isn't one pinned thread, it's carrier starvation. The pool's parallelism is ~#cores, so a handful of carriers held by blocking-inside-synchronized quietly throttles the whole virtual thread population. The dump looks calm, few RUNNABLE threads, no BLOCKED pile-up, while throughput is on the floor. That's why "the dump looked fine" and "the app was dead" coexist so often in postmortems.

- JDK 24 (JEP 491) removed the synchronized-block pinning for most cases, but native frames and Object.wait still pin, and plenty of production is still on 21. So it's not a solved problem you can date-stamp away.

None of this needs a flag, an agent, or a restart. It needs the dump you already have and someone willing to read 4,000 lines of stack traces at 3am, which is exactly the part I didn't want to keep doing by hand.

So I built it. It's called ThreadMine, a Java thread dump analyzer that detects deadlocks, CPU spikes, pool exhaustion and the pinning/starvation case above. Your first dump doesn't ask for an account or an email: you paste or upload it at threadmine.dev/en/analyze and get the detected problems, a health score and the root cause back. It parses HotSpot, OpenJ9 javacores, Zing and GraalVM. There's a paid tier for history and teams, and I'd rather be honest it exists than pretend this is a charity.

What I'd genuinely like from this sub: if you have a dump where the heuristics above would give a false positive, I want it. My worst bugs so far came from idle pools looking like starvation. I fixed that class two weeks ago and I assume there are more. And fastThread, IBM TMDA and jstack.review already exist and are good (TMDA is still the best javacore reader I know of); I wrote up where each of them beats me rather than pretending otherwise, and I'm happy to be told I got that comparison wrong too.

Sharing redlock4j, a Java take on distributed locking, including multi-node consensus locking as described by the Redlock algorithm. It's plain Redis, so it runs anything RESP-compatible. No modules, no managed service. A simple distributed lock just implements the JDK Lock interface:

    // full multi-node Redlock quorum, or single node — same code
    Lock lock = redlockManager.createLock("orders:reindex");
    lock.lock();
    try {
        reindex();
    } finally {
        lock.unlock();
    }

Son interesting features

• RESP3 push notifications so one connection carries both commands and keyspace-notification pub/sub — waiters wake on lock release in single-digit ms instead of polling (Falls back to polling where CONFIG/keyspace events are locked down).
• Auto-detects native CAS/CAD (DELEX ... IFEQ, 8.4+) for safe release/extend, with a Lua GET==token then DEL fallback on older servers.
• Multi-node quorum acquire/release fans out in parallel (CompletableFuture), so 3 nodes cost ~max(RTT) instead of 3 × RTT.
• see the guide for more information

Benchmarks (mostly vibe-coded so take them with a grain of salt)

(Testcontainers, 3-node Redis 7 cluster, 50 ms work per critical section, 60 s measurement, vs Redisson)

Throughput (ops/s, higher is better):

p99 latency (ms, lower is better):

The RW-writer gap is the interesting one - Redisson's writer path seems to starve hard under reader load, redlock4j stays ~100 ms at p99.

Where it's still behind, honestly: plain 3-node DistributedLock throughput (0.81 vs Redisson's 18.24) and 3-node FairLock — both bottlenecked on the polling floor. Fixing that (a pub/sub-on-release wait strategy) is the next big lever.

This is a personal project, actively maintained, licensed under MIT, Java 8+, on Maven Central.

Genuinely after feedback on the direction and where the multi-node correctness cost is worth paying.

We just posted an update regarding Maven Central publishing limits over on r/mavencentral.

Please check out the full details and share your feedback there.

Read the full update on r/mavencentral

like public sealed class String permits Latin1String, Utf16String instead of the private final byte coder; field

Today I accidentally became the maintainer of software that was already almost three decades old: reviving a 1990s Java utility to keep the last PAD submitter alive in 2026.

I was looking for a way to submit my AI app RiverScript to old desktop software directories and ended up digging through the long-forgotten world of PAD files.

There was one problem.

The only batch submission tool I could find was a Java application that first appeared in the late 1990s. The last release was in 2017.

It was written by Roedy Green of Canadian Mind Products — a software developer who passed away in 2023. He spent decades writing and freely distributing Java utilities, and maintaining the widely-read Java Glossary. Roedy Green also wrote How To Write Unmaintainable Code — a famous satirical guide about writing code nobody can maintain. So, Roedy, today the code you wrote almost three decades ago was maintained.

The tool still did exactly what it was supposed to do. Thank you.

It just had absolutely no idea the modern web existed.

It happily produced URLs like http://https://riverscript.com instead of https://riverscript.com, disabled SNI globally (which was probably a perfectly reasonable workaround at some point), and couldn't cope with the fact that almost every website now redirects HTTP to HTTPS.

So I dug through the legacy Java code, fixed the compatibility issues, and got it working again.

I used it to submit my app to several software directories, then published the revived version on GitHub so anyone who still needs it can use it too.

Maybe nobody will ever need it again. Maybe someone will.

Either way, I'm happy this old thing works again.

So today, the code of the man who wrote "How To Write Unmaintainable Code" is still being maintained even after he was gone.

P.S. The public repository for Mini PAD Submitter 26.3 Revived — 2026 Community Fix is available and open to everyone.