Hi Jim,

> It's a little more complex than this. The Java code needs to be
> able to call back into the engine, so some API is needed.

There must be some API for BTC anyway. :)

> I suppose a low level ad hoc interface could be cobbled together, but
> JDBC is almost certainly the right answer. A JDBC implementation
> requires a layer to map JDBC semantics into engine semantics (one
> could be recycled from my ODBC driver).

I planned to reuse JayBird for this. The bottom-most layer of JayBird
is Java implementation of GDS API, layers above map engine semantics
into JDBC semantics. So, if we get GDS-like API we will be able to
create JNI proxy between engine and JayBird. Rest is almost trivial
then. Or am I wearing pink glasses?

> It also requires a mechanism to synchronize JDBC object
> lifetimes with corresponding engine objects/blocks. The work is
> well worth doing, but non-trivial, particularly if you're going to
> "do it right."

Will this not automatically handled by JVM? I have little experience
in JNI, but if there is call from engine to JVM to execute some Java
code, there must be some call to stop execution, right? Also when the
code is executed, call we be returned back to the engine anyway. Correct?

Thanks!
Roman