Carlos tries to one-up the .NET BCL team

Carlos wrote (in comments) in response to my last CodeDom post:

    After all these years, still no way to build an AST from source. Tsk, Tsk, Tsk. Recall, you had this in Java when they moved the compiler away from native, that was when? JDK 1.2, just look at the internals.

Carlos, quit being silly–if I wanted to look at internals, I would go read the source for the publicly-available and openly-licensed C# compiler that comes with the SSCLI tarball. That’s not the point here. The CodeDom already has the capacity to go from source to compiled assembly (something which Java still lacks, by the way) using the ICodeCompiler interface of the CodeDomProvider class (which Microsoft dutifully provides for each and every one of their languages, by the way). That’s not what I’m looking for; what I want is the ability to go from source to CodeDom tree representation (a CodeCompileUnit), so that I can go into the AST and hack up–or amend, or weave, or whatever you want to call it–the code from there, then feed it back into the Compiler and have good code come out the other end. And, since CodeDom is language-agnostic, it means I could conceivably… (wait for it) have aspects that are language-agnostic, as well.

This is not a hard problem to solve, in many ways–I could, for example, get hold of the various language grammars individually, feed it into ANTLR or SableCC, then compile into standalone assemblies and use that to produce the AST desired. That’s not the point, either. I want the CodeDom functionality–to take source, go to a DOM-like tree of elements that I can muck with, then from there go either back to source or to compiled output. I can go from source to compiled assembly in a snap, as well as from DOM to compiled assembly (meaning I don’t have to worry about doing bytecode generation). What’s missing is source-to-DOM.

But in the meantime, let’s also quietly ignore the fact that, unfortunately for Carlos, technically you can’t redistribute anything you write that makes use of the javac classes/internals (since you’re not allowed to redistribute the JDK or any of its constituent parts outside the JRE). Carlos, I hope you don’t get any phone calls from Sun legal staff anytime soon asking to take a look at your code for license violations….

And, if I’m not mistaken, the rewrite occurred with JDK 1.3. (I can check with Neal Gafter or Josh Bloch if this is a serious point of contention; they probably remember a lot better than anyone.)

So, with all due respect, Carlos, once again you’re playing at FUD. Sad, really, because Java has enough good reasons to hold its own against .NET that it doesn’t need this kind of "support"; it just makes Java proponents seem like zealots.