Re: Usefulness of "final" (Was: Re: Inserting In a List)
On 4/3/2013 8:34 PM, markspace wrote:
On 4/3/2013 5:27 PM, Arne Vajh?j wrote:
On 4/3/2013 8:21 PM, markspace wrote:
On 4/3/2013 5:08 PM, Arne Vajh?j wrote:
Yes. But you you seemed to imply that I meant it based
on the JLS thing.
No, I was replying to Joerg.
Hmm.
You replied to a post by me and only quoted me.
The first post I made was to Joerg:
On 4/3/2013 12:01 PM, Joerg Meier wrote:
> "final" makes a variable or field impossible to reassign. It says
> absolutely nothing at all about whether or not that variables is
> modifiable. What you are thinking of is immutability, something that
is not
> formalized in Java.
Then you replied to me, saying that the section of the JLS I linked to
"17.5 Final Field Semantics" doesn't define immutability in Java
formally or informally. Which is wrong, if you just scan that section
for uses of the word "immutable." So that's where I kind of lost it.
I'm with Arne. The cited section uses the word "immutable"
and "immutability" without defining either. All it says is that
"final" can be an aid to implementing immutable objects -- but it
never says what "immutable" is. It doesn't even say that "final"
confers immutability; on the contrary, it says "final fields must
be *used correctly* [emphasis mine] to provide a guarantee of
immutability."
Toward the end of the section, we're told that String is
"perceived as truly immutable." So now there are two more notions:
"truly immutable" as opposed to merely "immutable," and "perceived
as truly immutable" as opposed to "actually truly immutable, not
dependent on somebody's perception." Where does the JLS define how
these three different kinds of immutability differ? Where does it
*define* even one of them?
Thought experiment: Using the JLS' definition of immutability,
support or refute "java.lang.String is mutable, because it computes
its hashCode() lazily and caches it in a non-final field, thereby
changing the String object's state at the first hashCode() call."
Thought experiment: Using the JLS' definition of immutability,
support or refute "All Java objects are mutable, because all have a
monitor whose state changes every time a synchronized block is
entered or exited. The monitor's state affects the behavior of
all threads attempting to synchronize on the object, so the change
of state is not strictly internal but is visible to all observers."
--
Eric Sosman
esosman@comcast-dot-net.invalid