Google's Latest Open Source Tool

Google’s New Contracts for Java Project

Jessica Thornsby
Contracts-for-Java

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
developer?

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:

@Requires({
“list != null”
})
@Ensures({
“result != list”,
“Collections.isSorted(result)”
})

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.

Author
Comments
comments powered by Disqus