Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 13CBF200BE9 for ; Mon, 26 Dec 2016 15:45:00 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 1245F160B3B; Mon, 26 Dec 2016 14:45:00 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 5CE88160B2A for ; Mon, 26 Dec 2016 15:44:59 +0100 (CET) Received: (qmail 35907 invoked by uid 500); 26 Dec 2016 14:44:58 -0000 Mailing-List: contact issues-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: issues@commons.apache.org Delivered-To: mailing list issues@commons.apache.org Received: (qmail 35892 invoked by uid 99); 26 Dec 2016 14:44:58 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 Dec 2016 14:44:58 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id 592E52C1F56 for ; Mon, 26 Dec 2016 14:44:58 +0000 (UTC) Date: Mon, 26 Dec 2016 14:44:58 +0000 (UTC) From: "Rob Tompkins (JIRA)" To: issues@commons.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (TEXT-36) Dependency on "Commons RNG" MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Mon, 26 Dec 2016 14:45:00 -0000 [ https://issues.apache.org/jira/browse/TEXT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15778436#comment-15778436 ] Rob Tompkins commented on TEXT-36: ---------------------------------- Bernd's comment seems like a really good pattern with regards to consuming other components, extending existing java classes/interfaces with our own implementations with the idea that the examples provided display using the other component. In doing this we give consumers more control over precisely the dependencies that they desire when running their applications. Either way, though, I'm in the +/- 0 category. So I'd say don't spend too much time worrying about my opinion here. > 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)