On 03/13/2011 11:10 PM, Graham Allan wrote:
Yes, this is... hard. String has what's known as a 'benign data race': when hashCode() is executed by different threads, there is a possibility that the hashCode field is computed and set twice, but since the result depends on only other immutable state, it doesn't matter, since they will always get the same result. While I don't think it's been proved that detecting this is impossible with static analysis, I've pretty much given up on trying to recognise such a pattern from the bytecode alone.
Of course, caches are a problem, but I don't fully understand the terms. I mean: in the end, what matters is the externally visible state, not the internal one. What's the problem of portions of the state being computed lazily, if the computing is thread-safe? I mean: what's the impact on design, I realize it's a headache for people writing tools to check immutability. I think they are two different concerns, even though related.
P.S. while I've made reference to a tool I released which is relevant to this discussion, I wasn't sure if it was bad form to promote it here. So I'll wait to see if anyone's interested to hear about it, in which case I'll happily link to it.
I'm raising my hand :-) -- Fabrizio Giudici - Java Architect, Project Manager Tidalwave s.a.s. - "We make Java work. Everywhere." java.net/blog/fabriziogiudici - www.tidalwave.it/people [email protected] -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
