Why Oracle and Java Cannot Work

Shlomi Fish has written up a piee on why Oracle and Java can't work together, but why Perl and Oracle will. It might be a language war type piece, but I don't really think it is. Both of these languages are really hot right now, and Shlomi does a great job explaining some of the reasons why.

The following is a feature by Slashdot Reader Shlomi Fish

Why Oracle for Java cannot Work

(and why Oracle for Perl can work better)

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 these languages. It not only reduces 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 jeopardy 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.