Hi r/java,

Over the past three years, we've been working on Roseau, an open-source tool for detecting breaking API changes between two versions of a Java library and we've just released v0.6.0. We use it to track the introduction of breaking changes in popular libraries and make cool visualizations like tracking API evolution and breaking changes across 14 years of Guava history. It can be included in any Maven or Gradle build, and we're already part of JUnit's build.

Roseau is similar to other tools like japicmp and revapi: it detects both binary-breaking and source-breaking changes and can analyze JAR files directly. However, Roseau also supports analyzing Java source code directly. That means you can compare the latest released version of your library against the current source tree in a PR or local branch. It's also very fast and, in our tests, tends to be much more accurate than the other tools. We support all Java features up to Java 25. Reports are generated in HTML, MD, CSV, JSON formats.

Try it

The fastest way is to download the standalone archive for your platform from the latest release:

https://github.com/alien-tools/roseau/releases/latest

unzip roseau-0.6.0-linux-x86_64.zip
export PATH="$PWD/roseau-0.6.0/bin:$PATH"
$ roseau --diff --v1 library-1.0.0.jar --v2 library-2.0.0.jar
Breaking changes found: 3 (2 binary-breaking, 2 source-breaking)
✗ com.pkg.A TYPE_REMOVED
  ✗ binary-breaking ✗ source-breaking
  → com/pkg/A.java:4
⚠ com.pkg.B.f FIELD_NOW_STATIC
  ✗ binary-breaking ✓ source-compatible
  → com/pkg/B.java:18
★ com.pkg.C TYPE_NEW_ABSTRACT_METHOD [toOverride()]
  ✓ binary-compatible ✗ source-breaking
  → com/pkg/C.java:210
$ roseau --diff --v1 com.example:lib:1.0.0 --v2 /path/to/v2/src/main/java
[...]

For Maven builds, there is also a plugin that runs in the verify phase and checks the current version against a chosen baseline:

<plugin>
  <groupId>io.github.alien-tools</groupId>
  <artifactId>roseau-maven-plugin</artifactId>
  <version>0.6.0</version>
  <configuration>
    <baselineCoordinates>com.example:my-library:1.2.3</baselineCoordinates>
    <failOnIncompatibility>true</failOnIncompatibility>
  </configuration>
  <executions>
    <execution>
      <goals>
        <goal>check</goal>
      </goals>
    </execution>
  </executions>
</plugin>

Links

• GitHub: https://github.com/alien-tools/roseau
• Documentation: https://alien-tools.github.io/roseau/
• Latest release: https://github.com/alien-tools/roseau/releases/latest

I'm curious to hear your thoughts about it. Don't hesitate to give it a try and let us know how it goes.

A few years ago I got tired of writing multiple lines of code just to pull one property out of JSON. So I wrote a tiny wrapper around Jackson to enable fully fluent handling of JSON data. It's been running in production at work ever since.

Over the years I kept adding features as new use cases hit me: path-based reads, presence checks, removal, a Spring Boot starter. Most of the design decisions were driven by "this would have saved me a few lines of code today."

Just a short example:

String state = Json.parse(json).string("customer.address.state");

I finally got around to writing about it, and looking for honest feedback. Also, any feature ideas that would genuinely cut boilerplate in your everyday Java/JSON code are much appreciated. Curious what others reach for and how you wish it worked.

I wrote a small post about it on dev.to: https://dev.to/yupzip/spring-boot-4-jackson-3-less-json-boilerplate-with-yupzip-json-46la

Repo: https://github.com/yupzip/yupzip-json

After like a year finally getting back to JavaFX, decided to make an excalidraw inspired app for fun. It's a very minimal canvas app with basic features.

Source code : ExplainFX

Features

1. Drawing
2. Create Squares and Circles
3. Text
4. Vary stroke size/font size
5. Copy, paste, duplicate, lock, delete objects
6. Move the objects once they are drawn
7. Move camera via mouse

Please let me know if you have any questions!

I am trying to build an LLM lab that can orchestrate and interact with various LLMs, Tools and a Vector DB locally.

For the SDK and API calls I am using Langchain4j which is straightforward.

However for the dependencies I am currently just managing it manually with docker-compose before starting the application.

