Posted by Dean Wampler
Fri, 22 Sep 2006 02:07:00 GMT
After a longer-than-expected effort, I’m pleased to announce the v0.6.0 release of Contract4J5.
The API for writing contract tests has not changed, but the internals have been restructured considerably to improve the code quality and make it easier to configure Contract4J5 using property files and Spring Framework Dependency Injection.
The release also provides examples of using Contract4J5 with binary weaving or load-time weaving. The latter is now the preferred way to introduce Contract4J5 into a “pure-Java” environment.
For more details, see the
Release Notes in the README or browse to http://www.contract4j.org.
Posted in AOP, Java and AspectJ, Contract4J | Tags AOP, AspectJ, Contract4J
Posted by Dean Wampler
Fri, 21 Apr 2006 16:25:00 GMT
I started a discussion yesterday on the “aspectj-users” group about humane pointcut languages. The notion of “humane interfaces” in programming has been discussed by Martin Fowler and in the context of user interfaces and product design by Jef Raskin.
This conversation was a spin-off of another
thread where I made a mistake that I occasionally make. An AspectJ user wanted to apply some after advice after constructor calls in a class that has an annotation,
e.g.,
@MyAnnotation
public class Foo {
public Foo(...) {...}
...
}
He needed help writing the pointcut and advice for this case. Without repeating the whole conversation here, at one point I remarked that
call( @MyAnnotation * *.new(..) )
matches constructors annotated with
@MyAnnotation, while
call( * (@MyAnnotation *).new(..) )
matches constructors in classes where the class has the annotation.
In fact, both are invalid expressions because the first
* is for the return type and there is no return type for constructors, so the first
* shouldn’t be there. Hence, the correct statement is that
call( @MyAnnotation *.new(..) )
matches constructors annotated with
@MyAnnotation, while
call( (@MyAnnotation *).new(..) )
matches constructors in classes where the class has the annotation.
This is the sort of mistake I make fairly often and I’m sure beginners really struggle with the pointcut syntax, although it’s generally great for experts because it is both succinct and powerful. However, sometimes a more “human-readable”, that is “humane”, syntax can be a real benefit.
In fact, I’ve been thinking about expressive pointcut languages quite a bit recently, not so much in this context, but more in the context of higher-level AOP abstractions. As I said in the discussion thread, it bothers me that we discuss high-level concerns, say for example security, then turn around and write PCDs using very low-level primitives that tend to reference specific classes, methods, etc.
Of course, I’m not the only person who thinks this way and the recent work on AO interface-based programming is a huge step towards making it possible to express aspects with appropriate levels of abstraction.
I would like to comment on this issue more in future blogs, but for now, let’s return to the original problem and look at some things we might do to make PCDs more humane.
The first thing I suggested in the thread is the addition of special keywords that could be substituted for some of the wild-cards:
| Keyword |
Maps To: |
Context |
$any_return |
* |
Used for any return type |
$any_arg |
* |
Used for any one method argument |
$any_arglist |
.. |
Used for zero-many method arguments |
$any_type |
* |
Used for any type expression (class, interface, ...) |
So, our previous
PCD that matches calls to the constructors could be written
call( (@MyAnnotation $any_type).new($any_arglist) )
This is a little more readable, especially for new users, while experts will prefer the more terse form for its brevity.
As an aside, you could use a similar mechanism to support regular expression matching while minimizing the potential for confusion, as discussed here. Something like $re(/(foo|bar)$/) to match names ending in foo or bar, for example.
Let’s combine our new
PCD with
after advice, to see a little more context. We want to “bind” the newly-created
Foo instance to a variable
foo. Handling newly-created objects is
tricky.
after() returning(Foo foo):
call( (@MyAnnotation $any_type).new($any_arglist) ) {
...
}
Another approach, if we’re using the
execution join point, is the following:
after(Foo foo):
execution( (@MyAnnotation $any_type).new($any_arglist) ) && this(foo) {
...
}
However, the keywords are a small improvement. Let me suggest that a real “humane”
PCD language should read more like English. Consider this rewriting of the same two expressions, using a made-up pointcut
DSL:
after() returning(Foo foo):
call(constructors().takingAnyArgs().inClassesAnnotatedWith(@MyAnnotation)) {
...
}
and
after(Foo foo):
execution(constructors().takingAnyArgs().inClassesAnnotatedWith(@MyAnnotation))
&& bindNewlyConstructedObjectTo(foo) {
...
}
This syntax is inspired by the syntax of mocking frameworks like JMock and equivalents in Ruby. Certainly my toy DSL could be improved; I made it up on the fly during the discussion thread yesterday.
However, because it reads like English, it is very self-documenting, making comprehension easier by AspectJ neophytes and even experienced AspectJ users who are new to the application.
I think it’s useful to remember that most code is write once, read many. We may not like to type a lot, but a literate style pays dividends over time.
Note that the syntax of this DSL and the standard syntax express essentially the same pointcut language “abstraction” for AspectJ.
So, I think there is a place for a more “humane” form of the AspectJ pointcut DSL. Similarly, I think that we need DSLs appropriate for higher-level AOP abstractions (e.g., at the design level) and ideally AOP DSLs that are domain-specific for non-trivial domains.
Read more...
Posted in AOP, Java and AspectJ | Tags AOP, AOSD, AspectJ, Design, Humane | no comments | no trackbacks
Posted by Dean Wampler
Thu, 13 Apr 2006 18:34:00 GMT
This is my inaugural blog hosted on my own web sites. My previous blogs can be found here.
My article on Contract4J went live on Tuesday, April 11 at IBM’s developerWorks.
In the article, I introduce Design by Contract and describe how Contract4J supports DbC in Java, using AspectJ under the hood. I end the article with a discussion of the emerging trends in aspect-oriented design using interfaces. That is, how the familiar interface-based design we’re used to in OOP is being extended to support aspects.
I intend to explore Aspect-Oriented Design in more detail in coming blogs. Please stay tuned!
Posted in AOP, Java and AspectJ | Tags AOP, AspectJ, Contract4J, developerWorks | no comments
