I co-wrote a paper on the subject a couple years ago during my undergraduate, which I humbly share with you :)
A Case Study in JML-Assisted Software Development
While I'm not sure if we may count those as "programmation by contract", some Java tools provide (some) static analysis:
- IntelliJ IDEA does some nullness analysis : http://www.jetbrains.com/idea/documentation/howto.html
- JSR 305 (Annotations for Software Defect Detection in Java) attempted to standardize on a set of annotations. We use it in our project, mainly the @Nonnull at the moment... I believe Findbugs considers these annotations.
- CodePro Analytix, also recently open sourced by Google, might also do some static analysis: http://code.google.com/javadevtools/codepro/doc/index.html
- Eclipse might too (any expert Eclipse user knows?)
I think there is still a lot to do in this space. "Contracts for Java" is a step in the right direction :)
The poster child of design by contract is the Eiffel Programming language.
IMO Contracts help you te really reduce the number of unit test you need to write.
And the tests that you DO write are more intersting in the BDD kind of way.
I highly recommend to study design by contract. Is one of those things that will make you a better developer in any language you use.
A good book with examples in Java and Eiffel is this:
Design by Contract, by Example
Basically you defined preconditions and postconditions for each function and it looks like this "contracts" flag will raise an exception if those conditions aren't met.
This is probably a better way to test software, but you still need to know how to write the preconditions and postconditions concisely.
What appealed to me was that it seemed to have a nice API against which one can write his own analyses. It exposes Java code at a granularity of control flow -- homogenization of for loops, while loops, etc. FindBugs works really well, and I use it on a reasonably large production codebase. However, extending it doesn't seem like much fun as one must express patterns in terms of Java bytecode! I tried using Crystal's built-in analyses on the same codebase upon which I use FindBugs, but it failed with an NPE.
Also, Soot from McGill (http://www.sable.mcgill.ca/soot/) seems worthy of consideration although the code is a bit creaky (it's dates back to at least 98, I think). It includes four different representations of Java code in various states between source code and byte code. Also, there are a lot of papers, theses, etc. which document various parts of the package.
I know it's annoying when a jar is not available in the Maven repository. But it shouldn't be a dealbreaker either.
We have a Maven repository proxy for the company, so I deploy my jars there:
mvn deploy:deploy-file ...
mvn install:install-file ...
But thanks for the feedback, I've added a README file now with proper dependency information and set up instructions. The build scripts are certainly quite shacky, I must admit; it was originally integrated into Google's internal build system but now that all of that has been stripped out (including the documentation), it looks kinda non-functioning.
I could certainly use some help in making that build and run smoothly in the outer Java world, since I'm not a Java programmer originally and my experience setting up Ant, Maven and the like is very very limited.
P.S.: It may be Google-branded but we're still just a small team. The other guys are taking care of the within-Google integration part so I should be working on the open source integration except I'm not very knowledgeable in the Java ecosystem, nor have I ever released any open source project with that level of visibility, so please be patient.
The fact that the general problem is impossible does not mean that the entire area of study is useless.
and restricted languages such as Spark
: You can play with it here: http://www.pexforfun.com/
Why Google even pushed this out in such an alpha state?
I can understand this sentiment, and I'd love to be able to add a Maven dependency on this project and start using it on production code tomorrow (well, monday actually).
But I am also glad Google followed the "ship early, ship often" mantra . Better alternatives may or may not exist, but I'm pretty sure I had never heard of them before, and never really cared for "contract programming" until now. I knew about JSR 305 and used the @Nonnull annotation when it made sense, but that's about it (I guess doing this already puts me ahead of 80% of Java programmers in this regard...).
Some might say that it's sad people waited for a Google-branded project to be interested in this subject. I choose to view it as an opportunity for the field as a whole. The interesting discussions it sparked (here and on other websites) are worth it by themselves. Some developers might even compare options and start using one of the "better alternatives" you hint about.
The project may be young, but it seems to generate a lot of interest, and I'm sure many people will contribute and improve it.
I'd like to mention though that Cofoja itself is not so "new", in a sense; it is a rewrite of Modern Jass, which itself was a rewrite of JASS. Though the code may be mostly new, we've borrowed many concepts, ideas, and implementation techniques from our predecessors, and hopefully learnt a bit from their experience.
One could then ask "why pick Modern Jass as a basis while there are other more <whatever> framework available?" but that's another question.
Java with Assertions (JASS). http://csd.informatik.uni-oldenburg.de/~jass/
Java Modeling Language (JML). http://www.jmlspecs.org/
Modern Jass. http://modernjass.sourceforge.net/
And if you're interested in the fine details of the internal differences between Cofoja and other frameworks, you may want to read my technical report: http://cofoja.googlecode.com/files/cofoja-20110112.pdf
I noticed in your report that you studied at Ensimag. That's funny: I almost went there! (I added it to my list of choices of Grandes Écoles, but finally opted for a generalist engineering school)