Re: FW: Kawa and BSF

[Per Bothner <per at bothner dot com>]

Allan Erskine <a.erskine@cs.ucl.ac.uk> writes:

> Throwing more specific checked exceptions would be fine, only a small amount
> more work for the user, and gives more flexibility to process, say, a syntax
> exception differently from an execution exception.

Throwing a more specific exception is not the problem.  The issue is
having to declare exception specifictions (throws clauses).  If every
non-trivial piece of Kawa code is declared to throw KawaException,
have you gained anything in safety?

>  KawaException was just
> my initial idea which involved minimal work on Kawa (you'd only need to
> throw them from the "user" methods, ie the ones a user is expected to call).

Plus the small detail of having to add "throws KawaException" to every
method which calls an unknwno Scheme function.  Been there.  Done that.

> As it stands, a user of kawa.jar can expect his program to fail on a simple
> Scheme syntax error, as he isn't forced at compile-time to catch what would
> otherwise be an informative exception.

Huh?  At compile-time you compile a module.  The compilation succeeds, or it
emits a diagnostic.  You can control how the diagnostics are emitted.  Why
should you want to throw an exception on a compile-time error?  That is
not what a real compiler does.  (It is not what javac does.)

I don't understand your point.  You seem to be talking about
compile-time and unchecked exceptions.  A compiler should never
throw an uncaught exception - if it is, it's a compiler bug.

A BSF interface for Kawa should compile the code, and check that there were
no compile-time errors, before evaluating (or compiling) the resulting
Expression.  If there were compile-time errors, of course we can throw
an exception - in a BSF interface method.

> An unchecked exception could easily
> propagate all the way up to the VM causing it to fail there - a potential
> bummer if we're Scheme scripting in a servlet, say.

Exactly.  So anything that calls a scripting enging needs to catch
*all* Throwables.

> All the other Java scripting languages I've looked at so far throw checked
> exceptions (JPython, Jacl, NetRexx).

Yes, just like SAX throws SAXException and lots of other libraries have
thriw own Exception class, which is a total lose once you start mixing
libraries.

> Anyway, (having had to check the source code first) I can guard against the
> deadly unchecked exceptions, catch them and throw (checked) BSF exceptions
> instead,

Yes.

> so it doesn't really affect me too much (except when I catch then
> rethrow a genuine code error masquerading as an innocuous BSFException, a
> bit of a problem that).

I'm not quiet sure what an "innocuous BSFException" would be.

> I'll tell you what I was wanting to do.  The apache XML Cocoon2 project has
> support for any BSF supported language.  I fancied having a shot at using
> Scheme (XML and Scheme - mmmmm), so Kawa was the obvious choice.
> 
> However, C2 is threaded, so if concurrent access to one Scheme scripted XML
> page occurred, you'd like these scheme scripts to be evaluated
> independently.  In this case, there would be a BSFManager instance for each
> thread, and each would have a separate BSFKawaEngine instance, which in turn
> would have a Scheme instance.  The desired behaviour would be for the
> separate Scheme instances to behave completely independently (apart from the
> circumstance of being given explicit shared access to some object).

> So in summary, it would be ideal to have separate instances of a Scheme
> engine with _no_ shared global environment (apart from one explicitly
> provided through shared access to objects eg env1.addBinding("x",o);
> env2.addBinding("x",o);).  Would this require a lot of work?

So basically, the Scheme engines are separate, but may access shared
objects.  In that case synchronizing on something like evalModule
seems like the wrong thing - you'd need some kind of synchronization
on the shared object o, it seems.
> 
> The alternative I suppose would be to use Kawa's own (incomplete) threading
> model, but it would strike me as unnatural to share a global environment in
> this use case.

What we need is a mapping from a thread to a Kawa "engine".  I used
Future for that i.e. future is the Kawa thread-specific state.  A problem
with Future is it doesn't really handle attaching a "Kawa engine"
to an existing thread.  One could use thread-local variables instead,
but these are not available in jdk1.1, and I don't want to leave jdk1.1
peopel in the lurch.  An option is to use Future for java1 and
thread-local variables in java2.

A short-term approach is a hashtable that maps a thread to a Future object;
Environment.getCurrent can use that hashtable.  The problem is handling
threads that finish.  We don't want the hashtable to prevent the thread from
being garbage collected, so perhaps we need weak references.

> Anyway, I'll look at the code you've checked in.  Meanwhile, what do you
> think?  Is this a feasible way to want to use Kawa?

I do think we want this to work, but exactly how to associate threads
to kawa "engines" is unclear, as is when/where to synchronize.
> 
> BTW I've finished and am testing preliminary support for Kawa in BSF.

Cool!

Once the support is stable, I need to add a comment to any Kawa method
called from BSF, to make sure I don't "improve" it.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/