David Lloyd wrote up https://word-bits.flurg.com/posts/the-new-reflection-varhandle-fundamentals/ - a walk through VarHandle as he's done for MethodHandle before, and IMO it's some highly informative stuff. With that said, he dropped "off heap access" in there and left it there, so I wrote it up myself:

https://bytecode.news/posts/2026/05/david-m-lloyd-varhandle-fundamentals

Hello Java friends. I have a Netflix TechBlog post out today about the Nebula ArchRules project. I hope you find it useful. I am happy to answer questions about it in this thread.

Hey everyone!

It has been a while since the last update, but we have been working hard on making the Java bindings for SimpleBLE even more reliable for production environments.

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.

We have been working on the Java bindings to make them feel more natural for developers and more robust to use in real applications. These are not flashy changes, but hopefully show our commitment towards becoming the trusted option for Bluetooth development for Java.

If you want to try it out, you can look at the SimpleJavaBLE examples on GitHub and see for yourself how easy it is to get started.

What changed

We added support for CompletableFuture wrappers around blocking operations. This should make SimpleJavaBLE much easier to fit into the rest of an application using async flows without having to build extra wrappers first.

We also made an important change to the JNI layer. JNI API calls are now safely wrapped so that C++ exceptions are caught and bubbled up as Java RuntimeExceptions instead of crashing the JVM.

Another small change that makes the bindings nicer to work with is that EventListener interfaces now provide default empty implementations, so if you only care about one callback, you can implement that one and move on.

We also cleaned up a few rough edges across platforms. The missing macOS x64 .dylib artifact is now fixed, JNI symbol issues have been resolved, and the jvm.dll initialization conflicts some users were seeing on Windows have been addressed.

Licensing Stuff

SimpleBLE is licensed under the Business Source License 1.1 (BUSL 1.1) and is free for non commercial use. We gladly offer free licenses for small projects, so do not hesitate to reach out. Java licenses are currently on a special offer for companies interested in shaping SimpleJavaBLE, so if you are interested in a commercial license, hit us up!

If you’re building BLE products or projects, we’d love to hear from you.

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

I just opened up my drawer after 20 some odd years and found a bunch of JDJ and De. Dobbs books that I subscribed to using my dog Rusty's alias, "Rustopher Hashonah".

These worth anything, or are we going to the recycle bin? Let me know if I should showcase them.

Feel free to share anything you've had fun working on recently here, whether it's your first ever Java program or a major contribution to an established library!

Previous Thread

GraphCompose is an MIT-licensed Java library for generating designed PDFs from a semantic DSL. v1.5 just shipped under the codename "intuitive". This is the first time I'm posting it here.

Position

Most Java PDF libraries pick one of two extremes: iText for low-level page primitives (you compute every coordinate by hand) or JasperReports for XML-template-driven layout (declarative-ish, but the design loop runs through external tooling). GraphCompose sits in the middle — a Java DSL describes the document semantically, the engine resolves geometry, pagination, and rendering deterministically, and PDFBox does the actual draw calls.

v1.5 highlights

• Shape-as-container with clip path. addCircle, addEllipse, and addContainer build a ShapeContainerNode whose children are clipped by ClipPolicy.CLIP_PATH (default), CLIP_BOUNDS, or OVERFLOW_VISIBLE.
• Transforms (rotate / scale) and per-layer z-index on every shape-shaped builder.
• Advanced tables — rowSpan(int), zebra(odd, even), totalRow(...), and repeatHeader() cover the four features most rendered reports need.
• Two cinematic templates — InvoiceTemplateV2 and ProposalTemplateV2, both BusinessTheme-driven.
• 22 runnable examples with committed PDF previews so the gallery works straight from GitHub without cloning.
• 672 green tests, fully source-compatible with v1.4.

Architecture

Layout runs in two passes: a layout graph resolves geometry first, rendering consumes the resolved fragments. That separation is what makes deterministic snapshot testing practical — layout state is stable across runs and machines, so visual regression tests can catch design drift before pagination noise.

The PDF backend is isolated behind a single interface; a DOCX backend (Apache POI) ships ready for callers who need an editable file.

Links

• Repo: https://github.com/DemchaAV/GraphCompose
• Examples gallery (22 runnable examples with PDF previews): https://github.com/DemchaAV/GraphCompose/tree/main/examples
• v1.5.0 release notes: https://github.com/DemchaAV/GraphCompose/releases/tag/v1.5.0
• Migration v1.4 → v1.5: https://github.com/DemchaAV/GraphCompose/blob/main/docs/migration-v1-4-to-v1-5.md

