This just in:
Never tried this one, but trying to put DbC in java was a big thing 10 years ago or so. For example
http://bugs.sun.com/view_bug.do?bug_id=4449383
Common issues are how to allow weakening of contract for preconditions, how to enabled ‘real’ language support for contract bodies and how to cope with binary-only interface for separate recompilations. From what I can see in google approach, they are embedding java inside text fields (which means that at the moment none of the important things will work - no autocompletion, no refactoring, no find references etc) and they are supporting only very naive weakening of preconditions (no way to weaken specific part of precondition, you need to repeat it fully each time). As for the binary compatibility, I wonder how well their implementation behaves if I have class A in library, having some contracts, class B in my application, having some extra invariants for example and then, after compiling B, I just silently replace A to version which has no contracts. And other direction - if A has no contract originally and I develop B, then replace the A with something which has post-conditions in methods, will they be checked for overwritten methods in B, without recompilation ?
Interesting thing is that it seems that none of the new ‘popular’ languages like scala, groovy or clojure implement DbC. There are some hacks to get it working (same as with plain java), but none of them really have Eiffel-like first class support.
I think that it has a lot to do with popularity of unit testing. Basically, well done unit tests ARE your DbC. Having both DbC and unit tests would be kind of duplication of work in many cases. And units tests have benefit of blowing up before the production time 