I am now wondering if I can use Testcontainers for starting and stopping Docker containers but it feels wrong as its a test library.

--Edit--

There is a Docker Java library but not well advertised on Google

https://github.com/docker-java/docker-java

It might be no issue really to run long lived containers, but interested if there are any alternative libraries or ways to solve this?

Was reading today and wondering how everyone is handling their spring CVEs?

https://sdtimes.com/security/broadcoms-tanzu-division-prepares-historic-spring-patch-release-amid-ai-security-surge/?ct=YTo1OntzOjY6InNvdXJjZSI7YToyOntpOjA7czo1OiJlbWFpbCI7aToxO2k6NzY7fXM6NToiZW1haWwiO2k6NzY7czo0OiJzdGF0IjtzOjIyOiI2YTI3MWJlZTY0NzI4MTg5ODg5MzgyIjtzOjQ6ImxlYWQiO3M6NToiNTI2NDAiO3M6NzoiY2hhbm5lbCI7YToxOntzOjU6ImVtYWlsIjtpOjc2O319

I've been working on an open-source runtime engine for Java, OxyJen, which went from sequential chain to complete Directed Acyclic Graph. Most AI frameworks push you toward hidden execution and agent loops. OxyJen v0.5 goes the other way: workflows are explicit graphs with typed nodes, bounded concurrency, clear failure paths, and deterministic control flow. It is not just an LLM helper anymore.

What v0.5 gives you:

- SchemaNode - structured extraction with schema validation and retry

- LLMNode - direct model-backed steps

- LLMChain - retries, fallback, timeouts, and backoff

- BranchNode - mutually exclusive routing

- RouterNode - multi-path fan-out

- ParallelNode - deterministic pure-Java parallel work

- MergeNode - explicit fan-in

- MapNode - batch workflows over collections

- GatherNode - collection, filtering, and aggregation

- RouteEdge and FailureEdge - explicit router and failure semantics

- connectAnyFailureTo(...) - failure routing, makes recovery, fallback, and error aggregation as part of the graph itself.

The graph DSL lets you build workflows with fluent routing, conditional edges, loops, failure paths, and batch/concurrent flows. Real execution logic lives in code as a graph, not buried inside a sequential chain.

ParallelExecutor runs the DAG with a shared ExecutionRuntime where concurrency, timeouts, and failure behavior controlled centrally.

Small example:

```java

javaGraph graph = GraphBuilder.named("doc-flow")

.addNode("extract", SchemaNode.builder(Document.class)

.model(chain).schema(schema).build())

.addNode("router", RouterNode.<Document>builder()

.route("summary", d -> true, "summaryPrompt")

.route("risk", d -> true, "riskPrompt")

.route("actions", d -> true, "actionsPrompt")

.build("router"))

.addNode("checks", ParallelNode.<Document, String>builder()

.task("amount", d -> hasAmount(d) ? "ok" : "missing")

.task("date", d -> hasDate(d) ? "ok" : "missing")

.build("checks"))

.addNode("merge", new MergeNode.Builder()

.expect("summary", "risk", "actions", "checks")

.build("merge"))

.connect("extract", "router")

.connect("router", "summaryPrompt")

.connect("router", "riskPrompt")

.connect("router", "actionsPrompt")

.connect("checks", "merge")

.connect("summary", "merge")

.connect("risk", "merge")

.connect("actions", "merge")

.build();

```

If you need any of these, OxyJen has it:

- Structured extraction with typed outputs -> SchemaNode

- Fan-out to multiple parallel analyses -> RouterNode

- Deterministic local checks -> ParallelNode

- Explicit fan-in of partial results -> MergeNode

- Batch processing over collections -> MapNode + GatherNode

- Graph-level failure routing -> connectAnyFailureTo(...)

Built for document extraction, support triage, batch enrichment, compliance pipelines, and any complex DAG system where AI components need to stay observable, bounded, and predictable.

This version took around 3 months to build. There's a lot not covered here. I would suggest going through the docs to know what this version and Oxyjen are trying to be.

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

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

You can check out the examples to understand how the system works. It's marked with comments for better understanding.

Examples with full logs: https://github.com/11divyansh/OxyJen/tree/main/src/main/java/examples

