[PATCH] Speed increase to Javadoc task

[gl...@ca.ibm.com]

Hey all.

As I said in a previous note, the current Javadoc task was unnecessarily 
(although very thoroughly) checking each .java fie in the source path for 
its package.  The unfortunate part about it is that Javadoc itself can't 
deal with .java files in the wrong directory.  So, there really isn't any 
need to check each and every file for its package, unless the Javadoc tool 
in JDK1.3 can handle this situation.  I didn't check that one, to be 
honest, but I'm not too hopefull.

At any rate, I've created a patch that removes the scanning of individual 
files and simply scans the directory structure for potential packages. The 
name matching rules still apply.

To provide a comparison, I have a source tree with 3, 605 java files.  I 
only need to document 63 of those files in five packages during one 
particular run of Javadoc.  With the old Javadoc task, it took 00:01:17. 
With the new Javadoc task, it took 00:00:21.  You decide. :-)



Glenn McAllister
Software Developer. IBM Toronto Lab, (416) 448-3805
"An approximate answer to the right question is better than the 
right answer to the wrong question." - John W. Tukey

Re: [PATCH] Speed increase to Javadoc task

[Chris Grindstaff <ch...@appliedreasoning.com>]

Speaking of Javadoc does anyone know of a decent alternative?

Javadoc is fine to use (albeit slow) - but try extending it.  I simply can't get
enough of private final members ;-)  It only adds insult to injury
reading the comments.  Other Sun developers ran into the same sort
of problems I'm having, but they're in the "blessed" package.  Grrr.
Oh yeah - I'm being protected from future changes and myself. :-)

All joking aside the biggest problem that I've had with Sun's stuff is
with their model objects.  PackageDoc, ClassDoc, etc.  Sun wrote their
stuff assuming that you would not want to modify those classes without
completely rewriting them or copying them.

About the only thing I've run into is:
http://home.austin.rr.com/kjohnston//javasrc.htm

Chris

Tuesday, August 29, 2000, 3:11:10 PM, glennm glennm wrote:
gcic> Hey all.

gcic> As I said in a previous note, the current Javadoc task was unnecessarily 
gcic> (although very thoroughly) checking each .java fie in the source path for 
gcic> its package.  The unfortunate part about it is that Javadoc itself can't 
gcic> deal with .java files in the wrong directory.  So, there really isn't any 
gcic> need to check each and every file for its package, unless the Javadoc tool 
gcic> in JDK1.3 can handle this situation.  I didn't check that one, to be 
gcic> honest, but I'm not too hopefull.

gcic> At any rate, I've created a patch that removes the scanning of individual 
gcic> files and simply scans the directory structure for potential packages. The 
gcic> name matching rules still apply.

gcic> To provide a comparison, I have a source tree with 3, 605 java files.  I 
gcic> only need to document 63 of those files in five packages during one 
gcic> particular run of Javadoc.  With the old Javadoc task, it took 00:01:17. 
gcic> With the new Javadoc task, it took 00:00:21.  You decide. :-)



gcic> Glenn McAllister
gcic> Software Developer. IBM Toronto Lab, (416) 448-3805
gcic> "An approximate answer to the right question is better than the 
gcic> right answer to the wrong question." - John W. Tukey

-- 
Chris Grindstaff
chrisg@appliedReasoning.com  |  www.appliedReasoning.com