Re: Usefulness of "final" (Was: Re: Inserting In a List)
On Wed, 03 Apr 2013 16:10:46 -0700, markspace wrote:
On 4/3/2013 3:46 PM, Joerg Meier wrote:
But of course, again, you cannot make an mutable OBJECT immutable simply by
creating a reference to it that is decorated with final.
Yup, you can. This class is also immutable:
public class Stooges {
private final ArrayList<String> stooges = new ArrayList<>(3);
{ stooges.add("Larry"); stooges.add("Curly"); stooges.add("Moe");}
public String getStooge( int stooge ) {
if( stooge < 1 || stooge > 3 ) throw new IllegalArgumentException();
return stooges.get( stooge-1 );
}
}
But it's immutable because you don't expose mutable functionality, not
because of the final keyword. Let me make a small alteration that will make
your class mutable, without removing the final keyword:
public class Stooges {
private final ArrayList<String> stooges = new ArrayList<>(3);
{ stooges.add("Larry"); stooges.add("Curly"); stooges.add("Moe");}
public String getStooge( int stooge ) {
if( stooge < 1 || stooge > 3 ) throw new IllegalArgumentException();
return stooges.get( stooge-1 );
}
public ArrayList<String> getStooges() {
return stooges;
}
}
There, and suddenly it's mutable.
Now as long as I haven't made some syntax or other simple error, all
instances of Stooges are immutable under the section of the JLS I
quoted. More over, each one is thread safe in all circumstances and
does not need synchronization to make it thread safe.
Yours would be immutable with or without the final keyword. It's kind of a
bad example, because ArrayList itself is mutable. Should have wrapped it in
Collections.unmodifiableList at least, but of course then it could still
have mutable contents (although of course not in the example, as String is
both immutable and final).
You may know this yourself, but the way you wrote the bit I quoted made
is sound like final fields have no special semantics associated with
them with respect to immutable objects (like the stooges ArrayList I
used above), when in fact they do. Although not in the fashion you
implied with p above, of course.
final can be used to create a class that is immutable, but so can other
Java mechanics (such as private fields with no setter). While final
certainly lends itself to design of immutable classes, there really aren't
any special semantics associated with it any more than with the private
keyword.
Again, I'm pretty certain that you already know all of the above and we are
just having a communication breakdown.
I think so.
Yeah, I figured halfway into my post that perceived misconception on your
part was too severe for it to actually be one. Nevertheless it seems a
worthwhile topic to discuss and maybe it will help someone else reading it
understand things better.
Liebe Gruesse,
Joerg
--
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.