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