Progress Report: The Main Points in the Initial KawaDD RoadMap are now complete.
Jonathan Revusky
has been completed. That is point 1 here:
http://code.google.com/p/kawadd/wiki/RoadMap
Thus, in KawaDD, there are not separate javacc/jjtree/jjdoc programs. It
is just one program. Since KawaDD is based on templates, building an AST
(or not) is simply a question of turning on or off certain sections of
the template that contain the tree-building code.
For those who are curious to see how this works in the nitty-gritty,
take a look at:
http://code.google.com/p/kawadd/source/browse/trunk/kawadd/src/kawadd/output/javacode.ftl
Look at the BuildMacro code that starts on line 82. The blocks in that
macro that start at lines 96 and 112 respectively contain code that is
included in the output if tree-building is enabled.
The way this works for the user is that, to have the tree-building code
generated, you need to use the new option TREE_BUILDING_ENABLED=true
either in the options part of your grammar file or as a command-line
option when you invoke KawaDD.
Note that if you have the tree-building code included, you can still run
the parser without building a tree. It's just:
MyParser parser = new MyParser(....);
parser.setBuildTree(false);
... etc.
and actually, you can see that the presence of the extra code for
tree-building does not impose a run-time penalty if you don't need it.
Okay, now I think this is all pretty much completely backward compatible
with JavaCC at this point. Though it is hard to be 100% sure, I grant. I
would really appreciate any feedback on whether people are able to
build/run their existing jjtree-based code using KawaDD.
You can get the kawadd code like this:
svn co http://kawadd.googlecode.com/svn/trunk/kawadd
cd kawadd
ant
(assuming you have svn, ant, and a JDK>=1.5 installed the above should
build)
You can simply run the kawadd or kawadd.bat in the kawadd/bin directory.
Now, when you use kawadd on an existing grammar.jjt that is set up for
using jjtree, here are the basic caveats:
1. You need to add the option TREE_BUILDING_ENABLED=true to your options
or alternatively, invoke KawaDD with the command-line toggle
TREE_BUILDING_ENABLED=true.
2. Any reference to MyParserTreeConstants needs to be changed to simply
MyParserConstants, since there is no separate XXXTreeConstants file. All
the constants are just in one place, which is XXXConstants.java. (I
think that's simpler anyway.)
3. Any reference to MyParser.jjtree.foo should be changed to simply
MyParser.foo since there is no separate jjtree object. Again, I think
that's simpler long-run, but causes this (rather small) migration issue.
4. As I've stated before, static parsers do not exist in KawaDD, so any
code that used the parser as if it was static has to be changed, from, say:
MyParser.entryPoint()
to:
MyParser parser = new MyParser(....);
parser.entryPoint();
So, I am very interested in any feedback from people as to whether they
can use KawaDD with existing JavaCC/JJTree projects. Also, I am nearing
the point where I am going to put out a KawaDD preview release and
announce it. But before that, there is a fair bit of.. well...
housekeeping work that needs to be done on the docs and examples. I am
very open to volunteers who may want to get involved in this.
Now, I think I should make the following point: really, if anybody was
lurking and interested in getting involved in JavaCC, the project you
should be interested in getting involved in is KawaDD, since that is the
project that is being actively developed, it is the continued
development of the JavaCC codebase. JavaCC is not being actively
developed, it is quite clearly a dead end. In a more sane world, what I
am announcing now would be a preview of the next version of JavaCC.
There is no technical reason for this fork to have occurred. It would
only make sense if the incumbent JavaCC developers had their own
roadmap for future development. However, they obviously do not. The
point of being involved in an open source project is to work on it and
make improvements, not to do nothing and actively prevent other people
from doing anything. In a more sane world, that kind of behavior, and
association with it, would tend to bring the participants into
disrepute. It would just be considered unacceptable. An aspect of this
whole episode that I find disappointing is that people seem to passively
accept this kind of unacceptable behavior. In fact, it even seems that
some people are so naive and gullible that they really do believe that
the person who showed up and wanted to do this work is the one to blame
when the situation gets unpleasant.
Regards,
Jonathan Revusky
--
KawaDD Parser Generator http://code.google.com/p/kawadd
lead developer, FreeMarker template engine, http://freemarker.org/