commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raymond DeCampo (JIRA)" <>
Subject [jira] [Commented] (TEXT-36) Dependency on "Commons RNG"
Date Thu, 05 Jan 2017 19:30:58 GMT


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:

    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()
    // or if they want commons-rng:
    UniformRandomProvider rng = RandomSource.create(RandomSource.MT);
    RandomStringGenerator gen = new RandomStringGenerator.Builder()

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:
>             Project: Commons Text
>          Issue Type: Improvement
>            Reporter: Gilles
>              Labels: api
>             Fix For: 1.1
> This is a follow-up of a [discussion|]
held in TEXT-34.
> IMHO, there is no harm in depending on the ["commons-rng-client-api" module|]
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

View raw message