Originally posted by Frankie Cha: With the implementation of JSR 175 in the upcoming Tiger, I am thinking of how this will affect the development and evolution of XDoclet. Could anyone shed some light or opinions.
Excellent question. As a committer to the XDoclet project and author of a book on XDoclet, I was a bit taken aback when I first heard about JSR-175. I remember commenting to my co-author that I felt a bit like a small child who just found out that Santa Claus isn't real. But then I learned more about it and came to the following conclusion (disclaimer: this is my opinion formed on my understanding of JSR-175. I welcome other opinions or interpretations of JSR-175). XDoclet is a meta-data driven code generation framework. JSR-175, on the other hand, is a means of injecting meta-data into compiled Java code. What's the difference? The key concepts here are build-time code-generation vs. run-time reflection. XDoclet generates code based on meta-data placed in Java code. This generated code could be deployment descriptors, value object classes, utility classes, interfaces, O/R mapping files...whatever. These artifacts are generated at build time. JSR-175 (as I understand it) lets you tag your code with meta-data that gets written into compiled Java code. The way you get it out is by way of run-time reflection. As I see it, build-time code generation doesn't sound anything at all like run-time reflection. These are two very different concepts. It just so happens that we arrive at both of them by way of tagging our code with metadata. Now...how JSR-175 will be applied is still subject to some speculation. It is possible that JSR-175 can be used with EJBs to replace the need for deployment descriptors. Or it may be used to designate certain methods as home methods or remote methods, thereby eliminating the need for home and remote interfaces. Used that way, JSR-175 will replace one need for XDoclet. Even then, I feel a bit uncomfortable compiling deployment information into a compiled EJB class. At least with XDoclet you can use Ant property substitution so that your deployment information isn't hard-coded into your EJB source code. However, there are other artifacts XDoclet generates that I can't envision JSR-175 replacing. Consider value objects and utility classes that XDoclet can generate for EJBs. How could JSR-175 replace those? One thing that may come to pass is that the means for tagging code for XDoclet may evolve from JavaDoc-style tags to JSR-175-style tags. XDoclet 2 (actually Generama) takes its metadata from an arbitrary metadata source--it just so happens that with XDoclet 2, that metadata source parses JavaDoc tags. Perhaps a new metadata source will be developed that parses JSR-175 tags. (Note: I'm just speculating here.) So, the conclusion I've come to is that XDoclet and JSR-175 are two different animals. They may look similar and there may be some intersection of the sets of problems that they solve. But I do not believe that JSR-175 spells the doom of XDoclet. [ January 29, 2004: Message edited by: Craig Walls ]
Thank you Craig, I am working on a tool now to generate Web Services based on POJO on JWSDP 1.3 using XDoclet. Does the Web Services chapter on your book covers that? Will not wait for JSR 175 or JSR 181. Best Regards
Joined: Sep 19, 2003
Originally posted by Frankie Cha: I am working on a tool now to generate Web Services based on POJO on JWSDP 1.3 using XDoclet. Does the Web Services chapter on your book covers that? Will not wait for JSR 175 or JSR 181.
No, the web services chapter covers Apache Soap and Apache Axis, but not JWSDP. There's not currently an XDoclet module fo JWSDP (thus the reason we didn't write about it). But, if you're working on such as tool, then there's no reason you couldn't base your tool on XDoclet. You'd just need to write your own XDoclet module for JWSDP and your set.