X-Received: by 10.224.72.199 with SMTP id n7mr4456029qaj.5.1365126557216; Thu, 04 Apr 2013 18:49:17 -0700 (PDT)
X-Received: by 10.50.135.10 with SMTP id po10mr94742igb.4.1365126557173; Thu, 04 Apr 2013 18:49:17 -0700 (PDT)
Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!t2no39419210qal.0!news-out.google.com!ef9ni1849qab.0!nntp.google.com!ca1no29867827qab.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.java.programmer
Date: Thu, 4 Apr 2013 18:49:16 -0700 (PDT)
In-Reply-To: <kjl8qp$ll1$1@dont-email.me>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=69.28.149.29; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T
NNTP-Posting-Host: 69.28.149.29
References: <d4ecae37-89d4-4747-a8ae-aea86fbbecf2@googlegroups.com> <19un43xj77bua.vw45l4e2wshi.dlg@40tude.net> <ntKdnSTV5a3le8fMnZ2dnUVZ8kmdnZ2d@bt.com> <as0ohhFb3opU1@mid.individual.net> <XuCdnUHfKZPInMHMnZ2dnUVZ7oudnZ2d@bt.com> <as360lFri5bU1@mid.individual.net> <qM6dnfaBydqB58HMnZ2dnUVZ8mmdnZ2d@bt.com> <m5js4x39je49.wr0biu59drh4.dlg@40tude.net> <kji61t$7u6$1@dont-email.me> <1m6qixygl0s9c$.1fv60gxfuhuyz.dlg@40tude.net> <kjicp7$jeu$1@dont-email.me> <117qwc9w50mtb.1aizwvzf7bigo.dlg@40tude.net> <kjieou$uii$1@dont-email.me> <1rb5a1rqvwu96.4bxnq45wdqe8.dlg@40tude.net> <kjigpn$9bd$1@dont-email.me> <1w5kdehhtnncm$.1rh63hnqiof0q$.dlg@40tude.net> <kjkdfi$qib$1@dont-email.me> <1g6egitgbvtbz.4k1lknlpi9th$.dlg@40tude.net> <b029593b-574a-4cb6-9246-73292154e995@googlegroups.com> <kjl8qp$ll1$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <c2f41101-1f4e-41c8-99fb-a58b02b2341f@googlegroups.com>
Subject: Re: Usefulness of "final" (Was: Re: Inserting In a List)
From: Lew <lewbloch@gmail.com>
Injection-Date: Fri, 05 Apr 2013 01:49:17 +0000
Content-Type: text/plain; charset=ISO-8859-1
Xref: csiph.com comp.lang.java.programmer:23334

markspace wrote:
> There's also several mentions in 17.5.1 final Field Semantics:
> 
> "Let o be an object, and c be a constructor for o in which a final field 
> f is written. A freeze action on final field f of o takes place when c 
> exits, either normally or abruptly."  And a few other mentions following 
> that.
> 
> The "freeze action" is later in that section explained to work like a 
> happens-before relation.
> 
> "Given a write w, a freeze f, an action a (that is not a read of a final 
> field), a read r1 of the final field frozen by f, and a read r2 such 
> that hb(w, f), hb(f, a), mc(a, r1), and dereferences(r1, r2), then when 
> determining which values can be seen by r2, we consider hb(w, r2). (This 
> happens-before ordering does not transitively close with other 
> happens-before orderings.) "
> 
> It's a wee bit complicated to suss out, but I do believe it is saying 
> that final fields are special in that they create happens-before 
> relationships that don't exist for fields that are non-final.  That goes 
> for private fields, public fields, etc.  Only final fields get this 
> freeze action with the happens-before relationship.

For the purposes of this thread, this is pretty much the capper on the 
usefulness of 'final' for thread safety.

It confirms that 'final' is not just window dressing, and that its semantics 
are tightly tied to creating thread-safe code.

It also confirms that the JLS is incredibly important to correct Java programming.

Thanks for citing that.
-- 
Lew