Java as UDF????

I know Oracle has taken that turn in 8i..... but....

Im also developing in Java, and in my opinion one should not use Java for
such purpose of two reasons... speed and memory requirements.
JBuilder 3 C/S needs at least 384 MB to run in an acceptable speed on a PIII
450 Mhz platform. IBM Visual Age requires around 512MB (thats the number
I've been recommended) on the development platform.

Reason? I dont know... since just about all other compilers and IDE's (c++,
pascal etc.) can easily run with an acceptable speed in 64MB, the Java
specific part must be the one using memory.

Thus the problems of using Java as UDF are:
1) The general speed of compiled bytecode WILL be slower than
natively compiled code where the compiler could take the time it needs to
optimize the code in the best way.
2) Although Java will run with limited memory, it will run like a
snail.

I have never understood why a widely accepted standard (although fairly
messy one) like C++ (or even better, plain C) is not as portable or as
readable or maintainable as Java.

When will the portability be needed? How often do you move your database
from one platform to another? Probably not more often than its possible to
recompile the UDF's on the new platform using a plain standard C++ or C
compiler.

Java takes care of leaks? Yep... but it also introduces leaks by it self,
which you cant do a thing about. Thus its better to be in charge yourself,
and thus have the complete control (and responsibility) of allocation and
deallocation of ressources.

Java is fine for some development tasks, although I would still prefer f.ex.
Delphi for most purposes except web applets.
But if the requirements is the fastest and smallest featurepacked database
existing, Java is not the choise for UDF's. Java is a hyped up buzzword
which in it own terms is not even platform independent. IBM does f.ex. not
support JDK 1.2 according to their own homepage. Latest supported release is
1.1.x. Next supported release is 1.3. Thus.... moving software developed
using JDK 1.2 to an IBM platform is currently practically impossible (I know
they are supporting a BETA 1.2.... but who wants to run production on BETA
code?).

Bottom line is... ok... let people develop UDF's in Java if they want to....
but PLEASE let native languages like C, C++ or OP be the standard way of
doing them.

Sorry about a long post....

best regards

Kim Madsen
kbm@...


-----Original Message-----
From: Ann Harrison [mailto:harrison@...]
Sent: 16. april 2000 20:10
To: IB-Architect@egroups.com; IB-Architect@egroups.com
Subject: Re: [IB-Architect] UDF replacement: native shared libraries vs.
Java


At 11:39 PM 4/6/00 -0600, Tim Uckun wrote:

>Just thinking out loud here...
>
>What if instead of having triggers and stored procedures the database could
>send events or signals. that way your code could hook into the database
>events yet be running outside the database altogether. Of course this could
>also be completely language neutral so you could code in PERL if you wanted
>to..
>
>Leave the database engine light and simple.

Ummm... Switching process context tends not to be simple or light -
especially if you're comparing it with a built-in trigger that's inserting
the current data into a row. There's also a lot of information available
to stored procedures and triggers (connection, transaction, current row,
new row, parameters...)

The language neutral part is very attractive though...

Ann


------------------------------------------------------------------------
Avoid the lines and visit avis.com for quick and easy online
reservations. Enjoy a compact car nationwide for only $29 a day!
Click here for more details.
http://click.egroups.com/1/3011/3/_/830676/_/955908656/
------------------------------------------------------------------------

To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com