R
Robert Klemme
OK then, so what definition would this group like to use to describe the
kinds of objects the JLS talks about in Section 17.5?
I'd go with the heading of that section: "final Field Semantics" - and
it's not primarily about "objects" but about "final fields" or put
differently: final object references. That section defines semantics of
final fields and just mentions "immutable objects" as an example of a
concept that may be created by (properly) using final fields.
Immutability (or constness) of an object is a tricky concept. There are
at least two useful and totally reasonable definitions:
1. State (as in: bit patterns in memory) of a const object never changes.
2. The user of a const object can never observe any state changes; put
differently: all methods of a constant object always return the same
results for the same inputs.
You can also see that from the development C++ took: keyword "mutable"
was introduced later to allow state changes of instances declared
"const"; this helps implementing lazy initialization and caching schemes.
Other than for type 1 constness compiler checks for type 2 constness are
significantly more complicated - if they are possible at all: call a
function in a method and all bets are off. Without access to the
function's source (or at least bytecode in Java) a compiler cannot
determine whether type 2 constness is observed in all circumstances.
Kind regards
robert