First the disclaimer: I have zero experience with writing such tools
and precious little with compilers. I'm just spewing what I think
but if there are accepted ways of doing these things, it'd be great
for anyone to step in and school me. I'm here to learn, hopefully by
contributing :)
What I'm thinking (and maybe this is dead obvious) is that there are
lots of high level tasks that javac and javadoc will have in common:
-understanding and parsing the syntax of the language itself
-the relevant parts of that are anything that you can javadoc: types,
fields, methods...
-the relation of classes in a package hierarchy, like when a method
takes an @arg of type java.lang.String, you've got to resolve that
and produce a link to the String javadoc
-essentially having the ability to take a target dir and produce a
walkable data structure of all it's contents
Of course, it's not a perfect match. Javadoc needs to treat javadoc
comments as different from other comments (not toss them) and it
doesn't need to understand things at a level finer than, say, methods
(doesn't need to know about if statements, loops, etc). But there's
enough there that the javadoc front end could essentially be the
javac frontend with the addition of handling the actual javadoc
contents. Then, of course, the back end of the compiler spits
out .class files while javadoc spits out html or whatever other
format you need, but that's the reason for the separation between
front and back ends :)
What I could do is take the eclipse compiler and see what parts of it
can be reused. I don't know anything about it so I won't offer any
speculation now. Also, obviously eclipse has it's own javadoc
functionality. Is that something that can be borrowed?
Assuming the easy case, that the tools are all there for poaching
with minimal work, what would the proper action be? It could be
stated that harmony will use the eclipse tools and you should go get
them from eclipse if you want them (at least for the time being,
until harmony gets to the point of being packaged up as a useable
jdk). I gather that's the current status of the compiler. Or
harmony could host the currently accepted binaries. Or the source
code could be taken into svn, in which case there's the question of
keeping in sync with the original tool. In all likelihood, it won't
be that simple and harmony will have some of it's own modifications...
Having asked so many questions, I'm now expecting to be told that
whatever I feel like doing will be better than nothing :-p I'm off
to see what I can find out about the eclipse toolset.
Jeremy
On 9-Feb-06, at 1:41 PM, Geir Magnusson Jr wrote:
Jeremy Huiskamp wrote:
What would be the suggested route for coming up with a javadoc tool?
Open up an editor, and start typing! :)
Is
there something out there now that could be imported and shaped
up? At the other extreme, I'm envisioning busting out jflex/cup
and doing a from-scratch implementation. I'm thinking there would
be a lot of overlapping functionality with the front end of a
compiler so should the two tools be considered together? Harmony
doesn't have a start on it's own compiler yet, correct?
We were planning to just use the eclipse compiler. No reason to
rewrite.
I guess the best thing to do is do a quick write-up on how you
might go about this. Someone here must have some ideas to share
too...
geir
Jeremy
On 31-Jan-06, at 2:14 PM, Geir Magnusson Jr wrote:
Ok - this isn't about the finer points of confusion surrounding
documentation....
We need a javadoc tool for Harmony.
The current conversation is a diversion from this, which I recall
was the original motivation behind the current generation of this
discussion.
So, anyone interested? We need all the tooling actually...
geir