RFC - pure Java client library interface

Hi All,

Currently there are two client APIs available for Event Store targeting the JVM. The first is a first-party API written in Scala and using Akka underneath (available here: https://github.com/EventStore/EventStore.JVM with an associated project here: https://github.com/EventStore/EventStore.Akka.Persistence).

The second is a third-party one developed by Stanislavas over at CERN (available here: https://github.com/valdasraps/esj), who also did a talk about it at our birthday bash in London last year.

“Because Reasons”, I personally have the need for a pure Java API (ruling our current first-party one out) which takes advantage of Java 8 features, and not be GPL-encumbered, and supports the same range of Event Store features as the .NET API, with the exception of explicit transactions.

The only dependencies I’m likely to take at this stage are SLF4J (for logging framework abstraction), Netty (for network communication and buffer utilities etc), and Protocol Buffers (necessary to read the Event Store protocol).

This work will be open source, and since it is a client API it will be liberally licensed. It has not yet been discussed whether it will be supported in addition to the Scala API, though once it’s as mature this is a possibility. I’ve made a start by drafting a public API interface, which is on this gist: https://gist.github.com/jen20/f061db530ae401765aeb

At this stage what I’m looking for is the following:

  • feedback from Java programmers about any changes they’d like to see (as comments on the gist or on this list)

  • feedback from those who might consider wrapping the API (for e.g. VertX integration, or for other JVM-targeted languages such as Clojure)

  • an idea of how many others may be interested in contributing to this project if is developed in the open rather than “big bang” open-sourced

Just to make it perfectly explicit, this is NOT intended to replace the Scala API and it’s quite conceivable it will never be supported commercially - if it is it will be in addition to the currently supported libraries.



Nice idea! Maybe we can align some parts as I started with a common event store Java interface that covers different implementations.
I joined your discussion: https://gist.github.com/jen20/f061db530ae401765aeb

Great - thanks for replying. I’ve replied to some of the comments on the gist, I’ll check out what you’re working on soon (about to get in plane).



As Github’s Gist has unfortunately no notifications: Just a short note that I added another comment to the discussion.

Thanks Michael.

I’ve opened up the repository for public access here: https://github.com/jen20/EventStore.Java - let’s move discussion to the issues on that repository. I’ve added the points you made on the gist already.


Hi James,

Good idea.

I’ll take a look at it at the weekend.



Quick note for anyone here that’s interested: the shape of the public API is now basically complete (subject to any feedback).

https://github.com/jen20/eventstore.java is the URL. Most connections will start with one of these forms:

SubscribableEventStoreConnection connection = EventStoreConnection.newClusterConnectionBuilder()


.discoverClusterViaDNS(“cluster.local”, 30778)

.withDefaultCredentials(new Credentials(“test.user”, new char[] { ‘p’, ‘a’, ‘s’, ‘s’}))



ReadableEventStoreConnection connection2 = EventStoreConnection.newSingleNodeBuilder()


.withConnectionAddress(new InetSocketAddress(“”, 2113))



And then go on to have the methods of each interface available to them.

If you have feedback on this design please open issues on the repository!