|Subject||Re: Java Stored Procedures|
> A better way to handle this is to tweak the JVM to load directlyWhy didn't you use the classloader hierarchy? Is there any good reason
> 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.
> Don't put Java source in the table. It's not useful to the databaseHow would storing the Java source code in database differ from storing
> 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.
> You will find almost instantly that the Firebird Java implementationHow should it touch the Java code running in tha JVM as long as we use
> 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
external JVM (one for Windows, one for Linux)?
> Something else you will probably want to do is to intercept certainWhy? It already works with a off-the-shelf JVM (in our case Sun), and
> "native" calls before they are resolved to an external native
> library. In specific, you will need this to support callbacks into
> the engine.
no interception was needed. Can you explain this in details?