SpringContracts 0.3, a Spring addin that allows enforcement of Design By Contract, has been released. Through use of annotations and an aspect, SpringContracts allows you to specify the behavior that a bean should comply with, such that an exception is thrown in the application if a bean should violate the contract. Main features:

• Gives you the freedom to notate Contracts - Preconditions, Postconditions and Invariants - in a flexible way. (based on Annotations or by an external contract notation even for third party class libraries)
• Lets you extend and configure the behaviour of contract validation via Spring's Application Context.
• Provides a pluggable way to switch the specification language in which to describe the conditions.
• Comes with a build in support for a wide range of specification languages (e.g. EL, OGNL, Groovy) with extensions due to first order logic (all quantor, exist quantor, implication)

The full feature list can be seen under the projects homepage. SpringContracts is an open source project under the Apache license. New features in release 0.3:

• Contract Validation for Constructors and ad hoc instantiations due to Load Time Weaving
• Beanshell / Java as specification language
• Spring 2.0 NamespaceHandler for concise external contract notation
• Simultaneous usage of Annotations and external contract notation for contract definition
• New Handler for publishing contract violations as lightweight Spring Application events
• Reference guide documentation (draft version)

Message was edited by: [email protected]

This rocks! I'm gonna spend my new found freedom specifying what behaviors muh beans should comply with! Whin I gits dun with that, Immuh gonnah spend thuh weekend pluggin in different specificashun languijiz!

extensions due to first order logic (all quantor, exist quantor, implication)

- this here languij sounds a bit uppitty but no bother... wee doggies! You waskals you!

OTOH, being able to verify that implementations comply with the specifications they're supposed to implement might be useful, far more useful than trying to mock a project whose capabilities you don't seem to want or need.

I like the idea because as the article says....you can add a comment but u cant enforce it... Though there are some articles that argue that semantic enforcement can be better done by abstract classes than pure interface (I know....the whole u can extend but one class in java....thats a downside to that approach) But back to this article...a question Instead of using this: @Precondition( condition = "arg1 not empty and this.size < this.capacity" ) will this be easier to work with as conditions get complex: @Precondition( condition = "JavaValidationHandlerClassname.validationMethod" )

The return of Eiffel.

I like the idea because as the article says....you can add a comment but u cant enforce it...
Though there are some articles that argue that semantic enforcement can be better done by abstract classes than pure interface (I know....the whole u can extend but one class in java....thats a downside to that approach)

But back to this article...a question

Instead of using this:
@Precondition( condition = "arg1 not empty and this.size < this.capacity" )

will this be easier to work with as conditions get complex:
@Precondition( condition = "JavaValidationHandlerClassname.validationMethod" )

I was hoping that by now, reasonable developers would have learned that code in comments or strings is a design smell that has never gained traction... guess not. As for Design by Contract, it's never been adopted for a bunch of reasons, some of them explained here. -- Cedric http://testng.org

Cedric, thanks for your feedback! As i wrote in my reply to Gili, i would like to see another way to notate contracts in Java. Back to your note. I guess your primary concern of having code / expressions in strings is the lack of having a compile time check of it's syntactic correctness, right? (i wonder if that's the reason why so much developers seem unattracted of runtime interpreted languages like Ruby ... ;o)) Now seriously. I read your mentioned block entry and have to admit - yes, DBC is not applicable for all sort of situations ('Design by Contract, by Example' by Mitchel and McKim, Addison-Wesley 2002 gives a good overview about that issue in chapter 8). It's well suited for abstract datatypes (as you've mentioned) but thinking back to one of my last projects i wished we could have used DBC, since almost 60 developers left a code desert that makes it quite impossible to reuse (not to mention to refactor) business logic. You had to look inside of each (almost too fat) class in order to understand it's behaviour. More than that, DBC could had helped to get down to classes with a sole responsibility and methods fulfilling only one task (another nice effect would have been the pain to express conditions for such fat multi purpose classes. Similarly to TDD where you feel the pain of testing tight coupled classes, not abstracted by interfaces or classes that violates Demeters Law, you feel the pain expressing contracts for such classes, giving you a strong hint of bad design). Even if DBC would reduce the antipattern 'test and navigate' (that is checking all input and collaborators against not to be null) would have been a great help (discovering the core business logic between all these checking clauses). So what's the core statement? On the one hand i have to admit - i would willingly abandon the idea of using strings for contract declaration, having DBC a first class citizen in Java. On the other hand i'm still a beliefer of DBC, helping you to increase the expressiveness of substantial parts of your system, guiding you to a simpler design at all. Mario

