At 11:05 AM 4/17/00 +0200, Kim-Bo.Madsen@... wrote:

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

There is no intrinsic reason for a Java compiler to be a pig. Java
has a tiny grammar, a simple target (byte codes), a straightforward
class file format, and no opportunity for peephole type optimizations.
The only possible reason that a Java compiler have those memory
requirements is that it is miserably architected and horribly coded.
Even so, this is irrelevant since the important piece is the UDF,
not the development environment.

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

Of course byte code interpretation is more extensive than hard compiled
code, but since the entire execution is engine is and always has been
an interpreter, so what?

A strong argument against Java is that Java strings are Unicode, so
all strings passed between Java and the engine require translation,
or that Java strings require allocation of two objects or that Java
lacks string oriented byte codes. All true and must be considered.

The main argument in favor of Java is that it runs in a restricted
sandbox. A Java method can be invoked within a larger system without
danger that it will trash memory or violate security. It's memory
allocation can be monitored as can the cycles it consumes. The
nature of the class file requires dynamic loading and permits
dynamic reloading. The advantages, in my mind at least, vastly
outway the theoretical performance hit.

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

A well written C++ program is potentially as portable as a Java program.
A badly written C++ program is totally unportable howerver, where a
badly written Java program is just as portable as a well written one.

C++, however, requires a top notch programmer the better part of a
year to master the language, which most C++ programs never do.
Java is an easier language to teach and to learn and much easier to
master than C++. Java doesn't have macros, templates, conditional
compilations, operators, overriding casting, levels of memory
allocation, inlines, calls by reference, non-virtual methods,
globals, unions, etc etc etc.

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

Server platforms change all the time. Two thirds of the Interbase
ports were the result of customers straddling serveral platforms.
Just watch the migration from NT to Linux...

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

You are dead wrong here. First, there is no reason why a JVM should
leak. Java objects can't leak unless the garbage collection is broken.
[Yes, a programmer can waste memory by making class level variables
to point to stuff unneeded, but that require's going out of your
way.].

The problem is explicit allocation/deallocation is that it eventually
consumes about 25-30% (or more) of total program size. The need
to manage lifetime of memory often forces more complex data structures
that would otherwise be needed. Use counts consume CPU cycles. Tracking
down leaks waste programmer cycles. Garbage collection is a very
good thing.

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

Please understand the there are almost no differences in the Java language
between 1.0 and 1.2 (internal classes are it), no change in the class
file whatsoever, and no changes to the bytecodes. There are implementation
changes to the base classes (a vast increase in the number "native"
methods required), many additional base classes, and profound overhauls
of the GUI subsystems (which stunk originally and though they smell
different now, still stink). There is nothing, absolutely nothing,
is the tiny number of base classes required to support UDFs that have
changed one iota from Java 1.0 or probably event Java -22.0.

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

I disagree. Interbase will be a better product if and when "native"
languages are deprecated:

1. It will be more secure (UDF can't violate security)
2. It will be more robust (UDF can't write over memory)
3. It will be easier to develop for (Java is better language)
4. It will be more portable
5. It will be easier to administrate
6. There can (and will) be a secondary market for UDF
libraries.

Java is not for everything. It is impossible to implement a
database with reasonable performance in Java. It is miserably
slow for fancy string stuff. It's GUI is reprehensible. But
as an embedded subsystem (for which it was originally designed)
it is superb.

Jim Starkey