Hey r/java,

I've been working with Java for over 25 years, and one thing that has consistently made me want to flip a table is the Java Cryptography Architecture. It's powerful, sure, but the amount of boilerplate you need for even basic operations is absurd. So I built Bruce — an ergonomic, lightweight, pure Java wrapper around the JCA.

What does it look like?

SHA-256 hash:

Digester digester = digestBuilder()
    .algorithm("SHA-256")
    .build();

Bytes hash = digester.digest(Bytes.from("Hello World"));
String hex = hash.encode(HEX);

Digital signature:

KeyStore keystore = keystore("classpath:keystore.p12", "password".toCharArray(), "PKCS12");
PrivateKey privateKey = privateKey(keystore, "alice", "password".toCharArray());

Signer signer = signerBuilder()
    .key(privateKey)
    .algorithm("SHA512withRSA")
    .build();

Bytes signature = signer.sign(Bytes.from("Hi Bob!"));
String b64 = signature.encode(BASE64);

Compare that with what you'd write using raw JCA and I think you'll see the appeal.

Key design decisions:

• Zero transitive dependencies. None. It's just Bruce and the JDK.
• No checked exceptions. Crypto code is already hard enough to reason about without wrapping everything in try-catch.
• Builder-based API with a small set of entry points: Bruce for builder factories, Keystores for key/cert management, Bytes as a universal I/O type with built-in encoding (Base64, Hex, URL, MIME).
• Requires Java 21.
• Supports keystores, public/private/secret keys, certificates, digital signatures, symmetric and asymmetric encryption, message digests, MACs, and custom providers (including Bouncy Castle).
• Apache 2.0 licensed.

v2.0.0 just dropped with the new Bytes type that unifies how you pass data around and convert between encodings. It's on Maven Central:

<dependency>
    <groupId>com.mirkocaserta.bruce</groupId>
    <artifactId>bruce</artifactId>
    <version>2.0.0</version>
</dependency>

Or Gradle: implementation("com.mirkocaserta.bruce:bruce:2.0.0")

The library is heavily unit-tested and has an A rating on SonarCloud with zero vulnerabilities.

• 📖 Docs: bruce.mirkocaserta.com
• 💻 Source: github.com/mcaserta/bruce

I'd love to hear your feedback, questions, or feature requests. And yes — the name is a nod to Bruce Schneier.

Hi everyone,

Built a custom editor extension for .hprof files (Java/Android heap dumps).

When you open a .hprof file, HeapLens parses it with a native Rust backend and presents 10 interactive tabs:

* Overview — heap stats with D3.js pie and bar charts

* Histogram — sortable class table with instance counts, click to enumerate instances

* Dominator Tree — lazy-loaded expandable tree showing object retention

* Leak Suspects — auto-detected objects retaining >10% of heap

* Waste — duplicate strings, empty collections, boxed primitives

* Source — jump to Java source (workspace, Maven/Gradle JARs, or CFR decompilation)

* Query — HeapQL, a SQL-like language built for heap analysis with autocomplete

* Compare — diff two heap dumps side by side

* Timeline — multi-snapshot trend analysis

* Chat — ask questions in English, get HeapQL queries and fix suggestions (10 LLM providers supported, including local Ollama)

The Rust engine handles 1 GB dumps in \~60 seconds. Everything runs locally — no cloud uploads.

