The MongoDB Java Driver 3.0
By Trisha Gee, MongoDB Java Engineer and Evangelist
You may have heard that the JVM team at 10gen is working on a 3.0 version of the Java driver. Weâve actually been working on it since the end of last year, and itâs probably as surprising to you as it is to me that we still havenât finished it yet. But this is a bigger project than it might seem, and weâre working hard to get it right.
So why update the driver? What are we trying to achieve?
Well, the requirements are:
More maintainable
More extensible
Better support for ODMs, third party libraries and other JVM languages
Thatâs all very nice, but itâs a bit fluffy. You can basically summarise that as âbetter all roundâ. Which is probably the requirement of any major upgrade. Since itâs too fluffy to guide us in our development, we came up with the following design goals.
Design Goals
Consistency
Cleaner design
Intuitive API
Understandable Exceptions
Test Friendly
Backwards compatible
Consistency
Java developers using the driver will have encountered a number of inconsistencies: the way you do things in the shell, or in other drivers, is not always the same way you do things in the Java driver. Even using just the Java driver, methods are confusingly named (whatâs the difference between createIndex and ensureIndex, for example?); the order of parameters is frequently different; often methods are overloaded but sometimes you chain methods; there are helpers such as QueryBuilder but sometimes you need to manually construct a DBObject, and so on.
If youâre working within the driver, the inconsistencies in the code will drive you mad if youâre even slightly OCD: use of whitespace, position of curly braces, position of fields, mixed field name conventions and so on. All of this may seem pedantic to some people, but it makes life unnecessarily difficult if youâre learning to use the driver, and it means that adding features or fixing bugs takes longer than it should.
Cleaner Design
Itâs easy to assume that the driver has a single, very simple, function - to serialise Java to BSON and back again. After all, its whole purpose is to act as a facilitator between your application and MongoDB, so surely thatâs all it does - turn your method call and Java objects into wire-protocol messages and vice versa. And while this is an important part of what the driver does, itâs not its only function. MongoDB is horizontally scalable, so that means your application might not be talking to just a single physical machine - you could be reading from one of many secondaries, you could be writing to and reading from a sharded environment, you could be working with a single server. The driver aims to make this as transparent as possible to your application, so it does things like server discovery, selects the appropriate server, and tries to reuse the right connection where appropriate. It also takes care of connection pooling. So as well as serialisation and deserialisation, thereâs a whole connection management piece.
The driver also aims to provide the right level of abstraction between the protocol and your application - the driver has a domain of its own, and should be designed to represent that domain in a sane way - with Documents, Collections, Databases and so on exposed to your application in a way that you can intuitively use.
But itâs not just application developers that are using the driver. By implementing the right shaped design for the driver, we can make it easier for other libraries and drivers to reuse some of the low-level code (e.g. BSON protocol, connection management, etc) but put their own API on the front of it - think Spring Data, Morphia, and other JVM languages like Scala. Instead of thinking of the Java driver as the default way for Java developers to access MongoDB, we can think of this as the default JVM driver, on top of which you can build the right abstractions. So we need to make it easier for other libraries to reuse the internals without necessarily having to wrap the whole driver.
All this has led us to design the driver so that there is a Core, around which you can wrap an API - in our case, weâre providing a backward-compatible API that looks very much like the old driverâs API, and weâre working on a new fluent API (more on that in the next section). This Core layer (with its own public API) is what ODMs and other drivers can talk to in order to reuse the common functionality while providing their own API. Using the same core across multiple JVM drivers and libraries should give consistency to how the driver communicates with the database, while allowing application developers to use the library with the most intuitive API for their own needs.
Intuitive API
We want an API that:
Feels natural to Java developers
Is logical if youâve learnt how to talk to MongoDB via the shell (since most of our documentation references the shell)
Is consistent with the other language drivers.
Given those requirements, it might not be a surprise that itâs taking us a while to come up with something that fits all of them, and this process is still in progress. However, from a Java point of view, we would like the following:
Static typing is an advantage of Java, and we donât want to lose that. In particular, weâre keen for the IDE to help you out when youâre trying to decide which methods to use and what their parameters are. We want Cmd+space to give you the right answers.
Generics. Theyâve been around for nearly 10 years, we should probably use them in the driver
We want to use names and terms that are familiar in the MongoDB world. So, no more DBObject, please welcome Document.
More helpers to create queries and objects in a way that makes sense and is self-describing
The API is still evolving, whatâs in Github WILL change. You can take a look if you want to see where we are right now, but we make zero guarantees that whatâs there now will make it into any release.
Understandable Exceptions
When youâre troubleshooting someoneâs problems, it becomes obvious that some of the exceptions thrown by the driver are not that helpful. In particular, itâs quite hard to understand whether itâs the server that threw an error (e.g. youâre trying to write to a secondary, which is not allowed) or the driver (e.g. canât connect to the server, or canât serialise that sort of Java object). So weâve introduced the concept of Client and Server Exceptions. Weâve also introduced a lot more exceptions, so that instead of getting a MongoException with some message that you might have to parse and figure out what to do, weâre throwing specific exceptions for specific cases (for example, MongoInvalidDocumentException).
This should be helpful for anyone using the driver - whether youâre using it directly from your application, whether a third party is wrapping the driver and needs to figure out what to do in an exceptional case, or whether youâre working on the driver itself - after all, the code is open source and anyone can submit a pull request.
Test Friendly
The first thing I tried to do when I wrote my first MongoDB & Java application was mock the driver - while youâll want some integration tests, you may also want to mock or stub the driver so you can test your application in isolation from MongoDB. But you canât. All the classes are final and there are no interfaces. While thereâs nothing wrong with performing system/integration/functional tests on your database, thereâs often a need to test areas in isolation to have simple, fast-running tests that verify something is working as expected.
The new driver makes use of interfaces at the API level so that you can mock the driver to test your application, and the cleaner, decoupled design makes it easier to create unit tests for the internals of the driver. And now, after a successful spike, weâve started implementing Spock tests, both functional and unit, to improve the coverage and readability of the internal driver tests.
In addition, weâre trying to implement more acceptance tests (which are in Java, not Groovy/Spock). The goal here is to have living documentation for the driver - not only for how to do things (âthis is what an insert statement looks likeâ) but also to document what happens when things donât go to plan (âthis is the error you see when you pass null values inâ). These tests are still very much a work in progress, but we hope to see them grow and evolve over time.
Backwards Compatible
Last, but by no means least, all this massive overhaul of design, architecture, and API MUST be backwards compatible. We are committed to all our existing users, we donât want them to have to do a big bang upgrade simply to get the new and improved driver. And we believe in providing users with an upgrade path which lets them migrate gradually from the old driver, and the old API, to the new driver and new API. This has made development a little bit more tricky, but we think itâs made it easier to validate the design of the new driver - not least because we can run existing test suites against the compatible new driver (the compatible-mode driver exposes the old API but uses the new architecture), to verify that the behaviour is the same as it used to be, other than deprecated functionality .
In Summary
It was time for the Java Driver for MongoDB to have a bit of a facelift. To ensure a quality product, the drivers team at 10gen decided on a set of design goals for the new driver and have been hard at work creating a driver that means these criteria.
In the next post, weâll cover the new features in the 3.0 driver and show you where to find it.













