• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

XDoclet and metadata JSR's

 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
author
Posts: 422
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 ]
 
Too many men are afraid of being fools - Henry Ford. Foolish tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic