This content has been marked as final. Show 5 replies
Well. If you are a student, you may develop that stuff by your own.
Then place it at somewhere like sourceforge.net
A few guys like you will find it and perhaps use it.
But you will never know... forget to hear anything from them, not even thanks!
(Just put yourself at their place -- would you write anything to the author?)
Be proud that someone is probably using it!
That's probably all benefits you are going to expect from that kind of endeavor.
Forget about making any money from this!
Well. By the time you will find a job where they pay you for the stuff you do.
You will give up your pet project and eventually forget about it.
Meanwhile, at the hosting site (e.g. at that very 'sourceforge.net'),
they will reorganize something, as they regularly do,
move something to somewhere else, do something wrong and the link to your project will get lost...
That's roughly how the first 5 those tools appeared.
You may add the sixth!
BTW, Javadoc itself won't be much helpful for that task because it gives no access
to the Java source code (particularly in a parsed form). You may develop a custom doclet
(it must be not less powerful than the standard one, to make any sense of it).
But in addition to the doclet, you will need to find by yourself the Java source of a particular class, parse it and generate an output by it with all those highlights and links you want.
This is not so little project... and given nobody will ever pay nobody is going to do it.
But you may try!
No, I am not a student. Yes, I would have all the abilities to get this going, except enough time. Yes, I know that open source tools get rusty due to effects you described, I have experienced this myself.
I wonder if reflection could get one around completely and correctly parsing the source again. Or is it rather BCEL to be used to get hold of line number information. Or is there an open interface to the compiler anywhere?
I wonder if reflection could get one around completely and correctly parsing the source again.No. Java reflection API (java.lang.reflect.* package) provides some basic info about the Java classes being executed. It has no connection with Java source nor even with binary representation of Java classes.
BCEL is closer to the subject, but still has nothing to do with the source code. If you needed to process the already compiled Java binary classes (e.g. to develop some code obfuscator or trasformer/optimizer) then it would be useful.
But what you need is a Java parser -- some piece of software that "reads" a human-written Java code and produces by it some tree of objects representing all the Java program things like classes, methods, fields, variables, statements, operators and so on. That object representation will allow you to connect the particular positions of the Java source with the things provided, for instance, by the Doclet API. Then, you will be able to highlight the Java source code and generate hyperlinks from it to all other parts of the documentation.
Or is there an open interface to the compiler anywhere?I think, there must be such libraries, including open source. For instance, a few minute search in Google gave me a couple of links:
There must be more...
But note. Generally, parsing of an object programming language like Java is not a trivial task. First, I would recommend to read some theory about this (that is how compilers work), simply because all such libraries will likely use some conventional notions and terminology of that field (like "context-free grammars", "LR or LL parser" and so on).