4

In C++, one can use the const keyword to indicate whether the pointer to the data or the data itself is constant (or both), i.e.

const SomeClass* p; // Data is constant

or

SomeClass* const p; // Pointer is constant

or

const SomeClass* const p; // Both are constant

In Java, the final keyword is much more limited:

final SomeClass o; // Reference is constant, the object can be changed

I have always wondered why Java is more limited than C++ in this respect. Was this a decision taken by the language designers (that could possibly have just as well been decided otherwise), or is there a technical reason that prevents it?

Does the fact that Java objects are managed by a garbage collector have an impact here?

Dabbler
  • 9,733
  • 5
  • 41
  • 64
  • 1
    I've never flagged anything for migration to https://cs.stackexchange.com, but I wonder if this question would fit there better. – Maarten Bodewes Feb 06 '20 at 21:50
  • @Kayaman: I changed the wording – Dabbler Feb 06 '20 at 21:54
  • related/maybe dupe: https://stackoverflow.com/questions/2735736/why-is-there-no-constant-feature-in-java – NathanOliver Feb 06 '20 at 21:56
  • I don't think that this question can be answered in a meaningful way. Since C++ has it, there cannot be a pure *technical* reason that prevents using this feature in another language. Obviously, it's possible but the resulting language would be a different one and other features might be impacted. But that is true for every design decision, so how different is the language allowed to look that the decision would still count as a *design* and not a *technical* decision? – flyx Feb 06 '20 at 22:45
  • `const` is really impacting feature. which impact overload resolution (and so, in C++, the double getter, `iterator` and `const_iterator`). The trade of complexity/safety might explain why some language have it and others don't or partially. – Jarod42 Feb 06 '20 at 23:30

1 Answers1

6

The first reason is that Java final doesn't serve the same purpose as C++ const. It's fine for the purpose it does serve, which is to be a semantic restriction on a hierarchy of object-oriented classes, to promote proper design of such a hierarchy. Which doesn't have anything to do with not being able to change the value/state of a class.

The second reason is that there was nothing to prevent Java from having a "const" feature of some kind. But it was initially designed for a very limited use case (limited compared to its current varied use cases) which was for embedded computing on tiny devices with limited resources in a simple way. And with that use case in mind one of the main initial goals was simplicity of programming code, simplicity of programming a virtual machine, simplicity of programming a compiler, and so on. and "const"-ishness was a complexity they didn't need at that time.

Since then Java has evolved - a lot - but with heavy constraints related to backward compatibility and ease of teaching the language - and so the evolution of the language (and the VM it runs on, and its framework) has proceeded pretty deliberately. (And, thus, slowly.)

And there is a feeling (justifiable) that a lot of what you get with declaring "const"-ishness you can get with other object-oriented features that are in the language, for example, having getters for fields but not setters.

So there's no reason for there not being "const"-ishness in the language/VM/framework yet except that it hasn't been considered as important as other things to work out, and there are workarounds within the language.

But people have added "const"-ishness to Java - just external to the language standard. Look up various libraries and tools for creating "immutable objects" to see what can be done.

(And to answer your last question: It has nothing to do with GC.)

davidbak
  • 5,775
  • 3
  • 34
  • 50