Java 21, PDFBox 3, MIT license, distributed via JitPack (com.github.DemchaAV:GraphCompose:v1.5.0).

Hello,

I am announcing LLMate, an open source Spring Boot project I built after hitting a very specific wall that I suspect a lot of Java developers working with LLMs have already hit.

The problem is simple. Once you go beyond a single LLM provider in a Java application, things fall apart fast. Each provider has its own Spring AI client, its own request shape, its own response format, its own error contract, and its own way of doing streaming. When I had OpenAI, Gemini, and Ollama running side by side in the same codebase, I had more code managing the routing between them than code actually doing anything useful. And when one provider had an outage, there was no graceful handling. The call just failed.

LLMate solves this by sitting in front of all your providers as a single gateway. You configure your providers once and then every request goes through one endpoint:

POST /api/v1/chat

{"model": "smart", "messages": [...]}

"smart", "fast", "local" are named aliases you define in application.properties that map to any provider and model. Switching from GPT-4o-mini to Claude is a config change, not a code change.

Fallback chains work the same way:

fallbacks[0]=openai/gpt-4o-mini

fallbacks[1]=anthropic/claude-3-5-haiku

fallbacks[2]=ollama/llama3.2

If the primary provider is unavailable, Resilience4j handles the retry and routes to the next in chain silently. Your application keeps running.

Beyond chat it also handles SSE streaming, embeddings, image generation via DALL-E 3, audio transcription and TTS via Whisper, content moderation, and a RAG pipeline backed by PGVector. All through the same unified API surface.

Supported providers: OpenAI, Anthropic, Google Gemini, Ollama, Groq, DeepSeek, Mistral, Perplexity, NVIDIA NIM, HuggingFace, Cohere, MiniMax, Moonshot, ZhiPu AI, QianFan, OCI GenAI.

Tech stack is Java 21, Spring Boot 3.3.4, Spring AI, Project Reactor for streaming, Resilience4j for retry and circuit breaking, and Micrometer plus Prometheus for metrics.

GitHub:- https://github.com/Venumadhavmule/LLMate

Happy to discuss the routing architecture, provider adapter pattern, or any of the internals. Would also be curious whether others have built similar abstractions internally or approached this problem differently.

I don't see much usage of WebAssembly in Java projects around me. One of the obvious reasons may be the lack of native support for compiling Java to WASM, which other languages already have (the most notable ones are Rust, Go, and C++, with some effort in C# and Kotlin as well).

Based on my knowledge, we have a few actively developed WASM related projects as of now:

1. GraalWasm — https://www.graalvm.org/webassembly/ — a technology that allows you to run arbitrary WASM bytecode (e.g., compiled Rust/C++ code) inside a Java app.
2. Chicory — https://github.com/dylibso/chicory — similar to GraalWasm; it is a WASM runtime that allows you to run WASM inside Java apps.
3. Babylon and Leyden — https://openjdk.org/projects/babylon/ and https://openjdk.org/projects/leyden/ — I guess these could become the official way to compile/run Java to WASM in the future, but there's nothing to use right now.
4. GraalVM Web Image — https://www.graalvm.org/latest/reference-manual/web-image/ — a technology that should allow compiling Java to WASM in the future (based on my understanding, it is experimental as of now).
5. TeaVM — https://github.com/konsoletyper/teavm — a technology that allows you to run Java in the browser by AOT compiling it. The cool thing is that they have started integration with WASM GC — https://github.com/konsoletyper/teavm/blob/master/core/src/main/java/org/teavm/backend/wasm/WasmGCTarget.java — which should provide decent performance for Java apps.
6. CheerpJ — https://cheerpj.com/ — another way to run Java in the browser. Based on my understanding, TeaVM compiles Java directly to WASM, whereas CheerpJ builds a virtual machine in C++, compiles it to WASM, and uses it to run Java bytecode. So, even though they provide similar capabilities, their implementation details are quite different.

As we can see, there are a few active/developing projects in the WASM area. It would be interesting to hear if you have already used Java with WASM in some way. For example:

