[
https://issues.apache.org/jira/browse/TEXT-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026262#comment-16026262
]
Gilles commented on TEXT-84:
----------------------------
Indeed, neither immutability nor thread-safety can be claimed when using an
external source.
And you are right that in this case, it would not be reasonable to expect that
a RNG is immutable or thread-safe.
At one point, I had contemplated adding a "ThreadLocalRandom" implementation in
"Commons RNG", but did not do it eventually because it would have implied
making an arbitrary choice of the RNG algorithm.
Now, if we assume that the "thread local" instance is used in multi-threaded
settings, can we conclude that the performance variation among the generator
will be dwarfed by the context switches and/or other computations? If so, we
could use the period as the selection criterion.
WDYT?
> RandomStringGenerator claims to be immutable, but isn't
> -------------------------------------------------------
>
> Key: TEXT-84
> URL: https://issues.apache.org/jira/browse/TEXT-84
> Project: Commons Text
> Issue Type: Bug
> Affects Versions: 1.1
> Reporter: Duncan Jones
>
> {{RandomStringGenerator}} claims to be immutable in the Javadocs, however it
> accepts a {{TextRandomProvider}} object through the builder pattern. This
> object may altered by external code, thus breaking the immutability claim of
> our generator.
> A possible solution is to adjust the documentation for {{TextRandomProvider}}
> and require implementations to be immutable. Alternatively, we can relax the
> documentation in {{RandomStringGenerator}} to remove the immutability claim
> or state that the mutability is linked to the mutability of the random source
> (when provided).
> I think we will have to do the latter, since the former would forbid callers
> from supplying a {{UniformRandomProvider}} instance as suggested in the
> documentation. Thoughts welcome.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
