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

["Craig R. McClanahan" <cr...@apache.org>]

On Fri, 20 Jul 2001, Christopher Cain wrote:

> [snip]                             Are we talking a specialized wrapper
> targetting specifically the stuff required for JSP, or are we talking
> about a general all-purpose Java wrapper that we could possibly release
> as a separate tool?
> 

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.

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?  :-).

- 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).

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

- Published, stable, and supported invocation API.

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

- 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.

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

- 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).

What did I miss?

Craig McClanahan

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

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

Glenn Nielsen at glenn@voyager.apg.more.net wrote:
> 
> Hmm.  I wonder how much optimization is needed in the generated byte code for
> something that will get profiled and optimized to native opcodes by HotSpot
> server.  Of course things other than Jasper, like Ant, might want to use it
> with a great deal of optimization.  Inclusion/use of the optimization should
> be optional.  I would rather have a small footprint fast JSP java source
> compile and let HotSpot server do the profiling and optimization.

Now, I didn't believe it myself until I got the proof, but, IT SEEMS, that
with HotSpot interpreting something like JSPs is actually FASTER than
compiling them...

It was applied to an XSP derivate by some Italian weirdos, and maybe Gianugo
can enlighten us on what he found out... Gianugo?

    Pier

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

[Glenn Nielsen <gl...@voyager.apg.more.net>]

"Craig R. McClanahan" wrote:
> 
> On Fri, 20 Jul 2001, Christopher Cain wrote:
> 
> > [snip]                             Are we talking a specialized wrapper
> > targetting specifically the stuff required for JSP, or are we talking
> > about a general all-purpose Java wrapper that we could possibly release
> > as a separate tool?
> >
> 
> 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.
> 
> 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?  :-).
> 

Hmm.  I wonder how much optimization is needed in the generated byte
code for something that will get profiled and optimized to native
opcodes by HotSpot server.  Of course things other than Jasper, like Ant,
might want to use it with a great deal of optimization.  
Inclusion/use of the optimization should be optional.  I would rather
have a small footprint fast JSP java source compile and let HotSpot server do the
profiling and optimization.

> - 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).
> 
> - Written in Java (and so embeddable in the Tomcat JVM) or accessible
>   easily and reliably via JNI on lots of platforms.
> 
> - Published, stable, and supported invocation API.
> 
> - Packaged in such a way that multiple compiles can be initiated
>   simultaneously (on different threads) with no conflicts.
> 
> - 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.
> 
> - Accepts its notion of a "class path" for looking up dependencies by
>   handing it a class loader, instead of a CLASSPATH-type environment.
> 
> - 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).
> 
> What did I miss?
> 
> Craig McClanahan

That is a very good list of requirements, can't think of any additons.

Glenn
 
----------------------------------------------------------------------
Glenn Nielsen             glenn@more.net | /* Spelin donut madder    |
MOREnet System Programming               |  * if iz ina coment.      |
Missouri Research and Education Network  |  */                       |
----------------------------------------------------------------------

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