6

I've been thinking about creating a Java framework that would allow programmers to specify invariants (pre- and post-conditions) on interfaces. The purpose would be to make code more robust and reduce the number of unit tests that would need to be written for different implementations of the same interface.

I envisage creating some way of annotating methods with invariants that the programmer would also write. E.G. 

interface Sort {
    int [] sort(int [] nums);
}

would be decorated with an annotation to ensure that any implementations return a sorted list. This annotation would be linked to a unit test that could be run at compile time against any implementation.

Is this a crazy idea or would this be useful to the wider programming community?

Matt Ball
  • 354,903
  • 100
  • 647
  • 710
Tarski
  • 5,360
  • 4
  • 38
  • 47
  • I'm not sure if linking it with unit test is a good move during compile time. Because _having test passed is just something_, if you know what I mean. Using an aspect weaver may be a better approach, no? (Then the next question will be - performance) – yclian Jul 22 '10 at 15:33
  • 2
    @yclian, I think the idea was to use these pre- and post-conditions to perform various static analyses in order to reduce the number of unit tests that would need to be written in order to get equivalent coverage. I didn't see any implication that this would necessarily be a runtime thing (although maybe some runtime assertions could be used to guard statements that static analysis could not prove safe). – Gian Jul 22 '10 at 15:53

4 Answers4

4

This sounds like it could be related to JML and ESC/Java, both of which have found reasonably wide-spread adoption within the kinds of projects that need a little more software quality than is offered by the usual set of techniques.

Gian
  • 13,735
  • 44
  • 51
  • 1
    I've never heard of either. "Reasonably wide-spread adoption" - data, please. I'll bet you have no basis whatsoever for this statement, except for one or two projects that you've done. – duffymo Jul 23 '10 at 00:19
  • 1
    @duffymo, I don't think the aggressive tone is necessary. I did qualify "reasonably wide-spread adoption". I was basing the statement on the fact that it is taught in at least a few universities that I know of, there is a fairly healthy ecosystem of JML tools (http://en.wikipedia.org/wiki/Java_Modeling_Language#Tool_Support), and most professional engineers are probably at least familiar with JML as a concept. There are also a decent number of peer-reviewed publications that deal with JML (http://scholar.google.com/scholar?hl=en&q=java+modeling+language). – Gian Jul 23 '10 at 06:44
  • 1
    There you go again: "most" is just as ephemeral as your "wide-spread". Both of those citations are academic in nature. I've never once had the programming by contract idea come up in an interview or a professional engagement of any kind. I only heard about it in graduate classes. I think that's because the concept appeals to academics, but the adoption rate outside the academy is slow to non-existent. – duffymo Jul 23 '10 at 09:17
  • I'm not claiming that it's popular. I'm saying that among software engineers who have any knowledge of formal verification, JML is well-known. That was why I qualified my original statement with "within the kinds of projects that need a little more software quality than is offered by the usual set of techniques". And frankly, your ignorance is just as anecdotal as my experience. Making strong claims about its use based on the fact that you've never heard of it is pretty arrogant. – Gian Jul 23 '10 at 09:54
  • I don't know of any software projects that would say they don't need high quality. I learned Eiffel and DBC back in 1994, so I'm not unaware. I will admit that I don't know about JML - because none of the companies or engagements I've had since then have asked for it. – duffymo Jul 23 '10 at 12:29
  • Most software projects would like higher quality, but don't want to pay for it, so they use standard techniques like unit testing and many some kind of methodology involving code reviews, but they don't go for formal methods. JML is in the realm of formal methods. And it hardly surprises me that companies haven't asked for it... it seems like it would only be used in places where software professionals recommended it as the right tool to obtain something closer to a mathematical guarantee of correctness for critical code. – Gian Jul 23 '10 at 12:39
  • I can't think of software that's more critical than flight control. The government demands that it be written in ADA. Does ADA have DbC built in? – duffymo Jul 23 '10 at 12:49
  • You're appealing to a false syllogism there. You wouldn't write flight control software in Java because you cannot make strong enough guarantees about correctness (and timing constraints). Ada has various external mechanisms available for DbC, and adding contracts to the core language is on the to-do list (AI05-0145). That's by-the-by, however, as there are many formal methods available. Extended static checking with JML specs is towards the low-end, the kinds of stuff they do on Ada code for Avionics is at the high end, with proportional cost and time involved. – Gian Jul 23 '10 at 13:00
  • 1
    You might be interested in SPARK http://www.praxis-his.com/spark.aspx which is a subset of ADA used for formal verification. – Tarski Jul 23 '10 at 13:45
  • Not false - just trying to see if software that requires higher quality uses DbC. Wikipedia tells that ADA has a plug-in for it, but I don't know anyone who writes ADA so I can't confirm. I see that Spring Contract exists, but I don't know how widely it's used. I know a lot of people who use Spring, but no one who uses Spring Contract. – duffymo Jul 23 '10 at 13:48
  • I don't think whether DbC is widly adopted or not is the only indicator of whether it is a good methodology. I cant take this argument seriously without discussions of the merits of DbC verses Unit testing or TDD – Tarski Jul 23 '10 at 14:34
  • I think success in the marketplace is a very good indicator indeed. I think that DbC can be done without a framework. When I write classes, I check incoming parameters. Call that preconditions if you want. I don't need a framework to do it. Truth is, it's not either/or. People do both. – duffymo Jul 23 '10 at 15:45
  • Ideally DbC (or any other verification) should be done as static analysis at compile time. You get much stronger assurances and it doesn't introduce any runtime cost. – Gian Jul 23 '10 at 16:43
