In my last blog entry, I shared some personal opinions about Java annotations. To briefly sum up, I think that annotations will be a very powerful weapon in the developers' arsenal and that mishandling them will lead to counter-productive and most probably disastrous development conditions. Another remark was targeted at some people (like Cédric Beust and others) who were willing to give the opportunity to developers to override annotations even though the latter had not yet made it into the mainstream development process. As I said, I think the idea is worth some research but it sounds to me like they want to make two steps at a time. Personally, I would find it much more prudent to first observe how people use annotations and then devise ways of improving their use if needed. Anyway, I wrote my last blog after reading Cédric's proposal and I actually wanted to give him some feedback as he kindly requested. Due to time constraints, I restricted myself to write some comments off the top of my head, without giving the appropriate feedback as intended. He legitimately reminded me in his comment and I thank him for that. So, I'm sharing my thoughts here. Actually, I will also comment on Bill Burke's solution since he and Cédric are both working on the same interesting problem. I can already admit that I would more easily go with Cédric's solution than with Bill's. I will elaborate why below.

On mixing Java code with XML (Bill)
Cédric states that he does not really like Bill's solution which partly consists of putting Java code into the XML deployment descriptor. I agree with him but not for the same reasons. Cédric is complaining that when renaming methods in the Java code we have to do the same mechanical and error-prone task in the deployment descriptor. Actually, Cédric's solution suffers from the same problem. If we rename the methods in the Java code, we will also have to remember to change the value of the "names" attribute in the <method> element. This problem is actually not really solvable since both Cédric and Bill advocate for having a separate file when overriding annotations. Since the Java code and the ad-hoc XML file (deployment descriptor or "annotation overriding" file) have to be in perpetual synchronization, it is unavoidable that both sides have to be updated somehow. This has always been a big debate anyway, but I tend to prefer not to write verbatim Java code within XML files. As Cédric said, this very much hints at a design smell even though the JBoss folks have found this practice to be quite useful according to Bill. I actually find Cédric's solution to be more elegant and scalable than Bill's since Cédric does not require to write Java code in his XML file, merely some method names and fully-qualified types.

On space-separated names in attribute values (Cédric)
I personally strongly dislike this practice since doing so removes the whole semantical meaning of what the attribute actually contains. Ideally, each method name should be contained in a separate element as it is currently done with the <method> element in EJB deployment descriptors. Of course, this is very verbose, but hey, this is what we get when using XML, so we just have to deal with it. If we really want to use XML, we have to use it at its full potential and not by taking some shabby shortcuts. In my opinion, people shouldn't explicitely write those XML files themselves, instead vendors should provide tool support for that (e.g., as proposed by Laurent Etiemble), so it doesn't matter if we use one, two or ten XML elements for capturing some method names. Computing power is becoming cheaper everyday, remember? I personally prefer to deal with reasonably verbose XML files than with some hybrid file resulting from crossbreeding Java with XML.

On whether the deployment descriptor is suitable for containing annotation overrides (Bill)
Bill would like to simplify the annotation overriding/insertion process to a maximum. To this end, he proposes to write the Java annotation code directly in the deployment descriptor and to use method signatures instead of verbose XML element graphs for identifying the constructs to be annotated. The intended goal is praiseworthy but we just discussed about the issues surrounding the tight coupling between Java code and XML. Bill also proposes to completely separate business logic from infrastructure code by EJBizing POJOs with XML. This materializes the last two goals of his proposal, namely that "XML should be a viable replacement for any annotation of any J2EE component" and that "annotations should be optional and not required for any J2EE component". Well, I don't know what to say except that this really doesn't go in the same direction the EJB 3.0 expert group is willing to take. What I find most strange in Bill's solution is that the advent of annotations is supposed to allow us to finally get rid of deployment descriptors. And what does he do? He stuffs annotations in the deployment descriptor!! Moreover, why do we find/need vendor-specific annotations in the same deployment descriptor as the rest of the standard stuff? What will happen if we want to deploy the same bean in another container? Rewrite the deployment descriptor and run the risk of maintaining as many deployment descriptors as vendors on the market? No thanks, let's learn on the past and don't make the same mistakes in the future. To Bill's defense, I'm quite sure (and I really hope) that the solution he presented is a very early first pre-draft version and that he will actually take care of all these small issues.

On whether we should be able to insert annotations and not just override them (Cédric)
In the current EJB specification, the Deployer is required to ensure that meaningful values are assigned to all environment entries before deploying the beans. For this very reason, I think it makes sense to allow annotation overriding. The current specification also states that the Deployer might modify/insert new elements when deploying beans (transaction attributes, etc) in case the bean provider and/or the application assembler failed to do so. For this reason, I would tend to be in favor of allowing deployers to insert new annotations when they are about to feed beans into the container, and I thus also agree with Bill's second goal ("Any annotation should be insertable/declarable through XML"). Whether this should occur through XML or not is another debate, though.

To summarize, the community wants to leverage annotations for simplifying Java development and we already see very controversial solutions. Bill's proposal takes the worst of both worlds by putting literal Java annotations within deployment descriptors which were initially intended to be eliminated thank to annotations. I don't quite see the benefit of his approach even though there might be one. I hope he will clarify his thoughts in the near future for the benefit of the community. Cédric requires the creation of a new ad-hoc XML file that would contain the declarations of annotation overrides as needed. Both approaches have their advantages and shortcomings. In the current EJB specification, we use the deployment descriptor for declaring/inserting/modifying infrastuctural parameters. As we will replace these descriptors with annotations, we will need to have at least the same functionalities as we had with descriptors and that's why people need to be able to override annotations. Time will tell whether replacing deployment descriptors (and home and component interfaces) with annotation facilities is a good thing or not. In my next blog, I will provide a comprehensive comparison between what developers have to write using the conventional EJB practices with/without XDoclets and how this will/would change with annotations. Stay tuned...