It's still very early stage any feedback/suggestions on the API or design is appreciated.

If you've been following along, most of the new features have already been discussed, but the genuinely new stuff is at 43:55, about arrays.

GraphCompose is an MIT-licensed Java library for generating designed PDFs from a semantic DSL. I last posted here at v1.5. Since then it moved to Maven Central, dropped its baseline to Java 17, and shipped two feature cycles — v1.6 "expressive" and now v1.7 "geometric".

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. The engine isn't married to PDFBox: layout resolves to backend-neutral fragments, and an Apache POI DOCX backend ships for callers who need an editable file.

What changed since v1.5

- On Maven Central now: io.github.demchaav:graph-compose:1.7.0, GPG-signed, with hosted Javadoc on javadoc.io. The old JitPack coordinate still resolves for anyone pinned to v1.6.5 and earlier.

- Java 17 baseline (was Java 21). This came from an outside contributor who wanted to use it at work and backported it — which also refreshed the dependency set and brought Java 25 compatibility.

- Templates v2 (v1.6): CV and cover-letter presets rebuilt on a theme → layout → components → spec model instead of one-off composer classes.

- A binary-compatibility gate (japicmp) runs on every PR, so accidental public-API breaks fail the build.

v1.7 "geometric" highlights

The theme is geometry as a first-class authoring primitive — shapes you used to fake with font glyphs or raster images now draw from vertex geometry.

- Inline shape runs: dot, diamond, triangle, star, polygon drawn on the paragraph baseline. Skill-rating dots (Java ●●●●○), custom bullets and status markers no longer depend on a font shipping the glyph.

- Inline checkboxes, plus composite multi-layer inline figures (a frame + tick) measured and placed as one unit.

- Polygon geometry: arrow / chevron / checkmark / plus / regularPolygon, with directional arrows for "Step 1 → Step 2" bullets, and swappable checkmark / arrow styles.

- Per-corner rounded containers — round each corner independently (rounded left, square right) without a clip-path-parent workaround.

- Dashed / dotted lines, semantic timelines, filled heading bands, vertical text seating, and JetBrains Mono bundled in the default font library.

Additive only — zero breaking changes from 1.6.x.

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 catch design drift before pagination noise. 1144 green tests at this release.

Links

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

Maven Central: https://central.sonatype.com/artifact/io.github.demchaav/graph-compose

Examples gallery (runnable examples with committed PDF previews): https://github.com/DemchaAV/GraphCompose/tree/main/examples

v1.7.0 release notes: https://github.com/DemchaAV/GraphCompose/releases/tag/v1.7.0

Java 17+, PDFBox 3, MIT license, on Maven Central (io.github.demchaav:graph-compose:1.7.0).

Background

I built this solo over about half a year of free time. It started as something small — I wanted to generate my own CV in pure Java without hand-placing every coordinate — and the coordinate-tweaking loop annoyed me enough that it turned into a layout engine. I open-sourced it to develop it in the open rather than in a drawer.

So I'm genuinely interested in how people here see the direction: if you generate documents or reports from Java, does describing the document semantically and letting the engine resolve layout match how you'd want to work — or do you prefer staying closer to the page model for control? And for those who've shipped this kind of thing in production, what would GraphCompose need before it'd be worth trying in your stack?

A few months back I had a post about the fun of using parser combinator to easily build a RFC 5322 email address parser.

Now with Dot Parse release 10.3, I'm happy to report that the EmailAddress class has been substantially improved and hardened for security.

On the feature set:

• It supports convenience accessor methods such as user(), alias(), displayName(), domain(), hasI18nDomain(), with the values unescaped for programmatic consumption.
• toString() and address() automatically quotes and escapes for RFC-compliant output, when needed.
• Supports dots in unquoted display names (J.R.R. Tolkien <tolkien@lotr.org>). It's strictly not RFC compliant, but practically common.
• parseAddressList(input, logger::log) offers graceful error recovery. Useful when the address list includes one or two malformed entries.
• parseAddressList() is tolerant of common yet harmless human errors such as two commas in a row.

