> Message: 2 Date: Tue, 05 Dec 2000 09:37:13 -0500 From: Jim Starkey
> <jas@...> Subject: Re: RE: UDF and null At 10:38 PM
> 12/5/00 +1100, Mark O'Donohue wrote:
>
>>> >>
>>
> First, my recommendation would be for an integrated, embedded JVM
> built as part of the base product for a couple of reasons.
>

Thats a fairly big ask, to not only be developing a relational database,
but also a java virtual machine as well. I appreciate where you are
comming from with this, since you've already implemented your own, but
I'd be worried that we already have enough to chew on at the moment.

If the first step here is to get the users to be able to run java UDF's
and attach java methods to triggers, I'd be inclinded to let the user
provide the JVM, at least in the first instance. Currently there is no
java code in Firebird, the only dependancy then is that the JVM runs the
users own code, so let them choose which one they want to run. This
would have an initial minimal impact on Firebird, but allow some
exposure and usage of java.

If further down the track Firebird includes a truckload of java code in
it then there is a stonger case for providing a default JVM with the
code. But even then I'd be inclined to provide it as a default JVM
loading it in the standard way so that a user can replacing it with
their own version if they wish.

I would have agreed with you 100% here a few years ago about an embedded
solution, but since java 1.1/1.2 most of the java classes, particularly
the non awt/swing subset of classes you are referring to are pretty
stable. I use a lot of JVMs, Microsoft, IBM, Sun, Blackdown, on
win32 (nt/2000/98/95), linux, solaris, and irix. I regularly move
class files amongst these systems and I've been pretty impressed with
how compatible a lot of the batch program code used at about the java
1.1 level actually is (swing code is another story however).

Embedding our own JVM would also leave the onus on us to compete with
performance things like hotspot/ the wonderfully fast IBM
implementation, and to add feature support for things like enterprise
java beans, java transaction services etc.

Often people have good reasons for choosing a particular JVM, say
wanting to migrate to the IBM one, because it is 20 times faster for
certain operations (it proved to be for mine) or becuase jdk1.3 fixes
certain bugs or provides a feature (like the proxy class, or collection
classes, or templates). Even some support (since we are a server) for
the (free) java Jikes, or gjc compilers would be a good idea since they
are often used in jakarta servlets to get a bit more speed milage. For
these reasons it would be desirable for users to be able to change JVM
without having to wait for us, or Kaffe to implement such features.


So in summary, Id be inclined to try and steer clear of getting involved
in developing a JVM or even customising an existing one. However, in
the future when/if Firebird contains a lot of java code then specifying
a compatible JVM version number or as the Jahar implementation catches
up in features including it as a compatible default JVM may be a good idea.

> First,
> you want explicit control over the implementations of the native
> functions that backup the base classes to give an appropriate
> sandbox.
>

What extra features are you after here that are not in the standard java
JVM,

Most of the access/security stuff I see as being similar to the
requirements for sandboxing used in running servlets. Initially I would
have said just call the java methods then over time adopt the sandboxing
from what is available, and is developing through the apache jakarta
project since their need and problems will be similar.

> Second, it guarentees cross platform and cross version
> compatibility (the Java byte codes are completely stable; base
> class implementation is big time slippery).
>

> Third, it simplifies
> the installation and configuration problems. There are at least
> two public source JVMs and one with a license compatible with
> Firebird.
>

Presumably you mean Kaffe and Japher here, Kaffe from memory is GPL, and
japher is being distributed under the LGPL, is that the one you were
thinking about?

Last time I looked at kaffe, although going well, part of why it was so
fast was becuase it didn't have a lot of the bytecode validation
implemented - so security here is a two edged sword. it also missed a
lot of basic classes like the crypto ones.

> For what it is worth, the Netfrastructure JVM is about 20,000 lines
> counting the JVM, the class file handling crud, and all native
> methods required to implement a reasonable set of base classes
> ("reasonable" in this case meaning "non-AWT"). The Netfrastructure
> JVM, however, contains some goodies not present standard JVMs.
> The line count, as I once told Diane Brown, includes both comments.
>

Hmm I must find out some more about this netfrastructure.

I presume it provides a restricted subset of java classes, something
like the current KVM definition, but presumably it does not contain gui
code? Who provides the base classes, and what is reasonable set, for
instance if I had code written in java using classes released in java
1.0/1.1/1.2/1.3 would I need to change it to run?

Does it run on a variety of client platforms, it sounds like it was
built to do so, how far does it go onto other platforms, FreeBSD, Mac,
MPE/XL?

I presume you compile using a standard jdk and package the classes in
jar/zip? format for distribution.

What sort of applications, do you develop with it. I guess it's for
distributed systems but not those where the client is the general
public, since it requires an install on the client machine.

To take this off line a little and to give me some more background on
where your comming from, do you have a web page, - with perhaps more
than just the two comments.


Cheers

Mark
--
Java - write once test everywhere.