Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Thu, 22 Dec 2016 08:13:58 +0000 (UTC)
From: "Duncan Jones (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.13029721.1482320959000.579845.1482394438428@Atlassian.JIRA>
In-Reply-To: <JIRA.13029721.1482320959000@Atlassian.JIRA>
References: <JIRA.13029721.1482320959000@Atlassian.JIRA> <JIRA.13029721.1482320959415@arcas>
Subject: [jira] [Commented] (TEXT-36) Dependency on "Commons RNG"
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 22 Dec 2016 08:14:00 -0000


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

Duncan Jones commented on TEXT-36:
----------------------------------

It would be good to hear why people are concerned about a link between TEXT and RNG. Is it a fear of Maven jar hell? I.e. TEXT depends upon a specific version of RNG, which clashes somehow with the preferred version of the user's code?

If that's the concern, then I don't think Gregory's suggestion saves us anything, since we'd have to depend upon RNG to offer the interface.

IMO, the four options I can see in descending order of preference are:

# Eat our own dog food - use RNG as the only visible option. Users can bridge to java.util.Random using RNG's bridge classes if they must.
# As above, but explicitly offer overloads with java.util.Random.
# Offer only java.util.Random in the interface, but shade RNG so that our internal default implementations are as good as can be.
# Don't use RNG at all.

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