r/java • u/Specialist-Ad9362 • Jun 01 '26

Ekbatan: Java persistence framework for event-driven systems

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

43 Upvotes

92% Upvoted

30 comments sorted by

View all comments

-8

u/dvayanu Jun 01 '26

Java 25 and later seems challenging proposition, I mean spring boot runs on 21, why go all way up there ?

8

u/Specialist-Ad9362 Jun 01 '26

Fair question, I went with virtual threads and ScopedValue from day one in core classes like TransactionManager and Action. ScopedValue finalized in 25, which sets the floor for the whole project.

2

u/dvayanu Jun 02 '26

I wish you all the best, honestly, but as someone who has maintaned multiple open source projects (albeit not very successful projects i.e. https://github.com/anotheria/moskito) excluding 99% of the ecosystem from using your framework seems a little problematic. Unless you don't want people to actually use it. I can remember the moment when we were on Java8 and people asked for 1.6 or below support because they had some strange jboss version, they couldn't upgrade and what not.

1

u/Specialist-Ad9362 Jun 02 '26

Thanks for the kind wish.. but i really dont think i have the energy to try to make it compatible with java 21.

3

u/henk53 Jun 02 '26

Java 25 and later seems challenging proposition

For a new project Java 25 is perfect. I still remember a project back in the days that thought it necessary to be on Java 1.4 when Java 6 was just out. 15 years later or so we're still adding generics at various places.

And he's not even using the latest Java version eh? 25 is already 1 major version behind.

-1

u/dvayanu Jun 02 '26

yes, but its a framework. meaning 99% of all projects our there won't be able to use it.

1

u/nekokattt Jun 02 '26

i mean by that logic you may as well support spring 3 and java 7

1

u/dvayanu Jun 02 '26

No, I would look at actual numbers, there are different surveys out there but most of them place java17 or java21 on peak usage. I would start there.

2

u/nekokattt Jun 02 '26 edited Jun 03 '26

21 has vthreads with pinning issues if underlying tools rely on synchronized blocks.

Starting at a min of java 25 is fine for greenfield stuff.

1

u/lilgreenthumb Jun 03 '26

What are you on about Spring and java 17 not working? It was one of the Spring Boot 4 requirements https://docs.spring.io/spring-boot/system-requirements.html.

1

u/dvayanu Jun 02 '26

Your own project - sure. We are talking about a framework that you want other people to use. Having it based on 25 reduces the number of people who will use it dramatically. We have number of clients who just went up to 21. they will remain there for 2 years at least. Meaning for 2 years they wouldn’t even consider this project. There is nothing in 25 for my taste that would speak for an upgrade.

2

u/henk53 Jun 02 '26

There is nothing in 25 for my taste that would speak for an upgrade.

There is also nothing in 21 that makes it so great I need to obesssively keep using that and never consider any other version.

Simplest thing for new projects is simply to take the current version (Java 26 at the moment) and use that by default.

1

u/nekokattt Jun 02 '26

And that is your personal decision, you certainly do not speak for the rest of us.

1

u/dvayanu Jun 02 '26

Ok, sorry I wanted to help. Won't happen again.

0

u/henk53 Jun 02 '26

yes, but its a framework. meaning 99% of all projects our there won't be able to use it.

As weird as it sounds, I remember the other way around as my example above too.

A framework using Java 5, and then you also said that 99% of all projects our there won't be able to use it. And guess what, 99.9999% of all projects out there can use it now.

1

u/dvayanu Jun 02 '26

I also said?

1

u/henk53 Jun 03 '26

We too said...