> What about javax.script package?

I think Rhino is directly supported, if not - there is definitely some
plugin package already.

> With some small (that I already plan) additions to FB Java Engine, it
> will be possible to implement an engine in Java that interfaces with
> javax.script engines.

Cool, let's talk about it after holidays...

> Would it be possible (and good) to directly call JDBC methods from
> Javascript functions?

Yes, you can call any method of any Java class - importing is almost
trivial. But you don't want to use JDBC for external procedures -
JavaScript implementation can be more elegant, like Jim showed or, for
example as an array (for small queries):

sql = "SELECT * FROM my_table";
for each(var rec in execQuery(sql)) {
doSomething(rec.first_col, rec["some quoted col"]);
}

or

var recs = execQuery(
"SELECT first_col, \"some quoted col\" FROM my_table);

// and access it via PK value
doSomething(recs["somePKValue1"].first_col);

// not sure here, but should work as well
doSomething(recs["somePKValue2"]["some quoted col"]);

// and so on

In other words, you can use traditional JDBC-like API, but in many cases
one can access records similar to a hashmap or via property names and so on.

The functions like execQuery() and alike can be added to the top-most
context and will be available in all JavaScript contexts inherited from
it (so-called, prototype based inheritance). And even more, you can
override some functions in child contexts and leave others untouched.
And you can do this on per-context basis (something like overriding a
method in an object, not a class, if that were possible in Java)...

If I were Jim and would create JavaScript interpreter from the scratch,
I would extend the language with some embedded SQL stuff to make the
syntax more SQL-friendly.

> Certainly will not be the fast things, but easy enough to support and if
> desired, reimplemented in different ways.

If you're about JavaScript, Rhino translates JavaScript code directly
into bytecode with all necessary optimizations and JIT compiler can
compile it to the native code. So it is not an interpreted language, or
better - not only interpreted, since there are two modes - interpreted
and compiled.

Roman