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