At 01:23 PM 5/15/00 -0600, Tim Uckun wrote:

>
>Although I have no real objection to the use of Java it might be nice to
>have a choice of languages. All modern scripting languages support
>integration with C pretty nicely and most have open source
>licences. Remember that Oracle had to upgrade their database to make it
>compatible with Java 1.2 and Sun is already ready to release 1.3. Keep this
>in mind if you plan on bundling them together. Unless the JVM selection is
>dynamic you stand a good chance of running behind the curve. The open
>source JVMs tend lag far behind the efforts of IBM and Sun.
>
>

There are two issues here: Multiple languages and choice of Java.

I don't think integration with an external language of than Java
is feasible for either portability or security. Java is about the
only language I know of with portable binaries and a rigorous
sandbox model. It also has a well designed object encapsulation.
Turning some other language designed for other purposes into a
DML is going to be an unsatisfying experience. Besides, with Java
as the near universal pedagogical language, hords of Java programmers
will be entering the job markets every year. Using the language
they used in school is a good marketting. Even with a JVM
source, the project is going to be non-trivial.

I haven't looked much at 1.3, but Java growth has always been in
base classes and the native methods to support them. The class
file format has not changed since the initial publication of the
specification. I think the only actual language extensions has
been internal classes, which is only name space management.

But the base classes have indeed changed, sometimes in incompatible
ways (if you follow the specifications, you can see when the smart
people quit Sun). This suggests that for compatibility and
portability, Interbase should control and maintain a fixed set
of base classes and native method implementations. We should
pick something and live with it. Most (probably all) of the
changes and extensions to the base classes have nothing to do
with embedded database operation, so the version where we fork
the classes is unimportant. Somehow I don't think AWT has
much to do with UDFs. We need java.lang.*, java.math.*,
java.sql.*, java.util.*, and very little else.

Over time, the integration of the JVM and database engine will
increase as things like dynamic class reloaded and synchronized
garbage collection are implemented. This will improve the
product, but decrease the attractiveness of invoking external
JVMs.

Jim Starkey