The Source for Java Technology Collaboration
User: Password:



Kohsuke Kawaguchi

Kohsuke Kawaguchi's Blog

Pumping up javadoc: JAXB RI architecture document

Posted by kohsuke on August 03, 2005 at 09:56 PM | Comments (6)

Good commenting always make it easier to understand the source code (although people have different opinions about what exactly is good comments.) As such, one of the things we've been doing is to make sure that the JAXB RI source code is well commented. This is mostly done by javadoc, which is good for describing lower-level details of the code.

It's also nice for a project to have a higher-level documentation. It's like a map of the source code, which helps you understand the big picture and which part of the code you need to dive in to fix the problem at hand. This has been somewhat lacking in the JAXB RI for quite some time.

We wanted to have such a high-level map of the JAXB RI source code. When we were working with 1.0.x, we tried a few StarOffice documents and a few HTML pages, but the problem is that it quickly gets out of sync. StarOffice documents have an additional problem of being binary files, which means if two people happen to be editing the same file, you are out of luck. HTML files are better in this respect, but it's hard to do pictures, which is very important for a high-level document.

so I've been thinking about how to do it. Javadoc is nice in the sense that it's harder to get out of sync with the source code; thanks to modern IDEs, whenever you change the source code, references in javadoc are automatically updated. I liked this very much, so I decided to write high-level documents in terms of javadoc.

The next problem was pictures. Because of those IDE support, it's nice if we can do pictures declaratively by writing text, instead of using a GUI tool (like Microsoft Visio.) In this way, class names in pictures will be updated, pictures can be diffed/merged, etc. GraphViz and UMLGraph are exactly such tools. So I wrote a little taglets which lets me write:

   {@DotDiagram
     digraph G {
       "JAX-WS" [label="JAX-WS RI"];

       // libraries
       node [style=filled,color=lightblue];
       XSOM; RNGOM; TXW; "DTD parser";

       // modules
       node [style=filled,color=lightpink];
       XJC; CodeModel; runtime; schemagen; "XJC API"; "runtime API";

       "JAX-WS" -> "XJC API" -> CodeModel;
       "JAX-WS" -> "runtime API";
       XJC -> XSOM;
       XJC -> "DTD parser";
       XJC -> RNGOM;
       XJC -> "XJC API";
       XJC -> CodeModel;
       XJC -> runtime -> schemagen -> TXW;
       runtime -> "runtime API";
     }
   }

... and have the following picture generated automatically:

The similar javadoc tag allows me to write a sequence diagram declaratively, thanks to UMLGraph.

Another customization I did to javadoc was to tweak the HTML generation. Normally, a package javadoc lists classes in it first, followed by a package description. A class javadoc lists some signature information first, then a class description. When I'm using a package or a class for a high-level documentation, I didn't like this order. It should just show my javadoc at the very top. Doing this turns out to be tricky, and eventually I was customizing the standard doclet. But in the end, I was able to get the desired layout. I defined @ArchitectureDocument tag to enable this custom layout

So, with all that said, I hope you like our JAXB architecture document!


Bookmark blog post: del.icio.us del.icio.us Digg Digg DZone DZone Furl Furl Reddit Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment

  • I've had a feeling for a while that the best place to store architecture information is with the code itself and this just validates that. It would be great if the next major enhancement to javadoc include support for this sort of diagramming.

    Posted by: ifairman on August 04, 2005 at 01:14 AM

  • .. , I didn't like this order. It should just show
    my javadoc at the very top. Doing this turns
    out to be tricky, and eventually I was customizing
    the standard doclet.

    yeah, the standard doclet ui is not templatized. so to tweak it is a hairy process, to say the least. this is one of the things i did with ashkelon: its architecture uses jsp templates for the ui, so it's easy to tweak (as evidenced by the speed with which javalobby was able to to customize its jdocs.com pages).

    Posted by: eitan on August 04, 2005 at 08:18 AM


  • It would be nice if javadoc could evolve. Given all sorts of advancements in HTML/browser, I think it's now possible to provide a much better user experience with javadoc.


    I'd love to use Ashkelon, but the problem is that it needs a server, which java.net doesn't offer.

    Posted by: kohsuke on August 04, 2005 at 02:56 PM

  • hi kohsuke, it's really cool this idea you've had to use text-src diagram descriptions to produce enhanced docs. i've been thinking about your comment on ashkelon and had the idea of writing a doclet that would essentially use a template-driven design to produce html pages. i was a little frustrated to find out that it's not easy to use jsp as a standalone templating mechanism (i could've reused my existing jsps in this new context).

    Posted by: eitan on August 05, 2005 at 02:14 PM

  • Thanks, eitan. I'm looking forward to seeing the improvements in Ashkelon. If you are really brave,consider embedding the servlet container in your application. I don't know how easy it is, but in theory it seems possible to reuse a JSP engine.

    Posted by: kohsuke on August 05, 2005 at 03:24 PM

  • Hello. I have a general question on javadoc and jaxb / xjc:

    I have generated classes using xjc. Unfortunately not all classes fulfill the javadoc coding standards.

    In the class ObjectFactory there is for example the following generated method:


    /**
    * Create an instance of MyObject
    *
    * @throws JAXBException if an error occurs
    */
    public com.test.MyObject createMyObject()
    throws javax.xml.bind.JAXBException
    {
    return new com.test.impl.MyObjectImpl();
    }

    to be valid concerning javadoc I would rather expect the following (@return Element and Exception qualified in the @throws Element):


    /**
    * Create an instance of MyObject
    *
    * @return possible object is
    * {@link com.test.MyObject}
    * @throws javax.xml.bind.JAXBException if an error occurs
    */
    public com.test.MyObject createMyObject()
    throws javax.xml.bind.JAXBException
    {
    return new com.test.impl.MyObjectImpl();
    }


    Do you have any suggestions for me?

    Best regards,
    Matthias

    Posted by: geissma on September 16, 2005 at 02:48 AM





Powered by
Movable Type 3.01D
 Feed java.net RSS Feeds