Java and .Net Bindings

[sirinath]

Can we have Java and .Net bindings?

[ChrisJamesC]

We have implemented java bindings for traildb here: https://github.com/Sqooba/traildb-java
Please note that some features are currently missing but issues and PRs are more than welcome since it's a work in progress.

[buremba]

There is also this library: https://github.com/aholyoke/traildb-java
@ChrisJamesC the tricky part is JNI, invoking java methods and getting the instance fields are actually quite expensive so the best way is to avoid the cost with proxy methods. Your library looks stable than the one that I sent but the performance is 25% worse for writes / 40% worse for reads.

[ChrisJamesC]

@buremba thanks for the feedback.
When we started writing our library, the one you published wasn't there yet. We already spent quite some time improving the performance of our library, but it's still slower on some aspects indeed. To be clear, our goal with these bindings as never been to be as efficient as the C library, it's been to be able to use traildb in our Java and Scala products.
Our next steps on this front are to benchmark and see where/how we can improve.
I also think that for the community around traildb we should try to have one solution for java instead of two, so we'll contact @aholyoke and see how we can proceed.

[aholyoke]

@ChrisJamesC well this is unfortunate. I definitely agree these projects should be merged somehow. I tried googling for java bindings when I started my project but couldn't find Sqooba's. I actually work for AdRoll so I plan to continue to support my java bindings for a while (Or Sqooba's if we decide to proceed with those).

Browsing the Sqooba source code I see a few issues that you will run into:

1. In some places instance and method ID's are not cached (This is an easy fix and will speed up your library considerably)

2. As buremba pointed out, a new TrailDBEvent object is allocated for each call to tdb_cursor_next. This slows things down considerably for large tdbs.

3. The pointer to the cursor buffer is stored on TrailDBEvent which erroneously implies that it can be reused after resetting the cursor. For example if you did something like this:

TrailDBEvent e1 = trail.next();
// Somehow set the cursor to a new trail (Not sure how to do this)
TrailDBEvent e2 = trail.next();

You would find that e1 contains the timestamp for the first event and the items from the second event 😬. 2 and 3 were actually a major issue for me and caused me to basically rewrite the entire project.

Anyway, not sure how you want to proceed. I could certainly use help making my bindings more Java idiomatic and supporting Scala.

[buremba]

Thanks for the answer @aholyoke! I believe that build phase for aholyoke/traildb-java is too complex compared to Sqooba/traildb-java and Scala support in Sqooba/traildb-java is great so it would be win-win-win (Sqoobe-Adroll-Community) if you guys can merge the libraries. :)

[Nennya]

Regarding issues mentioned by @aholyoke :

1. Yes this is mainly due to the remaining ByteBuffer which have to be replaced by simple long.
2. Indeed this slows a lot but that was the only way we found to make the TrailDBIterator behaves as close as possible to a Java Iterator. The goal since the beginning was to be able to do this:

TrailDBIterator trail = db.trail(0);

for(TrailDBEvent event : trail) {
    System.out.println(event);
}

But yeah we then lose speed because of the extra object TrailDBEvent and the fact we create it at each next call.

3. Indeed this is a big problem.

So I think the only somehow good compromise we can have if we want to keep an Iterator is to have something like this:

1. Instead of creating multiple TrailDBEvent, just create one and change its content at each next call.
2. If we not only want to access the TrailDBEvent content while iterating but also store it, provide an extra method which creates a copy of the current event.

Otherwise keep @aholyoke TrailDBTrail if we don't want an iterator.