{ Category Archives }
Software Development
Groovy + Annotations + Aspects
I have been doing a lot of digging into Groovy and DSLs lately, getting ready for my OSCON talk next week.
The Groovy language has great built-in support for creating DSLs. Along with its dynamic nature, Groovy has the “use” keyword for working with categories, and coming in 1.1, the ExpandoMetaClass if you want to complete.
“Use”ing Categories
Categories help you do scoped “extension” to normal every day objects. An example is in order:
So, inside the use block, there is now (effectively) a new property on the Integer class, called tacos, that will return a string describing your delectable entree. This is a very powerful technique, and is very useful for developing your own expressive syntax.
One drawback to this technique is that you have to define where you are using it. Use can be extended into closures, but does not always extend into predefined methods.
-
-
}
-
-
-
// However, you can do this from Java (or Groovy):
-
-
-
// calling methods on a class:
-
class A {
-
4.tacos // has not been evaluated yet
-
}
-
}
-
-
-
// but you can do this:
-
}
Groovy + Annotations + Aspects = annotated “use” clause
I was talking about Groovy Categories with Blaine Buxton, and was telling him that I did not like having the “use” block inside my DSL code, and wanted a more transparent approach. He suggested that perhaps an Annotation and an Aspect would do what I was looking for.
With the 1.1-Beta1 Release, Groovy has built in support for Java Annotations, and since Groovy compiles down to byte code, there is implicit support for Aspects. Putting these two things together allows us to create an annotation for a more powerful use:
With a simple annotation, @Uses(category=[list of category classes]), we now can define them for any method we want, without having to put them into the method body.
Here is the Annotation code:
-
package com.nimblelogic.groovy.dsl;
-
-
import java.lang.annotation.Inherited;
-
import java.lang.annotation.Retention;
-
import java.lang.annotation.RetentionPolicy;
-
-
@Inherited
-
@Retention(RetentionPolicy.RUNTIME)
-
public @interface Uses {
-
public Class[] category();
-
}
And here is the Aspect code:
-
package com.nimblelogic.groovy.dsl;
-
-
import groovy.lang.Closure;
-
-
import java.util.ArrayList;
-
import java.util.List;
-
-
import org.aspectj.lang.JoinPoint;
-
import org.aspectj.lang.annotation.SuppressAjWarnings;
-
import org.aspectj.lang.reflect.MethodSignature;
-
import org.codehaus.groovy.runtime.GroovyCategorySupport;
-
-
public aspect UsesAspect {
-
-
pointcut allMethods(): call(@Uses * *(..));
-
-
@SuppressAjWarnings
-
List< class > classes = getCategories(thisJoinPoint);
-
-
Object result = null;
-
if ( classes.isEmpty() ) {
-
result = proceed();
-
} else {
-
result =
-
GroovyCategorySupport.use(classes,
-
new Closure(thisJoinPoint.getTarget()) {
-
@Override
-
return proceed();
-
}
-
});
-
}
-
-
return result;
-
}
-
-
@SuppressWarnings(“unchecked”)
-
private List< class > getCategories(JoinPoint thisJoinPoint) {
-
List< class > classes = new ArrayList< class >();
-
-
// get class level categories (if any)
-
Class cl = thisJoinPoint.getTarget().getClass();
-
-
addCategories((Uses) cl.getAnnotation(Uses.class), classes);
-
-
// get method level categories (if any)
-
if ( thisJoinPoint.getKind().equals(JoinPoint.METHOD_CALL)) {
-
MethodSignature sig = (MethodSignature) thisJoinPoint.getSignature();
-
addCategories((Uses) sig.getMethod().getAnnotation(Uses.class), classes);
-
}
-
-
return classes;
-
}
-
-
-
private void addCategories(Uses uses, List< class > classList) {
-
if ( uses != null ) {
-
Class[] classes = uses.category();
-
for(Class cl : classes)
-
classList.add(cl);
-
}
-
}
-
}
One thing to note when working with Annotations / Aspects in Groovy: you have to keep track of the build order. I struggled for a while to figure out why I was not seeing the annotation in my Groovy classes. It was because it had not been built yet! I ended up having to split my compilation into 4 parts:
- Build the Annotation
- Compile the Groovy code
- Compile my other Java code (just test code)
- Weave the Aspects
Uncle Bob on XML
I’m trying to catch up to my overflowing Google reader, and have just seen Uncle Bob’s posting on XML “The Hidiocy of XML Languages“:
Look, writing in XML is hideous. It’s wordy, it’s error-prone, it’s arcane, it’s redundant, it’s redundant, it’s redundant, it’s… HIDEOUS! To make matters worse, we have been embedding OTHER languages INSIDE this horrible container. EGAD! YIKES! ZOUNDS! FORSOOTH! This is just plain nuts, stupid, idiotic, retarded, poo-poo-headed, silliness!
All I can say is AMEN!!! And it just gets better.
I’ve never been a fan of XML. Yes, it does have benefits as a data transfer mechanism, though even that is questionable. Take the ACORD standards as an example. This is the standard schema for defining interoperability standards for Insurance Company operations/transactions (Quotes, etc). Fair enough, this can be very useful for companies to work together. However, each insurance company has it’s own way of doing business, and may not use the schema in the same way. ie a Policy for this company (or even Line of Business) may not mean the same as for another. So, how interoperable is that?
XML sucks. Its better than binary, or — shudder — ASN.1, but it still sucks, and should not be used as a language. Thank you Uncle Bob for your rant! It makes me that maybe, just maybe, I’m not as insane as people think when I tell them that I hate writing logic in XML.
Simple Groovy script to remove .svn directories
The other day I needed to remove a mess of .svn directories from a project as I moved it from my personal box (using svn as the soure control) to the client’s source control system. This is a fairly frequent task, so attempting to be a “productive programmer” I decided that I would take the time to write a script to do this for me. After testing, it took about an hour to write… mainly because I tried to be too fancy, and tried a few things in Groovy I had not seen before. Overall, it was an hour well spent:
14 lines. I really like the eachDir and the eachFile methods on the File object… and there is even an eachFileRecurse. All I can say is: where the heck is the eachDirRecurse??? Oh well. It was still a good learning experience, and now I have a malleable tool next time I run into something similar.