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