[Prev][Next][Index][Thread]
Java is not type-safe
Its my pleasure to announce the availability of the following TR
at http://www.research.att.com/~vj/bug.html. This is a revised
version of a note I had circulated earlier privately.
Best,
Vijay
---------------------------------------
Java is not type-safe
Vijay Saraswat
AT&T Research
180 Park Avenue
Florham Park
NJ 07932
August 14, 1997
A language is type-safe if the only operations that can be
performed on data in the language are those sanctioned by the
type of the data.
Java is not type-safe, though it was intended to be.
A Java object may read and modify fields (and invoke methods)
private to another object. It may read and modify internal Java
Virtual Machine (JVM) data-structures. It may invoke operations
not even defined for that object, causing completely
unpredictable results, including JVM crashes (core dumps). Thus
Java security, which depends strongly on type-safety, is
completely compromised.
Java is not type-safe because it allows a very powerful way of
organizing the type-space at run-time (through user-extensible
*class loaders*). This power can be utilized to write a program
that exposes some flawed design decisions in the Java Virtual
Machine. Specifically, one can produce a class A and an
associated ersatz class A' which can "spoof" A: its name N is the
same as A, but it defines members (fields and methods)
arbitrarily differently from A. A "bridge" class B can be
defined which delivers to a class D (for which the name N is
associated with A') an instance of A. D can then operate on this
instance as if it is an instance of A', thus violating
type-safety.
There are two ways in which the violation of type-safety may
be addressed. I identify a necessary and sufficient conditions
on class loaders such that if all the classloaders definable in a
Java program satisfy this condition, then the program will not
have any "bridge" classes at run-time, and hence will
not exhibit this kind of type-spoofing. Thus one may still
informally argue that a *particular* Java program may not
exhibit this kind of type-spoofing, and one may design Java
programs in the future to satisfy this condition. A reading of
the informal description of class loaders given in HotJava
indicate that it may satisfy this condition.
For the *language* to be type-safe however --- a far more
desirable alternative --- either the classloader interface must
be redesigned or the JVM must be fixed. I argue that arbitrary
user-definable classloaders represent a significant conceptual
advance in Java, and should not be limited in any way. On the
other hand, I show that the JVM design can be fixed (without any
run-time penalites) by fixing the (link-time) constant pool
resolution process to take into account information available at
link-time and not just compile-time. Interestingly, this also
points out that Java is actually a rather impoverished language
for programming the Java Virtual Machine -- programs cannot be
written in Java which exploit (in a type-safe way) some of the
capabilities of the JVM to manipulate classes loaded in different
class-loaders.
Further study is needed to determine if there are any other
ways in which type-safety can be compromised in Java.
This is a revised version of an earlier note, of the same
name, that was informally circulated Monday Jul 21, 1997. That
version had (mistakenly, it now turns out) argued that some
run-time type-checks were unavoidable for unrestricted
class-loader functionality. Thanks to Drew Dean, Kathleen Fisher,
Nevin Heintze, Tim Lindholm, Martin Odersky and Fernando Pereira
for useful feedback and discussion. I remain responsible for the
actual contents of this note.