Proprietary Ties Still Bind
We now have two FOSS 1.5-capable compilers: ecj and the openjdk version of Sun’s javac. Both clearly have parsers for this version of the language, which got me thinking as to whether we should simply depend on one or the other (maybe even both) to provide parsing for gjdoc. I’ve looked at the OpenJDK code so far, and this seems fairly feasible. I’ve yet to look at ecj. In the meantime, I’d be interested to hear people’s opinions on what they think best. Clearly using one of these is a dependency we have to introduce, but, if we switch to 1.5 source code, this will be required anyway. It also removes the dependency on the lexer/parser framework we use (name escapes me right now…). As I see it, there are four options:
- Retain the current parser code and update it for 1.5. Given the state of this code, it’s likely to be something of a headache, and likely to remain fairly unmaintainable in the future.
- Replace the parser with our own generated using the tool we currently just use for expression parsing. Seems a little redundant as there are already capable parsers available.
- Depend on either ecj or OpenJDK javac for parsing.
- Use either ecj (if feasible) or OpenJDK for parsing, depending on which is also used to compile.
Any feedback is much welcomed.
I’ve also started to look at JikesRVM for SoC and run into some issues just trying to build it. Seems that not all is Free in the JikesRVM world and I can’t even build on a Free Java stack. My first trauma was trying to get ant (now used for the build system) to find a Java compiler. I couldn’t seem to get it to talk to ecj, so I pointed it at the JAR file for OpenJDK as an apparent ‘tools.jar’. I then ran into problems a few steps in, where it tries to use apt (the annotation processing tool, not the Debian package manager — which could have been interesting…) to preprocess some code. We don’t have an equivalent in Classpath, and it appears this is deprecated anyway in 1.6, in favour of javax.annotation.processing and capabilities in javac. Changing this is something we’re just beginning to discuss on the mailing lists, but it seems to be accepted that Sun or IBM is needed to build… ick. It seems there was some Kaffe support earlier, but it has gone the way of the dodo (along with its reference in the user manual). Ian Rogers has kindly supplied me with the file that is generated by this apt stage, so maybe I can at least see what hurdle comes next… Makes me think I should have made the project ‘Liberating JikesRVM’…
April 26th, 2007 at 11:58 am
Isn’t the new Compiler API supposed to address some of these issues?
I read an article recently - I think it was on Peter Ahé’s blog - that discusses these kind of uses for the Compiler API. I think the gist was - the current version can’t do it but we’re working in that direction longer term.
If that’s the case then going with javac seems more future-proof in that whatever API ends up getting standardized is more likely to be close to what javac has - and ecj will eventually have to comply too.
April 26th, 2007 at 1:50 pm
I’d suggest going with the openjdk code, as it’s GPL-compatible, i.e. it can be directly used to build upon, rather than having to work around ecj’s GPL-incompatiblity in one way or another.