Contract4J5 v0.6.0 Released
After a longer-than-expected effort, I just released v0.6.0 of Contract4J5.
Contract4J5 is a tool for doing Design by Contract in Java 5. The test conditions are defined using Java 5 annotations. AspectJ is used to implement Contract4J5.
You can find out more here and here. The main web site is http://www.contract4j.org.
!commentForm
Dean, Dean, Dean.
Circular dependencies? Six of the little blighters? From a code-mentoring shop? What would mum say ...
.ed
It used to be worse. ;) A drawback of AspectJ[?] is some of the hoops you have to jump through to reference aspect "objects" from Java, which are singletons by default, etc., etc. I also left in a few wierd relationships to support configuration options. If I could have assumed just Spring DI, then several of the hacks would go away. Anyway, I didn't look specifically for circular dependencies, but I guess I'll have to now ;). - dean
So I took a look at the dependencies with JDepend and I was able to remove most of them with some simple refactorings of the package structure (using Eclipse...). I'll fix the others later as I work on the next set of enhancements. I appreciate the "nudge" to look at the dependencies. C4J[?] isn't intended to be a "paragon of design virtue", but why not make it the best it can be? ;) To be honest, I hadn't really tried very hard to prevent cyclic package dependencies before because they weren't causing any real pain. Eventually, they would become painful if C4J[?] got big enough. As I discussed in my release notes, most of the work on this release was to fix more pressing "smells". The cyclic dependencies weren't very smelly, yet.... - dean
Circular dependencies? Six of the little blighters? From a code-mentoring shop? What would mum say ...
.ed
It used to be worse. ;) A drawback of AspectJ[?] is some of the hoops you have to jump through to reference aspect "objects" from Java, which are singletons by default, etc., etc. I also left in a few wierd relationships to support configuration options. If I could have assumed just Spring DI, then several of the hacks would go away. Anyway, I didn't look specifically for circular dependencies, but I guess I'll have to now ;). - dean
So I took a look at the dependencies with JDepend and I was able to remove most of them with some simple refactorings of the package structure (using Eclipse...). I'll fix the others later as I work on the next set of enhancements. I appreciate the "nudge" to look at the dependencies. C4J[?] isn't intended to be a "paragon of design virtue", but why not make it the best it can be? ;) To be honest, I hadn't really tried very hard to prevent cyclic package dependencies before because they weren't causing any real pain. Eventually, they would become painful if C4J[?] got big enough. As I discussed in my release notes, most of the work on this release was to fix more pressing "smells". The cyclic dependencies weren't very smelly, yet.... - dean
or is it just a tool for client-provider DbC[?]?
E
I'm not sure I know what you mean by client-provider DbC[?]. Concerning inheritance, complete support for the proper contravariant behavior of preconditions and covariant behavior of postconditions is not implemented, although a reasonable "80% solution" is planned. The tool will apply parent-class tests to subclasses. However, because Java annotations on methods can't be inherited, you must currently add the annotations to the corresponding derived-class methods. You can leave the test expression off; C4J[?] will walk the inheritance tree to find it. I'm also considering a runtime fix for this limitation to remove the requirement to add the annotations. It would add noticeable run-time overhead, but the more correct behavior would justify it, I think. These are several of the reasons it is not yet considered "1.0". - dean
E
I'm not sure I know what you mean by client-provider DbC[?]. Concerning inheritance, complete support for the proper contravariant behavior of preconditions and covariant behavior of postconditions is not implemented, although a reasonable "80% solution" is planned. The tool will apply parent-class tests to subclasses. However, because Java annotations on methods can't be inherited, you must currently add the annotations to the corresponding derived-class methods. You can leave the test expression off; C4J[?] will walk the inheritance tree to find it. I'm also considering a runtime fix for this limitation to remove the requirement to add the annotations. It would add noticeable run-time overhead, but the more correct behavior would justify it, I think. These are several of the reasons it is not yet considered "1.0". - dean
Add Child Page to Contract4j5060Released