paulruizendaal wrote:

>Yes, Oracle can store the .class files in the database. I still have
>to investigate that further. From a cursory glance, I'd say that all
>that it does is storing each .class file in a blob and on the fly
>retrieving/storing that into a configured directory which is in the
>configured classpath.
>
>

A better way to handle this is to tweak the JVM to load directly from blobs.

>For me it is *not* a priority, but adding a RDB$JAVA table, with
>name, source and bytecode would be an option. If the plugin cannot
>find the class, it looks it up in this table. If found, it moves the
>code into a classpath directory and tries again. If the name is not
>in the table either, or the code blob is null it reports 'not found'.
>
>

There needs to be a CLASSPATH somewhere both to pick up base classes and
for development. The java class table should logically follow the
classpath, meaning specifically that any class found in the CLASSPATH
takes precedence over the database version.

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 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.

>The create statement would take source and compile it using an
>external java compiler. If the compile fails, it stores a NULL in the
>code blob. It would need to clear the relevant class from the cache
>directory of course.
>
>

That's getting way to cute for anyone's good. Java development should
be done in an external IDE.

>The jvm.conf would need to include settings for the cache directory
>and for the java compiler path. The classpath setting should
>(automatically?) include the cache directory.
>
>

No, just a CLASSPATH.

>The RDB$JAVA table could be created on the fly when first referenced
>by the SQL compiler and/or the meta data system.
>
>

No, it should be created by the application that loads Java classes.
The engine shouldn't know *anything* about Java whatsoever unless you're
prepared to take the step of requiring Java.

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.

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.

I'm not going to do the JVM integration, but I've written a custom JVM
designed for embedded database use, so I have a pretty good idea of
where the elephant pits are.


--

Jim Starkey
Netfrastructure, Inc.
978 526-1376