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 

bq. but IMO it's easier to let the user choose which performance optimisations 
would be necessary.


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

Reply via email to