Earlier this month, the Open Source at Google blog [1] featured a post on Contracts for Java [2], a project described in that post as a "new open source tool" that is "based on Modern Jass [3] by Johannes Rieken [4]." Design by Contract [5]TM (DoC [6]) is often associated with the Eiffel [7] programming language and, in fact, this term is trademarked [8] by Eiffel Software [9]. Because the term "Design by Contract"TM is trademarked, other terms often used to describe the same approach include "Programming by Contract" and "Contract-First Development." (This might be an opportune moment to explicitly mention what my blog always states: trademarks used here remain the property of their respective owners.)
Contracts for Java is not the first framework or tool aimed at providing Java developers the ability to use contracts [10] to spell our preconditions, postconditions, and invariants in their code. Indeed, the Wikipedia [11] entry on Design by Contract [5] includes a section on languages with third-party support [12] for this concept and numerous Java tools and frameworks are listed. These include Modern Jass [3], Contract4J [13], jContractor [14], and C4J [15]. The Java Modeling Language [16] can also be used to reach the same objectives and there are various tools that support JML [17]. Another option is object validation with OVal [18].
Java's directly available assertions [19] mechanism can be used for similar purposes. The Preconditions, Postconditions, and Class Invariants section [20] of Programming with Assertions [19] states "While the assert construct is not a full-blown design-by-contract facility, it can help support an informal design-by-contract style of programming." This section then goes on to explain that assertions should not be used to "check the parameters of a public method," but that it is acceptable to check the parameters of nonpublic methods and that assertions can be used to check the postconditions of both public and nonpublic methods.
The reasoning for not using assertions for public method argument checking is that assertions can be turned off at runtime and thus cannot prevent improper invocation of the public methods. This continues to be an issue for Contracts for Java as well because it allows its runtime checking to be disabled. The Contracts for Java FAQ [21] addresses the comparison of assertions to Contracts for Java in the answer to the question How is this better than using assert? [22]
Another Java-oriented approach to contract-first programming is Groovy [23]-based gcontracts [24], a project directly inspired [25] by Bertrand Meyer [26]'s "design by contract" terminology used in Object Oriented Software Construction [27].
The comments (16 of them at time of this writing) on the Contracts for Java announcement are interesting. They indicate some general reservations among Java developers about the need for the project. The availability of existing frameworks (some of which I mentioned above), the availability of the standard assertion mechanism, and a desire to see support given to JSR-305 [28] instead.
Contracts for Java is a very new project that is likely to have some growing pains. It enters an already crowded field and a possibly skeptical audience. It does have some things going for it including a general agreement about the wisdom in Design by ContractTM and Google support (via the 20% time [29] piece of The Google Way [30]). I will be interested to see if it can rise above the existing frameworks, libraries, and tools designed for contract-oriented Java development.
Original posting available at http://marxsoftware.blogspot.com/ [31]
