|Subject||Re: Java Stored Procedures|
> For me it is *not* a priority, but adding a RDB$JAVA table, withIt can be implemented even more easier if we consider the classloader
> 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
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 anYou can use compiler from the JDK in the tools.jar.
> external java compiler.
> If the compile fails, it stores a NULL in theWhy not to throw an error and do not store anything there?
> code blob.
> It would need to clear the relevant class from the cacheWith classloader hierarchy this is not needed, Java can load classes
> directory of course.
from any input stream, and BLOB is as good as file system or network
> The big advantage of such a setup would be that databases remainQuestionable, since the compiled class often relies on the external
> self-contained ("xcopy installable").
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.