File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Other Java Products and Servers and the fly likes XDoclet and metadata JSR's Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » Other Java Products and Servers
Bookmark "XDoclet and metadata JSR Watch "XDoclet and metadata JSR New topic
Author

XDoclet and metadata JSR's

Michal Szklanowski
Greenhorn

Joined: Sep 23, 2003
Posts: 9
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

Joined: Sep 19, 2003
Posts: 301
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 ]

Spring in Action - Unleash POJO power in your applications!
Modular Java - Discover the secret weapon to modularity on the Java platform!
XDoclet in Action - Your complete guide to code generation with XDoclet.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: XDoclet and metadata JSR's