Discussions

News: Annogen: Overriding JSR175 Annotations and more

  1. Annogen is a new framework which allows you to override JSR175 Annotations. It can also help you maintain JDK1.4 support while you migrate your code to JSR175. In a nutshell, Annogen generates an Annotation proxy layer that lets you:

    Override JSR175 Annotations
    ...with data from XML or arbitrary plugin code that you write.

    Migrate JDK1.4 code to JSR175
    ...by translating javadoc tags into Annotations

    Work with popular introspection APIs
    ...including Reflection, Javadoc-Doclet, QDox, and APT-Mirror.

    For more information, please go to http://annogen.codehaus.org.

    Threaded Messages (14)

  2. Great work Patrick - Annogen rocks!

    I'm using it with great success on a project with Gram and it works like a charm. I was extolling its virtues at JavaPolis in a bar last night :)

    I'd love to see the Spring folks move to Annogen/JAM for their metadata...

    James
    Protique
    Enteprise Open Source
  3. This looks really promising, and after James' quick introduction last night at JavaPolis, this looks like something we could use in Spring to overcome some of our internal metadata problems.

    Hopefully I can find some time to try and integrate it.

    Rob
  4. JBoss AOP Annotation Compiler[ Go to top ]

    JBoss AOP has an Annotation Compiler that can take doclet tags and embed them in a JDK 1.4 class file. It has been maturing quite nicely as we released it almost a year ago and we use it in quite a few places where we want to support JDK 1.4 but have the power of annotations.

    You define annotations the same way you do in JDK 5.0: as interface minus the "@" and minus the "default". All annotation types are supported: Enums (if you follow an implementation pattern that parallels JDK 5.0), inner annotations, classes, primitives, etc...

    Our AOP framework allows you to override or add an annotation to an existing class, or to have runtime overrides that don't modify the actual class file.

    For more info, see:

    http://docs.jboss.org/aop/aspect-framework/reference/en/html/annotationcompiler.html


    Regards,

    Bill
  5. JBoss AOP Annotation Compiler[ Go to top ]

    I have to say the same thing as Bill.

    We provide this kind of feature wihtin AspectWerkz - strongly typed annotation in Java 1.4, nested annotation, arrays, type reference etc are supported.
    What we provide (still unique?) is an Eclipse plugin for Java 1.4 - which is neat to have the annotation compilation of the JavaDoc annotations beeing handled when Eclipse build.

    What we don't do for now is overriding - since we have some design decision to take on that from an AOP perspective: introduce annotation could perhaps fit for this "override feature".

    Going thru the cvs, it seems that AnnoGen requires the user to write a concrete implementation of a class with getter and setters (thus fields) just to access the annotation elements [the @AnnoGenBeanInfo or something which annotates the Java 5 annotation]. It seems a bit overwork to me - could n' t you provide an implementation based on dynamic proxies ? [thus requires nothing from the user since Java 5 annotations are compiled into regular interfaces]

    I perhaps missed a point there.

    Alex
  6. JBoss AOP Annotation Compiler[ Go to top ]

    Right, so to clarify: Annogen's focus is on overriding annotations, i.e. where you don't like the annotations that were declared at compile time. As a byproduct, it can provide some help with the 1.4 case - i.e., you can add annotations that weren't there at all compile time) - but that isn't really the main problem Annogen is trying to solve.

    So, yes, if what you need you need is a 1.4-compatible syntax for declaring 175 annotations, and you don't care about runtime overrides, then the aproach you and Bill describe is definitely the way to go.


    Going thru the cvs, it seems that AnnoGen requires the user to write a concrete implementation of a class with getter and setters (thus fields) just to access the annotation elements [the @AnnoGenBeanInfo or something which annotates the Java 5 annotation].


    Well, you don't have to write the implementation by hand - there is a code generator in the 'generate' module that will do it for you.


    It seems a bit overwork to me - could n' t you provide an implementation based on dynamic proxies ?


    Yeah, I played around with doing it that way as well, but I found it to be a bit awkward to use. In my own use cases, I need to introduce a fair amount of custom override logic for some fairly complex 175 types. Implementing InvocationHandlers to provide the new values wasn't very much fun. It's a lot nicer to be able to simply call some strongly-typed setters and adders on the code-generated impls.

    Maybe there is approach here I didn't consider, though? Would be interested to hear any other thoughts you may have on this.


    Cheers,
    -p
  7. JBoss AOP Annotation Compiler[ Go to top ]

    I have to say the same thing as Bill.We provide this kind of feature wihtin AspectWerkz

    One of the things I like about Annogen and JAM is that its not dependent on a particular AOP framework - its just a simple Java library I can use anywhere I need to process and/or transform metadata, annotations or doclet tags in a simple polymorphic interface that works on Java 1.4 and 5 - irrespective of whether I use an AOP framework or which one I use.

    While AOP is interesting and has may uses; i see metadata as being more useful in more circumstances. Or to put that another way, having a single, reuseble metadata processing engine is really important. When it comes to AOP choose the right one for the job based on what you need (AspectJ, AspectWerkz, dynaop, JBossAOP etc).

    (ducks AOP flames...)

    James
    Protique
    Enteprise Open Source
  8. JBoss AOP Annotation Compiler[ Go to top ]

    I have to say the same thing as Bill.We provide this kind of feature wihtin AspectWerkz
    One of the things I like about Annogen and JAM is that its not dependent on a particular AOP framework

    Just because our annotation compiler comes packaged with our AOP framework doesn't mean you have to use our AOP framework.

    Bill
  9. JBoss AOP Annotation Compiler[ Go to top ]

    I have to say the same thing as Bill.We provide this kind of feature wihtin AspectWerkz
    One of the things I like about Annogen and JAM is that its not dependent on a particular AOP framework
    Just because our annotation compiler comes packaged with our AOP framework doesn't mean you have to use our AOP framework.Bill

    FWIW personally I'm not terribly interested in an annotations compiler; I'm more interested in a nice & clean polymorphic API to the metadata itself - be it in doclet / annotation form in source / bytecode, or in some other format (XML, database etc).

    So far Annogen/JAM is the neatest API and implementation of such a thing I've found so far.

    James
    Protique
    Enteprise Open Source
  10. Am I the only one who feels that if annotations need overriding, it's probably a wrong use of annotations? Or is it becoming accepted practice to use annotations as if they're configuration parameters?
    Just wondering.

  11. Am I the only one who feels that if annotations need overriding, it's probably a wrong use of annotations? Or is it becoming accepted practice to use annotations as if they're configuration parameters?


    Right, the potential for annotations and overrides to be abused has been discussed quite a bit. I definitely do agree that there is cause for concern about the corrosive effect that annotation may have on the wall between 'development' and 'deployment' in J2EE.

    But I think there are other sorts of use cases where it is less clear-cut. To illustrate, I'll give you one of mine. :)

    I wrote Annogen about a year ago as part of my work on xml-beans where I was writing a tool to do 'start-with-java' binding for XML (a la Castor). There, you often want users to be able to customize the binding rules, e.g. change the XML element name that is generated from a class.

    Annotations are of course a very natural way for people to specify that kind of thing, and I would say about 95% of the time that is what people want to do.

    But I also have a 5% case where people want to do XML binding on java some beans whose original author did not intend for them to be fed into my tool. Those classes don't contain any annotations, yet those 5% of my users still be able to customize the element names.

    This leaves me with a difficult choice to make:

    a) Tell the 5% tough luck, you can't do that

    b) Tell the 95% that I don't support annotations at all and they have to use a clunky XML file for all customization

    c) Write two completely different mechanisms for handling customization, one for the 95% case and one for the 5% case

    d) Provide a facility for the 5% case to override/add annotations so that my code can treat them just like the 95% case.

    If I want to make everyone happy and still maintain some robustness in my code, I don't see an alternative to d.

    Cheers,
    -p
  12. c) Write two completely different mechanisms for handling customization, one for the 95% case and one for the 5% case
    d) Provide a facility for the 5% case to override/add annotations so that my code can treat them just like the 95% case.If I want to make everyone happy and still maintain some robustness in my code, I don't see an alternative to d.

    I think something more along the lines of (c) is valid:

    e) Write the basic functionality without annotations, then introduce a "shortcut" annotation mechanism. Legacy code can use the non-annotation approach, anything else can benefit from the annotation approach if it want to.

    As a general rule, annotations are supposed to be used when the binding between annotation value and code element is always there. If it's not always meant to be there, why have an annotation? Go retro and prescribe a deployment descriptor or property file, overridable by annotations.

    I just feel annotations can be tricky enough, let alone having to deal with annotations that aren't actually in code. I'm sure there are valid uses (such as getting around a legacy framework based around annotations), but I would like to see more examples before I was sold on it.
  13. Am I the only one who feels that if annotations need overriding, it's probably a wrong use of annotations? Or is it becoming accepted practice to use annotations as if they're configuration parameters?Just wondering.

    In our EJB 3.0 implementation, we're actually using annotations as our configuration object model. Since you are allowed to extend and implement an annotation in Java, this allows us to have one object model instead of having an annotation processor that takes annotations and converts them to an intermediary object model.

    The way we will have it working is that the XML processor for the ejb-jar.xml file will allocate annotations and add those annotations as needed to the annotation override facility. Then the EJB container works with annotations as the configuration object model delegating to the annotation override facility.

    Using our AOP framework, we define the default annotations for a given container type (Stateless, Stateful, etc...).

    i.e.:

          <annotation expr="!class(@org.jboss.ejb3.PoolClass)">
             @org.jboss.ejb3.PoolClass (org.jboss.ejb3.ThreadlocalPool.class)
          </annotation>

    This says that if the PoolClass annotation is not defined on the bean class, provide a default value.

    All this makes the of our EJB 3 container very very simple in regards to configuration as all the interceptors and components that make up the EJB container have a consistent way to obtain configuration from a variety of sources while having the same configuration model.

    Bill
  14. Should annotations be overriden?[ Go to top ]

    In our EJB 3.0 implementation, we're actually using annotations as our configuration object model.

    Personally, I agree with Michael Mahemoff and Nils Kilden-Pedersen, the way I that understand annotations being used in EJB 3.0 makes me uneasy. For example, what if you want to use two instances of the same class with two different configurations? Do you have to use the EJB 2.1 deployement descriptors for that, or is there simplified descriptors in 3.0?

    Also, it seems premature for a standard to have a heavy use of annotations, when not many people have experience with them yet to figure out the annotations "best practice". As far as I can see, the chances of getting the use annotations correctly at first are very slim. And if we want to have the future versions of EJB benitifs of those best practices that we'll eventually figure out, the EJB 3.0 Model with annotation has a serious risk of causing a backward compatibility pain.

    Guillaume
  15. Another clarification - I just notice now that someone at TSS added some information to the item summary that is not correct:

    Annogen is not built on top of JAM (it does _support_ JAM, along with Reflection, Mirror, QDox, et al.).

    Also, it does not do any kind of bytecode translation. This is probably why there was some confusion earlier about what Annogen does.



    Annogen is a new framework which allows you to override JSR175 Annotations. It can also help you maintain JDK1.4 support while you migrate your code to JSR175. It is built on top of JAM (which all came from BEA). Annogen allows you to take JDK1.4 code and translate into Java 5 bytecode with annotations plugged in.