1996-04-27 - Re: The Joy of Java

Header Data

From: Scott Brickner <sjb@universe.digex.net>
To: mpd@netcom.com (Mike Duvos)
Message Hash: ae6050dbfe6e193a51d59affe366d746ecf0934928398f9a07df07b65d0e6f42
Message ID: <199604262131.RAA13066@universe.digex.net>
Reply To: <199604260527.WAA02314@netcom8.netcom.com>
UTC Datetime: 1996-04-27 06:44:09 UTC
Raw Date: Sat, 27 Apr 1996 14:44:09 +0800

Raw message

From: Scott Brickner <sjb@universe.digex.net>
Date: Sat, 27 Apr 1996 14:44:09 +0800
To: mpd@netcom.com (Mike Duvos)
Subject: Re: The Joy of Java
In-Reply-To: <199604260527.WAA02314@netcom8.netcom.com>
Message-ID: <199604262131.RAA13066@universe.digex.net>
MIME-Version: 1.0
Content-Type: text/plain

Mike Duvos writes:
> > 1. Java is of course not a perfect language, nor even the
> > best for specific applications. Other languages will
> > continue to thrive. Critics of the language and related
> > items (applet model, JDK, JITs, etc.) may point to various
> > problems (e.g. security).
> > 2. However, the "big picture" is compelling. Java arrives
> > at a time when a Babel of languages and platforms threatens
> > interoperability. C++ is despised by many (though, to be
> > fair, liked by many, too), and developers are adopting
> > Visual Basic (and the vbx widgets, etc.), PowerBuilder,
> > Delphi, flavors of Smalltalk (no pun intended), and
> > scripting languages (Perl, TCL, Python, etc.).
>I completely agree with this.  Java incorporates the type of
>automatic corruption-proof memory management found in languages
>like APL, the basic notions of object oriented programming, fast
>dynamic linking, and a C-like program structure.
>This is powerful combination of features and gives Java the
>potential to do all the platform-independent things that were
>advertised for C before the rude reality of thousand line
>makefiles reared its ugly head. . The complete specification of
>the Java Virtual Machine means that the behavior of Java programs
>is perfectly well-defined, and one does not have to tweek
>anything which is processor or operating system dependent.

Unfortunately, this last statement isn't really true.  To quote from the
"Java Security" paper from some Princeton researchers:

    The Java language has neighter a formal semantics nor a formal
    description of its type system.  We do not know what a Java program
    means, in any formal sense, so we cannot reason formally about Java
    and the security properties of the Java libraries written in Java.
    Java lacks a formal description of its type system, yet the security
    of Java relies on the soundness of its type system.

And later:

    The Java bytecode is where the security properties must ultimately
    be verified . . . .  Unfortunately, it is rather difficult to verify
    the bytecode. . . .  The present type verifier cannot be proven
    correct, because there is not a formal description of the type
    system.  Object-oriented type systems are a current research topic;
    it seems unwise for the system's security to rely on such a
    mechanism without a strong theoretical foundation.  It is not
    certain that an informally specified system as large and complicated
    as Java bytecode is consistent.

And in the conclusions:

    We conclude that the Java system in its current form cannot easily
    be made secure.  Significant redesign of the language, the bytecode
    format, and the runtime system appear to be necessary steps toward
    building a higher-assurance system. . . . Execution of remotely-
    loaded code is a relatively new phenomenon, and more work is
    required to make it safe.

I do think that the ideas embodied in Java are very important, and will
significantly shape the future of computing, but Java itself may be just
a stepping stone on the way.