Re: Compiler API Features [Was: sun.tools.javac.Main will be removed from JDK1.4}

["Pier P. Fumagalli" <pi...@betaversion.org>]

Craig R. McClanahan at craigmcc@apache.org wrote:
> 
> As an absolute minimum, Jasper doesn't need much -- just a way to invoke
> the compiler in a multi-threaded server environment without multiple
> instances clashing with each other.  Even external processes work, albeit
> much more slowly than one would like.

Creating processes is _always_ a pain...

> I'm interested in accumulating a list of nicer features that we'd like to
> see in a compiler API.  Here's some of my initial thoughts:
> 
> - Small, fast, lightweight, but generates good (optimized)
> bytecodes.  (Who says goals can't conflict with each other?  :-).

Well, jikes is not big, but how's the bytecode it generates? Dunno myself.

> - Full support for all the features currently in, and about to be
> added to, the Java Language Specification (i.e. assertions and
> generics as soon as possible).

Jikes doesn't have a good past on this... Remember nesting classes in
classes when JDK 1.2 came out? It was broken/unsupported for almost 1 year.

> - Written in Java (and so embeddable in the Tomcat JVM) or accessible
> easily and reliably via JNI on lots of platforms.

At least Jikes is portable :)

> - Published, stable, and supported invocation API.

The C++ API is very nice in Jikes. Don't know how much stable (as I don't
have comparisons available) but definitely good.

Regarding this, javax.compiler could be a reality pretty soon, soooooo...
And maybe Jikes could be embedded in that API... (Seen a couple of proposals
- public ones - from Neal and the NetBeans guys, with a bunch of other
people)

> - Packaged in such a way that multiple compiles can be initiated
> simultaneously (on different threads) with no conflicts.

Thread-safe :) I don't know, that goes beyond my tonight investigations.

> - Accepts source input from configurable-per-class input stream,
> not just files.
> - Writes the bytecodes of its output to a configurable-per-class
> output stream, not just files.

Jikes does it... (the API is good, I told you!)

> - Accepts its notion of a "class path" for looking up dependencies by
> handing it a class loader, instead of a CLASSPATH-type environment.

That might be a problem, as from loadClass() you can't get back to a
byte[]... I believe you could do something like checking classes as
resources (as URLClassLoader does), but for some really weird class loaders
that could be broken...

> - Generates debugging information usable to map lines of Java code back
> to a non-Java language that the Java code was generated from (i.e.
> the outcome of JSR-045).

That's _TRICKY_, because the mapping is external to the source, so, who
actually generates that source should keep track of
orig.file+orig.line=dest.file+dest.line maps... You always read the source
from an inputStream, and what you're proposing is more like a SAX XML
Handler or something like it :)

> What did I miss?

Should start coffee machine if expected compilation time >= 5 mins.

    Pier