Its been some time now that i have started to try out a few examples in EJB3. I have been working with EJB2 since a couple of years now. Looking at the few examples on EJB3 the one thing that stands out is the use of annotations. In EJB3, unlike its older version, we make use of annotations to mention the properties of the bean which were earlier defined in the ejb-jar.xml descriptors. In general the things which were put in deployment descriptors earlier have now been pulled into the java classes using annotations.
One of the highlighted points in the older version of EJB was that you could use the deployment descriptors and not put that stuff in the java files allowing changes to the deployment descriptors without having to recompile the code. However with EJB3 we are mentioning these details in the java files, so does this not mean that any changes that might be reqiured later on will need recompilation of the java files? Why was this approach of declaring the bean metadata in the java files taken?
The only answer that i have seen so far to this question is that "You can still use the ejb-jar.xml if you want, in EJB3". However, was there any specific reason why this decision was taken? Does anyone have any better answers?
If the question is, "Why did we add support for annotations?" then the answer is partly that annotations allow for much easier development. But that is not the whole reason. It is most often the case that the metadata is tightly coupled to the Java code and that changes to one really do affect the other. This makes annotations a very good option for metadata definition. In these cases having the metadata dislocated from the code can actually lead to modification errors where one side was changed but the other was not (how many times have EJB programmers in the past changed the code but forgotten to make the descriptor match their code changes?). At the level of convenience, though, it is very nice to be able to add the metadata at the same time and in the same place as the code without having to go to an external XML file.
There are indeed a couple of examples where you do want to change some metadata and do not want to have to edit/recompile the Java code (for example, adding a security role) and these will still likely be most often done in XML. The big win is that because the XML can be sparse, annotations can be used in all the places where they make the most sense and small amounts of XML can be added on top to define or even override the bits that are not coupled to the code.
Hope that helps you understand why we did what we did. It wasn't just us getting on the annotation bandwagon. There are real advantages to using annotations.
how many times have EJB programmers in the past changed the code but forgotten to make the descriptor match their code changes?
The big win is that because the XML can be sparse, annotations can be used in all the places where they make the most sense and small amounts of XML can be added on top to define or even override the bits that are not coupled to the code.
Sounds right, the developer will have the discretion of choosing when to use the annotation(or rather which annotation to use) and when to use the xml descriptors.
Thanks Mike, for answering this.
subject: EJB3 - Rationale behind deployment descriptors no longer needed