Some time ago I was investigating the possibility to have a light in-memory model of java sources. My research has gone mainly to QDox and xjavadoc, passing also through commons attributes.
Unfortunately, after following the mailing list for a long time, I am unable to say that the support for JDK 1.5 will be available soon (or at least at a specific moment in the future – even if the developers are already taking into account this).
So, I get back a little bit and evaluated the problem some other way:
- how are they implementing these features?
- why are they implementing this way?
- which way should i go for?
Answering these will help me find (hopefully) the good way.
- How are they implementing these features?
- QDox: has its own model that is able to keep information about 5 elements: java types, java classes, java fields, java methods and tags. So in order to support JDK 1.5 features, they will need (in big lines) to improve the java type to support generics and add a model class for annotations. Another interesting point of QDox is that it is using its custom java source lexer/parser written in flex and yacc (i guess). They will need also to enhance this too.
- xjavadoc: has its own model too. In big lines it supports the same elements as QDox does (which in fact represent their real working target). In the same direction, xjavadoc uses its own parser based on JavaCC. So, I would say that xjavadoc has to do the same enhancements as QDox.
- Why are they implementing this way?
- While the model used in both cases is very clear and I think that with the enhancement I was talking they will be stable for a long time, I am not very sure why both solutions have chosen to use custom parsers. I know that javadoc tool is memory expensive while working with large object graphs, I guess if it is used to parse only bunches of sources and than solve references in memory it would possibly be a viable solution. Here I would like to have some insights of the guys involved in QDox and xjavadoc
- Which way should i go for?
- I would say that imo QDox seems more alive than xjavadoc (even if the xdoclet guys are working hard). One solution would be to get involved into QDox dev and make/contribute with the enhancements. (But I don’t know if I have a place there as they are already many and I am not sure they are in need for my help). Another solution would be to reinvent half a wheel and go for a solution based only on javadoc parser. While I see some benefits in doing this (assuring the compatibility with the latest JDK available and independence for any custom parsers, and possible to offer access at the code level, without really parsing it), I think I must find out firstly the answer to the above question.
Update: there was an anonymous poster suggesting the solution with javadoc. I think if I choose this solution I must thank him [blink/].
2 responses to “QDox, xjavadoc and the alike… maybe one more”
I initially wrote xjavadoc. I abandoned it a while ago and got involved with QDox. -Then I ported over some of the xjavadoc features from xjavadoc to QDox.
QDox is better than xjavadoc at everything it does: Both speed and API.
Both QDox and xjavadoc implement their own parser for speed reasons. xjavadoc is 5-10 times faster than javadoc, QDox somewhere around 20-50 times faster I think.