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).
- 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.
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?
It's based on the idea of formal proofs for programs. There is a really good paper about this by dijkstra, but I can't seem to find it now.
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.
I haven't used contracts, but I think if you have more assertions in your code then you need fewer assertions in your tests. But you still need to exercise the code with about the same number of tests, or your testing won't find the bugs.
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.
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.
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 !!!
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.
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.
[+] [-] zlapper|15 years ago|reply
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...
Download: http://cic.puj.edu.co/wiki/lib/exe/fetch.php?media=grupos:av...
[+] [-] zlapper|15 years ago|reply
[+] [-] jgershen|15 years ago|reply
[+] [-] eneveu|15 years ago|reply
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 :)
[+] [-] ajmurmann|15 years ago|reply
[+] [-] elviejo|15 years ago|reply
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...
[+] [-] endlessvoid94|15 years ago|reply
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.
[+] [-] skybrian|15 years ago|reply
[+] [-] ShabbyDoo|15 years ago|reply
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|15 years ago|reply
[+] [-] Yrlec|15 years ago|reply
[+] [-] jefffoster|15 years ago|reply
[+] [-] silverlake|15 years ago|reply
[+] [-] JVerstry|15 years ago|reply
[+] [-] eneveu|15 years ago|reply
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:
It's better than having each developer manually install the jar in their local repository: More information:http://maven.apache.org/plugins/maven-deploy-plugin/usage.ht...
http://maven.apache.org/plugins/maven-install-plugin/example...
[+] [-] ivenkys|15 years ago|reply
[+] [-] tarkin2|15 years ago|reply
[+] [-] jdp23|15 years ago|reply
[+] [-] dhimes|15 years ago|reply
[+] [-] MarkSweep|15 years ago|reply
[+] [-] spicyj|15 years ago|reply
[+] [-] likpok|15 years ago|reply
[1]: You can play with it here: http://www.pexforfun.com/
[+] [-] shareme|15 years ago|reply
Why Google even pushed this out in such an alpha state?
[+] [-] eneveu|15 years ago|reply
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.
[+] [-] regularfry|15 years ago|reply