Help wanted! Port C# eventstore client to Java

EventStoreDB
#1

Hi all,

Anyone interested in helping to port the eventstore’s C# client api (https://github.com/EventStore/EventStore/tree/dev/src/EventStore.ClientAPI) to Java?

I know there are currently two Java clients available, but both have severe drawbacks:

The license is GPL, so not usable in any project with license other than GPL…

Scala/Akka stuff that is very different to use compared to the standard Java way (The C# client is far closer to what is needed in Java).

I’m thinking about porting the C# event store client API almost 1:1 to Java, but I have not the time to do it all on my own.

So, some Java volunteers here? (C# experience may help, but in first place good Java knowledge is required)

Cheers,

Michael

#2

- ESJ (https://github.com/valdasraps/esj)
The license is GPL, so not usable in any project with license other than GPL...

I would try talking to them. Quite likely they can make it BSD etc and
didn't realize the challenges you would face.

"- EventStoreJVM (https://github.com/EventStore/EventStore.JVM)
Scala/Akka stuff that is very different to use compared to the
standard Java way (The C# client is far closer to what is needed in
Java)."

You do know there are Java wrappers using a idiomatic java api?

#3

I created an issue with request to change the license for ESJ - If they don’t want to change it I’d like to start with an alternative soon. The Java wrapper is OK, but it’s just -a wrapper- and the code base including the libraries is very heavy. Beyond that the threading approach very likely will cause problems in a standard JEE container. I like a more lightweight approach. ESJ with a better license would be my first choice…

#4

I’ve been working on a new Java client using Netty underneath already. However, one caveat: the stuff I’m working on will be Java 8 only and use CompletableFuture. I guess if someone was that bothered they could port it to use ListenableFuture from Guava too. Luckily, since Java 7 support has already ended (or is about to depending on whether they mean the beginning or end of April 2015) this shouldn’t be an issue beyond the language level setting.

Though possible to implement the current protocol, it’s not ideal and would be best with breaking protocol changes that could come only in version 4 - I’m currently profiling switching from protocol buffers to cap’n proto which is a significant improvement in many different respects, especially GC impact.

Unfortunately there are some things in the current protocol which are a bit nasty at the moment when working on other platforms - primarily the utterly ludicrous byte ordering of UUIDs that .NET (“mental endian” as I call it) gives by default (and is sadly present in protobuf-net for backwards compatibility).

#5

Sounds interesting. Java 8 will be not really a problem. Did you already publish it somewhere?