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.
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.
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 !!!
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.
Well, it does not compile !!! There is no documentation about dependencies... This project is far from operational and mature !!! I'd really rather that people did not deliver half-ass projects and loose people's time...
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.
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.
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.
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.
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)
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...