commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (JIRA)" <>
Subject [jira] [Commented] (TEXT-36) Dependency on "Commons RNG"
Date Thu, 22 Dec 2016 12:42:58 GMT


Gilles commented on TEXT-36:

bq. It would be good to hear why people are concerned about a link between TEXT and RNG.


Indeed, are there technical objections?

There is nothing in favour of using the JDK's {{Random}} class in new applications (or libraries
such as TEXT):
* no speed of generation advantage,
* no quality of randomness advantage,
* no memory consumption advantage.

Over the course of developing what has become Commons RNG, I've made a summary of [why not
to use {{java.util.Random}}|].

The only justification for using it is when applications are required to reproduce the same
sequence as the particular algorithm implemented by {{Random}} (needless to say: It is not
the most obvious case for "randomness").

bq. Is it a fear of Maven jar hell?

This would be bogus, given that we don't release code that could create it (due to the change
of package name and coordinates).

bq. Eat our own dog food


bq. Users can bridge to java.util.Random using RNG's bridge classes

Not sure what you mean.
is a bridge *from* Commons RNG's {{RandomSource}} *to* JDK's {{Random}} (so not applicable
to pass to a TEXT API based on Commons RNG).
A user who would want to use {{Random}} as the underlying generator would create the corresponding

bq. explicitly offer overloads with java.util.Random.

This what Gary proposes.

Thus, assuming a {{TextRandomProvider}} interface:
import java.util.Random;

public class JdkRandomBridge implements TextRandomProvider {
    private final Random delegate;

    public JdkRandomBridge(Random rng) {
        delegate = rng;

    // TextRandomProvider methods

import org.apache.commons.rng.UniformRandomProvider;

public class CommonsRngBridge implements TextRandomProvider {
    private final UniformRandomProvide delegate;

    public CommonsRngBridge(UniformRandomProvider rng) {
        delegate = rng;

    // TextRandomProvider methods

bq. Offer only java.util.Random in the interface, but shade RNG so that our internal default
implementations are as good as can be.

This does not look good: users who want to control the randomness generation are stuck with
a sub-par algorithm, while users who don't care get a better one...

Moreover, as a general remark, I'm -0 on "hiding" a fundamental parameter of some functionality
(here, the RNG for building _random_ strings).

bq. Don't use RNG at all.

Does not make any sense. ;)

> Dependency on "Commons RNG"
> ---------------------------
>                 Key: TEXT-36
>                 URL:
>             Project: Commons Text
>          Issue Type: Improvement
>            Reporter: Gilles
>              Labels: api
>             Fix For: 1.0
> 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