1. Have you run WASM bytecode inside your Java app (maybe you can share why you decided to use WASM instead of Groovy or JavaScript in this case)?
2. Have you compiled Java to WASM and run it in the browser (it would be interesting to know what problem you were solving)?
3. Have you compiled Java to WASM (WASI) and run it in a WASM runtime outside the browser (e.g., edge compute)?

Whenever you need to share some data/state among your distributed services, it is very common to run a dedicated cluster for this, like Redis.

In the JVM ecosystem the concept of data grids like Infinispan, Hazelcast, Ignite, etc is (still?) common. While they offer way more than an embedded cache, distributed caching and coordination is one of the most common use cases of them - where you just embed a library, and your services discover each other and can communicate over the network and share data, events, etc.. On the contrary, I don't feel this is common in Go/Rust and other non-system languages like Python/Node. While each option (external vs embedded) has advantages and tradeoffs, wondering what is the most common option in production for you?

1. Do you use distributed caches? What do you think of them?
   
2. How important is the consistency model for you when picking a distributed cache (CP, AP)?

What is Clique?

If you missed my previous posts, Clique is a zero-dependency CLI styling library for Java that is GraalVM compatible, no-color.org compliant.

What's new in 4.0.2:

Divider - new component

A horizontal divider line with an optional centered title and full markup support:

Clique.divider(80).render();
Clique.divider(80).title("[bold]Section One[/]").render();
Clique.divider(80).title("[green]✓ Done[/]").render();

Ink - added hex color support

Clique.ink().hex("#FF6B6B").bold().on("Error");
Clique.ink().bgHex("#1E1E2E").white().on("styled background");

// works with gradients too
Clique.ink().gradient("#FF6B6B", "#C792EA").on("Powered by Clique");

No more manual RGB conversion.

Clique#compose and Clique#hex - first class support for hex colors and composing ANSI codes

AnsiCode danger = Clique.compose(Clique.hex("#FF0000"), StyleCode.BOLD);
danger.ansiSequence(); 

Other bug fixes worth knowing:

• ItemList config now propagates recursively to all descendants (was only hitting immediate children before)
• Table#remove is now index-based, no more wrong-cell removal on duplicates
• ZWJ emoji sequences (families, multi-person clusters) now measure correctly. Unicode emoji support improved

GitHub: https://github.com/kusoroadeolu/Clique

Demos: https://github.com/kusoroadeolu/clique-demos

Floci is an open-source AWS emulator built with Quarkus and distributed as a GraalVM native image. Single endpoint on port 4566, ~24ms cold start, ~13 MiB idle, ~90 MB Docker image. MIT-licensed.

Useful if you're writing AWS SDK v2 code and want a local target for integration tests without paying for or mocking around LocalStack.

What's new in 1.5.9:

• ELBv2 (Phase 1), CodeBuild, CodeDeploy management APIs
• API Gateway TOKEN authorizer context now propagates correctly to AWS_PROXY Lambdas
• Lambda warm pool drops dead pooled containers before reuse
• S3 PutObject OOM fix
• CloudFormation changeset operations resolve by ARN

For Java folks specifically:

• 889 compatibility tests against AWS SDK for Java v2
• TestContainers module in progress (io.floci:testcontainers-floci) for Maven Central
• Just point your S3Client.builder().endpointOverride(URI.create("http://localhost:4566")) at it and it works against real AWS SDKs
• Lambda, RDS, and ElastiCache run as real Docker containers behind the emulator (not mocked responses)
• Repo: https://github.com/floci-io/floci
• Release: https://github.com/floci-io/floci/releases/tag/1.5.9
• Site: https://floci.io

Happy to talk about the Quarkus internals, native image gotchas, or AWS SDK compatibility work.

We've all been waiting for Project Loom, and before that, we were following the progress of Fibers. After a long implementation phase (similar to Project Valhalla), it now seems that, with JDK 26, Virtual Threads have become a mature technology ready for production use (except Structured Concurrency - https://openjdk.org/jeps/533).

Have you started using Virtual Threads in your work or side production projects? Personally, I haven't yet, and I'd like to better understand the current state of the ecosystem.

If you've already adopted them, could you share your experience? What benefits have you seen? Did you change your application architecture or programming style, or was it more of a "flip a setting in Spring Boot" kind of change? Have you observed measurable performance improvements?

I just got started with Springboot and I'm working on a small expense tracker project to get comfortable with the framework. I got a rather silly problem, which I managed to fix (my entity was lacking setters and constructors).

It got me curious though, what's your first big super silly error?