[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Article for Slashdot: Oracle for Java



Well, I am going to post the enclosed article on behalf of myself, and not
on behalf of the entire list. In any case, I'm sending it here first to get
some comments, corrections, etc. 

BTW, What do you think makes the best title: 
"Oracle for Java: can it work?" 
"Oracle for Java - why it cannot work"
"Oracle for Java vs. Oracle for Perl"
"When not to follow the sun"
"Why Java is not suitable for OO RDBMSes?"

Well, here goes:

---------------------------------------------

Oracle Corp. recently announced that they are planning to release a 
version of their Database Server to run on Java. Despite Java's 
popularity and all the hype around it, is this really a good idea?

Java is converted into a machine-independent bytecode, and then 
interpreted or JIT-compiled by a system-dependent interpreter. Such 
interpreted languages have the advantage of running within their own 
virtual machine. Thus, they can hide such machine-code derived 
problems of buffer overflows or assigning values to the NULL pointer: 
in the worst case the interpreter will either trap the exception or 
exit with an error code, and will not cause any damage to the system. 
Furthermore, they can supply functionality to the programmer that is 
implemented by different APIs on different OSes enable him to release 
only one release for all of them.

It is no wonder that most knowledgeable users and administrators do 
most of their day-to-day programming in one or more of those 
languages. It doesn't only reduce the time of development but lower 
problems in uploading the programs to the server or distributing them 
to the users. And of-course the various Assembly-level glitches are 
trapped by the interpreter, which makes it more secure in the first 
place. There is a performance cost naturally, but most systems are 
powerful enough as it is to handle it.

Java is one such technology, but is hardly the only one. Other such 
technologies include Perl, Python and Tcl/Tk. From what I know of 
Java's features as a computer language, it is my belief that it is not 
suitable as a basis for a full-featured object-oriented database 
server. If Oracle proceed with their plan, I predict that:

1. It will take a long time to develop, and consume Oracle of precious 
personnel and money.
2. Once released, it will be ignored by professional administrators.
3. Oracle will end up selling it to many end-users who will keep 
complaining, asking for constant support and demanding their money 
back.
4. It may even break Oracle, in a time when its financial status is in 
prodigy anyhow.

It's not that I don't like Java. It's a cute language, but it's 
clearly a language for toys: small client-side or serve-side applets 
that do various simple tasks; configurable controllers for home 
appliances; various multimedia rich applications such as games, demos 
or educational programmers. Maybe even a sophisticated role-playing 
gaming system across the Internet based entirely on Java.

But an entire object-oriented relational database management system? 
For that matter is Java suitable for a powerful and configurable 
web-server that can rival Apache or Netscape's Enterprise Server? How 
about a cross-protocol messaging system like MS Exchange Server? Or a 
search-engine like Altavista or Excite? How about a system that can 
integrate various online services (e.g: web, mail, push technology, 
IRC, ICQ, FTP, usenet) with one consistent interactive content?

All the applications I mentioned do a lot of data and text processing. 
And with all due respect Java is not suitable for data and text 
processing. I can testify that both C++ (which is probably the 
language Oracle is written with at the moment) and perl version 5 are 
much better. Plus, perl 5 is much handier than C++, and has some 
advantages of being an interpreted language running on top of its own 
virtual machine.

In Java a two-dimensional array has to be initialized with the 
following statements:
int array[][] = new int [] [10];
for(int a=0;a<10;a++)
{
    array[a] = new int [10];
}

And if I later need to resize it beyond the 10*10 boundary... oh well. 
In Perl any array can have an unlimited number of dimensions and an 
item can be written at any coordinates. For example:

my (@array);
$array[100000][5000][87778787] = 3;

is a perfectly legal perl statement. It is very possible to write a 
short non-recursive function in perl that can duplicate a complex 
hierarchial data-structure, containing giga-bytes of information. To 
duplicate a Java object, I need to assign each one of its members 
separately. The Java statement "MyClass New = Old" will result in two 
references to the same physical object. 

In Java, the most common data structures like a stack, a queue, or an 
associative array lie somewhere under the java.lang package and have 
names like java.lang.Stack or java.lang.Deque. Furthermore, they can 
only handle the most generic data-type: Object. This means that Oracle 
Programmers will have to implement their version of these containing 
either more basic data-types (such as the various integers) or derived 
classes of Object that will not require them to do the sub-classing 
all the time. After all, how much can one do with a reference to 
Object?

A standard perl array on the other hand can serve as a stack, queue or 
deque as well as a standard vector, and one can join them or retrieve 
selected items and ranges of it by using the built-in perl operators 
and functions. Perl5 hashes can serve as associative arrays, classes, 
as base for binary-trees, and many other uses. A perl scalar cannot 
only be a buffer whose size is limited only by the perl interpreter, 
but a reference to all other perl data-types. And its behaviour is 
transparent for the programmer.

I did not do an expert research on object-oriented databases, but from 
what I've heard each database can contain, besides tables, several 
other databases and a record can contain a table within one of its 
fields. Are the end-users who would like to script the server with 
Java are going to see a database as an object that contains an array 
of Objects or com.ORACLE.whatever.BasicDBClass's which have to be 
subclassed into com.ORACLE.whatever.Table's and 
com.ORACLE.whatever.Database's?

A basic Perl data structure can be "tied" into objects and a list of 
parameters, which can enable the programmers and end-users to think of 
a record as a simple hash, which is the natural way to think of it, in 
my opinion. And a RDB table would simply be an array of such hashes. 
For instance, to increment the values of the field myfield in the 
table mytable by 1, one would have to write the following code in 
Java:

Int ref;
for(int a=0;a<mytable.getRecordsNum();a++)
{
    ref = (Int)(mytable.getRecord(a).getField("myfield"));
    ref.fromInt(ref.toInt()+1);    
}

And in perl:
foreach $r ($mytable->@records)
{
    $r->{"myfield"}++;
}

I wonder what will be easier to understand. Java's object-oriented 
programming is based on the Smalltalk school of OOP and is very 
restrictive: objects can only be single-inherited, operators cannot be 
overloaded, no pointers to methods, strict data-typing etc. Perl 5 has 
much more flexible OOP capabilites, and for a large-scale project such 
as modern RDBMS, I believe both its programmers and the users who will 
want to script it will appreciate it. Perl also has some advantages 
over C++ in that field. For instance, one can add member items and 
methods to objects at run time, since they are represented internally 
by hashes.

Java's I/O mechanism is quite awkward with names such as 
FileInputStream, BufferedOutputStream, or ServerSocket for some of the 
most basic I/O operations. Perl uses simple global functions like 
"open", "print", "pipe", "socket", or "print", and can do some complex 
I/O operations with a few statements. And an RDB server requires a lot 
of I/O.

If Oracle for Java comes out, I will not even want to try it. For 
once, I know it's going to be a super-complex hierarchy of classes and 
interfaces that will be a mess for Oracle's newly-recruited 
programmers to make sense of, much less keep up to date. Even if its 
first version works, I know that at a certain point, it will break 
under pressure and the code will fall to pieces. So, I'd rather not 
rely on a Java based RDBMS in the first place.

Secondly, I don't know if I will be able to script the damn thing 
without losing my mind. With all due respect, Java per-se is not a 
good scripting language, while perl is perhaps the best scripting 
language on the planet. 

The Java technology is not in a stable state now. There are already 3 
major versions of the JDK and many APIs are constantly changed, or 
even lack a proper specification. Almost all Java run-time 
environments are problematic and unstable, and most web-browsers ship 
only with JDK 1.0.2. Java micro-controllers may help solve this 
problem, but it will take some years before they are integrated into 
future much less existing systems. Chances are that end-users will try 
the Java DBMS out, see that it isn't stable or fast enough, and give 
up immediately.

On the other hand, if I'll hear that a serious OO RDBMS based on Perl 
is due to arrive I will be eagerly waiting to try it out, and I 
believe most people who used UNIX recently will say the same. Perl5 is 
an amazing language, with superb system-integration, extensibility and 
embeddebility, AI-like features, a good security mechanism and on top 
of all a nice C-like syntax.

Oracle for Perl will be able to act as its own multiplexer, 
de-multiplexer and middleware. One will be able to program it to read, 
write and transceive data to other resources on the network. It will 
be able to act as its own RAD. UNIX users write Perl scripts that 
perform complex and simple data manipulation, even with simple 
flat-file records, and if the perl programmer will be able to access a 
state-of-the-art database engine and SQL interface at the tip of his 
hands: the sky is the limit.

When I joined the Java Developers Connection some weeks ago, my 
registration was handled by a script ending with the ".pl" extension - 
a clear indication that it was a perl script. If the webmasters of 
JavaSofts' website preferred to a perl script over a Java servlet for 
the simple database-related task of registering a new developer entry, 
then how can anyone except an entire database server to be programmed 
and maintained with Java?

I realize that many newbies believe Java to be "the language of the 
future" and will say "for what?" if they hear of 
Oracle/Informix/OpenIngres/etc. for Perl. Still, I believe those 
vendors can make enough money of their databases by selling them to 
more experienced developers, administrators and users who are familiar 
with the perl technology. After the newbies will hear from them how 
great it is, they will want to try it too. 

It is my belief that no single computer language is suitable for all 
purposes, especially Java with its so many inherent restrictions. And 
the way I see it, if Oracle is looking for a cross-platform language 
to run a server on, perl, not Java, should be their choice.




----------------------------------------------------------------------
Shlomi Fish        shlomif@ibm.net
Home Page:         http://t2.technion.ac.il/~shlomif/

Women are the second most difficult to understand entity in the world after
the Windows NT kernel.