Code generation and Annotations

This post will be about code generation and JDK5 annotations. If you are one of the lucky ones being able to make use of the latest JDK features at work you'll surely have benefit from the many improvements such as the templating capabilities, the simplified for-loop, specialized overloading, ... and maybe even the newly introduced annotations.

For people not familiar with this concept: annotations are specific sets of meta-data used to attach more information to specific parts of a class definition such as a member field. Annotations are becoming increasingly more popular in combination with middleware such as Spring and Hibernate. If you have used XDoclet or AndroMDA before you are already familiar with annotations (albeit in another form). I will be giving examples shortly anyway.

The interesting thing with annotations, and this is what makes them complementary to regular class information, is that they do not convey class information but rather meta-information, information about information, and this is typically what you would do when modeling a class diagram in UML.

Meta-data and UML

Most people use UML to describe a static part of their domain, typically the object model. This model features classes, inheritance, associations, attributes, and so on. So far nothing special, it gets interesting when using the more advanced features such as <<stereotypes>>, @tagged.values or even the more common features such as changeability, multiplicity, query-flag, etc...

Let's, for the sake of simplicity, take a small persistable POJO with a few attributes, it could be described as follows:

Class : "Person"
Attribute id : Long
Attribute name : String
Attribute phone : String

We can now give additional information to further complete the "Person" class:

• id is required


• name is required


• phone is optional and there can be many numbers per person


• the class can be persisted

Let's see how this can be modeled using UML:

Class : "Person" @persistable
Attribute id : Long [multiplicity=1]
Attribute name : String [multiplicity=1]
Attribute phone : String [multiplicity=0..*]

As you can see this is probably the most efficient way of expressing our information, it is complete yet does not contain anything extra. The corresponding Java code, on the other hand, is a little more verbose (most of the time you'll write accessors to your member fields).

For those meta-data features that are not supported by UML (you might want to create your own sets of meta-data) you can always resort to the use of tagged values.

Unfortunately not all UML tools support tagged values that well, they should be supported on ANY possible model element.

AndroMDA

When using AndroMDA for code generation it becomes very easy to benefit from these UML features: a simple Velocity (or Freemarker) template can transform the Person class from UML to actual Java code. This is basically a one-on-one transformation, a no-brainer.

The idea of using AndroMDA with UML is to be able to most efficiently translate the business domain into a binary form, next it can be processed and more code can be produced that could be fed to a compiler or interpreter. It appears the use of annotations extends this smoothly concept.

In reality

Why would you want to make use of such features ? Well, let me give you some examples where I'm applying the stuff I explained above:

• My problem domain asks for some kind of administration GUI which can be connected to the back-end in order to perform operations on the object model. We would like to write as little code as possible for this GUI and therefore we like to have it auto-detect specific meta-data from the individual object types.
  
  
  When the GUI client deserializes class instances received from the server it can introspect them in order to detect this meta-data, it could for instance detect an attribute is mandatory or needs to adhere to some specific format in order to present the user the proper validation logic.
  


• Objects in the domain model often have attributes that do not need persistence, we call these types of objects operational data, what the persistence framework is concerned these attributes are transient.
  
  
  The AndroMDA templates have been updated to render a specific annotation for these attributes so they are treated differently on the server: all operational data is cached for performance and reused when an the same instance is loaded in a separate session.
  

I'm sure you could come up with your own specific applications, the usage is so natural one wonders why it took so long for this feature to be available in the Java programming language.