[
https://issues.apache.org/jira/browse/LANG-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502481
]
Michael Sclafani commented on LANG-334:
---------------------------------------
Sadly, it was much easier for us to use a common subclass that provided
synchronization between the constructor and all the static accessors than it
was get set up to build our own version of the package, then distribute and
install it. So a different form a serialization did fix it.
I understand your discomfort in dealing with race conditions since I've had to
deal with solving them myself many, many times, but I don't know of any
practical solution other than reasoning about the temporal logic of the code.
> Enum is not thread-safe
> -----------------------
>
> Key: LANG-334
> URL: https://issues.apache.org/jira/browse/LANG-334
> Project: Commons Lang
> Issue Type: Bug
> Reporter: Michael Sclafani
> Fix For: 2.3.1
>
> Attachments: EnumPlay.java
>
>
> Enum uses no synchronization. Even if you assume that instances are only
> declared statically, the cEnumClasses map is global and can be written to
> when a thread triggers static initialization of B.class while some other
> thread is doing getEnumList(A.class). Unsynchronized access of a map
> undergoing mutation is not thread-safe.
> This isn't theoretical. We're seeing ValuedEnum.getEnum(X.class, 0) return
> null after returning the correct value over 100,000 times, and then return
> the correct value again on the next invocation.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
