Toward const-ness in Java

In many of these discussions, arguments against use of const in Java have centered on perceived weaknesses of const in C++.

Let’s try to imagine how we could make the const keyword useful in Java. Here’s my proposal.

I've had second thoughts. Not to say that the idea won't work, just that it needs more thought than it's given here.
I was thinking only in terms of compiling, but the only way Java has for knowing a method's signature when a class is loaded, is from information stored in the class file. For code that uses constness from another class, it will need the constness info at class load time, not just at compile time.

I think that, by looking at the strengths and weaknesses of constness in C++, we can come up with a better implementation for Java.

The main points:

  1. To methods outside a const object, the object appears to be read-only.
  2. What constness means internally for a class is up to the designer.
  3. It should be impossible to override constness

What read-only means for a given class is up to the designer of the class. Typically, it means precisely that the data of an instance cannot be modified. However sometimes it’s desirable for an object to maintain an internal cache or counter, etc, that is updated even when a const method is called.

So let’s say that within the code of methods of a const class, any member data not marked const (or for primitive types, final) is modifiable.

That is, it is up to the class to protect its own data.

Note that this is different from C++, where, to modify member data from within a const method, you have to cast away the constness.

One objection to constness in C++ is that it isn’t hard to cast away constness. Let’s just say that constness can’t be cast away in Java.

Another is the confusion between logical constness and physical constness (Dave Harris, comp.lang.java 1995/11/25)

“An object is logically constant if its abstract state does not change. It’s physically constant if the bit-pattern which implements its state does not change.”

(I should also mention: some people are heard using the term “security” in discussions of constness. If you are one of these people, please get out a book on C++, read about what constness is about, and try some examples, before proceeding with the present article. FYI, constness has nothing to do with security.)

Constness is about clarity of responsibility for updating data. It is a contract, by which code assures its user that it won't alter certain data (and conversely, that it might alter other data).

In C++, it is possible for the code to be lying. That would be very bad. But the point is not (the unattainable ideals of) absolute security or certainty. The point is to have a contract, that is easy for all parties to understand.

Thus the constness of C++ is a logical constness. It is common practice for a class to cast away constness internally for bookkeeping purposes. The present proposal also will be about a sense of logical constness, but at a different level than that of C++.

Let’s say that constness is purely syntactic in Java, that it has no meaning at run time. One advantage of this is that it only affects the compiler, not virtual machines. Code compiled by a compiler that recognizes the const modifier could run in an old virtual machine, although the compiler packaged with that old virtual machine does not implement const.

See also: A Comprehensive Theory of Adding 'const' to Java, by David R. Tribble

const keyword

from outside a const object

from inside an object,

constness cannot be cast away