[Fwd: XML doclet name]
Context:
Some days ago, and several months after my initial announcement, I
finally resumed work on the Javadoc drop-in we decided to name
'gjdoc' back then - perhaps you remember.
There are still a number of bugs and unresolved issues, but I hope
we at cp-tools can provide a useful alpha version during the next
two or three weeks, last not least.
One thing was missing all the time: a replacement for Suns "Standard
Doclet" which allows you to produce documentation in HTML format.
In order to fill this gap, I recently wrote a doclet which outputs
XML code, and a corresponding XSLT sheet which transforms this into a
set of HTML pages.
The following refers to this intermediate doclet, which basically
does nothing but dump Doclet API information to stdout in XML format.
I'm forwarding this to the Classpath list because of the XML issues
involved. Perhaps someone can tell me what the current GNU policy is
on XML unique URLs and such?
Julian
Original Message
Subject: XML doclet name
Date: Mon, 25 Feb 2002 03:54:11 +0100
From: Julian Scheid <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Not only Sun and Apache efforts for writing Javadoc as XML
are named XMLDoclet. See http://www.google.com/search?q=xmldoclet
So we should come up with a different name I suppose.
What about "gjdocxml" or "gjxmldoclet"? Any suggestion?
We need names for the following too:
(my suggestion in brackets)
- xml namespace prefix ("gjdoc:")
- xml namespace url ("http://www.gnu.org/software/cp-tools/gjdoc";)
- xml dtd file name ("gjdoc.dtd")
- xml dtd url ("http://www.gnu.org/software/cp-tools/gjdoc.dtd";)
- xsl sheet ("gjdoc2html.xsl")
Let me know what you think of these, I'm especially unsure about
the URLs... is there anything like a GNU XML standard?
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: [Classpath] style question
> ">" == C Scott Ananian <[EMAIL PROTECTED]> writes: >> What I was saying, in effect, was that duplicate array bounds >> checks should be optimized away, *if the compiler can determine >> that they are, in fact, duplicate*. Yes. In this case I don't think it is too far-fetched that a compiler could discover this. Strings are used often enough that teaching a Java compiler about String.length wouldn't be unreasonable. (gcj can't do these optimizations now, but we plan to do them in the future.) >> Using the try-catch construct obscures this fact, so it makes it >> harder for the compiler to Do The Right Thing. I agree with this too. Also, since exceptions are presumably exceptional, compiler writers probably won't spend as much time optimizing them as they will on unexceptional code paths. I think we have to ask, though, what the goal is. If it is performance, then there is no single answer, since different implementations have different tradeoffs. For instance with gcj I think exceptions are a bit more expensive than they are with, say, Sun's JDK. OTOH other things are cheaper (and ultimately a redundant bounds check will be free). If the goal is clarity, then it is a little harder to judge. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
