[
https://issues.apache.org/jira/browse/LANG-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12777947#action_12777947
]
Boris commented on LANG-481:
----------------------------
Henri,
The current hashCode() is fine of course :) And as optimum long as speed is no
concern it's also the best. Just my 2ct on this topic:
Caching or pre-calculating the value will be a trade-off on how you want to use
the class. If you pre-calculate the value and never use hashCode() the "effort"
was pointless. If you cache it, it will MAY be re-calculated on every call (but
this is rather unlikely).
I think the cached-approach is the best (if it's done right of course :)), but
the constructor-approach is easier to get right.
But as one can use String.hashCode() as a boilerplate it should be easy to
implement optimistic caching right.
> Possible race-conditions in hashCode of the range classes
> ---------------------------------------------------------
>
> Key: LANG-481
> URL: https://issues.apache.org/jira/browse/LANG-481
> Project: Commons Lang
> Issue Type: Bug
> Affects Versions: 2.4
> Reporter: Boris
> Priority: Minor
> Fix For: 3.0
>
> Attachments: LANG-481-reordering_datarace.patch, LANG-481.patch
>
>
> The hashCode() methods of the range classes look very suspicious to me. The
> value is lazily initialized, but the calculation is done _on the cached
> value. With some unlucky timing a caller may get an incomplete hash.
> An unlucky sequence of Code could be something like
> T1: if (hashCode == 0) // true
> T1: hashCode = 17;
> T2: if (hashCode == 0) // now false because hashCode was already set
> to 17
> T2: return hashCode; // return 17
> T1: hashCode = 37 * hashCode...........
> where T1 and T2 are different threads accessing the method in parallel and T2
> gets the wrong hash "17".
> Affected classes are
> org.apache.commons.lang.math.DoubleRange
> org.apache.commons.lang.math.FloatRange
> org.apache.commons.lang.math.IntRange
> org.apache.commons.lang.math.LongRange
> org.apache.commons.lang.math.NumberRange
> org.apache.commons.lang.math.Range
> Possible fix: calculate the hash on a temporary variable and finally assign
> it to the member
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
