At 12:29 AM 12/7/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.
>

"Don't hide your eyes, plagarize. But be careful to call it research."

-- Tom Lehrer

>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.

Requiring the poor sap who just wants a database to have the
skills of a system integrator to find and install a compatible JVM,
configure the system so it can find its base classes without
impacting other activity on the machine is more than I'm comfortable
with. My goal with Netfrastructure is to make the whole thing
installable by someone with the skills of an ISP -- in short,
breathing and going to the bathroom.

>
>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.
>

Hey, it's open source. In any case you want to stay with the published
APIs (I even did that). But there are a bunch of native calls from
base classes dealing with threads and stuff that you really want to
field. Depending on implementation, any JVM is either going to recognize
and handle them itself or pass them off to an external library. The
latter doesn't fly very well. A second issue is monitor implementation.
Having the Java monitors mesh with the thread synchronization mechanisms
used by the containing engine is necessary to do deadlock detection.
This isn't life and death because we all know that in a well designed,
well implemented, divinely blessed, and flawlessly administered system
dead locks don't occur. Another nice thing to have is class loading
from the database itself. There are probably other acceptable ways
to do this, but sure is easy to have the JVM be database aware.

>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).
>

The semantics of the base classes are pretty well defined, but the
implementations (and the fine details) are all over the map. The
Sun classes, for example, have shifted from very close to pure Java
to almost pure native functions in 1.2.

Personally, I favor tight integration among subsystems. Reasonable
people can differ.

>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.
>

I wouldn't touch those porkers with a 10 foot pole. You really
want a tight sandbox. Communication outside the box is borderline,
but probably permisible. Importing class files over the network
isn't.

I wouldn't lose sleep over the perform issue for a couple of reasons.
First, Java triggers, UDFs, and stored procedures will account for
a fairly small number of cycles consumed. Second, for database stuff,
Java performance is bounded by the string handling code, which doesn't
lend itself to byte code optimization. The speed of the memory
allocator is almost certainly more important that just in time
compilation.

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

Hmmm. First, dynamic class reloading to support both rapid development
and 24x7 operation across application upgrades. Second, a garbage
collector optimized for a database environment (threads aren't stalled
during garbage collection). Third, a mechanism for mandatory class
manifests to protect third party application code. Four, mentioned
above, inclusion of the SYSTEM.JAVA_CLASSES table on the class
search path. Fifth, a mechanism to coordinate object life times
between C++ objects (generally managed with use counts) and their
Java proxies (garbage collected). And lots of little stuff.

>Hmm I must find out some more about this netfrastructure.
>

Wrong list. You want Helen to ban me? My wife to throckle me?

>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?
>

I stole base classes from Microsoft, Jdk 1.1.8, and Jdk 1.2 depending
on mood, phase of the moon. The Microsoft classes are cleaner, the
Sun more functional.

When you look the progression of Sun classes there is a very pronounced
diminuation of quality as the smart people left and the morons took
over. Remind you of anything? The worst case was a private native
function in the serialization code that returned a vector of class
objects representing the stack frames. The dork decided that he
need to know the class type of his caller's caller. Somebody should
have explained that that was a stupid thing to want or maybe just
fired him.

>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?
>

Win32 and Linux so far. Have a lobby for Solaris. Don't care much
about the rest except MPE/XL, which I despise with great passion.

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

You can compile with whatever. I use J++ because I have poor taste.

Packaging in Netfrastructure is sublime. It knows the Java class
for an application and the class for its parent application. It
does a class tree walk (yeah, yet another useful special feature)
for each, find the classes referenced in the application not referenced
in the parent app, finds the class files (.jar, .zip, .class,
database) and sticks them in the package file. On restoration/install,
the classes get dumped into the database where they belong. One
file, indivisible, with justice and compatibility for all. It is
sooo coool.

>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.
>

Netfrastructure is for packaged Internet solutions. It runs on
iron and the interface for everything is the browser. An app
can be installed, customized, and administered by the truely
clueless. Or an app can be installed, cloned a zillion times,
each clone individually customized and administered, all on a
single server.

>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.
>

Why didn't I think of that? A Web page? What a great idea!

Jim Starkey