You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Duncan Jones (JIRA)" <ji...@apache.org> on 2016/12/22 08:16:58 UTC

[jira] [Issue Comment Deleted] (TEXT-36) Dependency on "Commons RNG"

     [ https://issues.apache.org/jira/browse/TEXT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Duncan Jones updated TEXT-36:
-----------------------------
    Comment: was deleted

(was: I am currently not in the Office. Your mail will not be forwarded. I will be Back on 2017-01-16

If you need technical support with SEEBURGER products, contact support@seeburger.de or http://servicedesk.seeburger.de

General inquiries can be directed to our info team: info@seeburger.de

Greetings Bernd Eckenfels
Chief Architect, SEEBURGER AG








SEEBURGER AG            Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:                Axel Haas, Michael Kleeberg, Friedemann Heinz, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1
D-75015 Bretten         Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0            Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de               Registergericht/Commercial Register:
e-mail: info@seeburger.de               HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.


This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.

)

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