Hi,

> It's tempting to consider a JVM like any other loadable procedure,
> but there differences. One is configuration information. A
> loadable procedures needs only module and entrypoint names. A Java
> procedures needs those for the JVM itself, a path for the JVM to
> find it classes.zip, possibly someplace for it to load property
> files, and the class and method names of the Java procedure.
> Another difference is that starting up a JVM is extremely expensive
> -- not the sort of thing you want to do everytime a function is
> called. But if the JVM is going to have an existence independent of
> invocation, I fear you are going to be looking at a whole different
> mechanism. Does it make sense to generalize and re-usable resource?
> It may be. But it does rather blow simplicity out of the water.

Idea behind the JVM is following. JVM is a module, each module should
have its initialization phase (remember Photoshop plugins? on startup
main application scans predefined directory for .dlls, loads them and
tries to call some init function, this function does the rest). When
you install JVM module (can be shipped with a separate installer), it
will get its own configuration (Windows - registry, Unix - /etc/...),
it would include then CLASSPATH entries, heap sizes, etc.

So what is module and entry points in our case? Module is symbolic
identifier ('JAVA' or 'JVM' in our case). Entry point would be unique
(canonical?) name of Java entity to execute. In simple cases this
canonical entity is simple static method
('org.firebirdsql.procedure.Sample.someStaticMethod(String, int)' for
example, I'd rather use this notation instead of internal JVM
representation), for selectable procedures that would be name of the
class implementing some interface (SelectableProcedure for example).

So yes, you're right, JVM would live its independent of invocation
life. Eugeney Putilin has already working prototype of such model, it
works with superserver and embedded versions of Firebird. Also it
works when from Java application you call embedded Firebird, which in
turn calls Java method.

Main issue with Eugeney code is that in order to make this work he had
to modify engine's code (surprise?). But such ad hoc changes do not
bring stability to the engine. We need a robust architecture and clean
API that allow people create such things.

Jim, I'm really glad that you have joined this discussion, especially
in the light of your email about internal JDBC-like interface you
implemented in Vulcan. Did you read the paper in the file area? Does
it make sense to you?

Thanks!
Roman Rokytskyy