34

Possible Duplicate:
Why is there no Constant keyword in Java?

Why const keyword is not used in Java?
Can you see any disadvantages of using some transitive const or immutable keyword in Java syntax or why common cumbersome approach was chosen?

Can you see reasons for closing the request, does Sun provides any explanations?

Community
  • 1
  • 1
Mike
  • 20,010
  • 25
  • 97
  • 140
  • 4
    What do you want `const` to do? Obviously something else than `final` (otherwise it would be redundant). But surely not making the referenced object automagically immutable? – Thilo Sep 15 '11 at 09:05
  • 2
    same thread at http://stackoverflow.com/questions/2735736/why-is-there-no-constant-keyword-in-java – Umesh Awasthi Sep 15 '11 at 09:06
  • Check this out. http://stackoverflow.com/questions/2735736/why-is-there-no-constant-keyword-in-java/2735906#2735906 – Santosh Sep 15 '11 at 09:08
  • That it! Making the referenced object automagically immutable! As D programming language is already implemented. It is clear for me why goto is 'deprecated' (reserved and not used) but why const is not part of Java specification till now?.. Are there any reasons for this? – Mike Sep 15 '11 at 09:10
  • The enhancement request ticket in the Java Community Process for implementing const correctness in Java was closed in 2005, implying that const correctness will probably never find its way into the official Java specification. Can you see reasons for this? – Mike Sep 15 '11 at 09:12
  • 1
    Wikipedia says the JCP found it "impossible to implement" (in a backwards-compatible way) – Thilo Sep 15 '11 at 09:15
  • @MyKhaylo, look at GaryF's answer in the link. http://stackoverflow.com/questions/2735736/why-is-there-no-constant-keyword-in-java/2735788#2735788. – Santosh Sep 15 '11 at 09:16
  • If you want immutable objects, that is, ensuring when passed to a function is not modified, you can use several tricks as pointed: `String` is already immutable, use immutable lists like passing a copy with `Collections.unmodifiableList(List)` or use `Enumeration` or `Iterator`; use defensive copy before passing (not in the method itself as you don't know outside) objects to a method... – David Oliván Sep 15 '11 at 09:37
  • @David: That is of course the common, cumbersome (and still error-prone) approach that he wants to avoid by means of a magic keyword. But I guess there is no easy way out (without completely changing how Java works). – Thilo Sep 15 '11 at 09:46
  • Part of the reason `goto` is deprecated is because you have `break` and `continue` which can do much the same thing. You can even have `break` without a loop. – Peter Lawrey Sep 15 '11 at 11:10

3 Answers3

30

Can you see reasons for closing the request, does Sun provides any explanations?

Yes. Sun provided 3 reasons for why they won't act on the request in the request itself. I quote:

"There are no current plans to add this feature to Java. In addition to creeping featurism, we see the following problems with this feature:

  1. Adding const is too late now. Had this been added from 1.0, the situation could have been different.

  2. Const pollution: the C++ approach requires all const methods to be marked with a const keyword. This means that most methods will have to be marked const explicitly. This tend to clutter all methods in C++.

  3. Compatibility is a very important feature of the JDK. Arguably, the collection classes should be modified to indicate that the elements are const. That would require all existing implementations to be updated in the same way, effectively breaking all existing non-JDK implementations of the collection interfaces. Similarly, hashCode would have to be const, breaking the current implementation of String."

UPDATE

Out of curiousity, I spent a few minutes trawling through the subject lines of the Project COIN mailing list. Somewhat to my surprise, nobody bothered to suggest const. (Or if they did, I missed it.)

So either nobody cares (enough) for this idea any more, or people with sufficient expertise to formulate a project COIN proposal recognize that there's no chance that it would pass muster.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • +1. I guess the third reason is the biggest one. I don't completely understand the second one and if it is relevant, but the first one is (without further explanation) a bit of hand-waving (why is it too late for features if they in and of themselves have no problems, and why does that not apply to generics and closures, who also bring rather big changes). – Thilo Sep 15 '11 at 09:55
  • @Thilo - I agree that the reasons 1 and 2 are not great. But they ARE reasons provided by Sun. Which is what the OP asked for. – Stephen C Sep 15 '11 at 10:02
  • can't grasp this idea (really tried to). Can't see any broken backward compatibility or pollution of code in providing ADDITIONAL OPTIONAL way of forcing compiler (and help developer) to check that some variable marked immutable not to be used as 'left hand' value. – Mike Sep 15 '11 at 11:19
  • 3
    @Mykhaylo Adamovych - I just quoted what Sun said. I don't pretend to understand all of the issues involved, but I'm SURE it is not as simple as you think ... – Stephen C Sep 16 '11 at 05:19
9

It is not used because it has no function in Java. I quote from Wikipedia:

Although reserved as a keyword in Java, const is not used and has no function.

Therefore you should use final instead.

Here is another, maybe more reliable source.

8

Actually, the Wikipedia article you linked has your answer:

An enhancement request ticket for implementing const correctness exists in the Java Community Process, but was closed in 2005 on the basis that it was impossible to implement in a backwards-compatible fashion.

Thilo
  • 257,207
  • 101
  • 511
  • 656