I would offer that the key distinction is whether final is used: This
prescribes what you must do when using the object.
Take Date for example. You can't just pass one directly from one thread to
another. The receiving thread could read a date associated with
System.currentTimeMillis() of 0.
But, String, since it uses final on its char[], fundamentally changes this.
(If the final keyword were not present in String, even though you have no
way to change its char[], it would be broken with respect to threading
semantics.)
On Wednesday, May 7, 2014 10:35:04 AM UTC-4, Andy Fingerhut wrote:
>
> Sorry if I'm beating a dead horse here.
>
> I agree that my example is not using published Clojure APIs, and I never
> do that kind of thing in a Clojure program, except as an example that
> PersistentVector's are mutable if you use Java APIs instead of restricting
> yourself to Clojure APIs. You don't even need to use reflection in Java or
> know about JVM security policies to mutate them (I am not suggesting that
> Clojure should be changed in any way here).
>
> I've actually got a copy of Java: Concurrency in Practice, and looked up
> (some of) what they say about immutability. Here is one definition they
> give of immutability, with some preceding text. I have added emphasis to
> one phrase:
>
> "Neither the Java Language Specification nor the Java Memory Model
> formally defines immutability, but __immutability is *not* equivalent to
> simply declaring all fields of an object 'final'__. An object whose fields
> are all final may still be mutable, since final fields can hold references
> to mutable objects.
>
> An object is *immutable* if:
> + Its state cannot be modified after construction;
> + All its fields are 'final'; and
> + It is *properly constructed* (the 'this' reference does not escape
> during construction)."
>
> I have no argument with PersistentVector satisfying the 2nd and 3rd bullet
> points above, but (1) seems not to hold. According to JCIP's definition of
> effectively immutable ("Objects that are not technically immutable, but
> whose state will not be modified after publication"), PersistentVector
> appears to me to be effectively immutable, but not truly immutable.
>
> Andy
>
>
> On Tue, May 6, 2014 at 8:31 PM, Alex Miller <al...@puredanger.com<javascript:>
> > wrote:
>
>> Hey Andy,
>>
>> It does matter with regard to visibility across threads - your example
>> does not use a synchronization mechanism and there is no guarantee that
>> other threads will ever see those changes (so don't ever ever do that :).
>> But if you stick to the normal Clojure apis, all is good. I'd highly
>> recommend reading JCIP to dive into the details.
>>
>> Final field freeze is particularly weird and it baked my noodle when I
>> first encountered it - here's a blog I wrote about it approx 697 years ago
>> in internet time (and Brian Goetz backs me up in the comments :)
>> http://tech.puredanger.com/2008/11/26/jmm-and-final-field-freeze/
>>
>> Alex
>>
>>
>> On Tuesday, May 6, 2014 7:35:43 PM UTC-5, Andy Fingerhut wrote:
>>
>>> Alex, I may be unfamiliar with the definitions of truly immutable and
>>> effectively immutable being used here, but if I can mutate the contents of
>>> a Java Object array that is a final field after an object is constructed,
>>> does it really matter that much if it is final? It is trivially easy to
>>> mutate using Java access. Here is the example that I mentioned earlier in
>>> this thread, copied here for convenience:
>>>
>>> user=> (def v [1 2 3])
>>> #'user/v
>>> user=> (class v)
>>> clojure.lang.PersistentVector
>>> user=> v
>>> [1 2 3]
>>> user=> (aset (.tail v) 1 -2)
>>> -2
>>> user=> v
>>> [1 -2 3]
>>>
>>> Andy
>>>
>>>
>>> On Tue, May 6, 2014 at 4:49 PM, Alex Miller <al...@puredanger.com>wrote:
>>>
>>>> The Clojure persistent data structures are truly immutable - all
>>>> fields are final and referred objects are not mutated after construction
>>>> so
>>>> that freeze occurs. One obvious exception are the transient variants (
>>>> http://clojure.org/transients). You can look at the code in
>>>> https://github.com/clojure/clojure/tree/master/src/jvm/clojure/lang -
>>>> any of the Persistent*.java.
>>>>
>>>>
>>>> On Tuesday, May 6, 2014 4:11:49 PM UTC-5, Mike Fikes wrote:
>>>>>
>>>>> Are the persistent immutable data structures in Clojure "truly"
>>>>> immutable (using final fields, relying on constructor freezing), or are
>>>>> they mean to be merely effectively immutable (as defined in JICP)?
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Clojure" group.
>>>> To post to this group, send email to clo...@googlegroups.com
>>>>
>>>> Note that posts from new members are moderated - please be patient with
>>>> your first post.
>>>> To unsubscribe from this group, send email to
>>>> clojure+u...@googlegroups.com
>>>>
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/clojure?hl=en
>>>> ---
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Clojure" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to clojure+u...@googlegroups.com.
>>>>
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com<javascript:>
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com <javascript:>
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+u...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
