Aaron M. Renn writes:
> Per usual I was thinking
> of something more ambitious. To the best of my knowledge there is no
> standard parsing API. I was thinking that there should be a "parselet" API
> for applications that need to parse Java source files (JavaDeps, JavaDoc,
> etc).
This is an excellent idea. A JavaDeps and JavaMake tool
should be on the GNU TODO list in some way, too, IMO.
Question: would it be possible to separate parsing "in
comments" from all other Java parsing? In a way that
a parser for SGML/XML could operate on a stream that
removed the standard java comment "wrapper" - '/**', '*/',
and leading '*' independ of your Java syntax parselet?
The default in-comment parsing would to the javadoc
craptag+HTML thing, but you could also use decent
markup and DTD instead.
Further: would it be possible for that parselet to
generate entities from the Java source that could
be added to the output send to the doclet? Has anybody
a suggestion on how to avoid duplications like:
/**
*
* @return void zip. No return value.
* @param int blah. This is ignored.
*/
public void blub( int blah ) {..}
DOC++ uses additional special comments in an attempt
to solve this problem:
/**
* @return void zip
*/
public void blub(
/// This is ignored.
int blah
) {..}
If your parselet/doclet design could somehow keep in
mind issues of merging the information generated from
parsing actual code with the information provided
in javadoc markup'ed comments, that would be great.
Adding more @craptags is not going to last long as
a solution.
James Clark has written an XML parser in Java (XP,
IIRC). Maybe it would be good to collect and review
the available Java-based parsing tools (like
ANTLR 2.0) and XML/SGML utilitities prior to getting
into the parselet API?
b.
