{ Category Archives }
Design
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.
What is Success in the Enterprise?
I got a comment on my James McGovern::Thought Leadershit blog post earlier today, ostensibly from James himself, that I feel compelled to respond to:
Don’t have such a low threshold for measuring success. Success is Java, .NET, XML, Web Services, SOA, etc. Ruby has potential and an upward trajectory but can’t yet be called successful.
In terms of getting large enterprises whose primary business model isn’t technology involved in Ruby benefits Ruby by the simple fact that this demographic represents 90% (The masses) of all IT folks. More importantly, this same demographic has 590% more capital than the 10% that Ruby currently has. Capital allows folks to accelerate the growth, features and adoption of all the hard work the Ruby community put into it.
You should noodle this thought and even if you agree slightly, you should amplify it in your next blog entry…
I slightly agree with the above, mostly with the demographics and the problems those demographics cause. Not sure about the math…. However, what I really want to address is not the demographics… those are a causal by-product the misunderstanding evident in these statements:
Don’t have such a low threshold for measuring success. Success is Java, .NET, XML, Web Services, SOA, etc. Ruby has potential and an upward trajectory but can’t yet be called successful.
My definition of success in the enterprise has absolutely nothing to do with the technology used. Technology is nothing more than an enabler for the solutions set forth by the organization to accomplish its goals. Java, .Net, XML, Web Services, SOA, and yes, even Ruby are all just tools (and fads) that we have at our disposal at this point in time that help accomplish these goals. They are not the success factors themselves.
I am much more concerned with providing value and efficiencies to the organization. Solving problems matters more then the technology used.
What I value more than the programming language
- Right sized solutions to the right problems. It is so easy to build the wrong sized solution, buts worse when its not even the right problem.
- Simplicity Simplicity is a mindset. But lets not mistake it for “Do the simplest thing that could possibly work.” Do the simplest thing that can be maintained for 10 years.
- Maintainability I am sick and tired of hearing about brand spanking new projects using Struts, because thats what people know. But, on the other hand, if you can see struts still being used (and supported) at the EOL for your project, by all means. Typically I prefer to weigh my decisions on what is the latest, with the most likelyhood to succeed. Failing that (which most frameworks do), I want to know how bad (unreadable) the frameworks code is… good sign of how easy it will be to fix problems when you are on your own.
- Flexibility I want flexibility in my language, my IDE, my organization, and not least of which: my system’s architecture.
- Structure But, you cannot be all flexibility. Think of your app as a piece of Bamboo. Simple, elegant, solid, and flexible in the wind.
- Understanding The team must be able to read my code. Everyone (devs, admins, users, everyone) must understand the vision of the app. Without this, you have people doing things that will invariably be incongruent with the vision and goals of the team and organization.
In essence, I want everyone to think about what they are doing, and try to come up with the simplest, most maintainable system they can. I think that that is difficult in every language, and in fact I think it transcends language. This is the Silver Bullet problem (there isn’t one). So, all I can do is try to design the system the best I can, and then use a language that gives me the best Thought to Expression ratio for my solution.
Thought to Expression Ratio
I’ve mentioned this a couple of times before. Thought to Expression Ratio is a very subjective measure of how much expression is needed to convey a thought, with a ratio of 1:1 being perfect expression of a thought and 1:0 being the no expression capable of the thought.
As an example, remember the old saying “A picture is worth a thousand words”. Now, if only we had a programming language that could do that. Well, we do in a way. This is were Domain Specific Languages come into play. We can bring the programming system closer to the thoughts of the organization, and in so doing, raise the Thought to Expression ratio. And right now, there are few languages that give me the flexibility to define a DSL easily, with Ruby being the one with the most interest pointed in its direction.
Durability
By day I am a Enterprise Java developer/architect. By night I play with Ruby, and Smalltalk, and other languages that intrigue me. Why? Because Java will not be around forever. Java is indeed the next COBOL. In fact, so is Ruby. And C++, and VB, and .Net. and ….
I am a proponent of Ruby, though not as much as one might think given some of my previous posts. I value the flexibility that Ruby gives me, but I also hate the sheer power with which Ruby allows a person to write the most horrendously ugly code this side of perl. Indeed, this is what could very well be the downfall of Ruby.
Success
In the end, success on an Enterprise application can only be determined by the organization and teams involved. This is a hard problem, especially the more stakeholders involved in the definition of success. And, to me, that has nothing to do with the languages involved.
Epigrams on Programming
Just ran across Alan Perlis’s Epigrams on Programming:
This one goes with my recent rant on interfaces:
The string is a stark data structure and everywhere it is passed there is much duplication of process. It is a perfect vehicle for hiding information.