What's new in the Couchbase Java SDK 1.2

For all users of our Java SDK, we prepared some nice additions for you. This post covers them in detail and shows how you can get more productive

Note that this blog post assumes you are running the 1.2.1 release, because there have been some slight changes between 1.2.0 and 1.2.1 that affect for example the listener support and metrics collection.

Maven Central Distribution

From the 1.2.0 release forward, the Java SDK is distributed directly from Maven Central. This means that you don't need to include the Couchbase repository anymore. The following maven code is enough to get started (note that the groupId has changed):

Now since 1.2.0, there is a new way to deal with responses - adding listeners. The idea is to supply a callback to the future which will be executed once the operation is done. A simple example is shown here:

Note that the `.get()` method on the future will not block anymore because the result is already computed. Whatever you put in the callback method will be executed asynchronously on the thread pool. To see how flexible that approach is, let's rewrite the example from above waiting until the 100 futures are done.

Here we are using a CountDownLatch which waits on the current thread as long as it has been counted down a hundred times. Exactly what we need in our situation, but the code is much easier to read. More importantly, its much more flexible because other things like firing off a new request, querying a web service or calculating a result can be done.

It is also possible to override the default `ExecutorService` implementation with a custom one. This may be needed if the default behavior (Basically a upper-bounded cachedThreadPool) does not suite your needs. Also, you should use this approach if you create a bunch of `CouchbaseClient` instances so you can share the same service across all of them.

Enhanced Profiling Capabilities

Getting insight into a running application is always difficult, so we set out to make it easier for you. We incorporated a library called metrics that profiles, depending on the configuration level chosen.

If you look at the `MetricType` enumeration you can see that there are three types of values you can choose from: OFF (which keeps metric collection off), PERFORMANCE (which only collects performance-relevant metrics) and DEBUG (which collects all kinds of metrics, including the performance ones). While the metrics library is quite efficient, keep in mind that metric collection takes some resources away from your application.

By default, the metric information will be printed out on the console every 30 seconds. You can run the following test code from your IDE and see how it looks:

I won't go into detail of all these metrics in this blog post, please refer to the documentation for a more complete picture. One more thing I want to show you is that the metrics library is also able to expose these metrics through JMX. All you need to do is set a system property that changes the output mode: `net.spy.metrics.reporter.type=jmx`. Other possible settings are `csv` and slf4j`. If you choose a logger that prints out information at a given interval you can change it by setting `net.spy.metrics.reporter.interval` to anything else than 30.

So if you put the line `System.setProperty("net.spy.metrics.reporter.type", "jmx");` before the code shown above, you can open (for example) jConsole and switch to the MBeans tab of the application. You'll see a `metrics` subsection exposed that contains the same metrics as they would show up in the logs.

CAS with Expiration

Before 1.2.0, it was not possible in one command to do a `cas` update and set a new expiration at the same time. You had to do a second `touch` operation which was not efficient nor atomic. Now, the API exposes a new `cas()` method that allows you to pass in the expiration time at the same time. It is easy to use:

client.cas("key", cas, newExpiration, value);

The asynchronous variations have been exposed since 1.2.1 as well.

Initializing through Properties

One thing that comes in handy if your cluster ip addresses change often is that you can now initialize a `CouchbaseClient` object based on system properties. Here is an example:

Of course you can set these properties in your application container or during startup, so it's very flexible and not tied into your code directly. Note that if you forget to set one of these properties, the code will warn you like this:

Other Changes

In addition to the enhancements shown above, the release includes - as always - numerous smaller bugfixes. The default poll interval for `ReplicateTo` and `PersistTo` has been lowered to `10ms` to account for performance changes that went into the Couchbase Sever 2.2 release. Also, the client now uses the `CRAM-MD5` authentication mechanism automatically if the server supports it (since 2.2 as well).

These awesome new features should be enough reason to upgrade right now! If anything pops up that doesn't work as expected, please ask customer support or open a ticket here.