2

I think design by contract is a great idea and I've glanced at frameworks that provide that functionality in Java. I think what has held me back is that getting buy-in from a team for these sorts of frameworks can be difficult. I think it's perceived as being only of academic interest which is strange because really it's just like embedding unit tests within the code.

Java's main nod in this direction, the assert statement, has been around for several years but I rarely see it used - often only in the code I write myself! There's a lot of mileage in using asserts (especially combined with unit tests) and I've found a few bugs using them, it's just a pity people don't use them.

Cheers,

Ian.

Ian Fairman
  • 625
  • 5
  • 11
  • I agree with you that asserts are underused. I've just done my SCJP exam and Sun recommends using asserts to check pre-conditions on private methods only. But really, there is nothing to stop you from using them to check post-conditions as well. The problem I have with assertions is that they are by default disabled - I would like to use a framework that does compile time checking. – Tarski Jul 23 '10 at 14:37
1

I think Bertrand Meyer's programming by contract idea is largely dead. He built pre- and post-conditions into Eiffel, but that language is below Latin on the usage scale.

There are Java programming by contract libraries out there; Contractor is one. But its day has come and gone. The fact is that even Eiffel had a way to turn them off in production, because the runtime cost wasn't worth the benefit.

Only 6 Eiffel questions on Stack Overflow - a small percentage indeed. If you search for SO tags with "contract" in them, you'll see a very small number. Not much interest in the topic on this site. It claims to draw the biggest audience of professional programmers in the world.

duffymo
  • 305,152
  • 44
  • 369
  • 561
  • interesting views. would you say that test driven development is a better approach than design by contract? – Tarski Jul 22 '10 at 22:29
  • "would you say that test driven development is a better approach than design by contract?" - absolutely. There's no runtime penalty; they provide better information about the behavior of classes; they document far better than contracts would. Given a choice, I'd rather have the tests. – duffymo Jul 23 '10 at 00:18
  • 3
    I wouldn't say they document far better than contracts would. Using TDD you might test a few inputs to stretch the functionality, but a contact may define in abstract terms what the function actually does. e.g. a sum(x, y) function might have contract returns x + y whereas a test might just assert that sum(1, 2) = 3 – Tarski Jul 23 '10 at 07:36
  • 3
    I really have to disagree. There is still plenty of work going into various design-by-contract-based approaches to correctness, although the work has certainly moved on from Eiffel. TDD does not (and cannot!) make any claims towards ensuring correctness. Testing does not provide anything except reasonable suspicion of correctness. More rigorous approaches (such as those involving contracts) can make much stronger claims. – Gian Jul 23 '10 at 10:29
  • I suppose the trouble comes when you try to write contracts for a complex routine. People naturally prefer examples, like tests than a formal definition – Tarski Jul 23 '10 at 12:17
  • 1
    And fair enough too. I'm definitely a fan of testing, but there is a continuum stretching from doing no kind of validation whatsoever all the way to constructing your entire program inside a theorem prover, and testing falls somewhere below the kinds of design-by-contract techniques that we've been discussing. You go to the extra effort to provide more assurances on the correctness of your software when it is worth spending the time or money to do so. – Gian Jul 23 '10 at 13:04
0

What great programming Idea is not crazy!!! I definitely think it would be useful.

Jose Diaz
  • 5,353
  • 1
  • 31
  • 29