commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Eckenfels (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TEXT-36) Dependency on "Commons RNG"
Date Thu, 22 Dec 2016 08:14:58 GMT

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

Bernd Eckenfels commented on TEXT-36:
-------------------------------------

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)

Mime
View raw message