Const declaration discussion

Question

(Since there is no "possible/future features" forum, I'm posting here, since a lot of the postings here deal with such matters.)
Like some other Java users I'm a fan of the const declaration concept - const methods (not modifying the instance) and parameters (the object the parameter references will not be modified by the method). In part because it adds valuable error checking ability at compile time, and in part because it makes method declarations a lot clearer in many cases.
(I'm not advocating a run-time conversion between const/non-const like in C/C++. Like e.g. final, this characteristic should be fixed after compilation.)
I know there is an RFE on this - which was closed some years back, without much evaluation (not posted there, anyway). I've also been able to find some shallow discussions in the forums, and some have hinted that it can be a complex feature in some scenario, perhaps implying that it would not be without caveats.
Perhaps some readers here know more about this issue and why the const keyword (which is reserved in the Java spec) has been decided to be unused?

Answer 1

I don't have a deep knowledge of this, but AFAIK it's not practical (or possible) for the compiler to enforce this.
Consider this method:
static void printAndPeel(const Apple a, Fruit f) {
System.out.println(a + "is an apple");
System.out.println(f + "is an unpeeled fruit");
f.peel();
System.out.println(f + "is a peeled fruit");
The 'const' Apple referred to by a is unchanged by the method 99% of the time. But when a==f , a strange bug occurs (from the point of view of anyone expecting a to remain unpeeled). The same would happen if this were a non-static const method of Apple, where 'this' takes the place of the parameter 'const Apple a'.
Presumably the source of the problem is that you want objects to be const (within the scope of a method, say), but using syntax which declares references to objects as const. But there can be all kinds of references to an object, including ones in different threads.
You could ensure an object was const by:
(a) making it immutable always,
(b) making it mutable but (say within the scope a method), ensuring that absolutely all references to the object are const (the Collections.unmodifiableCollection() wrapper attempts to do this),
(c) having some kind of lock in the object itself which is enabled during the scope of a method, and throws an exception if someone tries to modify the object.
Re these:
(a) is the way to go, I think. I'd like to see an 'immutable' keyword you could apply to a class, which ensured all its fields were final and immutable (primitives would count as immutable). This would both be useful as a compile-time check for developers, and as a hint for the JVM to do various optimisations.
(b) I don't see how this could work at compile time. If an object is mutable, you want it to be temporarily immutable sometimes (within the scope of a method, say). The compiler would have to prove that all non-const references accessible in that method could not point to the const object - even references of type Object! This places very stringent restrictions on what you can do in a method. Additionally, you have to ensure other threads can't change the object - very hard to enforce.
(c) sounds possible but not ideal, because it's a runtime check. The above printAndPeel() method would compile OK and fail occasionally when run. But maybe this solution could be implemented in the VM in a fairly efficient manner by reusing the synchronisation locks somehow?