In building Gregari I’ve tried to leverage two basic concepts
- Generate as much as I can via Xdoclet (or Castor) at build time, ideally any boilerplate code.
- Write the rest but leverage abstract classes or Java5 Annotations/Interceptors.
Assuming one is familiar with Java Annotations… prior to the Java 5 release if you wanted to use the annotation concept you could do the following, i.e.
- at build time use Xdoclet tags @blah.blah-blah my-attribute=”hi” within the JavaDoc section
- at runtime use Spring AOP Annotations (amongst others) by @@MyAnnotation( my-attribute=”hi”)
But then came Java 5 with built-in annotation support and so I converted all of my Spring annotations over to the Java 5 standard. But I still had a lot of ugly Xdoclet tags remaining in my code. After reading Manning’s “Seam In Action”, i.e. http://www.manning.com/dallen/… I was struck on how JBOSS Seam leveraged Java5 Annotations. So I basically got rid of my mixture of XDoclet tags (for code generation) and Java5 Annotations (for runtime)… and instead went to exclusively Java5 Annotations. It even sped up XDOCLET2 code generation by approximately a factor of 10. The downside is perhaps I went overboard… but not sure what else to do…
So I use Java5 Annotations for the following major concepts:
- Taxonomies – I have two major taxonomies, i.e. to distinguish one type of objects from another (i.e. business objects from data access objects, mainly done for code generation purposes). The other major taxonomy is for what capabilities the object supports so that any cross cutting Interceptors can act accordingly. Essentially these taxonomy annotations are “marker interfaces”. These taxonomy annotations are both at the class and method levels… where appropriate.
- Metadata – In order to customize/configure/personalize enterprise applications (such as in a SAAS model where you can configure the application… you first need to know what’s possible. By embedding the code with annotations… it should centralize code/metadata in one place. As a part of a build process (or other) the code can be parsed and the metadata stored in configuration files, databases, etc.
- JEE specific annotations (EJB’s, Transactions, Entities)
- Hibernate (ORM, Validation and Search)
- JBOSS Seam specific annotations
- System management – One of the issues for 24/7 Operations (DFO-Design For Operations) is that developers write the code but operations supports it (yet there’s little hand off between the two groups). What if development annotated their code to create health models, instrumentation models, task models, etc. so that a management system could be generated to support the code being developed. Perhaps just another way to support Extreme Programming, i.e. your code is self documenting. Normally this is just for other developers… but operation/development engineering (i.e. developers who create software to optimize system management) is another audience.
- Interface generation – A Java best practice is to have all concrete objects implement an interface. Other objects reference the interface instead of the concrete object. This allows many cool things, i.e. mock objects, etc. Normally the interface is hand written but… if the concrete interface were the master… you could generate its supporting interface (assuming this is the first implementation of that interface). Interface generation would be optional based on if the marker annotations were present or not. So… this is done at the class level to signify an interface as well as the method level to signify what methods should be included in the interface.
- Method level behavior, i.e. should encryption/decryption be implemented, caching, user-defined-fields (UDF’s), history, notes, addresses, list of values (enumerated values), security, etc. JEE Interceptors will detect this and act accordingly.
- Page level behavior, i.e. by leveraging the Java5 concept of package-info.java’s at the package level, I can implement component level annotations. All sub-packages presumably are of the same “component”. And thus my leverage component component level behavior (where applicable). I use this at the system management level to create statistics by component.
In subsequent blog postings (to this one) I’ll give specific examples of what this looks like.
