

Google open sources "Contracts for Java" - eneveu
http://google-opensource.blogspot.com/2011/02/contracts-for-java.html

======
zlapper
This is very similar to JML!

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
[http://portal.acm.org/citation.cfm?id=1556581&preflayout...](http://portal.acm.org/citation.cfm?id=1556581&preflayout=flat)

Download:
[http://cic.puj.edu.co/wiki/lib/exe/fetch.php?media=grupos:av...](http://cic.puj.edu.co/wiki/lib/exe/fetch.php?media=grupos:avispa:papers:cbg_09.pdf)

~~~
zlapper
(thinking out loud: wouldn't be cool if someone at Google contacts me? I'd
love to work for them :)

------
jgershen
Very cool stuff. I wonder if there is any way to integrate something like
KeYmeara (<http://symbolaris.com/info/KeYmaera.html>) for a way to prove
correctness of Java systems (or components of Java systems).

~~~
eneveu
I did not know about KeYmeara. Looks great!

While I'm not sure if we may count those as "programmation by contract", some
Java tools provide (some) static analysis:

\- Findbugs

\- 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 :)

~~~
tikkes
Eclipse does not do static analysis by default I believe. There are some
patches however...

~~~
ShabbyDoo
The out-of-the-box Eclipse distro does include some static analysis stuff, but
it's turned off by default. Preferences->Java->Compiler->Errors/Warnings.
Under "Potential Programming Problems", you can alert on such things as
guaranteed NPEs, etc.

------
ajmurmann
Not having any experience with contracts like this, I wonder how this relates
to testing. Is this thought to be an addition or an alternative to usual xUnit
style and integration tests. Or are these concepts not even related and I am
getting it all wrong?

~~~
elviejo
This contracts refer to the concept of "Design by Contract."

<http://en.wikipedia.org/wiki/Design_by_contract>

The poster child of design by contract is the Eiffel Programming language.

<http://www.eiffel.com/developers/design_by_contract.html>

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 [http://www.amazon.com/Design-Contract-Example-Richard-
Mitche...](http://www.amazon.com/Design-Contract-Example-Richard-
Mitchell/dp/0201634600)

------
ShabbyDoo
I have read a bit about Crystal SAF, a static analysis framework for Eclipse
from CMU:

<http://code.google.com/p/crystalsaf/>

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.

------
ShabbyDoo
In general, why has static analysis not been more popular? When I first ran
FindBugs on a 50 KLOC codebase I inherited, it identified several real, non-
trivial bugs which likely hurt many users. Perhaps the average Java
developer's skill level is too low to make sense of these tools' results? But,
one would think that most teams have at least one "adult" who would love more
visibility into a codebase.

------
Yrlec
Microsoft has a similar project for .NET <http://research.microsoft.com/en-
us/projects/contracts/> . Based on a quick look I think Microsoft's project is
a bit more mature (already has VS-intergration for example).

~~~
jefffoster
There was also an older project known as Spec# at
<http://research.microsoft.com/en-us/projects/specsharp/>

------
JVerstry
Looks interesting, but why isn't there a .jar to download or a maven reference
to use this project? Moreover, there is no documentation explaining how to
activate/disactivate contracts... Sorry, but it seems like half-ass delivery
to me !!!

~~~
eneveu
It's still quite new, so for now I think you'll have to build it from source.

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 ...
    

It's better than having each developer manually install the jar in their local
repository:

    
    
      mvn install:install-file ...
    

More information:

[http://maven.apache.org/plugins/maven-deploy-
plugin/usage.ht...](http://maven.apache.org/plugins/maven-deploy-
plugin/usage.html)

[http://maven.apache.org/plugins/maven-install-
plugin/example...](http://maven.apache.org/plugins/maven-install-
plugin/examples/specific-local-repo.html)

~~~
rz0
Yeah, sorry but you have to build it from source, for now. There is no point
in making a release now as there are a few bugs that need correcting before
that.

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.

------
ivenkys
A good thing to have - better than the "assert" keyword in Java.

------
tarkin2
In the sorted parameters example contract, would it not be as good to pass an
new object whose constructor ensures the sorting?

------
jdp23
Great to see, although it's really too bad that they didn't introduce this as
part of the language when they developed it.

~~~
dhimes
Live and learn, eh?

------
MarkSweep
The next step for this would be to statically verify the annotations are being
obeyed.

~~~
spicyj
That sounds (close to) impossible. How would you tell if a given piece of code
sorts a list properly? There are a million and one sorting algorithms and the
static analyzer would have to be really smart to be able to check that
reliably.

~~~
atamyrat
Yes, it is impossible. See: Halting problem.

~~~
likpok
The thing about program verification is that everyone knows that of course it
is in general impossible. However, I am not writing a simulator. Most of the
code I write does not actually take advantage of the power of a Turing
machine.

The fact that the general problem is impossible does not mean that the entire
area of study is useless.

~~~
riffraff
see: dependent typing <http://en.wikipedia.org/wiki/Dependent_type>

and restricted languages such as Spark
<http://en.wikipedia.org/wiki/SPARK_(programming_language)>

------
shareme
Hmm, other java contract projects more mature for a few years even and fully
in production..

Why Google even pushed this out in such an alpha state?

~~~
eneveu
You are not the only one arguing about the project's lack of maturity and the
existence of better, more mature alternatives (which ones?).

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.

~~~
rz0
Alternatives include: JML, C4J, Contract4J, JASS, and Modern Jass. The most
popular and well-known solution is probably JML.

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.

Links: C4J. <http://c4j.sourceforge.net/> Contrac4J.
<http://www.contract4j.org/> 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>

~~~
eneveu
Thanks for these links. Sounds like there are indeed alternatives, but they
were considered before creating Cofoja.

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)

