I am super excited to finally write this announcement, because it allows me to put the spotlight on something we’ve been working hard over the last months. In a collective effort across the SDK team, we have started to roll out completely new SDKs which are faster, have simpler APIs, are future proof for upcoming server features and ease integration with framework ecosystems.

In addition to improving the Java SDK, we are also releasing a brand-new Scala SDK! It provides first-class support for everyone developing in Scala and makes integration into the Scala ecosystem much easier going forward.

Since all of this is pretty new, here be dragons. We appreciate all feedback and bug reports to make this the best SDK we have ever delivered.

Highlights

This post groups the highlights in two sections. One discusses the reworked API (across all SDKs), the other covers Java SDK specific enhancements.

Cross-SDK API Improvements

In an effort to improve the usability of the APIs, we’ve trimmed and refactored them quite heavily. The result is a very cohesive and regular API structure which should make it much easier to use both for newcomers and long Couchbase users.

For a quick comparison, here are some APIs from the 2.x Java SDK:

And then of course there are the timeout overloads:

Compare this to the new API:

Each method returns a Result and has an optional block at the end called Options. The old Document concept has been replaced with a simpler and more regular equivalent throughout the API. Optional properties like timeout, durability requirements or CAS have all been moved into the options parameter, leading to less overloads and only “one place to look”.

Later blog posts will dive deeper into the API rework, but for now let’s move on to the Java specific improvements.

Java Specific Improvements

The two most visible changes to the user are:

  • Java 8 as a baseline java version
  • Reactive APIs migrated from RxJava to Reactor

RxJava 1.x has served us well for many years (in fact, we’ve been one of the first adopters), but since it has been marked as end-of-life we had to look at alternatives. Together with the fact that reactive-streams emerged as the de-facto standard for integration between the different implementations, we had to decided between RxJava 2.x and reactor. While both were head-to-head on performance (mostly), after a long evaluation period we decided on reactor for the following reasons:

  • native java 8 api
  • slightly better performance in some of our key workloads
  • more community traction and growing constantly (also due to being integrated into spring core)

If your application platform is built in RxJava 2, fear not: since both support reactive-streams, you can just plug it in on top of our reactive APIs.

In the 2.x SDK, we had two APIs: a blocking API and an async API exposed through RxJava. In SDK 3 we’ve added a third API to give you even more control:

  • the blocking API remains
  • A reactive API exposes Mono and Flux responses from reactor
  • The async API exposes CompletableFutures, which can be used as building blocks if the highest level of performance is needed.

Last but not least one major enhancement for all reactive query APIs is the optional support for backpressure. If you need to read huge results and want to avoid putting them all onto the heap at once, you can now use the reactor backpressure mechanims which we are extending down to our internal async IO layer. We are preparing another in-depth blog post for this topic, so stay tuned!

Getting Started

If you want to give it a try, you can pick it up from our own pre-release maven repository:

 

Once the dependencies are resolved, you can connect to any cluster that is older than Couchbase Server 5.0. Then, open a bucket and use the collection of choice (collection support is already part of the API for an upcoming Couchbase Server release). For older releases just select the defaultCollection and it will just work:

Now you can write and read a document:

If you want to learn more, please take a look into our new documentation which is currently being written and fleshed out constantly. You can also look for code examples here.

Posted by Michael Nitschinger

Michael Nitschinger works as a Principal Software Engineer at Couchbase. He is the architect and maintainer of the Couchbase Java SDK, one of the first completely reactive database drivers on the JVM. He also authored and maintains the Couchbase Spark Connector. Michael is active in the open source community, a contributor to various other projects like RxJava and Netty.

Leave a reply