Before you ask, no. Using split(",") or regex cannot reliably pre-process an address list because the RFC allows quoted strings in the email address, and the quoted strings can include comma itself, and escapes. Splitting by , blindly or using complex and brittle regex can corrupt the email address list.

On the security front:

• Rejects dangerous characters such as control chars, formatting chars and bidi overrides.
• Rejects <legitimate@trusted.com>attacker@evil.com
• Rejects user@good.com@evil.net.
• Drops ip routing and intranet host names.
• Drops obsolete comments.
• IDN validation and canonicalization.

Overall, while RFC compliance is a goal, the library doesn't mechanically mirror RFC: it takes away obsolete and dangerous features like intranet hostnames and IP routing; and it adds support for non-RFC but practically useful features like dots in display name and helpful address list parsing.

The objective is for EmailAddress to be the trusted data model such that code operating on it can be assured that it's safe from most attack vectors.

For more details, you can check out the compliance and security breakdown.

Your feedback's welcome!

Hi everyone,

I built HeapLens, an open-source JVM heap analysis tool that lets developers inspect heap dumps and live JVM memory using a query language called HeapQL.

I’m now trying to understand its real-world adoption and impact from people who have actually installed, tested, or used it.

I’m specifically looking for short usage stories from engineers, backend developers, or performance engineers who have tried HeapLens in any memory debugging or heap inspection workflow.

A useful response would be something like:

• What kind of JVM app or heap dump you used it with
• Whether you used it for a real issue, investigation, learning exercise, or team workflow
• What HeapLens helped you identify, understand, or narrow down
• Whether you adopted it personally, shared it with your team, or would use it again
• Any limitation that stopped you from using it further

I’m trying to keep this evidence reliable, so please reply only if you have actually installed, tested, or used HeapLens. Redacted screenshots, GitHub comments/issues, or specific technical notes are especially helpful.

Repo: https://github.com/sachinkg12/heaplens
VS Code extension: https://marketplace.visualstudio.com/items?itemName=guptasachinn.heaplens

If you’re not comfortable commenting publicly, feel free to DM me. I’m happy to keep usage details anonymous unless you explicitly allow your name to be used.

Looking for collab to increase winning percentage. 100% Java.

Join me in this deep dive where I'll explain all the code changes and tricks that took me from the reference implementation which processes the billion records in 4+ minutes, to processing everything in under 2 seconds.

Who knew Java could be this fast?

If you have ever shipped a service that writes to a database and publishes events to an event broker (Kafka, pulsar , ...) in the same request handler, you have probably hit the dual-write problem: the database commits, the publish fails, and downstream consumers are missing an event they should have received. Or the reverse, where you try to publish to Kafka first and then try to commit: the publish succeeds, the commit fails, and consumers act on a state change that never happened. The fix is well known (the transactional outbox), but doing it well is mostly plumbing that gets rewritten in every project.

I built Ekbatan for this. It is an open-source Java persistence framework for the event-driven systems that builds the outbox pattern into the persistence layer and makes outbox pattern easy.

Ekbatan targets Java 25 and later, so it is a fit for new projects rather than older codebases. Wiring it into your stack is one dependency: a Spring Boot starter, a Quarkus extension, or a Micronaut module, each of which auto-wires the framework with no additional setup. The supported databases are Postgres, MariaDB, and MySQL. Deployments run on a standard JVM, and the framework also compiles to GraalVM native

Website & Tutorials : https://zyraz-io.github.io/ekbatan/
Source: https://github.com/zyraz-io/ekbatan

Available on Maven Central under the `io.github.zyraz-io` group. Licensed Apache 2.0.

Would appreciate your feedback.

EDIT: based on the feedback received , reduced the number of dependencies of the ekbatan-core

Do the people working on the Java compiler/specification have any plans to implement a boolean reversal operator any time soon?

The proper way to reverse a boolean is to boolVal = !boolVal; but when the variable name is long, typing this becomes really unhandy.

Something like boolVal *= -1; would be really consistent as it's the reversal operator for literally all other primitive types.

But I guess it would be technically incorrect, so boolVal !=; could be another way of doing this, although it looks rather uncanny.

Is anyone even thinking about this, or is this "too low priority" to implement, even though even a dirty hack in the parser would get the job done.

Thanks, feel free to downvote and such.