cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ru...@us.ibm.com
Subject Re: Project Coordination
Date Fri, 14 Apr 2000 19:56:13 GMT


Pierpaolo Fumagalli wrote:
> Hmmm... So, if we cannot compile those into code, we have to
> differentiate two cases: XSP+Java=Compiled Generator, XSP+Other
> Language(BSF)=?????

Here's something I posted previously under a different subject on this
mailing list:

Now you need something that will "compile" code in the user's choice of
language into Java.  Three interesting cases:

1) The language that the user chooses is, in fact, Java.  In that case,
BSF's job is real easy...it simply hands you back the string.

2) The language you pick can be transliterated into Java.  NetRexx can be
done this way.  In which case, there is a translation done and you are
handed back Java to process.  This is actually only a small number of cases
however.

3) The language is a pure interpreter.  Two interesting subcases of this
are JVM based languages and non-JVM based, but for purposes of this part of
the discussion there is no difference - what is done is that the code is
suitably quoted and inserted into a "bsf.eval" call - and executed at
runtime.

The beauty of such an approach is that if something doesn't work right with
a particular language, and does work with Java, then you have pretty much
isolated the problem down to the component that is causing the problem
(BSF).  Furthermore, if the language you are interested in is Java, the
support for other languages incurs exactly zero overhead at runtime and an
almost undetectable (string compare and method call) overhead at compile
time.

There are some messy details that I'm glossing over (parameter passing, for
example), but essentially that's the picture.

- Sam Ruby



Mime
View raw message