Hi Mario, Yes, my two main concerns with code in strings is lack of type safety and no completion from the IDE's, so they're definitely a no-no for me. As for your unfortunate experience, I sympathize, and again, it seems to me that tests would have helped just as much (if not more) than DBC. I say tests are more expressive simply because DBC is limited to "before", "after" and "around" verifications. Tests let you write arbitrarily complex pieces of code, although invariants are admittedly harder to capture (but as I said before, they also quickly become impossible to express with real world code). And by the way, I already held these beliefs before I created TestNG (the entry I linked to was written in 2002 :-)). -- Cedric http://testng.org

Hi Cedric, thanks again for your feedback - appreciate that kind of conversation! From my viewpoint DBC and Tests aren't competing techniques, rather than tools that could complement one another. I'll give a brief summary of some issues (most of them are greatly influenced by the book 'Design by Contract by Example'), where it's valuable to think about how DBC could support for a better design. I will elaborate on that thoughts in a separate blog entry under my blog site as soon time allows some more writing. 1. Rely on a proper context In my experience, most developers tend to insert guard clauses in their code despite having unit tests. They don't seem to trust about the context in which the method get's called (this maybe comes because of a mental and local 'distance' between the code and the test). Having contracts aside the code you can rely on seems to increase trustability in the running context. This may be because of ... 2. Supporting defensive programming DBC protects / defend methods from bad arguments in the real hard world, testing potentially a wider range of input than a test ever can do. 3. Clearer, reliable Documentation Contratcs form part of the public (client-) view of a class (personally i'm lazy - i want to recognize the core behaviour of a building block by looking at its interface / signature, not studying an amount of code be it the building block itself or a test). Assertions are checked at runtime, thereby testing that the stated contracts are consistent with what the routines actually do. 4. Hepls to test integration Having contracts that can be turned on and off makes it very easy to test and retest parts of a program. It allows you for instance to continue to test class A while you are working on class B, in case there are any interactions you did not foresee (and anything that helps testing will lead to code with fewer bugs). 5. Encourage to think about the conceptional model of a building block Thinking about such matters as pre-, postconditions and invariants help to make the concept of a class more explicit. That leads to ... 6. Clearer Designs Obligations and benefits are shared between client and supplier and are clearly stated. The limitations on the use of a method are clearly expressed and the consequences of calling it illegally are clear, so programmers are encouraged not to build routines that are too general, but to design classes with small single-purpose routines (while TDD guides more towards loosely coupled building blocks, DBC guides more towards smaller building blocks with a clear resoponsibility). 7. Easier Debugging DBC can take part in 'real life', that means under real runtime conditions, maybe during development and user acceptance test (they take effect under real circumstances while 'real' clients and real collaborators (maybe also contracted) interoperate with each other. So contracts also guarding the collaboration of muliple building blocks forcing to fulfill a collective adduced goal due to a specification). Additionally, having clear sound messages that state the cause of a contract violation helps locating where the fault lies semantically. 8. Support for reuse For library users (where tests may not be accessible), contratcs clearly explain what library classes do and what constraints there are on using them. They provide feedback to someone learning to use other peoples classes. (sometimes you only know the interface to operate with - the implementing class is unknown. Having contracts on that interface gives you a clear, sound concept of the limitations and relevant effects in programming against that interface in a proper way) 9. Encourage to comply to the open close principle While tests usually test a single unit, DBC handles inheritance in a broader way, supporting also inheritance of contracts to subclasses and therefore forcing to adhere to the claimed behaviour, stated in contracts of a superclass or interface. As mentioned above - some of the points briefly. Hoping that i can extend that opinions in a separate blog entry the very next time. As i said - i appreciate that kind of conversation :o) Greetings Mario

I was hoping that by now, reasonable developers would have learned that code in comments or strings is a design smell that has never gained traction... guess not.

Well, I guess I have to advocate my own "DBC for Java" tool then, http://c4j.sourceforge.net. In C4J you write your contracts in pure Java (in a separate class) so you'll get help from your IDE, you can even debug your contract code if you want to. And no ugly xml either, the contracts are dynamically tied to the application code at class loading, just like in aop. Cheers / Jonas

Hi Jonas,

I was hoping that by now, reasonable developers would have learned that code in comments or strings is a design smell that has never gained traction... guess not.

Well, I guess I have to advocate my own "DBC for Java" tool then, http://c4j.sourceforge.net.

