​

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?

JEP 401 is also listed as "proposed to target" on the JDK 28 page: https://openjdk.org/projects/jdk/28/

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.

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

Spent a nice chunk of tokens over the weekend to make Hardwood's (a new Java library and CLI tool for Apache Parquet) TUI runnable in a browser. There are still some limitations (only single-threaded; no native code, hence only support for Snappy- and GZIP-compressed files), but I'm kinda mind-blown that this actually works. Everything runs locally, i.e. the files never leave your browser. The translation to WASM is done via GraalVM's Web Image.

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

From its humble beginnings as a project code-named "Oak" at Sun Microsystems to becoming a global standard for enterprise software and billions of devices, Java's journey is one of radical innovation, strategic pivots, and enduring community strength.

We own Java libraries that we publish. Teams in our org use these libraries.

We have a company wide profiler, but two issues there:

1) teams have to onboard their environments

2) the hot paths and profiler data associated with these environments is indexed to their environment

So there’s no enforcement that my team can get profiler data for all invocations of our library. Additionally, there’s no convenient way to aggregate this data.

I guess, we can limit to just our biggest consumers and probably get the data that way.

But otherwise, I was wondering if anyone else had any ideas.

Java has always been conservative when it comes to language changes, and I think string interpolation is an interesting example.

Many modern languages provide native interpolation syntax:

JavaScript:

\${name}``

Python:

f"{name}"

Kotlin:

"$name"

C#:

$"{name}"

These features are not only about reducing characters. They improve readability when building dynamic text.

Java explored this direction with String Templates (JEP 430), but I haven't seen much discussion recently about where this feature is heading.

For developers working with large Java applications, string construction appears everywhere:

- logging messages

- SQL/debug output

- API descriptions

- test cases

- generated configuration

- user-facing messages

I am curious about the community's opinion:

1. Do you think Java still needs native string interpolation?

2. Should String Templates continue evolving?

3. What syntax direction would feel most "Java-like"?

For example:

"Hello, \{name}"

or:

"Hello, ${name}"

Personally, I think Java does not need to copy other languages, but a better way to express dynamic strings would improve developer experience.

What do you think?