SpringContracts – Design By Contract with seamless integration into Spring is now Open Source

it’s now about one and a half year ago that i was starting to deal with the question of how to increase the semantical expressiveness of software, mainly written in java.

of course you have interfaces in java to describe a kind of ‘contract’ on what methods an implementor of this contract have to provide to clients. but this kind of contract is way to poor in order to describe the semantical behaviour of a component, interface or class. it is easy to implement an interface with a completely different behaviour than the intended one (for example, i could implement a pop() method of an interface ‘Stack’ which delivers the first element at bottom of the Stack instead the one on top and though the interface ‘contract’ is statisfied).

we not only need contracts on a syntactical level but contracts on a semantical level in order to provide software with higher expressivenes and thus higher reliability.

Design by Contract to the rescue

Design by Contract (DBC) is a concept that tries to solve the mentioned problem in that it let’s you express so called invariants, preconditions and postconditions (for further information have a look at wikipedia). first invented by Bertram Meyer and supported in the programming language Eiffel, the idea of DBC has nowadays reached out into the community of software development.
not for nothing the longing for DBC support in java stays at no. 2 in the top 25 of RFE’s (request for enhancements) at Sun’s Developer Network.

with the rising of the Spring framework and with it a new major recognition of AOP, there was one half of a solution for DBC. the other half comes with the tiger release of java, in that it provided support for Annotations.

SpringContracts – Design by Contract

given this, i startet to play with the offered features and ended up with a solution i called SpringContracts.
SpringContracts is based on the mentioned technologies. you can annotate invariants, preconditions and postconditions using annotations. the conditions itself can be expressed by a pluggable specification language (at this time, SpringContracts ships with support for Expression Language (EL), OGNL and Groovy, with Extensions due to first order logic – like all quantor, exist quantor or implication).
at runtime, there is an aspect which will check and validate the semantical compliance of the expressed contracts.

But why the Spring in SpringContracts?

Spring framework is the ideal partner when it comes to configuring SpringContracts.
for example you can define on how to react on contract violations. maybe you want to fail fast (maybe not the worst idea) and throw an exception, maybe you want to content yourself with a log entry – it’s up to you and a question of a simple configuration setting in Spring’s ApplicationContext.
mentioned Spring’s ApplicationContext – you have (should you be in need of) a whole bunch of easy to configurable options:

you could deactivate for example preconditions (usually the part of the contract, the client have to fulfill) and only check invariants and postconditions.

you could switch from EL (default) to Groovy in order to use your preferred language to specify conditions.

you could define so called named constraints and use them all over in any of your conditions.

you could define your contracts in an external source (Spring’s ApplicationContext) and apply them to any of your wanted classes or interfaces without touching them / ‘polluting’ them with annotations.

did i get you?

as you have certainly allready noticed, i did this enumeration of features to bark your interesst in SpringContracts ;o)
you now may have an idea that a solution like SpringContracts can add value, increasing the semantic expressiveness of software.
you can annotate your classes or interfaces with invariants, preconditions and postconditions, that helps you to express the required behaviour, which will reach out beyond syntactical correctness.
this kind of specification is more than a plain documentation in that it can be validated at runtime. this said, contracts are spec n’ checks.

for all of you, who would like to take a closer look at SpringContracts – you will find the project homepage hosted at http://springcontracts.sourceforge.net.

every feedback is highly appreciated and … by the way … i’m in search of some ‘combatants’ who may like to contribute … :o)



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: