> A better way to handle this is to tweak the JVM to load directly
> from blobs.
> ...
> Something that I did to my JVM was add a mechanism to traverse the
> class tree. With a little efforts, this can be used to find
> application classes for an automatic load. Netfrastructure
> distributes base classes in a zip file, and applications derive from
> a single application class. To find the classes associated with an
> application, it does a tree walk from the base application class,
> another from the specific application class, and loads/save the
> classes in the second tree that aren't in the first.

Why didn't you use the classloader hierarchy? Is there any good reason
for this?

> Don't put Java source in the table. It's not useful to the database
> and there's no practical way to guarantee that it's in sync with the
> class blob. No compiler can find it there, and Java source files
> are normally handled by source code manager (cvs). Putting them in
> the database will drive everyone nuts.

How would storing the Java source code in database differ from storing
PSQL there?

> You will find almost instantly that the Firebird Java implementation
> will require changes to whatever base classes your JVM comes with.
> Plan for it.
>
> If you aren't aware of it, base classes are the least bit portable,
> containing all sorts of nasy native stuff to actually make thiings
> work.

How should it touch the Java code running in tha JVM as long as we use
external JVM (one for Windows, one for Linux)?

> Something else you will probably want to do is to intercept certain
> "native" calls before they are resolved to an external native
> library. In specific, you will need this to support callbacks into
> the engine.

Why? It already works with a off-the-shelf JVM (in our case Sun), and
no interception was needed. Can you explain this in details?

Roman