SqlLite interface from java?

O.K:

the sqllitejdbc works great in java,
the running sqllite instance is separate from the memory image in the js interpreter: they have different persistence locations
(the files are saved in different places), but the saved files are compatible.
It seems clear that the two implementation (the js interpreter and the jvm/jdbc version) are each using their own running memory images... there can only be one connection to each at any given time, but both implementations can be running at the same time, even accessing db's named the same, and the data in memory is not effected by the other. the persisted file is saved in a different locationin JS than JVM. Two or more connections to same db in java or two connections to db in js won't work, one connection per memory instance.

The HSQLDB implementation is very fast, and has a *much* larger set of SQL implememnted, including granting privilages, full implementation unions and joins, and other nicities.

That being said one might use the java/jdbc SqlLite implementation over the HSQLDB implementation just for the file compatibility: there is not much one would want to do in a Max App that the SqlLiteLDBC can't do. And therefore, unless there is a need for Java extensibility, the javascript version should be fine.

So, three embedded DB choices, all good, all with strengths, but one is a much fuller implementation of SQL.

SqlLite in javaScript
(included in Max5)

SqlLite in JVM - like the JS version, but embedded in the larger, more fully developed Java language.

HSQLDB in JVM - most fully implemented of the choices , by far.
Only issue would be non -compatibility with the Max5 embedded SqlLite's persisted files.

and finally:
The last two (w/ DBs embedded in JVM's, not javascript interpreter) seem to work just fine in Max4.6.

Lotsa choice, it's all good,
"Chacun a son Gout"
(as the old lady said as she kissed the cow...)

L&K

Char lieB