Google’s New Contracts for Java Project
Contracts: a useful addition to the Java programmer’s toolkit?
Google recently launched a new open source project, which seeks to enable users to annotate their code with contracts in the form of preconditions, postconditions and invariants. In this interview, JAXenter speaks to Contracts for Java team member and YouTube software engineer, David Morgan, on the new tool and what value it can add for Java developers.
JAXenter: Can you introduce us to the ‘Contracts for Java’ project?
David Morgan: Software engineering has come a long way since the days of hand crafted machine code. But large projects still suffer numerous and unpredictable bugs and delays, and there is still a long way to go.
The developer community is slowly putting together an ever-increasing toolkit for fighting complexity: agile methodologies, test driven development, new and more powerful languages, code analysis and refactoring tools.
One methodology and language feature that has been around for some time but has never become popular in the Java world is contracted code. I thought that contracts could be a useful addition to the Java programmer’s toolkit and began investigating how we could use them at Google.
Obviously I first looked at the available tools, but didn’t find anything that matched what I personally wanted. The closest was Modern Jass by Johannes Rieken, so I started building on that. Most of the actual implementation was by Nhat Minh Le, who interned at Google in the summer of 2010, with advice and guidance from Andreas Leitner. We open sourced the resulting tool a few weeks ago. The response has so far been positive, but the actual impact remains to be seen.
JAXenter: What benefits does annotating Java
code with contracts, add for the
David: There are lots of ways of looking at contracts. I like to see contracts as making code a little self aware.
Procedural code is very much like a list of instructions that are followed blindly, and everyone knows that following instructions blindly can lead to problems, sometimes serious ones. Contracted code is no longer followed blindly: at each steps it “knows” something about the state it’s supposed to start and finish in.
This is a lot more like how a human would follow instructions, and the advantage is clear: as soon as something doesn’t make sense, the process stops and you can figure out what went wrong.
The funny thing is that a programmer usually does think about those checks while writing code, since they will imagine stepping through the code and what should happen at each stage. This is incredibly important knowledge, but normally it’s discarded and forgotten. With contracts it can be written down and used.
What computers are best at is following instruction blindly, so when a program is actually being used, contracts are turned off to let the program run as quickly as possible.
JAXenter: How can contracts be used to turn interface documentation into code?
David: Interface documentation says what a piece of code does: what needs to be supplied as input, what the side effects are, and what the results will be.
Normally this is expressed in Javadoc, for example:
* @param list any list of integers
* @return a new list containing the same values, sorted
Concepts like “new list” and “sorted” can be expressed in code, and anything that can be expressed in code can be used in a contract:
“list != null”
“result != list”,
Here the concept “is sorted” is provided by another class called Collections.
Now the interface says the same thing but in a way that can be checked at runtime; if the state not as expected when runtime checking is enabled, the program will stop and the developer can figure out what went wrong.
For more information on the technologies at work in Contracts for Java, check out Nhat Minh Lê’s technical report.