In C4J you write your contracts in pure Java (in a separate class) so you'll get help from your IDE, you can even debug your contract code if you want to.

And no ugly xml either, the contracts are dynamically tied to the application code at class loading, just like in aop.


Cheers / Jonas

Your approach is interesting, and at least more robust than the "code in strings" one. I'm still concerned that refactorings will silently break your Contract classes since methods won't be automatically renamed there (unless you also have refactoring plug-ins for c4j?). Overall, I still think that if I'm going to write an extra class to verify my code, I'd rather write a real test case instead of a class that is limited to invariants and pre/post conditions... -- Cedric http://testng.org

I'm still concerned that refactorings will silently break your Contract classes since methods won't be automatically renamed there (unless you also have refactoring plug-ins for c4j?).

You're right, this is the biggest issue I have with c4j. There is an eclipse plugin on it's way though that will include refactoring support at some point. In the end unit test and dbc both have their respective strengths and weakneses, personally I tend to think that black box testing of larger building blocks is much more effective anyway. / Jonas

Jonas, thanks for your informations. As i replied to Parag, i'm personally not sure if outsourcing contract validation to a separate class and therefore increasing the number of dependencies from the contracted class to the validation handling class is desirable. Don't get me wrong: as most of the times it's a question of trade off. On the one hand - as you've mentioned - having IDE support. On the other hand dependency to an additional class (which you have to keep in mind additionally when you recap about the semantic concept of the contracted class). What's your opinion about a number of query methods, that can be refered inside of a contract element, residing in the class under contract itself? (As i also replied to Parag, SpringContracts can also be extended and configured easily to base upon Java classes serving as validation classes. Thanks to Spring, configuration is very easy - just switching the responsible ContractBuilder ;o) Best regards Mario

Hello Mario, keep up the good work!

As i replied to Parag, i'm personally not sure if outsourcing contract validation to a separate class and therefore increasing the number of dependencies from the contracted class to the validation handling class is desirable.

Don't get me wrong: as most of the times it's a question of trade off. On the one hand - as you've mentioned - having IDE support. On the other hand dependency to an additional class (which you have to keep in mind additionally when you recap about the semantic concept of the contracted class).

Since contracts often tend to be rather complicated, I think it is important to have IDE support. The main drawback is refactoring as Cedrik points out, but such errors that can probably be rather easily prevented if C4J simply denies to load a class that defines contracts for methods that don't exist (just added that to my TODO list...).

What's your opinion about a number of query methods, that can be refered inside of a contract element, residing in the class under contract itself?

I'm not sure what you mean. I can see no reason to limit the number of queries that are used in the contract code, if that's what you meant. Regards / Jonas

Hello Jonas, thanks again for your fast reply and your feedback at all!

I'm not sure what you mean. I can see no reason to limit the number of queries that are used in the contract code, if that's what you meant.

I think that was a misunderstanding. What i wanted to state is, that there is no good reason not to have as many query methods in your 'classes under contract' as needed to achieve expressive and concise assertions, as long as those query methods are meaningfull to the client (in this case the developer, who want's to learn about the effective behaviour of a certain building block). So it seems that we have the same opinion on that. So under that circumstances, assertions itself can be very expressive, concise and readable when mainly based on such queries that encapsulate most of above mentioned complexity. (on the other hand, when really having such complex assertions, it might be a smell or at least a hint, that the given class is to fat, to general or having at least methods that handle more than a one-purpose task) IDE support for refactoring is great help, especially when not only handling with a few classes, no question about that! The point of having the biggest amount of code encapsulated in query methods instead of in the assertions itself targeted that concern, in that they should also encapsulate most of time that area of code that would change in case of refactoring. As i said before, having IDE support and validation handling in separate classes is a decision for one side of a trade off. The other side comes with an increased dependency and an increased mental workload when asking about the semantic concept of a building block. As contracts belong to the public view of a class or method they are part of their public interface and therefore an extension of their signature. It's the same reason why having javadoc (which also aims to express the semantic concept and effectiveness of a class or a method in a limited way, because of not forcing the building block to comply to that stated behaviour) directly stucked to the signature - because they belong to the public view of the class that should be seen as one (not separated into another location). On the other side the yet limited potential of expressing assertions or at least refering query methods using annotations (directly stucked / belonging to the public signature) and strings with lack of IDE support. As said, it's a trade off and i think none decision - either to the one nor to the other side - will make a solution better than the other. Both solutions have their strenghts and shortcomings and therefore their 'right to exist'. I think the specific situation with the related requirements will give the amplitude to decide which solution will meet the needs best for a certain situation. Best regards Mario

Parag, thanks for your feedback. To your question: I'm not sure getting your point, but i guess you want to outsource the validation logic into a separate validation handler bean, right? This would be possible with SpringContracts, for example by having an alternative ContractBuilder that is based on validation beans (maybe declared in Springs application context or following some conventions). The concern i have is the introduced dependency of the contracted bean to a set of validation handler beans. Right now contracts are only dependend on the contracted bean itself and the calling context (arguments and return value) - always there to validate the bean. Refering some additional beans would mean that they have to be present in any runtime context, the beans are running in with contract validation activated. Yoy maybe could instead have some more query methods, helping you to encapsulate more complex condition fragments (again i'm refering to 'Design by Contract, by Example' by Mitchel and McKim, Addison-Wesley 2002, where they state that is completely legal to have additional query methods in the contracted building blocks) In short: having external validation handler beans would be possible, but you have to pay the price of having additional dependencies. Mario

