[jira] [Created] (BSF-44) Un-thrown exception
Jaechang Nam created BSF-44:
---
Summary: Un-thrown exception
Key: BSF-44
URL: https://issues.apache.org/jira/browse/BSF-44
Project: Commons BSF
Issue Type: Bug
Reporter: Jaechang Nam
Priority: Trivial
There is an un-thrown exception (BadArgumentException) in
src/main/java/org/apache/bsf/engines/netrexx/NetRexxEngine.java (found from the
current snapshot, f8eeaf2f8dd69e49b094b16b5c4d660c40f6be74). I have no idea if
it is intended to do so. But thought it could be worth to report in case.
{code}
128 public NetRexxEngine ()
129 {
130 // handle logger
131 logger = BSF_LogFactory.getLog(this.getClass().getName());
132 /*
133 The following line is intended to cause the constructor to
134 throw a NoClassDefFoundError if the NetRexxC.zip dependency
135 is not resolved.
136
137 If this line was not here, the problem would not surface until
138 the actual processing of a script. We want to know all is well
139 at the time the engine is instantiated, not when we attempt to
140 process a script.
141 */
142
143 new netrexx.lang.BadArgumentException();
144 }
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TEXT-36) Dependency on "Commons RNG"
[
https://issues.apache.org/jira/browse/TEXT-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15768011#comment-15768011
]
Bernd Eckenfels edited comment on TEXT-36 at 12/21/16 7:59 PM:
---
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(int)}}.
In fact I would exepect RNG to provide such an Adapter already. Advantage is,
that no dependency of TEXT to RNG is needed.
was (Author: b.eckenfels):
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&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)
[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&focusedCommentId=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&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)
[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&focusedCommentId=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&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)
[jira] [Updated] (TEXT-38) Fluent API in "RandomStringBuilder"
[
https://issues.apache.org/jira/browse/TEXT-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated TEXT-38:
---
Summary: Fluent API in "RandomStringBuilder" (was: Fluent API in
{{RandomStringBuilder}})
> Fluent API in "RandomStringBuilder"
> ---
>
> Key: TEXT-38
> URL: https://issues.apache.org/jira/browse/TEXT-38
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Gilles
> Labels: api
> Fix For: 1.0
>
>
> It can be construed as potentially dangerous to let user code change any of
> the settings of the builder, as other parts of the code could be using a
> reference to the same instance.
> In Commons Math, where the fluent API pattern was applied, a new builder
> (immutable) instance would be created. For example, see [this
> class|https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=blob;f=src/main/java/org/apache/commons/math4/fitting/SimpleCurveFitter.java;h=54f6cbfe1e003cec74f2b0e71efc1b13000a5525;hb=HEAD].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TEXT-38) Fluent API in {{RandomStringBuilder}}
Gilles created TEXT-38:
--
Summary: Fluent API in {{RandomStringBuilder}}
Key: TEXT-38
URL: https://issues.apache.org/jira/browse/TEXT-38
Project: Commons Text
Issue Type: Improvement
Reporter: Gilles
Fix For: 1.0
It can be construed as potentially dangerous to let user code change any of the
settings of the builder, as other parts of the code could be using a reference
to the same instance.
In Commons Math, where the fluent API pattern was applied, a new builder
(immutable) instance would be created. For example, see [this
class|https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=blob;f=src/main/java/org/apache/commons/math4/fitting/SimpleCurveFitter.java;h=54f6cbfe1e003cec74f2b0e71efc1b13000a5525;hb=HEAD].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TEXT-37) Global vs local source of randomness
Gilles created TEXT-37:
--
Summary: Global vs local source of randomness
Key: TEXT-37
URL: https://issues.apache.org/jira/browse/TEXT-37
Project: Commons Text
Issue Type: Improvement
Reporter: Gilles
Fix For: 1.0
This is a follow-up of a
[discussion|https://issues.apache.org/jira/browse/TEXT-34?focusedCommentId=15761636&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15761636]
held in TEXT-34.
By default, {{RandomStringBuilder}} will use a shared {{java.util.Random}}
object.
I think that the decision of which generator to use lies with the code that
_constructs_ the {{RandomStringBuilder}} instance, not with code that _uses_ it
(to build a string).
It would be safer to pass the RNG instance at construction (since, anyways, the
constructor must be called):
{code}
RandomStringBuilder sb = new RandomStringBuilder(new MyRandom());
String s = sb.ofLength(length).build();
{code}
In the above, the {{MyRandom}} type is the subject of TEXT-36.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IO-524) Documentation Bug of Tailer - it opens thread within
[ https://issues.apache.org/jira/browse/IO-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15767075#comment-15767075 ] Arik Sher commented on IO-524: -- just to make sure. the documentation I see is here: http://commons.apache.org/proper/commons-io/javadocs/api-2.5/org/apache/commons/io/input/Tailer.html > Documentation Bug of Tailer - it opens thread within > > > Key: IO-524 > URL: https://issues.apache.org/jira/browse/IO-524 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.4, 2.5 >Reporter: Arik Sher >Priority: Minor > > Documentation of > org.apache.commons.io.input.Tailer > describes how to handle threading, while it seems that thread being openened > within, and seamlessly to user. > need to update the doc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TEXT-36) Dependency on "Commons RNG"
Gilles created TEXT-36:
--
Summary: Dependency on "Commons RNG"
Key: TEXT-36
URL: https://issues.apache.org/jira/browse/TEXT-36
Project: Commons Text
Issue Type: Improvement
Reporter: Gilles
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)
[jira] [Created] (IO-524) Documentation Bug of Tailer - it opens thread within
Arik Sher created IO-524: Summary: Documentation Bug of Tailer - it opens thread within Key: IO-524 URL: https://issues.apache.org/jira/browse/IO-524 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 2.5, 2.4 Reporter: Arik Sher Priority: Minor Documentation of org.apache.commons.io.input.Tailer describes how to handle threading, while it seems that thread being openened within, and seamlessly to user. need to update the doc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
