[jira] [Commented] (TEXT-36) Dependency on "Commons RNG"
[ https://issues.apache.org/jira/browse/TEXT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15804394#comment-15804394 ] Raymond DeCampo commented on TEXT-36: - bq. Whether the feature is out-of-scope is a good question. For this issue, the assumption was that the class is there already. Understood. bq. The "" tag would not impose a transitive dependency. Yes, I missed this aspect, that would make it more palatable. bq. You are welcome to implement it. Pull request on github against the TEXT-51 branch: https://github.com/apache/commons-text/pull/25 > 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.1 > > > This is a follow-up of a > [discussion|https://issues.apache.org/jira/browse/TEXT-34?focusedCommentId=15762623=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)
[jira] [Commented] (TEXT-36) Dependency on "Commons RNG"
[ https://issues.apache.org/jira/browse/TEXT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15803179#comment-15803179 ] Gilles commented on TEXT-36: bq. if I \[...\] wasn't interested in the class generating random strings Whether the feature is out-of-scope is a good question. For this issue, the assumption was that the class is there already. bq. dependency on a random number generator library \[is\] a strange thing for a text library to depend on We agreed on that. The "" tag would not impose a transitive dependency. bq. I would go with the TextRandomProvider interface scheme EXCEPT that it should be eligible to be a functional interface Fine. You are welcome to implement it. :) bq. Then in the javadoc for the class put examples using commons-rng +1 > 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.1 > > > This is a follow-up of a > [discussion|https://issues.apache.org/jira/browse/TEXT-34?focusedCommentId=15762623=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)
[jira] [Commented] (TEXT-36) Dependency on "Commons RNG"
[ https://issues.apache.org/jira/browse/TEXT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15802286#comment-15802286 ] Raymond DeCampo commented on TEXT-36: - My 2 cents (not that anyone should care) - if I were including commons-text in a project and wasn't interested in the class generating random strings (will most of the commons-text users be in this scenario?) I would prefer there not be a dependency on a random number generator library which seems like a strange thing for a text library to depend on. That said, if it were up to me, I would go with the TextRandomProvider interface scheme EXCEPT that it should be eligible to be a functional interface. Also it should have the same signature as the nextInt() method in java.util.Random and UniformRandomProvider. This will make implementation easy for Java 8 users. I am thinking something like: {code} public interface TextRandomProvider { public int nextInt(int max); } // Then Java 8 users can do something like: java.util.Random jur = new java.util.Random(1234L); RandomStringGenerator gen = new RandomStringGenerator.Builder() .usingRandom(jur::nextInt) .build(); // or if they want commons-rng: UniformRandomProvider rng = RandomSource.create(RandomSource.MT); RandomStringGenerator gen = new RandomStringGenerator.Builder() .usingRandom(rng::nextInt) .build(); {code} Then in the javadoc for the class put examples using commons-rng and that's what 99% of the people will use anyway. Plus there's no dependency on commons-rng unless you are actually using the functionality. People still on Java 7 will have to implement the interface but the number of users on 7 will be diminishing so I'm not too concerned about inconveniencing them. > 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.1 > > > This is a follow-up of a > [discussion|https://issues.apache.org/jira/browse/TEXT-34?focusedCommentId=15762623=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)
[jira] [Commented] (TEXT-36) Dependency on "Commons RNG"
[ https://issues.apache.org/jira/browse/TEXT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15792967#comment-15792967 ] Rob Tompkins commented on TEXT-36: -- Linking TEXT-51 which moves RandomStringGenerator onto its own branch for the 1.0 release to be incorporated in the 1.1 release. > 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=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)
[jira] [Commented] (TEXT-36) Dependency on "Commons RNG"
[ https://issues.apache.org/jira/browse/TEXT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15778751#comment-15778751 ] Gilles commented on TEXT-36: bq. how to give the consumer the most options By implementing a custom interface (exemplified as {{TextRandomProvider}} above). > 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=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)
[jira] [Commented] (TEXT-36) Dependency on "Commons RNG"
[ https://issues.apache.org/jira/browse/TEXT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15778644#comment-15778644 ] Rob Tompkins commented on TEXT-36: -- Fair. I was just thinking of how to give the consumer the most options. > 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=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)
[jira] [Commented] (TEXT-36) Dependency on "Commons RNG"
[ https://issues.apache.org/jira/browse/TEXT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=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)
[jira] [Commented] (TEXT-36) Dependency on "Commons RNG"
[ https://issues.apache.org/jira/browse/TEXT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15769967#comment-15769967 ] Gilles commented on TEXT-36: bq. It would be good to hear why people are concerned about a link between TEXT and RNG. +1 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}}|http://commons.apache.org/proper/commons-rng/userguide/why_not_java_random.html]. 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 +1 bq. Users can bridge to java.util.Random using RNG's bridge classes Not sure what you mean. [JDKRandomBridge|http://commons.apache.org/proper/commons-rng/commons-rng-simple/apidocs/org/apache/commons/rng/simple/JDKRandomBridge.html] 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 [{{UniformRandomProvider}}|http://commons.apache.org/proper/commons-rng/commons-rng-simple/apidocs/org/apache/commons/rng/simple/RandomSource.html#JDK]. bq. explicitly offer overloads with java.util.Random. This what Gary proposes. Thus, assuming a {{TextRandomProvider}} interface: {code} import java.util.Random; public class JdkRandomBridge implements TextRandomProvider { private final Random delegate; public JdkRandomBridge(Random rng) { delegate = rng; } // TextRandomProvider methods } {code} {code} import org.apache.commons.rng.UniformRandomProvider; public class CommonsRngBridge implements TextRandomProvider { private final UniformRandomProvide delegate; public CommonsRngBridge(UniformRandomProvider rng) { delegate = rng; } // TextRandomProvider methods } {code} 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: 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=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)
[jira] [Commented] (TEXT-36) Dependency on "Commons RNG"
[ https://issues.apache.org/jira/browse/TEXT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 supp...@seeburger.de or http://servicedesk.seeburger.de General inquiries can be directed to our info team: i...@seeburger.de Greetings Bernd Eckenfels Chief Architect, SEEBURGER AG SEEBURGER AGVorstand/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 - 0Prof. Dr. Simone Zeuchner Fax: 07252 / 96 - Internet: http://www.seeburger.de Registergericht/Commercial Register: e-mail: i...@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=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)
[jira] [Commented] (TEXT-36) Dependency on "Commons RNG"
[ https://issues.apache.org/jira/browse/TEXT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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=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)
[jira] [Commented] (TEXT-36) Dependency on "Commons RNG"
[ https://issues.apache.org/jira/browse/TEXT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15768011#comment-15768011 ] Bernd Eckenfels commented on TEXT-36: - I would stick with the Java.util.Random signature, if you want to specify a different random Generator you can subclass j.u.Random and overwrite `protected int next(ind)`. In fact Iwould exepect RNG to provide such an Adapter already. Advantage is, that no dependency of text to RNG is needed. > 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=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)
[jira] [Commented] (TEXT-36) Dependency on "Commons RNG"
[ https://issues.apache.org/jira/browse/TEXT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15767896#comment-15767896 ] Gary Gregory commented on TEXT-36: -- I can see a best of both worlds here based on your description. TEXT provides a random interface with 2 implementation: one to Java own random with a red waving flag on it and another impl based on RNG. > 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=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)