• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

XDoclet and metadata JSR's

 
Michal Szklanowski
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How XDoclet relates with two coming metadata JSR's?
Is it a completition or complementation for XDoclet, already mature tool.
I am afraid we enter the same situation as when Sun reinvented wheel
designing its own logging framework, when production-ready and mature
log4j could be used.
 
Craig Walls
author
Ranch Hand
Posts: 363
8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Michal Szklanowski:
How XDoclet relates with two coming metadata JSR's?
Is it a completition or complementation for XDoclet, already mature tool.

Here's how I see it: JSR-175 (Java metadata) is a mechanism by which you can tag up your Java code with metadata, using a mechanism known as annotations. This metadata then gets woven into the compiled Java class file. From there, applications and tools can access that metadata using reflection. To summarize: JSR-175 is a runtime metadata specification based on reflection.
JSR-181 is nothing more than an implementation of JSR-175 as applied to web-services.
XDoclet, on the other hand, is a code-generation tool. It's a build-time mechanism for auto-generation of code artifacts. The only commonality between XDoclet and JSR-175 is tagging classes with metadata.
So, in my analysis of the two, although they resemble each other on the surface, XDoclet and JSR-175 are two different animals.
That said, JSR-175 has the potential of addressing many of the complexities that XDoclet also addresses. Already people are talking about tagging EJB source code with JSR-175-style annotations as an alternative to deployment descriptors. Used this way, JSR-175 would replace DDs and home/remote/local/localhome interfaces and would therefore remove the need for XDoclet to generate DDs and these interfaces.
The problem with this is that the metadata tags would not only be hard-coded into the EJB source code, but would also be compiled into the EJB class files. This is worse than XDoclet in 2 ways: The first and most obvious way is that deployment info is compiled into the class files--at least XDoclet still produces a separate deployment descriptor. The second way this is worse is that with XDoclet you do not have to hardcode metadata in the tags. You can use Ant properties as place holders for your metadata and put the actual values in an Ant build properties file to be chosen at build time--I don't know if JSR-175 has a similar build-time way of choosing metadata values.
Even so, if JSR-175 were to remove the need for deployment descriptors, home interfaces, remote interfaces, and other such sillyness, there are still things XDoclet code generation can do that JSR-175 annotations can't do. XDoclet can generate value objects and utility objects for EJBs, O/R mapping files for Hibernate, and mock object classes--just to name a few.
[ December 10, 2003: Message edited by: Craig Walls ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic