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

It can be implemented even more easier if we consider the classloader
hierarchy in Java. This can be implemented at the same time when
dynamic deployment is implemented.

> The create statement would take source and compile it using an
> external java compiler.

You can use compiler from the JDK in the tools.jar.

> If the compile fails, it stores a NULL in the
> code blob.

Why not to throw an error and do not store anything there?

> It would need to clear the relevant class from the cache
> directory of course.

With classloader hierarchy this is not needed, Java can load classes
from any input stream, and BLOB is as good as file system or network
location.

> The big advantage of such a setup would be that databases remain
> self-contained ("xcopy installable").

Questionable, since the compiled class often relies on the external
libraries, which are located on the file system. So we would need to
invent something like CREATE JAVA LIBRARY to be able to store .jar in
the database. This however has an issue that you cannot use it from
isql, since you cannot specify binary BLOB content in DSQL. And so on.

Roman