Discussions

News: To Annotate or Not?

Bookmark and Share Get thread feed

  1. To Annotate or Not? (11 messages)

    • Posted by: Doug Clarke
    • Posted on: November 01 2004 14:49 EST
    Java 2 Standard Edition (J2SE) 5.0 is now a reality, annotations have become popular, and the Java metadata feature it introduced is being touted with much fanfare as being somewhere between a new and better way to develop applications and a full-scale programming revolution. Whatever it is, it certainly deserves exploration as well as some tire kicking to see exactly how it stacks up against the current metadata technology (XML) we all know and love, or love to hate.

    This article makes some comparisons between the two paradigms of storing and reading metadata and considers the advantages and disadvantages of annotations. Code examples help explain some of the issues concretely.

    Full OTN Article: To Annotate or Not?

    The use of annotations and/or XML formatted meta-data is being discussed on several expert groups and it would be interesting to get feedback from the developer community at large as to how they see this technology being best used.
    Reply to this

    Threaded Messages (11)

  2. To Annotate or Not?[ Go to top ]

    So what is the cost of brevity? Specifying the metadata beside the source instead of in a decoupled XML file has certain repercussions.

    I don't think this is a real issue. The annotations can act as "keys" within a container environment. A property of a bean may be annotated that it wants to use "employeeDataSource" and the container can then provide the datasource based on the annotation-- basically fill in the blanks. BEA's pollinate project is kind of like this and it's not hard to conceptualize Spring in a pure annotated environment.
    Reply to this Reply to original

  3. To Annotate or Not?[ Go to top ]

    I understand your point, but unfortunately there are far too many cases where even what you described is too tightly coupled. In some enterprise environments, developers don't have control over things like datasource names (because they're considered deployment or admin details). In this case, it is better to have the datasource name specified outside of the code. This is probably a lot more common than you might think. Consider deploying an application to a client's production environment. Companies can be really anal about what can get changed in their production environments, and its better to be able to adapt the application to the environment than the other way around.

    I understand the problems with xml-based configuration, but I think the main culprit is overly verbose XML. Compare the tedious J2EE specifications for config files with something like Hibernate or Webwork. In the former case, XML is a real pain in the ass. In the latter, it's extremely concise and easy to understand.

    Despite the recent rush to annotations, I still think that it is better to keep certain details out of code so that they can be modified as necessary. IMHO this approach leads to much looser coupling, and thus greater code flexibility. You do have to watch, however, that your config formats are easy to deal with.
    Reply to this Reply to original

  4. A stupid question[ Go to top ]

    this approach leads to much looser coupling, and thus greater code flexibility. You do have to watch, however, that your config formats are easy to deal with.

    Dear, Drew McAuliffe.
    I read and understood your good opinion.
    But, I don't know the words, "IMHO". :)
    Reply to this Reply to original

  5. A stupid question[ Go to top ]

    IMHO = In My Humble Opinion
    IMNSHO = In My Not So Humble Opinion
    Reply to this Reply to original

  6. Thanks, han theman!![ Go to top ]

    You are so kind! :)
    Reply to this Reply to original

  7. To Annotate or Not?[ Go to top ]

    Yup. Sun make it real pain to do the deployment XML so that they can introduce annotation to fix it. The annotation can make code/deployment coupling so strong that Sun can come out with a new way (annotation interceptor in jdk 1.6? :)) for fixing it. and the cycles goes on...
    Reply to this Reply to original

  8. RE: To Annotate or Not?[ Go to top ]

    I see the value of both the developer simplicity of annotations (provided they are minimal with good defaults) and also the need for the ability to use concise XML meta-data. Ideally I would like to see JSRs looking at using annotations follow a common pattern that allows for the best of both solution. The meta-data used at runtime should start with annotations (if provided) apply the defaults as needed, and then override any configuration using the XML meta-data. This would allow for enterprise developers to use as much or as little of annotations as they want and still have the flexibility and control to externalize the meta-data that makes sense. This could be for organization and roles in the development team or also for the purpose of controlling or overriding some configuration options post development.
    Reply to this Reply to original

  9. POJMM[ Go to top ]

    I still think that it is better to keep certain details out of code so that they can be modified as necessary. IMHO this approach leads to much looser coupling, and thus greater code flexibility. You do have to watch, however, that your config formats are easy to deal with.

    Annotations don't replace the out of code metada mode, it just will offer a additional way. I believe that the POJMM(Plan old Java Metada Mode) will continue like a way for update metada in run-time, or after deploy time...

    Deivson Rayner.
    from Brazil.
    Reply to this Reply to original

  10. EJB3 XML configuration format[ Go to top ]

    Will to-be EJB3 also standardize a xml-based configuration format (for dependency injection / properties) to compliment annotations for the usage scenarios Drew described? Or will it be up to each vendor to do their own thing? I missed that.

    If so, what will the format look like?
    Reply to this Reply to original

  11. EJB3 XML configuration format[ Go to top ]

    Yes, some folks are looking into how this would work at the J2EE level (the scope at which resources are used) and in fact a proposal is being circulated right now within the J2EE, EJB and other expert groups as well. I believe that it will work just as you might hope/expect it to work, where either annotations may be used, XML elements may be used or both will exist and the XML will override the @Resource annotation.

    The proposal is not final but I will say that the proposed format is consistent with the existing resource-ref elements, which is a good thing, and I would be surprised if it changed.

    -Mike
    Reply to this Reply to original

  12. Based on my Xdoclet experience[ Go to top ]

    Perhaps the experience of using Xdoclet annotations in the code to generate metadata is relevant here.

    It was really convenient in the short term. There was an immediate boost in developer producticvity.

    However, I dread the posibility of moving my ejbs to a different app server or even letting the dbas change any existing table or column names.

    I am not sure I would recommend embedding annotations in code for generateing meta data.
    Reply to this Reply to original