At 02:10 PM 04-12-00 -0500, you wrote:

>The software world today is radically different from when I originally
>designed and implemented UDFs. Processors are blindingly fast, memory
>is dirt cheap and plentiful, and we have more sophisticated tools
>and infrastructures for designing systems. As designers, we need
>to remember that all designs are compromises, and if the world changes,
>compromises need to be revisited from time to time.

Ah, those sweet, innocent days of the mid-eighties when Windows was just an
idea in a potting shed, the Internet was not a hangout for vandals with
high IQs, VB-script had not been invented and database designers designed
databases that were intrinsically stunning to behold.

>Java is the idea solution to database embedded UDFs. Java code
>runs in a controlled sandbox. A Java method cannot see, let along
>change, anything that is not within the sandbox. Java cannot leak
>memory (a JVM can, but that is a bug). A Java method can be safely
>unwound without lose of resource or danger of deadlock. Resources,
>memory and processor, can monitored and constrained. Java, as an
>object oriented language, provides a mechanism through which arbitrary
>context can be made available to a UDF, including connection handling.
>Java has a well defined exception mechanism, allowing a UDF to cry
>for help. Java code is intrinsically cross platform and can be
>readily stored within the database itself, permitting backup of
>the UDF itself, not just its name. Java is a stable, widely
>respected standard with dozens of independent JVM implementations.
>And Java has a debug architecture consistent with remote debugging.

All of the above. But Java also inflates the installation footprint. As
you said, compromises...

Helen

All for Open and Open for All
InterBase Developer Initiative · http://www.interbase2000.org
_______________________________________________________