One of the Java compiler's main lines of defense is its memory allocation and reference model. Memory layout decisions are not made by the Java language compiler, as they are in C/C++. Rather, memory layout is deferred until run time, and will potentially differ depending on the characteristics of the hardware and software platforms on which the Java system executes.
Secondly, Java does not have pointers. The compiled code references memory via symbolic handles that are resolved at runtime. Java programmers cannot forger pointers to memory, because the memory allocation and referencing model is completely opaque to the programmer and controlled entirely by the underlying run-time platform.
Very late binding of structures to memory means that programmers cannot infer the physical memory layout of a class by looking at its declaration. These features lead to more reliable and secure applications.
However, there are some implementation errors that disclose storage layout.
Although Java does not allow direct access to memory through pointers, the
Java library allows an applet to learn where in memory its objects are stored.
All objects have a hashCode()
method which, unless overridden
by the programmer, casts the address of the object's internal storage to an
integer and returns it.
The use of garbage collection rather than relying on explicit user deallocation eliminates some security holes. If Java had manual deallocation, this could provide a round about way of illegally casting. For example, a malicous object of type MyFile and then deallocates the memory used by that object, keeping the pointer. Then, the program creates a File knowledge of how allocation and deallocation is done, the new pointer to the File object is the same as the original MyFile pointer. The private methods of the File object are now accessible through the MyFile pointer.
Copyright © 1996 Virginia Polytechnic Institute & State University
All Rights Reserved
Vijay Sureshkumar
<vijay@csgrad.cs.vt.edu>
Last modified: Sun Oct 20 21:52:09 1996