|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 20
Messages: 20
Messages: 20
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
SpringContracts 0.3 released
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: joeo@enigmastation.com
|
|
|
Message #225064
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
yippee!
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!
|
|
|
Message #225066
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: yippee!
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.
|
|
|
Message #225072
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
looks promising
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" )
|
|
|
Message #225095
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What is wrong with this approach
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
|
|
|
Message #225098
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: looks promising
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
|
|
|
Message #225103
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RE: What is wrong with this approach
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
|
|
|
Message #225104
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: RE: What is wrong with this approach
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
|
|
|
Message #225105
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RE: Re: looks promising
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
|
|
|
Message #225108
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: RE: Re: looks promising
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
|
|
|
Message #225130
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RE: looks promising
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
|
|
|
Message #225136
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: looks promising
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
|
|
|
Message #225166
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: looks promising
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
|
|
|
Message #225170
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: looks promising
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
|
|
|
Message #225180
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RE: Re: RE: Re: looks promising
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
|
|
|
Message #225182
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: looks promising
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
|
|
|
Message #225191
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: looks promising
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
|
|
|
Message #225233
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: looks promising
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
|
|
|
Message #225274
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java need to evolve
@Precondition( condition = "arg1 not empty and this.size < this.capacity" )
mmmmnnnnhhh.... we need closures
@Precondition(condition=(List arg1): arg1!=null && size < capacity)
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
