final on objects

[Matthias Kaeppler]

Hi,

is it normal that the compiler doesn't complain
when I execute a modifying method on a final object?
Does final only mean that the object simply isn't
being modified?

I'm coming from the C++ camp, and there you have
no chance to call non-const methods on const
objects without getting a compile time error.

Thanks,
Matthias

 

[Johan Poppe]

is it normal that the compiler doesn't complain
when I execute a modifying method on a final object?
Does final only mean that the object simply isn't
being modified?

What do you mean with a final object?

If a class is final, it cannot be subclassed.

If a variable is final, it cannot be changed. But if the variable is a
reference type, the object it refers to can still be changed. So if a
variable is declared and initialized with
final Bar myBar = new Bar();

then this is perfectly legal:
myBar.setSomething(42);

However, this is not legal:
myBar = new Bar();

If you want to object itself to be immutable, you must change the code
defining that class. (There was a long discussion here recently about
exactly what loop you have to jump trough to make a class immutable.
You may want to google that.)

 

[Alan Krueger]

Hi,

is it normal that the compiler doesn't complain when I execute a
modifying method on a final object?
Does final only mean that the object simply isn't being modified?

I'm coming from the C++ camp, and there you have no chance to call
non-const methods on const objects without getting a compile time error.

Java final != C++ const

 

[John Currier]

I'm coming from the C++ camp, and there you have

no chance to call non-const methods on const
objects without getting a compile time error.

Unless things have changed significantly in C++ in the past 7 years
(when I jumped ship to Java) you can cast away the "constness" of an
object and call away.

John

 

[Matthias Kaeppler]

Unless things have changed significantly in C++ in the past 7 years
(when I jumped ship to Java) you can cast away the "constness" of an
object and call away.

John

Ouch. Yes, you can do a lot of stupid things in C++

 

[Matthias Kaeppler]

then this is perfectly legal:
myBar.setSomething(42);

However, this is not legal:
myBar = new Bar();

If you want to object itself to be immutable, you must change the code
defining that class. (There was a long discussion here recently about
exactly what loop you have to jump trough to make a class immutable.
You may want to google that.)

That's what I meant, thanks.

 

[Owen Jacobson]

Unless things have changed significantly in C++ in the past 7 years (when
I jumped ship to Java) you can cast away the "constness" of an object and
call away.

John

Doing anything non-const with a formerly-const value after
const_cast<T>ing it away is either implementation defined or simply
undefined. The cast exists for interoperability with pre-standard code
that abuses const in some fashion.

Anyways, final isn't const. Final just means that a value won't change:
try to change the value of a final reference in Java and it'll complain,
but change the referenced object all you want.

 

[John Currier]

Doing anything non-const with a formerly-const value after

const_cast<T>ing it away is either implementation defined or simply
undefined. The cast exists for interoperability with pre-standard code
that abuses const in some fashion.

Can it be both "undefined" and "exists for interoperability" without
interoperability being undefined?

I remember having to cast away consts whenever I called what you refer
to as pre-standard code, but that code didn't abuse const...it just
didn't know anything about it because const didn't exist when the code
was written.

John