"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 [EMAIL PROTECTED] | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
