[ 
https://issues.apache.org/jira/browse/TEXT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15802286#comment-15802286
 ] 

Raymond DeCampo commented on TEXT-36:
-------------------------------------

My 2 cents (not that anyone should care) - if I were including commons-text in 
a project and wasn't interested in the class generating random strings (will 
most of the commons-text users be in this scenario?) I would prefer there not 
be a dependency on a random number generator library which seems like a strange 
thing for a text library to depend on.

That said, if it were up to me, I would go with the TextRandomProvider 
interface scheme EXCEPT that it should be eligible to be a functional 
interface.  Also it should have the same signature as the nextInt() method in 
java.util.Random and UniformRandomProvider.  This will make implementation easy 
for Java 8 users.  I am thinking something like:

{code}
    public interface TextRandomProvider {
        public int nextInt(int max);
    }
    
    // Then Java 8 users can do something like:
    java.util.Random jur = new java.util.Random(1234L);
    RandomStringGenerator gen = new RandomStringGenerator.Builder()
        .usingRandom(jur::nextInt)
        .build();
    // or if they want commons-rng:
    UniformRandomProvider rng = RandomSource.create(RandomSource.MT);
    RandomStringGenerator gen = new RandomStringGenerator.Builder()
        .usingRandom(rng::nextInt)
        .build();
{code}

Then in the javadoc for the class put examples using commons-rng and that's 
what 99% of the people will use anyway.  Plus there's no dependency on 
commons-rng unless you are actually using the functionality.

People still on Java 7 will have to implement the interface but the number of 
users on 7 will be diminishing so I'm not too concerned about inconveniencing 
them.

    

> Dependency on "Commons RNG"
> ---------------------------
>
>                 Key: TEXT-36
>                 URL: https://issues.apache.org/jira/browse/TEXT-36
>             Project: Commons Text
>          Issue Type: Improvement
>            Reporter: Gilles
>              Labels: api
>             Fix For: 1.1
>
>
> This is a follow-up of a 
> [discussion|https://issues.apache.org/jira/browse/TEXT-34?focusedCommentId=15762623&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15762623]
>  held in TEXT-34.
> IMHO, there is no harm in depending on the ["commons-rng-client-api" 
> module|http://commons.apache.org/proper/commons-rng/commons-rng-client-api/javadocs/api-1.0/index.html]
>  of Commons RNG; the "zero dependency" mantra does not hold here, since TEXT 
> already depends on LANG.
> OTOH, I see that it is counter-productive (i.e. it harms the Commons project 
> as a whole) to not advertize or use other Commons components, despite the 
> "own dog food" phrase appearing recurrently on the "dev" ML.
> Rather than having people blindly use {{java.util.Random}}, we should allow 
> them to choose wisely, based on full information.
> IMO, that means to indeed use {{UniformRandomProvider}} in order to raise 
> awareness about alternatives to the sub-optimal algorithm used by the JDK.
> However, if some Commons developers do not trust that the 
> {{UniformRandomProvider}} interface can be stable enough for TEXT, then we 
> should follow Jochen Wiedemann's advice (cf. archive of the "dev" ML) and 
> define TEXT's own interface to random numbers, with bridges to it from 
> {{UniformRandomProvider}} and from {{java.util.Random}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to