At 08:51 AM 4/7/00 +1000, Jan Mikkelsen wrote:

>Jim Starkey <jas@...> wrote:
>
>>I would very much like to see the current UDF mechanism phased out
>>in favor of Java. The sandbox model is attractive, but the (theoretical)
>>ability to install or replace UDFs while the server is running would
>>be absolutely wonderful. There are JVMs that handle dynamic class
>>replacement, but no open source ones. The main problem is efficiency
>>switching between C and Java without undue overhead. There are
>>also thread and garbage collection issues, but given a suitably
>>tame JVM...
>
>
>I can't really see why shared libraries (DLLs, whatever) can't be replaced
>on a running system. Other than a simple matter of programming, of course.
>:-)
>
>A new version of a DLL is loaded, new statements start using the new
>functions. Once the statements which used the old functions are finished,
>the old DLL is not needed, it can be unloaded.
>

It probably could be done. But that isn't the point. UDF's have
always been a liability from the perspective of reliability and
security. Loading an executing an arbitrary library, even one
more or less vetted by the DBA, is scary. A UDF can write over
memory, break security, trash records, corrupt databases, and
anything else it's evil little heart desires. The concept of
a UDF exchange is unthinkable. Who in their right mind is going
to stick unknown code in the guts of their mission critical
database server? Certainly not somebody smart enough to use
Interbase.

A Java function is completely safe. It runs in a controlled
sandbox and cannot see anything that is not passed to it or
declared as a public class level static variable, and even
that can be controlled by a suitably paranoid VM.

The advantages of Java UDFs, blob filters, and possibly stored
procedures are so great that I don't think it makes sense extending
the old, insecure, native UDF mechanisms.

Jim Starkey