cp-tools-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Cp-tools-discuss] Gjdoc sample output


From: Julian Scheid
Subject: [Cp-tools-discuss] Gjdoc sample output
Date: Mon, 10 Mar 2003 01:20:44 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2) Gecko/20021126

I generate the full Classpath API from time to time for testing
purposes and thought I'd put it on the Web until the official
Classpath API docs are updated.

Find it here: http://217.160.129.185:6565/classpath-api/index.html
It is password protected to keep the bots out - username is 'cp',
password the same. This is the full documentation for Classpath,
updated yesterday from CVS.

You may want to check above page sometimes when you see CVS commits
for Gjdoc, I will try to keep it in sync with my changes.

Notes:

- Package Tree generation turns out to be awfully slow for the full
  Classpath tree, actually it's unbearable. Until I have optimized the
  process, I have disabled their generation. Under above link you will
  find trees for some packages, but not all, I stopped the process at
  some time.

- The date format in the footer is German. This is already fixed, the
  date will now always be US english regardless of what locale Gjdoc
  is run in. (I plan to add i18n support in the long term, though.)

- Missing package descriptions result in ugly blanks on the front page.

- Some @see links do not work properly.

- No, it's not very useful to have a list of all known direct subclasses
  of java.lang.Object ;)

- Misplaced HTML tags in some Classpath comments can lead to undesired
  results. This is most obvious in java.applet, where an occurrence of
  the string "<applet>" in a comment leads to a bogus applet popping
  up on the documentation pages. I suppose you don't mind if I fix these
  problems as I encounter them. (I think I do have write access to
  Classpath.)

The worst problem, which you can't see in above pages, now turns out
to be performance. The changes I did in the last release affected
performance for large source trees far more severe than I had thought.

I think pre-computing the heritage information in the doclet and storing
it as XML data will help a lot. XSLT doesn't seem to be so fast at
recursive operations.

Julian






reply via email to

[Prev in Thread] Current Thread [Next in Thread]