commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TEXT-84) RandomStringGenerator claims to be immutable, but isn't
Date Fri, 26 May 2017 13:07:04 GMT

    [ 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)

Mime
View raw message