References, Pointers, and Null in Java

Programmers often judge a language by how little it asks of them. A language that lets you use a variable without announcing it first, or that lets you move a pointer wherever you like, feels faster to work with. This feeling comes with a belief: that a language which skips a requirement is simply more convenient and carries no real cost. Java's designers took a different view. They held that part of the problem with programming errors can be traced to the languages programmers use, and that a language can be built to protect against certain categories of error. This article examines the belief and asks how a language feature can prevent an error from happening at all.

A language without a declaration requirement has no list of legitimate names to check against. When the programmer types a name, the language accepts it and creates storage for it. A spelling slip, a stray character, or a substituted punctuation mark therefore produces a valid program that does something the programmer never intended. Nothing in the language flags the mistake, so the wrong behavior may surface only after the program has run for a long time, or only under conditions that are hard to reproduce.

The source treats this declaration rule as the foundation of the wider argument. Java variables must be declared before they are used, so a misspelled name that was never declared is reported at the point where it appears, instead of quietly becoming a new variable.

Java's protective features all follow one of two strategies. The first is to design the language so that a particular error is impossible to write. If the construct that would produce the error does not exist, nothing needs to be checked at all. The second applies when an error cannot be removed entirely. In that case the language is designed so that the error is detected automatically at the moment it happens. Detection has two benefits: it stops the error from causing further harm, and it alerts the programmer that a bug needs fixing.

An array is created with a fixed number of locations, numbered from zero up to a maximum index. Using a location outside that range is an error. Consider an array A with three locations, A[0], A[1], and A[2]. The positions A[3], A[4], and so on do not belong to the array. In Java, an attempt to store data at A[3] is detected automatically. By default the program is terminated, unless the error is caught by the program, a topic the source defers to a later section.

The diagram shows the boundary. Slots zero through two are allocated to the array, and the access at position three falls outside the allocated range. Java checks the index, so the access stops there rather than continuing into memory that belongs to something else.

The source contrasts this with C and C++. There the programmer must make sure the index is legal. If the programmer does not, the computer stores the data in memory that is not part of the array. That memory might be in use for something else, so the result is unpredictable and can be far more serious than a terminated program.

The source calls pointers a notorious source of programming errors. In Java, a variable of an object type holds one of two things: a pointer to an object, or the special value null. Using null as if it were a pointer to a real object is detected by the system, which is the second strategy at work. The source contrasts this with languages in which avoiding null pointer errors is left entirely to the programmer.

In the diagram, ref_a has a pointer leading to an object, so using it reaches real data. ref_b holds null, which points to nothing. Using ref_b as though it led to an object is the kind of misuse Java detects, rather than letting it proceed as if a valid object were present.

The source gives a historical case to show why this matters. On an early Macintosh computer, a null pointer was implemented as a pointer to memory location zero. A program that used a null pointer could change values stored near that location, and those locations held important system data. Damaging that data could crash the whole system, a far more severe outcome than a single failed program.

A second category of pointer error occurs when a pointer refers to an object of the wrong type, or to a segment of memory that holds no valid object at all. The source states that these errors are impossible in Java, because Java does not let programmers manipulate pointers directly. In other languages a pointer can be set to point essentially anywhere in memory, and doing so incorrectly produces unpredictable results. Here the first strategy applies: the dangerous operation is removed from the language rather than checked after the fact.

A memory leak occurs when memory that is no longer needed is never released, so it accumulates. In Java, once no pointers refer to an object, that object is garbage collected, and the memory it occupied becomes available for reuse. In other languages the programmer must return unused memory to the system. If that step is forgotten, unused memory builds up and leaves less for programs and data. The source recalls that many common programs for older Windows computers leaked memory so badly that the machine would run out after a few days and need to be restarted.

The key difference is who carries the responsibility. Java moves it from the programmer to the system, so one common category of leak is prevented by design rather than left to discipline. Your code does not need to remember a manual release step for every object it stops using.

A buffer is a segment of memory that a program has allocated to hold data it expects to receive, for example data arriving from another computer over a network. A buffer overflow occurs when more data arrives than the buffer can hold. What follows depends on whether the program or networking software detects the overflow. If it is detected, the only result is a failed transmission. The serious case is an undetected overflow, where the software keeps writing past the end of the buffer into memory that belongs to something else. That memory might hold important data, or even part of the program itself.

The source explains why this is a security problem. If an overflow overwrites part of a program with received data, the computer later executes that data as if it were program code. The data could be anything, including a program that crashes the machine or takes it over. This is why buffer overflows so often appear in news about network security.

For software written entirely in Java, the source says buffer overflow errors are impossible. Java provides no way to store data into memory that has not been properly allocated. Doing so would require a pointer to unallocated memory, or an array index outside the allocated range, and both are prevented as described in the earlier sections.

The safety features described in this article protect the code the programmer writes in Java. They do not make every line of code that runs inside the platform immune to every error. Knowing where that boundary lies is part of understanding what the language actually promises.