[
https://issues.apache.org/jira/browse/LANG-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578187#comment-15578187
]
Gilles commented on LANG-1254:
------------------------------
bq. We could try to further optimise that code, covering all possible scenarios
of poor performance...
This is unlikely.
This issue is somewhat related to LANG-1196; they are examples of possibly
opposite requirements: let user manage the RNG vs have the library code ensure
thread-safety.
bq. but IMO it's easier to let the user choose which performance optimisations
would be necessary.
Agreed.
bq. Writing simple, threadsafe code, I believe we are also giving more
flexibility to users in choosing how to design their code for different
environments, and use different optimisation techniques.
I may miss something, but I think that "simple" and "threadsafe" are at odds.
IMO, "simple" implies _not_ thread-safe.
See e.g. Commons Math's (development version)
[RandomUtils|http://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math4/random/RandomUtils.html]
for an alternative design that is flexible: the user can choose which
implementation to pass and how many independent data generators are needed.
> ThreadLocalRandom should be used in utility classes
> ---------------------------------------------------
>
> Key: LANG-1254
> URL: https://issues.apache.org/jira/browse/LANG-1254
> Project: Commons Lang
> Issue Type: Improvement
> Reporter: John Mark
> Priority: Minor
>
> I noticed that both {{RandomUtils}} and {{RandomStringUtils}} use a constant
> for the {{Random}} instance. The javadoc for
> [Random|http://docs.oracle.com/javase/8/docs/api/java/util/Random.html]
> indicates that
> [ThreadLocalRandom|http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ThreadLocalRandom.html]
> should be used for performance in multithreaded designs. I would think that
> a public utility class would qualify as a multithreaded design and should
> therefore use {{ThreadLocalRandom}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