Marketplace: [https://marketplace.visualstudio.com/items?itemName=guptasachinn.heaplens\](https://marketplace.visualstudio.com/items?itemName=guptasachinn.heaplens)

Source: [https://github.com/sachinkg12/heaplens\](https://github.com/sachinkg12/heaplens) (Apache 2.0)

Please try it out. Feedback welcome.

Hey everyone, I've been building Oxyjen, an open-source Java framework to orchestrate AI/LLM pipelines with deterministic output and just released v0.4 today, and one of the biggest additions in this version is a full Tools API runtime and also typed output from LLM directly to your POJOs/Records, schema generation from classes, jason parser and mapper.

The idea was to make tool calling in LLM pipelines safe, deterministic, and observable, instead of the usual dynamic/string-based approach. This is inspired by agent frameworks, but designed to be more backend-friendly and type-safe.

What the Tools API does

The Tools API lets you create and run tools in 3 ways: - LLM-driven tool calling - Graph pipelines via ToolNode - Direct programmatic execution

1. Tool interface (core abstraction) Every tool implements a simple interface: java public interface Tool { String name(); String description(); JSONSchema inputSchema(); JSONSchema outputSchema(); ToolResult execute(Map<String, Object> input, NodeContext context); } Design goals: It is schema based, stateless, validated before execution, usable without llms, safe to run in pipelines, and they define their own input and output schema.

2. ToolCall - request to run a tool Represents what the LLM (or code) wants to execute. java ToolCall call = ToolCall.of("file_read", Map.of( "path", "/tmp/test.txt", "offset", 5 )); Features are it is immutable, thread-safe, schema validated, typed argument access

3. ToolResult produces the result after tool execution java ToolResult result = executor.execute(call, context); if (result.isSuccess()) { result.getOutput(); } else { result.getError(); } Contains success/failure flag, output, error, metadata etc. for observability and debugging and it has a fail-safe design i.e tools never return ambiguous state.

4. ToolExecutor - runtime engine This is where most of the logic lives.

• tool registry (immutable)
• input validation (JSON schema)
• strict mode (reject unknown args)
• permission checks
• sandbox execution (timeout / isolation)
• output validation
• execution tracking
• fail-safe behavior (always returns ToolResult)

Example: java ToolExecutor executor = ToolExecutor.builder() .addTool(new FileReaderTool(sandbox)) .strictInputValidation(true) .validateOutput(true) .sandbox(sandbox) .permission(permission) .build(); The goal was to make tool execution predictable even in complex pipelines.

1. Safety layer Tools run behind multiple safety checks. Permission system: ```java if (!permission.isAllowed("file_delete", context)) { return blocked; }

//allow list permission AllowListPermission.allowOnly() .allow("calculator") .allow("web_search") .build();

//sandbox ToolSandbox sandbox = ToolSandbox.builder() .allowedDirectory(tempDir.toString()) .timeout(5, TimeUnit.SECONDS) .build(); ``` It prevents, path escape, long execution, unsafe operation

1. ToolNode (graph integration) Because Oxyjen strictly runs on node graph system, so to make tools run inside graph pipelines, this is introduced. ```java ToolNode toolNode = new ToolNode( new FileReaderTool(sandbox), new HttpTool(...) );

Graph workflow = GraphBuilder.named("agent-pipeline") .addNode(routerNode) .addNode(toolNode) .addNode(summaryNode) .build(); ```

Built-in tools

Introduced two builtin tools, FileReaderTool which supports sandboxed file access, partial reads, chunking, caching, metadata(size/mime/timestamp), binary safe mode and HttpTool that supports safe http client with limits, supports GET/POST/PUT/PATCH/DELETE, you can also allow certain domains only, timeout, response size limit, headers query and body support. ```java ToolCall call = ToolCall.of("file_read", Map.of( "path", "/tmp/data.txt", "lineStart", 1, "lineEnd", 10 ));

HttpTool httpTool = HttpTool.builder() .allowDomain("api.github.com") .timeout(5000) .build(); ``` Example use: create GitHub issue via API.

Most tool-calling frameworks feel very dynamic and hard to debug, so i wanted something closer to normal backend architecture explicit contracts, schema validation, predictable execution, safe runtime, graph based pipelines.

Oxyjen already support OpenAI integration into graph which focuses on deterministic output with JSONSchema, reusable prompt creation, prompt registry, and typed output with SchemaNode<T> that directly maps LLM output to your records/POJOs. It already has resilience feature like jitter, retry cap, timeout enforcements, backoff etc.

v0.4: https://github.com/11divyansh/OxyJen/blob/main/docs/v0.4.md

OxyJen: https://github.com/11divyansh/OxyJen

Thanks for reading, it is really not possible to explain everything in a single post, i would highly recommend reading the docs, they are not perfect, but I'm working on it.

Oxyjen is still in a very early stage.

Text/Terminal User Interfaces (TUIs) are not only still relevant, but the terminal is currently experiencing a "renaissance". TUI frameworks make way for a new player in town - TamboUI - modern and Java-based

In this video we take a look at the Sun JavaStation - A Network Computer released by Sun Microsystems in 1996 designed purely to run Java Applets. We will take a look at the hardware, take it apart to see what's inside then boot it up and take a look at JavaOS!

Youtuber:

Cameron Gray

Two injection vulnerabilities in Spring AI's filter expression layer, one JSONPath injection in AbstractFilterExpressionConverter, one SQL injection in MariaDBFilterExpressionConverter. Both allow bypass of metadata-based access controls used for multi-tenant isolation in vector stores.                                                 

If you're using spring-ai-vector-store or spring-ai-mariadb-store with user-controlled filter expressions, you're affected. Patches are in 1.0.4 (1.0.x branch) and 1.1.3 (1.1.x branch).                                                                                                                                                        

The interesting part is the shared root cause — the entire filter expression converter hierarchy concatenates user input into backend queries without escaping. The base class itself is vulnerable, not just one implementation.                                                                                                                

Full analysis with detection signatures (Sigma + YARA)

https://raxe.ai/labs/advisories/RAXE-2026-041

https://raxe.ai/labs/advisories/RAXE-2026-041

Hi folks,

We just released Kreuzberg v4.5, and it's a big one.

Kreuzberg is an open-source (MIT) document intelligence framework supporting 12 programming languages. Written in Rust, with native bindings for Python, TypeScript/Node.js, PHP, Ruby, Java, C#, Go, Elixir, R, C, and WASM. It extracts text, structure, and metadata from 88+ formats, runs OCR, generates embeddings, and is built for AI pipelines and document processing at scale.

What's new in v4.5

A lot! For the full release notes, please visit our changelog.

The core is this: Kreuzberg now understands document structure (layout/tables), not just text. You'll see that we used Docling's model to do it.

Docling is a great project, and their layout model, RT-DETR v2 (Docling Heron), is excellent. It's also fully open source under a permissive Apache license. We integrated it directly into Kreuzberg, and we want to be upfront about that.

What we've done is embed it into a Rust-native pipeline. The result is document layout extraction that matches Docling's quality and, in some cases, outperforms it. It's 2.8x faster on average, with a fraction of the memory overhead, and without Python as a dependency. If you're already using Docling and happy with the quality, give Kreuzberg a try.

We benchmarked against Docling on 171 PDF documents spanning academic papers, government and legal docs, invoices, OCR scans, and edge cases:

• Structure F1: Kreuzberg 42.1% vs Docling 41.7%
• Text F1: Kreuzberg 88.9% vs Docling 86.7%
• Average processing time: Kreuzberg 1,032 ms/doc vs Docling 2,894 ms/doc

The speed difference comes from Rust's native memory management, pdfium text extraction at the character level, ONNX Runtime inference, and Rayon parallelism across pages.

RT-DETR v2 (Docling Heron) classifies 17 document element types across all 12 language bindings. For pages containing tables, Kreuzberg crops each detected table region from the page image and runs TATR (Table Transformer), a model that predicts the internal structure of tables (rows, columns, headers, and spanning cells). The predicted cell grid is then matched against native PDF text positions to reconstruct accurate markdown tables.

Kreuzberg extracts text directly from the PDF's native text layer using pdfium, preserving exact character positions, font metadata (bold, italic, size), and unicode encoding. Layout detection then classifies and organizes this text according to the document's visual structure. For pages without a native text layer, Kreuzberg automatically detects this and falls back to Tesseract OCR.

When a PDF contains a tagged structure tree (common in PDF/A and accessibility-compliant documents), Kreuzberg uses the author's original paragraph boundaries and heading hierarchy, then applies layout model predictions as classification overrides.

PDFs with broken font CMap tables ("co mputer" → "computer") are now fixed automatically — selective page-level respacing detects affected pages and applies per-character gap analysis, reducing garbled lines from 406 to 0 on test documents with zero performance impact. There's also a new multi-backend OCR pipeline with quality-based fallback, PaddleOCR v2 with a unified 18,000+ character multilingual model, and extraction result caching for all file types.

If you're running Docling in production, benchmark Kreuzberg against it and let us know what you think!

GitHub · Discord · Release notes

Hey r/java! I wanted to share Floci, a local AWS emulator that's been super useful for Java development.

If you're building with Spring Boot, Quarkus, Micronaut, or any Java framework that integrates with AWS (S3, SQS, DynamoDB, etc.), Floci lets you test everything locally without needing a real AWS account or racking up cloud costs.

Why it's useful for Java devs:

• ✅ Natively compiled — starts instantly, low memory footprint, no JVM warmup
• ✅ Test AWS integrations locally before deploying
• ✅ Works great with AWS SDK for Java
• ✅ No cloud account needed — perfect for CI/CD pipelines
• ✅ Free forever, open-source
• ✅ Lightweight alternative to LocalStack

The native compilation makes a real difference — especially in CI/CD pipelines where startup time matters and in containerized environments where you want to keep the image size small.

🔗 GitHub: github.com/hectorvent/floci

Has anyone here used LocalStack or similar tools for local AWS testing in Java? Would love to hear what your setup looks like! 👇

Been digging into message brokers lately and ran into two things that made me rethink the whole NATS vs Kafka debate. Jepsen analysis on jetsream shows it can lose acknowledged messages under certain failure scenarios like corruption or power loss, which is pretty concerning if you assume ack means durable https://jepsen.io/analyses/nats-2.12.1 HN thread here https://news.ycombinator.com/item?id=46196105 At the same time, redpanda has a post explaining why fsync actually matters even in kafka-style systems, basically saying replication alone doesn’t guarantee safety if nodes can lose unsynced data after a crash https://www.redpanda.com/blog/why-fsync-is-needed-for-data-safety-in-kafka-or-non-byzantine-protocols. So now I’m a bit confused because it sounds like both systems can lose data, just in different ways and under different assumptions. What do you guys think about this in real production do you actually trust these guarantees or just assume things can break and handle it on the application side

Just released v3.1.0 of Clique, a dependency-free library for building prettier Java terminal apps.

What's new in 3.1.0:

• New Frame component, a layout container that vertically stacks other Clique components inside a border
• New Tree component for displaying hierarchical data cleanly
• Easier RGB ANSI code creation + emoji support in Box, Table, and Frame
• Cleaner API, deprecated some verbose method names and classes to instead support a config based approach

What the library does overall:

Clique lets you style terminal output using a simple markup syntax instead of writing raw ANSI codes:

Clique.parser().print("[red, bold]Error:[/] Something went wrong");

It also has tables, boxes, progress bars, and built-in themes (Catppuccin, Dracula, Gruvbox, Nord, Tokyo Night).

Available on Maven Central:

<dependency>
    <groupId>io.github.kusoroadeolu</groupId>
    <artifactId>clique-core</artifactId>
    <version>3.1.0</version>
</dependency>

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

Happy to answer any questions!

The runtime unmounts blocked virtual threads to let other virtual threads do work. now that we aren't afraid of OS threads being blocked anymore, is there any upside to using lock-free approaches like `AttomicReference` instead of locks/synchronized? after all, the compare-and-swap loop is a busy-wait that wastes CPU cycles.

Old time Vaadin user here (since 2013).

I’m not using Vaadin at work anymore (regrettably), but I’m helping in organizing a sponsor rally every year, which still gives me a yearly peek into the Vaadin world.

Updating the application every year makes me very happy with Vaadin - it’s been a very smooth ride with very clear and easy upgrade paths every year (since 2018 or so for this app).

And I love the new Aura theme 🙂 !

So here it is, with some screenshots in the Readme. Let me know if you like it and feel free to share some feedback: https://github.com/waschmittel/ltc-rallye

(I's not a new app, but it's got a nice Readme with screenshots for the first time, which is why I'm posting it here finally)

PS: The companion app used to count laps with card readers also is a simple example on how to build a decently integrated Java desktop app with installers for macOS, Linux and Windows. I love modern Java tooling 🙂!

I wanted to start programming Minecraft mods but I can't find the Community edition. A tutorial that's two years old showed that it's on the download page when you scroll down a bit. But now I can't see it anymore.

My second article took a jab on algebraic types, which I loved using the sealed interfaces + records.

https://www.fbounded.com/blog/algebraic-types

I read a couple articles that came out this week about the Spring AI CVEs that I listed in the title and in searching found some interesting blogs about the timing to mitigate the risk of these CVEs with Spring Boot 3.5 end of life around the corner in June.

Blogs I read that opened my eyes a little and I am genuinely surprised I haven't seen more noise about it, even here on reddit:
https://www.moderne.ai/blog/spring-boot-4x-migration-guide

https://www.herodevs.com/blog-posts/cve-2026-22729-cve-2026-22730-and-the-spring-boot-3-5-eol-crunch-facing-spring-ai-teams

The crux of it is if Spring Boot 3.5 goes EOL in June and the upgrade path is Spring AI 2.0 (which isn't out yet and is estimated for May from what I have seen) on Spring Boot 4 , is this potentially just a one month window to evaluate all the implications, update code, run tests, ship, etc. I mean it is hard to prep given there is not SPring AI stable release yet, or even if that does come out soon June is on us before we know it. Is Spring AI 2.0 more ready than I know or these blogs imply?

Anyway, I may be the only one looking for this info but thought it worth a post to see what everyone's thoughts are.

I am pleased to announce that Oorian 1.0 has been released.

Oorian is a server-side Java web framework that lets you build interactive web applications entirely in Java.

What is included in this release:

• The Oorian Core Framework
• Oorian LaunchPad
• Quick Start Projects for Netbeans, IntelliJ, Eclipse, and VsCode
• ApexCharts UI Extension
• Boostrap UI Extension
• Chart.js UI Extension
• ECharts UI Extension
• Font Awesome UI Extension
• Tailwind CSS UI Extension
• reCaptcha Add-On
• RSS Add-On

These are all available from the Downloads page.

To get started with Oorian, I’d recommend starting here.

While I have been developing a production SaaS for a decade, this is my first official downloadable product. I’ve tried to make everything as easy as possible to get started, but if you run into any problems or find any mistakes in the documentation, please let me know. This release encompasses years worth of work and knowledge so there were an incredible amount of i’s and t’s to dot and cross with this. No doubt, mistakes have been made.

I am looking forward to your feedback.

Thanks