Discussions

This article by Daniel Rubio clearly explains many of the advantages Java EE 5 offers for developers, showing the advantages of the new platform's changes. Annotations, EJB3 (including persistence), and changes in the web tier (including the standardization of JSF) are the main highlights.

Meta data is a powerful programming concept, one which allows developers to specify or alter application code behavior outside of the actual programming logic. In prior Java enterprise versions, this was achieved through XML files known as deployment descriptors; however, while this allowed for such behavioral customizations, it forced even the simplest applications to fulfill such a requirement whether they needed meta data or not.
In Java EE 5, meta data can now be embedded directly in application code -- a process known as attribute programming. What was once required to be specified in additional XML descriptors can now be accomplished with in-line declarations, providing a more streamlined development process -- users of an open source Java project named XDoclet can probably relate to this concept.
This is not to say XML descriptors are obsolete in Java EE 5, they are still very much valid. As a matter of fact, XML descriptors provide a secondary and overriding mechanism to any meta data that might have been declared within application code. In other words, a Java EE 5 application server will automatically take any behavior properties declared in a deployment descriptor over those embedded in Java byte-code.

You have to be careful with meta, since it's processing and interpretation is tied to the underlying technology. In building your domain model, this might not always be a good idea, though making your domain logic tightly coupled with JEE. Some might not feel that it's a bad idea. From the small snippet that was shown on the article, the validation of the field is done through a setter annotation. If this class is not a part of the core domain, the convenience of annotating the validation logic might be a plus, if the class represents a core domain entity or VO, the issue is that you are now externalizing your business logic to a third party component. Many might not see it that way, since JEE is a standard and will be around for years to come, but I'd still be hesitant to do so. There are more valid uses for annotations, like dependency injection, persistence, etc... that annotate your domain classes with concerns that are third party framework concerns to begin with.
Ilya

You have to be careful with meta, since it's processing and interpretation is tied to the underlying technology. In building your domain model, this might not always be a good idea, though making your domain logic tightly coupled with JEE. Some might not feel that it's a bad idea. From the small snippet that was shown on the article, the validation of the field is done through a setter annotation. If this class is not a part of the core domain, the convenience of annotating the validation logic might be a plus, if the class represents a core domain entity or VO, the issue is that you are now externalizing your business logic to a third party component. Many might not see it that way, since JEE is a standard and will be around for years to come, but I'd still be hesitant to do so. There are more valid uses for annotations, like dependency injection, persistence, etc... that annotate your domain classes with concerns that are third party framework concerns to begin with.

Ilya

Well I don't mind the validation annotations unless I can't replace or add new validators (note : I don't know if it's the case in Java EE 5).

I'm not sure that I understand how annotations/metadata tie you down to any implementation. Or for that matter how using third-party code to implement aspects of your business logic is unusual or bad, and even if it were, how using annotations contribute to that any more than previous methodologies.
For me, annotations have so far provided me with the ability to more elegantly structure my code. Previously cross-cutting concerns such as validation, security, etc either had me inlining a bunch of code or developing/using a framework to provide a more structured and reusable solution. Annotations allow me to put the metadata where it is relevant and provides a somewhat convenient API for accessing it. Simplifying both the framework and the writing of the application that uses it.
I guess in a way annotations have reduced the cost of extracting aspects by providing a convenient and elegant mechanism for implementing them.

I'm not sure that I understand how annotations/metadata tie you down to any implementation. Or for that matter how using third-party code to implement aspects of your business logic is unusual or bad, and even if it were, how using annotations contribute to that any more than previous methodologies.

For me, annotations have so far provided me with the ability to more elegantly structure my code. Previously cross-cutting concerns such as validation, security, etc either had me inlining a bunch of code or developing/using a framework to provide a more structured and reusable solution. Annotations allow me to put the metadata where it is relevant and provides a somewhat convenient API for accessing it. Simplifying both the framework and the writing of the application that uses it.

I guess in a way annotations have reduced the cost of extracting aspects by providing a convenient and elegant mechanism for implementing them.

Security is a cross cutting concern, though annotations and/or AOP techniquest generally handle it very elegantly. I was more refering to business logic that belongs within core domain objects.
The way annotations tie you down, is the fact that you're relying on a specific annotation processor to process a particular annotation. If you say ever move away from JEE and you're using validator annotations, you'd be forced to write your own annotation processor to facilitate these concerns. I'm not saying that using annotations is bad. It's an awesome facility within the JDK, but I'm just concerned about overusing it, as is the case for overusing any other frameworks facilities. Some facilities might provide a faster way to complete a functionality, but might not be the best decision in the long run.

i agree with what you are saying...but i think that the scenario you describe is one of those sorts that has about a 1% chance of probability of occurrance. lets face it, if you design your app in java using ANY middleware aspects provided by JEE (even without annotations) and then decide to "move away from JEE", you're basically gonna need to scrap your entire project.
so yes, perhaps u are extracting some business logic (i.e. validation) to an external location (the jvm) but my point is that so much of any enterprise project is already dependant on the fact that the jvm is present that it really doesnt make you any more "tightly bound" than you were before.
my main concern with annotations is that they are often times more cryptic than standard code and distribute functionality/semantics to places outside of the class definition. one can no longer simply look at a method and know exactly what is happening in that method, one now needs to look at the annotations, interpret them...and this often times requires knowledge of even more external frameworks in the case of proprietary annotations.
i am a big fan of hibernate for example, but i would still prefer to put my mapping definitions into their own .hbm.xml files rather than in the actual class definition as annotations. for one, this provides better transparency of the persitence mechanism, and the annotations are still not as powerful as the full-blown hibernate mapping file constructs.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.