@Precondition( condition = "arg1 not empty and this.size < this.capacity" ) </blockquote> mmmmnnnnhhh.... we need closures @Precondition(condition=(List arg1): arg1!=null && size < capacity)

Design by Contract sounds great but I'm not sure this particular design has my vote. What I don't like is the embedding of code into String values using annotations. That's a big no no. I also don't like seeing XML configuration files. That stuff is like kryptonite. You should be feeding XML to computers, not to humans. I would like to point out that the Javadoc @throws coupled with actually throwing the declared exceptions is a formal enough way of declaring pre/post conditions. It seems to me that it is easier to declare a method checkInvariants() and invoke it from all my methods than it is to use SpringContracts to define invariants. That lowers the learning curve and (in my view) readability is actually better. I honestly don't think that Design by Contact will be decent in Java until it is a first-class citizen of the language. Just my 2 cents. Gili

Gili, thanks for your critical comments! I would love to see support for Design By Contract as a first class citizen in the Java Language. As you can see, the concept is not for nothing on no.1 in the top 25 of RFE's (Request for Enhancements) at Sun's Developer Network. Having a way to notate contracts in a typed way would be of course a better way! Unfortunately, there is only a small chance of adoption of this RFE and so you have to use the tools that are given ... I'm not sure if Javadocs @throws clause is a statisfying way increasing the semantical expressivenes of an interface, class or module. Of course you can comment under which circumstances the exception is thrown, but you can't enforce the described behaviour. As mentioned in an example at the Quickstart document, you can't express syntactically that - say on an Interface Stack and all it's implementing classes - a method push() have to fulfill the contract on laying the pushed element ON TOP instead ON BOTTOM of the stack. That's only possible by a semantical specification rather than by a syntactical one. That said, Contracts are Spec's and Checks, enforcing the class to fulfill the stated contract, showing the effects (by postconditions) of a method. I have some problems with a method checkInvariants(). First of all,you have to put the invocation to the start and end of all of your public methods (could we already talk about cross cutting here? Nevertheless - i would like to count a contract rather to the signature of a method than to it's implementation. I would like to see the behaviour of a method only by check out this 'extended' signature than have to look inside the code in order to understand it's behaviour). Adding a new method will enforcing you not to forget to put the invocation of the check methods into such newly added methods. Furthermore, whats about subclasses? You have to call super.checkInvariants() manually (first checking if such a method exists) in order to get the full stack. That might by manageable with subclasses, but what's about implementing interfaces, that are contracted (even when implementing more than one interface). Having the chance to add semantical contracts on an interface base is not the worst idea in my opinion - a checkInvariants() method isn't usable in that case. In sum - i believe that contracts in fact DO increase the semantic expressiveness of modules in an easy way and have to admit that there would be better ways of declaring contracts with a full language support of Design By Contract - making SpringContracts in a way dispensable - but that sacrifice would be a price to pay! Mario

Having a way to notate contracts in a typed way would be of course a better way!

Easy: write tests. I fail to see what putting contracts inside the application code buys us. As I said before, either the pre/postcondition/invariant is easy to express, and you can just use assert() inside your code, or it's more complex logic, in which case you're better off using tests to verify it (tests also happen to be more expressive than DBC will ever be). In my experience, DBC becomes quite useless in the real world, where invariants are sometimes extremely hard to express. Don't get me wrong: it's a great way to learn about algorithms and concepts such as terminations, but it's of little value beyond Stack and Array. -- Cedric http://testng.org

A good alternative is Contract4J!