Submitted On 01-JUL-1998
The first part of the above evaluation is incorrect. Here is a more concrete
example showing this problem.
public class Test
// we only want Test to be able to change this
private String m_data;
m_data = "Some data we don't want changed";
// what we want here is const String getData()
public static void main( String args )
Test aTest = new Test();
String local = aTest.getData();
local.concat( " add some junk Test does not want" );
The work arounds for this are
1. declare getData like this
return new String( m_data );
which means all types you want to return have to support a copy constructor
or clone() in addition to the fact you are allocation needless memory.
2. make a wrapper class which passes through all the read methods to the object
you want to return but does not have any set methods, but this would mean that
you have to make one of these for EVERY type of data; plus you still have the
extra memory usage going on.
Neither of these is clean, and the lack of this ability makes encapulation
impossible. Without encapulation OO worth much less.
Submitted On 10-JUL-1998
It seem to me the evaluator is more
confused than the submiter in this
feature request. Or maybe he didn't
have the time to read it carefully.
It was obvious, just looking at the
code of the second example, that 'field'
is a reference to an object 'MyType' and
not a primitive type like 'float' or 'int'.
I think the submiter is right (However,
maybe I should point that the example
below is maybe not the best one: "String"
is imutable, so it is safe to return it
with 'getData' without making a copy of
it. The code "local.concat" will have no
effect on "local".)
I really don't agree with the evaluator when
he said that "final" method parameters are
the most frequent use for "const". "final"
is NOT "const", except if the parameter is
a primitive data type. I sure the staff at
Sun are very competent guys, and I belive
they have some good raison to not implement
something like the "const" keyword (again
this is NOT final or blanck final fields).
However, I think it would be nice to have
an other evaluation than this one. I support
the submiter on this feature request.
Submitted On 15-JUL-1998
Another workaround is to have your class implement
a "Const" interface. This is implicitly what the
C++ const keyword is does.
I tried it but I don't use it anymore.
Drawbacks: you can really only add it to your
own classes; other classes could implement your
interface; it can be a pain.
"Const" is dead! Long live "const"!
class Thing implements Thing.Const
int get() ;
public int get()
return 0 ;
public void set()
public static void main(String args)
Thing thing = new Thing() ;
Thing.Const thing2 = new Thing() ;
thing2.set() ; // Compiler error: Method set() not
found in nested interface Thing. Const.
Thing.Const thing4 = thing ; // Nice automatic cast
thing3.set() ; // Compiler error: Method set() not
found in nested interface Thing. Const.
Thing thing4 = (Thing)thing2 ; // Casting away const
Submitted On 17-JUL-1998
One of the *biggest* uses is to indicate that a
method does not modify an object's variables.
Using const in this way in C++ has saved me tuns
of time when debugging. I hope this gets added
in some future version of Java... however, it
would also require const object references.
Submitted On 11-MAY-1999
Both solutions presented above are not really convenient
for me :
1 - Copy of the return object : memory and space
efficiencies are seriously hit.
2 - Const interface : works but it means that i have to
double all my classes. Moreover is the standard Java lib
const-correct ? Moreover, why is there a const reserved
keyword in JAVA ?
Submitted On 11-NOV-1999
Another workaround used in the collections classes is to create a (private)
subclass of a class
that you want to restrict changes to that throws exceptions if you call
List myReadOnlyList = Collections.unmodifiableList( myList );
myReadOnlyList provides a filter that throws an UnsupportedOperationException
if you call a
modifier method, and passes 'const' methods on to myList.
An advantage of this method is that it does not allow the dangerous 'casting
away const', so
you don't have to assume that all your clients are well-behaved.
The obvious disadvantage is that the error occurs at runtime, not compile time.
Submitted On 15-JUN-2000
It's not smart.
And it makes difficult to understand DOMAIN-Model.
"const" is strong and availavle keyword.
We need "const"!
Submitted On 20-SEP-2002
I love coding in Java. But I always feel that "const"
functionality should be added to Java similar to how C++ has
it. Since we currently support most of the "const-ness"
functionality in "final", I'd love to see the full functionality for
the next release of the JDK. I've tried all sorts of workarounds
for this (interfaces, cloning ...) But these workarounds are
inefficient (memory usage and performance wise) and counter-
I believe that a solution to adding this functionality is not too
complicated and Sun engineers have accomplished much more
complicated tasks than this. I just hope that this issue is not
pushed under the rug.
PLEASE NOTE: JDK6 is formerly known as Project Mustang