[jira] [Closed] (TEXT-84) RandomStringGenerator claims to be immutable, but isn't
[
https://issues.apache.org/jira/browse/TEXT-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones closed TEXT-84.
Resolution: Fixed
Assignee: Duncan Jones
Fix Version/s: 1.2
Fixed in 4004cfdee.
> RandomStringGenerator claims to be immutable, but isn't
> ---
>
> Key: TEXT-84
> URL: https://issues.apache.org/jira/browse/TEXT-84
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Duncan Jones
>Assignee: Duncan Jones
> Fix For: 1.2
>
>
> {{RandomStringGenerator}} claims to be immutable in the Javadocs, however it
> accepts a {{TextRandomProvider}} object through the builder pattern. This
> object may altered by external code, thus breaking the immutability claim of
> our generator.
> A possible solution is to adjust the documentation for {{TextRandomProvider}}
> and require implementations to be immutable. Alternatively, we can relax the
> documentation in {{RandomStringGenerator}} to remove the immutability claim
> or state that the mutability is linked to the mutability of the random source
> (when provided).
> I think we will have to do the latter, since the former would forbid callers
> from supplying a {{UniformRandomProvider}} instance as suggested in the
> documentation. Thoughts welcome.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TEXT-84) RandomStringGenerator claims to be immutable, but isn't
[
https://issues.apache.org/jira/browse/TEXT-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16028771#comment-16028771
]
Duncan Jones commented on TEXT-84:
--
bq. WDYT?
I suppose you could run some tests to prove your assumptions around performance?
Supposing it existed, how would you propose to use ThreadLocalRandom with
RandomStringGenerator?
bq. Is there a value in "conditional immutability"?
In the Pair example, I could imagine some limited usefulness (perhaps when
composing Pairs into another object). Less so with RandomStringGenerator.
> RandomStringGenerator claims to be immutable, but isn't
> ---
>
> Key: TEXT-84
> URL: https://issues.apache.org/jira/browse/TEXT-84
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Duncan Jones
>
> {{RandomStringGenerator}} claims to be immutable in the Javadocs, however it
> accepts a {{TextRandomProvider}} object through the builder pattern. This
> object may altered by external code, thus breaking the immutability claim of
> our generator.
> A possible solution is to adjust the documentation for {{TextRandomProvider}}
> and require implementations to be immutable. Alternatively, we can relax the
> documentation in {{RandomStringGenerator}} to remove the immutability claim
> or state that the mutability is linked to the mutability of the random source
> (when provided).
> I think we will have to do the latter, since the former would forbid callers
> from supplying a {{UniformRandomProvider}} instance as suggested in the
> documentation. Thoughts welcome.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (TEXT-84) RandomStringGenerator claims to be immutable, but isn't
[
https://issues.apache.org/jira/browse/TEXT-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones updated TEXT-84:
-
Description:
{{RandomStringGenerator}} claims to be immutable in the Javadocs, however it
accepts a {{TextRandomProvider}} object through the builder pattern. This
object may altered by external code, thus breaking the immutability claim of
our generator.
A possible solution is to adjust the documentation for {{TextRandomProvider}}
and require implementations to be immutable. Alternatively, we can relax the
documentation in {{RandomStringGenerator}} to remove the immutability claim or
state that the mutability is linked to the mutability of the random source
(when provided).
I think we will have to do the latter, since the former would forbid callers
from supplying a {{UniformRandomProvider}} instance as suggested in the
documentation. Thoughts welcome.
was:
{{RandomStringGenerator}} claims to be immutable in the Javadocs, however it
accepts a {{TextRandomProvider}} object through the builder pattern. This
object may altered by external code, thus breaking the immutability claim of
our generator.
A possible solution is to adjust the documentation for {{TextRandomProvider}}
and require implementations to be immutable. Alternatively, we can relax the
documentation in {{RandomStringGenerator}} to remove the immutability claim.
I think we will have to do the latter, since the former would forbid callers
from supplying a {{UniformRandomProvider}} instance as suggested in the
documentation.
> RandomStringGenerator claims to be immutable, but isn't
> ---
>
> Key: TEXT-84
> URL: https://issues.apache.org/jira/browse/TEXT-84
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Duncan Jones
>
> {{RandomStringGenerator}} claims to be immutable in the Javadocs, however it
> accepts a {{TextRandomProvider}} object through the builder pattern. This
> object may altered by external code, thus breaking the immutability claim of
> our generator.
> A possible solution is to adjust the documentation for {{TextRandomProvider}}
> and require implementations to be immutable. Alternatively, we can relax the
> documentation in {{RandomStringGenerator}} to remove the immutability claim
> or state that the mutability is linked to the mutability of the random source
> (when provided).
> I think we will have to do the latter, since the former would forbid callers
> from supplying a {{UniformRandomProvider}} instance as suggested in the
> documentation. Thoughts welcome.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (TEXT-84) RandomStringGenerator claims to be immutable, but isn't
Duncan Jones created TEXT-84:
Summary: RandomStringGenerator claims to be immutable, but isn't
Key: TEXT-84
URL: https://issues.apache.org/jira/browse/TEXT-84
Project: Commons Text
Issue Type: Bug
Affects Versions: 1.1
Reporter: Duncan Jones
{{RandomStringGenerator}} claims to be immutable in the Javadocs, however it
accepts a {{TextRandomProvider}} object through the builder pattern. This
object may altered by external code, thus breaking the immutability claim of
our generator.
A possible solution is to adjust the documentation for {{TextRandomProvider}}
and require implementations to be immutable. Alternatively, we can relax the
documentation in {{RandomStringGenerator}} to remove the immutability claim.
I think we will have to do the latter, since the former would forbid callers
from supplying a {{UniformRandomProvider}} instance as suggested in the
documentation.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (LANG-1334) Deprecate CharEncoding in favour of java.nio.charset.StandardCharsets
[
https://issues.apache.org/jira/browse/LANG-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones closed LANG-1334.
--
Resolution: Fixed
Fixed in commit 7c19a1ff4.
> Deprecate CharEncoding in favour of java.nio.charset.StandardCharsets
> -
>
> Key: LANG-1334
> URL: https://issues.apache.org/jira/browse/LANG-1334
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.5
>Reporter: Duncan Jones
>Assignee: Duncan Jones
> Fix For: 3.6
>
>
> Java 7 introduced {{java.nio.charset.StandardCharsets}}, which negates the
> need for our {{CharEncoding}} method.
> Deprecating this class was discussed in
> http://markmail.org/message/iiy4z6js3mj4z6fz, but never actioned. I'm about
> to commit a change that actions this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (LANG-1334) Deprecate CharEncoding in favour of java.nio.charset.StandardCharsets
Duncan Jones created LANG-1334:
--
Summary: Deprecate CharEncoding in favour of
java.nio.charset.StandardCharsets
Key: LANG-1334
URL: https://issues.apache.org/jira/browse/LANG-1334
Project: Commons Lang
Issue Type: Improvement
Components: lang.*
Affects Versions: 3.5
Reporter: Duncan Jones
Assignee: Duncan Jones
Fix For: 3.6
Java 7 introduced {{java.nio.charset.StandardCharsets}}, which negates the need
for our {{CharEncoding}} method.
Deprecating this class was discussed in
http://markmail.org/message/iiy4z6js3mj4z6fz, but never actioned. I'm about to
commit a change that actions this.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (LANG-1319) MultilineRecursiveToStringStyle StackOverflowError when object is an array
[
https://issues.apache.org/jira/browse/LANG-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones closed LANG-1319.
--
Resolution: Fixed
Fix Version/s: 3.6
Thanks for the report. Fixed in commit 7587431.
> MultilineRecursiveToStringStyle StackOverflowError when object is an array
> ---
>
> Key: LANG-1319
> URL: https://issues.apache.org/jira/browse/LANG-1319
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.builder.*
>Affects Versions: 3.5
>Reporter: Sergiy Proskuryakov
>Assignee: Duncan Jones
> Fix For: 3.6
>
>
> MultilineRecursiveToStringStyle style = new MultilineRecursiveToStringStyle();
> String result = ToStringBuilder.reflectionToString(new String[] {"1","2"},
> style);
> java.lang.StackOverflowError
> at
> org.apache.commons.lang3.builder.ToStringStyle.appendStart(ToStringStyle.java:409)
> at
> org.apache.commons.lang3.builder.ToStringBuilder.(ToStringBuilder.java:262)
> at
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.(ReflectionToStringBuilder.java:481)
> at
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:300)
> at
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:157)
> at
> org.apache.commons.lang3.builder.RecursiveToStringStyle.appendDetail(RecursiveToStringStyle.java:74)
> at
> org.apache.commons.lang3.builder.MultilineRecursiveToStringStyle.reflectionAppendArrayDetail(MultilineRecursiveToStringStyle.java:142)
> at
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.reflectionAppendArray(ReflectionToStringBuilder.java:633)
> at
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.appendFieldsIn(ReflectionToStringBuilder.java:538)
> at
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:711)
> at
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:301)
> at
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:157)
> at
> org.apache.commons.lang3.builder.RecursiveToStringStyle.appendDetail(RecursiveToStringStyle.java:74)
> at
> org.apache.commons.lang3.builder.MultilineRecursiveToStringStyle.reflectionAppendArrayDetail(MultilineRecursiveToStringStyle.java:142)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (LANG-1319) MultilineRecursiveToStringStyle StackOverflowError when object is an array
[
https://issues.apache.org/jira/browse/LANG-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones updated LANG-1319:
---
Assignee: Duncan Jones
> MultilineRecursiveToStringStyle StackOverflowError when object is an array
> ---
>
> Key: LANG-1319
> URL: https://issues.apache.org/jira/browse/LANG-1319
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.builder.*
>Affects Versions: 3.5
>Reporter: Sergiy Proskuryakov
>Assignee: Duncan Jones
>
> MultilineRecursiveToStringStyle style = new MultilineRecursiveToStringStyle();
> String result = ToStringBuilder.reflectionToString(new String[] {"1","2"},
> style);
> java.lang.StackOverflowError
> at
> org.apache.commons.lang3.builder.ToStringStyle.appendStart(ToStringStyle.java:409)
> at
> org.apache.commons.lang3.builder.ToStringBuilder.(ToStringBuilder.java:262)
> at
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.(ReflectionToStringBuilder.java:481)
> at
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:300)
> at
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:157)
> at
> org.apache.commons.lang3.builder.RecursiveToStringStyle.appendDetail(RecursiveToStringStyle.java:74)
> at
> org.apache.commons.lang3.builder.MultilineRecursiveToStringStyle.reflectionAppendArrayDetail(MultilineRecursiveToStringStyle.java:142)
> at
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.reflectionAppendArray(ReflectionToStringBuilder.java:633)
> at
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.appendFieldsIn(ReflectionToStringBuilder.java:538)
> at
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:711)
> at
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:301)
> at
> org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:157)
> at
> org.apache.commons.lang3.builder.RecursiveToStringStyle.appendDetail(RecursiveToStringStyle.java:74)
> at
> org.apache.commons.lang3.builder.MultilineRecursiveToStringStyle.reflectionAppendArrayDetail(MultilineRecursiveToStringStyle.java:142)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (LANG-1309) Should EqualsBuilder.reflectionEquals return false if both values of a field is null?
[
https://issues.apache.org/jira/browse/LANG-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15802057#comment-15802057
]
Duncan Jones commented on LANG-1309:
I'm afraid I can't reproduce this issue with v3.5. What version of Lang are you
using?
> Should EqualsBuilder.reflectionEquals return false if both values of a field
> is null?
> -
>
> Key: LANG-1309
> URL: https://issues.apache.org/jira/browse/LANG-1309
> Project: Commons Lang
> Issue Type: Improvement
>Reporter: Andres Joy
>Priority: Minor
>
> EqualsBuilder.reflectionEquals return false if both values of the two objects
> on a field is null. Is this behavior intended?
> Consider the following example:
> {code}class Person {
> String name;
> int age;
> String phone = null;
> ...
> }{code}
> And a test method:
> {code}Person p1 = new Person();
> p1.name = "Mike";
> p1.age = 30;
> Person p2 = new Person();
> p2.name = "Mike";
> p2.age = 30;
> assertTrue(EqualsBuilder.reflectionEquals(p1, p2));{code}
> This test won't pass because the assertion will fail.
> Moreover, in this example, the objects we compare are actually equal(morally
> speaking) and the check should therefore return true.
> What motivates the current behavior?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (TEXT-37) Global vs local source of randomness
[
https://issues.apache.org/jira/browse/TEXT-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones closed TEXT-37.
Resolution: Fixed
Assignee: Duncan Jones
Fixed as part of 08ac56a50.
> 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
>Assignee: Duncan Jones
> Labels: api, constructor
> 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] [Closed] (TEXT-38) Fluent API in "RandomStringBuilder"
[ https://issues.apache.org/jira/browse/TEXT-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duncan Jones closed TEXT-38. Resolution: Fixed Fixed in commit 08ac56a50. > Fluent API in "RandomStringBuilder" > --- > > Key: TEXT-38 > URL: https://issues.apache.org/jira/browse/TEXT-38 > Project: Commons Text > Issue Type: Improvement >Reporter: Gilles >Assignee: Duncan Jones > 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] [Commented] (LANG-1280) WordUtils should use toXxxxCase(int) rather than toXxxxCase(char)
[ https://issues.apache.org/jira/browse/LANG-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15777829#comment-15777829 ] Duncan Jones commented on LANG-1280: This class has already been ported to Commons Text and I'm about to refactor it into multiple classes. Might be best to find another issue to work on, this will be deprecated and removed in a future release. > WordUtils should use toXxxxCase(int) rather than toXxxxCase(char) > - > > Key: LANG-1280 > URL: https://issues.apache.org/jira/browse/LANG-1280 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Reporter: Sebb > > The Javadoc for Character#toTitleCase(char) recommends using > Character#toTitleCase(int) instead. This method was added in Java 1.5 which > is perhaps is why it was not used originally; maybe we should use it now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (LANG-1302) java.lang.StringIndexOutOfBoundsException resulting in WordUtils.wrap
[ https://issues.apache.org/jira/browse/LANG-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15770293#comment-15770293 ] Duncan Jones edited comment on LANG-1302 at 12/22/16 3:25 PM: -- I can't reproduce this from the current trunk. Suspect this is a duplicate of LANG-1292 and is now fixed. Will be released in 3.6. Thanks for reporting the issue. was (Author: dmjones500): I can't reproduce this from the current trunk. Suspect this is a duplicate of LANG-1292 and is now fixed. Will be released in 3.6. > java.lang.StringIndexOutOfBoundsException resulting in WordUtils.wrap > - > > Key: LANG-1302 > URL: https://issues.apache.org/jira/browse/LANG-1302 > Project: Commons Lang > Issue Type: Bug >Affects Versions: 3.5 > Environment: Mac, Android, Linux >Reporter: Vadiraj Purohit >Assignee: Duncan Jones > Fix For: 3.6 > > > Commons-lang3:3.5 > Issue code: > String appName = "Google Play Store"; > appName = WordUtils.wrap(appName, appName.length()/2); > System.out.println(appName); > Resulting exception: > Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String > index out of range: -3 > at java.lang.String.substring(String.java:1967) > at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:328) > at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:176) > at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:100) > at removedups.Main2.main(Main2.java:32) > This exception does not occur in commons-lang3:3.4 though -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (LANG-1302) java.lang.StringIndexOutOfBoundsException resulting in WordUtils.wrap
[ https://issues.apache.org/jira/browse/LANG-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duncan Jones resolved LANG-1302. Resolution: Duplicate Assignee: Duncan Jones Fix Version/s: 3.6 I can't reproduce this from the current trunk. Suspect this is a duplicate of LANG-1292 and is now fixed. Will be released in 3.6. > java.lang.StringIndexOutOfBoundsException resulting in WordUtils.wrap > - > > Key: LANG-1302 > URL: https://issues.apache.org/jira/browse/LANG-1302 > Project: Commons Lang > Issue Type: Bug >Affects Versions: 3.5 > Environment: Mac, Android, Linux >Reporter: Vadiraj Purohit >Assignee: Duncan Jones > Fix For: 3.6 > > > Commons-lang3:3.5 > Issue code: > String appName = "Google Play Store"; > appName = WordUtils.wrap(appName, appName.length()/2); > System.out.println(appName); > Resulting exception: > Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String > index out of range: -3 > at java.lang.String.substring(String.java:1967) > at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:328) > at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:176) > at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:100) > at removedups.Main2.main(Main2.java:32) > This exception does not occur in commons-lang3:3.4 though -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TEXT-38) Fluent API in "RandomStringBuilder"
[
https://issues.apache.org/jira/browse/TEXT-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15769459#comment-15769459
]
Duncan Jones commented on TEXT-38:
--
I'd be happy to make this change. It would make it easier to move towards a
thread-safe implementation.
I propose we rename the class to {{RandomStringGenerator}} and create an inner
{{Builder}} class. I would also propose we force callers to construct the
generator using the builder (i.e. the {{RandomStringGenerator}} is private.
Sound ok? If so, I'll make that change.
> 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] [Commented] (TEXT-37) Global vs local source of randomness
[
https://issues.apache.org/jira/browse/TEXT-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15769453#comment-15769453
]
Duncan Jones commented on TEXT-37:
--
I think this issue is blocked until we decide on TEXT-38.
If we alter the class (as suggested in TEXT-38), then we would likely have a
{{RandomStringGenerator}} class with a inner {{Builder}} class. In this
situation, the builder could accept a random generator in whatever way feels
most elegant (I would vote for a fluent method call), since it cannot later be
changed by the user of the generator.
> 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
> Labels: api, constructor
> 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] [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
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&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=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&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] [Closed] (TEXT-34) Add class to generate random strings
[
https://issues.apache.org/jira/browse/TEXT-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones closed TEXT-34.
Resolution: Implemented
Fix Version/s: 1.0
First version of class committed. There's some open issues above, but I suggest
we tackle those separately if people feel strongly about them.
{quote}
Repository: commons-text
Updated Branches:
refs/heads/master d7d2d9157 -> 120409051
TEXT-34: Add class to generate random strings
Project: http://git-wip-us.apache.org/repos/asf/commons-text/repo
Commit: http://git-wip-us.apache.org/repos/asf/commons-text/commit/12040905
Tree: http://git-wip-us.apache.org/repos/asf/commons-text/tree/12040905
Diff: http://git-wip-us.apache.org/repos/asf/commons-text/diff/12040905
{quote}
> Add class to generate random strings
>
>
> Key: TEXT-34
> URL: https://issues.apache.org/jira/browse/TEXT-34
> Project: Commons Text
> Issue Type: New Feature
>Reporter: Duncan Jones
>Assignee: Duncan Jones
> Fix For: 1.0
>
>
> The {{RandomStringUtils}} class will be deprecated in Commons Lang and reborn
> in Commons Text.
> Because the original class has some complicated parameters and potentially
> unnecessary capabilities, I'll simplify as I move it across. I'll also ensure
> the class plays nicely with Unicode characters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TEXT-34) Add class to generate random strings
[
https://issues.apache.org/jira/browse/TEXT-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15765020#comment-15765020
]
Duncan Jones commented on TEXT-34:
--
Thanks for those links, Giles.
So shall I just crack on and make TEXT dependent upon RNG? If we see TEXT as a
second-level component, as I've heard mentioned on the mailing lists, then that
would be the right choice. We can become the poster-child for doing randomness
correctly.
In which case, I would adjust the {{usingRandom}} method to accept a
{{UniformRandomProvider}} argument. Does that sound ok? What would be your
recommendation for the default generator to use for the class, if one is not
provided?
> Add class to generate random strings
>
>
> Key: TEXT-34
> URL: https://issues.apache.org/jira/browse/TEXT-34
> Project: Commons Text
> Issue Type: New Feature
>Reporter: Duncan Jones
>Assignee: Duncan Jones
>
> The {{RandomStringUtils}} class will be deprecated in Commons Lang and reborn
> in Commons Text.
> Because the original class has some complicated parameters and potentially
> unnecessary capabilities, I'll simplify as I move it across. I'll also ensure
> the class plays nicely with Unicode characters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TEXT-34) Add class to generate random strings
[
https://issues.apache.org/jira/browse/TEXT-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15764980#comment-15764980
]
Duncan Jones commented on TEXT-34:
--
I'm still not completely sold on the {{withDigits()}} convenience method,
although I can understand where you're coming from. My concern lies in the fact
that it's not particularly scalable and also doesn't intrinsically make it
clear what happens when you chain them together.
Would {{withDigits().withNumbers()}} give you just numbers or would they
combine to be alphanumeric? How many more of these would we want/need to have?
Maybe I can find a way to draw more attention to a series of built-in
predicates. Nicer naming might help, I guess {{DIGIT_PREDICATE}} is a bit
unwieldy.
To some extent, I don't have a whole lot of sympathy for people who explore an
API using auto-complete rather than reading the documentation :-)
> Add class to generate random strings
>
>
> Key: TEXT-34
> URL: https://issues.apache.org/jira/browse/TEXT-34
> Project: Commons Text
> Issue Type: New Feature
>Reporter: Duncan Jones
>Assignee: Duncan Jones
>
> The {{RandomStringUtils}} class will be deprecated in Commons Lang and reborn
> in Commons Text.
> Because the original class has some complicated parameters and potentially
> unnecessary capabilities, I'll simplify as I move it across. I'll also ensure
> the class plays nicely with Unicode characters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TEXT-34) Add class to generate random strings
[
https://issues.apache.org/jira/browse/TEXT-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15763499#comment-15763499
]
Duncan Jones commented on TEXT-34:
--
{quote}
I'd suggest adding more methods like {{withRange(char, char)}}
{quote}
I really like that syntax. I think I might remove {{withMinimum/Maximum}} in
favour of {{withinRange(int, int)}}. It also avoids the issue of deferring the
{{min <= max}} check until {{build()}} is called.
{quote}
... {{withDigits()}} or {{withLetter()}} to make common cases easier.
{quote}
Did you notice the fields I defined? It means you can do:
{code:java}
import static org.apache.commons.text.RandomStringBuilder.DIGIT_PREDICATE;
...
String str = new
RandomStringBuilder().ofLength(5000).filteredBy(DIGIT_PREDICATE).build();
{code}
{quote}
Regarding the filter, I wonder if it would be worth making the pending string
accessible to the test method. A test could thus be based on the previous
characters, and it would be possible to write a test avoiding the repetitions
characters.
{quote}
Nothing prevents a custom filter from saving the characters seen so far:
{code:java}
CodePointPredicate uniqueFilter = new CodePointPredicate() {
private final Set seen = new HashSet<>();
@Override
public boolean test(int codePoint) {
return seen.add(Integer.valueOf(codePoint));
}
};
String str = new
RandomStringBuilder().ofLength(26).withMinimum('A').withMaximum('Z')
.filteredBy(uniqueFilter)
.build();
System.out.println(str);
{code}
(Note: building this example showed me that I've messed up the random number
generation, so I'll add a test to catch that and will fix it in the pull
request)
If we think accessing the previous string is a common enough occurrence, we
could update {{CodePointPredicate}} so that it's passed an object representing
the current state of the string, allowing for queries. In your specific
example, I'm not sure that makes the code any better, since you would need to
repeatedly scan the string for each new character.
> Add class to generate random strings
>
>
> Key: TEXT-34
> URL: https://issues.apache.org/jira/browse/TEXT-34
> Project: Commons Text
> Issue Type: New Feature
>Reporter: Duncan Jones
>Assignee: Duncan Jones
>
> The {{RandomStringUtils}} class will be deprecated in Commons Lang and reborn
> in Commons Text.
> Because the original class has some complicated parameters and potentially
> unnecessary capabilities, I'll simplify as I move it across. I'll also ensure
> the class plays nicely with Unicode characters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (RNG-33) Consider adding convenience methods to UniformRandomProvider
[
https://issues.apache.org/jira/browse/RNG-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15762504#comment-15762504
]
Duncan Jones commented on RNG-33:
-
OK, looks like most bases are covered already.
What about {{static byte[] nextBytes(int count)}}? It's a minor inconvenience,
but it always frustrated me that I had to generate a byte array before filling
it.
> Consider adding convenience methods to UniformRandomProvider
>
>
> Key: RNG-33
> URL: https://issues.apache.org/jira/browse/RNG-33
> Project: Commons RNG
> Issue Type: Improvement
>Affects Versions: 1.0
>Reporter: Duncan Jones
>Priority: Minor
>
> Commons Lang maintains a class called
> [{{RandomUtils}}|http://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/RandomUtils.html],
> which supplements the methods offered by {{java.util.Random}}.
> If similar methods were added to {{UniformRandomProvider}}, we could
> deprecate {{RandomUtils}} in favour of using RNG.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TEXT-34) Add class to generate random strings
[
https://issues.apache.org/jira/browse/TEXT-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15762353#comment-15762353
]
Duncan Jones commented on TEXT-34:
--
I feel like the school boy who wasn't listening... :-) Which conversation was
this?
Do we just go ahead and create a dependency on RNG and use
{{UniformRandomProvider}} wherever we need randomness?
> Add class to generate random strings
>
>
> Key: TEXT-34
> URL: https://issues.apache.org/jira/browse/TEXT-34
> Project: Commons Text
> Issue Type: New Feature
>Reporter: Duncan Jones
>Assignee: Duncan Jones
>
> The {{RandomStringUtils}} class will be deprecated in Commons Lang and reborn
> in Commons Text.
> Because the original class has some complicated parameters and potentially
> unnecessary capabilities, I'll simplify as I move it across. I'll also ensure
> the class plays nicely with Unicode characters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TEXT-35) Unfinished class Javadoc for CosineDistance
Duncan Jones created TEXT-35:
Summary: Unfinished class Javadoc for CosineDistance
Key: TEXT-35
URL: https://issues.apache.org/jira/browse/TEXT-35
Project: Commons Text
Issue Type: Bug
Reporter: Duncan Jones
Priority: Minor
The second paragraph for the CosineDistance class documentation contains an
unfinished sentence.
{quote}
It utilizes the CosineSimilarity to compute the distance. Character
sequences are converted into vectors through a simple tokenizer that works with
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TEXT-34) Add class to generate random strings
[
https://issues.apache.org/jira/browse/TEXT-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15762116#comment-15762116
]
Duncan Jones commented on TEXT-34:
--
Thanks for the feedback Emmanuel. It's great you have a real life use case we
can examine.
One concern I had about adding that functionality was it didn't seem very
text-oriented to me. It is essentially selecting random objects from an array;
the objects just happen to be {{char}} or {{int}} values.
The specific functionality you describe can be achieved with the filters, but I
appreciate that was only an example:
{code:java}
String licence = new
RandomStringBuilder().ofLength(20).withMinimum('A').withMaximum('Z')
.filteredBy(new CodePointPredicate() {
@Override
public boolean test(int codePoint) {
return codePoint != 'O' && codePoint != 'I';
}
}).build();
{code}
So, in short, it was a deliberate omission, but I forgot to kick off the
discussion about whether it was a good idea!
By the way, I'm not suggesting filters are an appropriate substitution for the
original functionality. There's no efficient way you can use filters to create
an arbitrary collection of characters. I'm questioning whether the original
functionality belongs in a text-processing component.
> Add class to generate random strings
>
>
> Key: TEXT-34
> URL: https://issues.apache.org/jira/browse/TEXT-34
> Project: Commons Text
> Issue Type: New Feature
>Reporter: Duncan Jones
>Assignee: Duncan Jones
>
> The {{RandomStringUtils}} class will be deprecated in Commons Lang and reborn
> in Commons Text.
> Because the original class has some complicated parameters and potentially
> unnecessary capabilities, I'll simplify as I move it across. I'll also ensure
> the class plays nicely with Unicode characters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (LANG-1078) -1, 0 or error for String/Array operations
[
https://issues.apache.org/jira/browse/LANG-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones closed LANG-1078.
--
Resolution: Not A Bug
Assignee: Duncan Jones
Fix Version/s: (was: Discussion)
I would suggest any further discussion is continued on the developer mailing
list.
> -1, 0 or error for String/Array operations
> --
>
> Key: LANG-1078
> URL: https://issues.apache.org/jira/browse/LANG-1078
> Project: Commons Lang
> Issue Type: Wish
> Components: lang.*
>Reporter: haiyang li
>Assignee: Duncan Jones
>
> what're design insights for below implementation:
> #1: SHOULD throw exception for negative index?
> {code:title= org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
> public static int indexOf(final boolean[] array, final boolean
> valueToFind, int startIndex) {
> if (ArrayUtils.isEmpty(array)) {
> return INDEX_NOT_FOUND;
> }
> if (startIndex < 0) {
> startIndex = 0;
> }
> for (int i = startIndex; i < array.length; i++) {
> if (valueToFind == array[i]) {
> return i;
> }
> }
> return INDEX_NOT_FOUND;
> }
> {code}
> #2, Why does StringUtils.indexOf("", "") return 0, not -1?
> first of all, "" is an empty String. '0' index doesn't exist in "". secondly,
> both null and "" strings are considered as none. I think it's inappropriate
> to say we found a none thing in position 0. so I suggest to return -1(not
> exists) to the index of any string in a null or "" string or null or "" empty
> string in any thing.
> (i read the java doc and a few jira tickets. but didn't find the discussion
> related to this kind of issue. so i created a new ticket).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TEXT-34) Add class to generate random strings
[
https://issues.apache.org/jira/browse/TEXT-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15761636#comment-15761636
]
Duncan Jones commented on TEXT-34:
--
I've uploaded this as a pull request to GitHub, to allow for easy reviewing:
https://github.com/apache/commons-text/pull/20/files.
Thoughts welcome, before I commit this to master. I opted for a builder
pattern, which seems quite an elegant approach to the problem (inspired by the
presence of a {{Builder}} interface in the project).
> Add class to generate random strings
>
>
> Key: TEXT-34
> URL: https://issues.apache.org/jira/browse/TEXT-34
> Project: Commons Text
> Issue Type: New Feature
>Reporter: Duncan Jones
>Assignee: Duncan Jones
>
> The {{RandomStringUtils}} class will be deprecated in Commons Lang and reborn
> in Commons Text.
> Because the original class has some complicated parameters and potentially
> unnecessary capabilities, I'll simplify as I move it across. I'll also ensure
> the class plays nicely with Unicode characters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TEXT-34) Add class to generate random strings
Duncan Jones created TEXT-34:
Summary: Add class to generate random strings
Key: TEXT-34
URL: https://issues.apache.org/jira/browse/TEXT-34
Project: Commons Text
Issue Type: New Feature
Reporter: Duncan Jones
Assignee: Duncan Jones
The {{RandomStringUtils}} class will be deprecated in Commons Lang and reborn
in Commons Text.
Because the original class has some complicated parameters and potentially
unnecessary capabilities, I'll simplify as I move it across. I'll also ensure
the class plays nicely with Unicode characters.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-833) ToStringBuilder should use StringBuilder
[
https://issues.apache.org/jira/browse/LANG-833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15759047#comment-15759047
]
Duncan Jones commented on LANG-833:
---
The documentation for {{ToStringBuilder}} makes no guarantees about
thread-safety. Do we need to preserve non-documented behaviour?
We could add another constructor that accepts a {{StringBuilder}}, then
internally only use a {{StringBuffer}} if the class is constructed with one.
> ToStringBuilder should use StringBuilder
>
>
> Key: LANG-833
> URL: https://issues.apache.org/jira/browse/LANG-833
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.1
>Reporter: Shevek
> Fix For: Patch Needed
>
>
> Rewriting as lang3 but still using StringBuffer (synchronized) looks like a
> missed opportunity. Please use StringBuilder.
> Suggest audit for uses of StringBuffer in lang3 overall. No cause for it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1043) isAllUpperCase should only check Alpha characters
[
https://issues.apache.org/jira/browse/LANG-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15759028#comment-15759028
]
Duncan Jones commented on LANG-1043:
Any complaints if I close this? Looks like we've reached consensus that the
current method behaves like it should. I feel there hasn't been a strong case
put forward for why we should add another method that checks only alphabetic
characters.
> isAllUpperCase should only check Alpha characters
> -
>
> Key: LANG-1043
> URL: https://issues.apache.org/jira/browse/LANG-1043
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.3.2
>Reporter: Frédéric JECKER
> Fix For: Discussion
>
> Attachments: LANG-1043.patch
>
>
> Currently, isAllUpperCase checks character by character if the current
> character is UpperCase or not using Character.isUpperCase().
> The problem is that characters like spaces aren't considered as uppercase
> characters.
> IMHO, isAllUpperCase should only check the state of alpha characters so that :
> - StringUtils.isAllUpperCase("ABC DEF GHI") = true (false currently)
> - StringUtils.isAllUpperCase("ABC / DEF") = true (false currently)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-771) DateUtils.ceiling does not behave correctly for dates on the boundaries
[
https://issues.apache.org/jira/browse/LANG-771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones updated LANG-771:
--
Description:
{{DateUtils.ceiling}} does not behave as expected for dates exactly on the
boundaries specified.
To be consistent with the name "ceiling", it follows that if a date is already
at its "ceiling", it should not be pushed any higher. Yet the current
implementation (and, it would appear, all implementations since its creation)
of {{DateUtils.ceiling}} push a value exactly on its ceiling to the next value.
Observe what happens if the following tests are added to
{{DateUtilsTest.testCeil()}}:
{code:java}
double double4 = 15.0;
assertEquals("ceiling double-4 failed",
double4,
Math.ceil(double4));
Date date4 = dateTimeParser.parse("March 30, 2003 01:10:00.000");
assertEquals("ceiling minute-4 failed",
date4,
DateUtils.ceiling(date4, Calendar.MINUTE));
{code}
The first assert passes, as Math.ceil behaves as it should (i.e.
Mail.ceil(15.0) = 15.0).
However, the second assert fails with:
{code}
ceiling minute-4 failed expected: but
was:
{code}
as the routine incorrectly (I believe) pushes the value to the next minute.
Either the method is incorrectly named ([as previously
suggested|https://issues.apache.org/jira/browse/LANG-434?focusedCommentId=12855836#comment-12855836])
or it should probably be corrected to be consistent with expected behaviour
(using Math.ceil as a benchmark).
If changing the behaviour of {{DateUtils.ceiling}} is perceived to have too
many flow-on effects (e.g. backwards compatibility issues) then perhaps it
should be renamed to {{DateUtils.ceil}} to make it consistent with the Math
class method name and to make the change in behaviour obvious (and perhaps also
have a {{DateUtils.floor}} as a synonym for {{DateUtils.truncate}}).
was:
DateUtils.ceiling does not behave as expected for dates exactly on the
boundaries specified.
To be consistent with the name "ceiling", it follows that if a date is already
at its "ceiling", it should not be pushed any higher. Yet the current
implementation (and, it would appear, all implementations since its creation)
of DateUtils.ceiling push a value exactly on its ceiling to the next value.
Observe what happens if the following tests are added to
DateUtilsTest.testCeil():
double double4 = 15.0;
assertEquals("ceiling double-4 failed",
double4,
Math.ceil(double4));
Date date4 = dateTimeParser.parse("March 30, 2003 01:10:00.000");
assertEquals("ceiling minute-4 failed",
date4,
DateUtils.ceiling(date4, Calendar.MINUTE));
The first assert passes, as Math.ceil behaves as it should (i.e.
Mail.ceil(15.0) = 15.0).
However, the second assert fails with:
ceiling minute-4 failed expected: but
was:
as the routine incorrectly (I believe) pushes the value to the next minute.
Either the method is incorrectly named ([as previously
suggested|https://issues.apache.org/jira/browse/LANG-434?focusedCommentId=12855836#comment-12855836])
or it should probably be corrected to be consistent with expected behaviour
(using Math.ceil as a benchmark).
If changing the behaviour of DateUtils.ceiling is perceived to have too many
flow-on effects (e.g. backwards compatibility issues) then perhaps it should be
renamed to DateUtils.ceil to make it consistent with the Math class method name
and to make the change in behaviour obvious (and perhaps also have a
DateUtils.floor as a synonym for DateUtils.truncate).
> DateUtils.ceiling does not behave correctly for dates on the boundaries
> ---
>
> Key: LANG-771
> URL: https://issues.apache.org/jira/browse/LANG-771
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.time.*
>Affects Versions: 3.0.1
> Environment: Windows XP Professional
> Java 1.6
>Reporter: Ryan Holmes
>Priority: Minor
> Fix For: Patch Needed
>
>
> {{DateUtils.ceiling}} does not behave as expected for dates exactly on the
> boundaries specified.
> To be consistent with the name "ceiling", it follows that if a date is
> already at its "ceiling", it should not be pushed any higher. Yet the
> current implementation (and, it would appear, all implementations since its
> creation) of {{DateUtils.ceiling}} push a value exactly on its ceiling to the
> next value.
> Observe what happens if the following tests are added to
> {{DateUtilsTest.testCeil()}}:
> {code:java}
> double double4 = 15.0;
> assertEquals("ceiling double-4 failed",
>
[jira] [Created] (LANG-1300) Clarify or improve behaviour of int-based methods in StringUtils
Duncan Jones created LANG-1300:
--
Summary: Clarify or improve behaviour of int-based methods in
StringUtils
Key: LANG-1300
URL: https://issues.apache.org/jira/browse/LANG-1300
Project: Commons Lang
Issue Type: Improvement
Components: lang.*
Affects Versions: 3.5
Reporter: Duncan Jones
Priority: Minor
Fix For: Discussion
The following methods use an {{int}} to represent a search character:
{code:java}
boolean contains(final CharSequence seq, final int searchChar)
int indexOf(final CharSequence seq, final int searchChar)
int indexOf(final CharSequence seq, final int searchChar, final int startPos)
int lastIndexOf(final CharSequence seq, final int searchChar)
int lastIndexOf(final CharSequence seq, final int searchChar, final int
startPos)
{code}
When I see an {{int}} representing a character, I tend to assume the method can
handle supplementary characters. However, the current behaviour of these
methods depends upon whether the {{CharSequence}} is a {{String}} or not.
{code:java}
StringBuilder builder = new StringBuilder();
builder.appendCodePoint(0x2070E);
System.out.println(StringUtils.lastIndexOf(builder, 0x2070E)); // -1
System.out.println(StringUtils.lastIndexOf(builder.toString(), 0x2070E)); // 0
{code}
The Javadoc for these methods are ambiguous on this point, stating:
{quote}
This method uses {{String.lastIndexOf(int)}} if possible.
{quote}
I think we should consider updating the {{CharSequenceUtils}} methods used by
this class to convert all {{CharSequence}} parameters to strings, enabling full
code point support. The docs could be updated to make this crystal clear.
There is a question of whether this breaks backwards compatibility.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (LANG-1299) Add method for converting string to an array of code points
[
https://issues.apache.org/jira/browse/LANG-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones closed LANG-1299.
--
Resolution: Implemented
Assignee: Duncan Jones
Fix Version/s: 3.6
{quote}
Repository: commons-lang
Updated Branches:
refs/heads/master 855a52385 -> 600eb9eb9
LANG-1299 - Add method for converting string to an array of code points
Project: http://git-wip-us.apache.org/repos/asf/commons-lang/repo
Commit: http://git-wip-us.apache.org/repos/asf/commons-lang/commit/600eb9eb
Tree: http://git-wip-us.apache.org/repos/asf/commons-lang/tree/600eb9eb
Diff: http://git-wip-us.apache.org/repos/asf/commons-lang/diff/600eb9eb
{quote}
> Add method for converting string to an array of code points
> ---
>
> Key: LANG-1299
> URL: https://issues.apache.org/jira/browse/LANG-1299
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.5
>Reporter: Duncan Jones
>Assignee: Duncan Jones
>Priority: Minor
> Fix For: 3.6
>
>
> Java 7 doesn't offer a method for converting a string to an array of code
> points. This might be something we could add to {{StringUtils}}.
> {code:java}
> int[] codePoints = StringUtils.toCodePointArray(someString);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1295) ArrayUtils.toArray(T... items) has unsafe use of varargs
[
https://issues.apache.org/jira/browse/LANG-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15758385#comment-15758385
]
Duncan Jones commented on LANG-1295:
The only solution I can think of here is to deprecate the original method and
instead offer:
{code:java}
@SafeVarargs
public static T[] toArrayOf(Class clazz, final T... items) {
if (items == null) {
return null;
}
@SuppressWarnings("unchecked")
T[] result = (T[]) Array.newInstance(clazz, items.length);
System.arraycopy(items, 0, result, 0, items.length);
return result;
}
{code}
I believe this new method is safe, since it only relies on the items being of
type {{T}}, but doesn't care whether {{items}} is a {{T[]}}.
Thoughts and comments on this issue very welcome!
> ArrayUtils.toArray(T... items) has unsafe use of varargs
>
>
> Key: LANG-1295
> URL: https://issues.apache.org/jira/browse/LANG-1295
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.5
>Reporter: Duncan Jones
>Priority: Critical
>
> {{ArrayUtils.toArray(T... items)}} is marked as {{@SafeVarargs}}, but I
> suspect the use of the varargs is unsafe.
> An example, drawn heavily from [this StackOverflow
> answer|http://stackoverflow.com/a/14252221/474189], demonstrates this:
> {code:java}
> static T[] arrayOfTwo(T a, T b) {
> return ArrayUtils.toArray(a, b);
> }
> @Test
> public void testBadVarArgs() throws Exception {
> @SuppressWarnings("unused") // Need to assign to trigger exception
> String[] result = arrayOfTwo("foo", "bar");
> }
> {code}
> the above code throws an exception: {{java.lang.ClassCastException:
> [Ljava.lang.Object; cannot be cast to [Ljava.lang.String;}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1299) Add method for converting string to an array of code points
[
https://issues.apache.org/jira/browse/LANG-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15757763#comment-15757763
]
Duncan Jones commented on LANG-1299:
Example implementation:
{code:java}
public static int[] toCodePointArray(String s) {
int[] result = new int[s.codePointCount(0, s.length())];
int index = 0;
for (int i = 0; i < result.length; i++) {
result[i] = s.codePointAt(index);
index += Character.charCount(result[i]);
}
return result;
}
{code}
> Add method for converting string to an array of code points
> ---
>
> Key: LANG-1299
> URL: https://issues.apache.org/jira/browse/LANG-1299
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.5
>Reporter: Duncan Jones
>Priority: Minor
>
> Java 7 doesn't offer a method for converting a string to an array of code
> points. This might be something we could add to {{StringUtils}}.
> {code:java}
> int[] codePoints = StringUtils.toCodePointArray(someString);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (LANG-1299) Add method for converting string to an array of code points
Duncan Jones created LANG-1299:
--
Summary: Add method for converting string to an array of code
points
Key: LANG-1299
URL: https://issues.apache.org/jira/browse/LANG-1299
Project: Commons Lang
Issue Type: Improvement
Components: lang.*
Affects Versions: 3.5
Reporter: Duncan Jones
Priority: Minor
Java 7 doesn't offer a method for converting a string to an array of code
points. This might be something we could add to {{StringUtils}}.
{code:java}
int codePoints = StringUtils.toCodePointArray(someString);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1299) Add method for converting string to an array of code points
[
https://issues.apache.org/jira/browse/LANG-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones updated LANG-1299:
---
Description:
Java 7 doesn't offer a method for converting a string to an array of code
points. This might be something we could add to {{StringUtils}}.
{code:java}
int[] codePoints = StringUtils.toCodePointArray(someString);
{code}
was:
Java 7 doesn't offer a method for converting a string to an array of code
points. This might be something we could add to {{StringUtils}}.
{code:java}
int codePoints = StringUtils.toCodePointArray(someString);
{code}
> Add method for converting string to an array of code points
> ---
>
> Key: LANG-1299
> URL: https://issues.apache.org/jira/browse/LANG-1299
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.5
>Reporter: Duncan Jones
>Priority: Minor
>
> Java 7 doesn't offer a method for converting a string to an array of code
> points. This might be something we could add to {{StringUtils}}.
> {code:java}
> int[] codePoints = StringUtils.toCodePointArray(someString);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1298) Add methods to RandomUtils that accept source of randomness
[
https://issues.apache.org/jira/browse/LANG-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15756502#comment-15756502
]
Duncan Jones commented on LANG-1298:
I've created RNG-33 to suggest adding similar convenience methods to RNG. If
that is implemented, I would agree we should deprecate {{RandomUtils}}.
> Add methods to RandomUtils that accept source of randomness
> ---
>
> Key: LANG-1298
> URL: https://issues.apache.org/jira/browse/LANG-1298
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Reporter: Duncan Jones
>Priority: Minor
>
> We should add overloads to {{RandomUtils}} that accept a {{Random}} instance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (RNG-33) Consider adding convenience methods to UniformRandomProvider
Duncan Jones created RNG-33:
---
Summary: Consider adding convenience methods to
UniformRandomProvider
Key: RNG-33
URL: https://issues.apache.org/jira/browse/RNG-33
Project: Commons RNG
Issue Type: Improvement
Affects Versions: 1.0
Reporter: Duncan Jones
Priority: Minor
Commons Lang maintains a class called
[{{RandomUtils}}|http://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/RandomUtils.html],
which supplements the methods offered by {{java.util.Random}}.
If similar methods were added to {{UniformRandomProvider}}, we could deprecate
{{RandomUtils}} in favour of using RNG.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (LANG-1298) Add methods to RandomUtils that accept source of randomness
Duncan Jones created LANG-1298:
--
Summary: Add methods to RandomUtils that accept source of
randomness
Key: LANG-1298
URL: https://issues.apache.org/jira/browse/LANG-1298
Project: Commons Lang
Issue Type: Improvement
Components: lang.*
Reporter: Duncan Jones
Priority: Minor
We should add overloads to {{RandomUtils}} that accept a {{Random}} instance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (LANG-1286) RandomStringUtils random method can overflow and return characters outside of specified range
[
https://issues.apache.org/jira/browse/LANG-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones closed LANG-1286.
--
Resolution: Fixed
Assignee: Duncan Jones
Fix Version/s: 3.6
Fixed in commit 7f7fa03ea.
The class needs an overhaul to make better use of the code point methods in
{{Character}}. I'll work on that in future commits.
{quote}
Repository: commons-lang
Updated Branches:
refs/heads/master 35c27d025 -> 7f7fa03ea
Fix for LANG-1286: RandomStringUtils random method can overflow...
Project: http://git-wip-us.apache.org/repos/asf/commons-lang/repo
Commit: http://git-wip-us.apache.org/repos/asf/commons-lang/commit/f643b4fa
Tree: http://git-wip-us.apache.org/repos/asf/commons-lang/tree/f643b4fa
Diff: http://git-wip-us.apache.org/repos/asf/commons-lang/diff/f643b4fa
{quote}
> RandomStringUtils random method can overflow and return characters outside of
> specified range
> -
>
> Key: LANG-1286
> URL: https://issues.apache.org/jira/browse/LANG-1286
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.5
>Reporter: Duncan Jones
>Assignee: Duncan Jones
> Fix For: 3.6
>
>
> {{RandomStringUtils.random()}} can overflow and return characters that are
> outside the range specified by the {{start}} and {{end}} parameters. This is
> because it casts a random integer in the range {{[start,end)}} to a
> character, without checking if this will overflow.
> Example failing test case:
> {code}
> @Test
> public void testCharOverflow() throws Exception {
> int start = 65535;
> int end = Integer.MAX_VALUE;
>
> @SuppressWarnings("serial")
> Random fixedRandom = new Random() {
> @Override
> public int nextInt(int n) {
> // Prevents selection of 'start' as the character
> return 1;
> }
> };
>
> String result = RandomStringUtils.random(1, start, end, false, false,
> null, fixedRandom);
> char c = result.charAt(0);
> assertTrue(c >= start && c < end);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1295) ArrayUtils.toArray(T... items) has unsafe use of varargs
[
https://issues.apache.org/jira/browse/LANG-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15747364#comment-15747364
]
Duncan Jones commented on LANG-1295:
Agreed, but the bigger question on this issue and LANG-1296 is can we fix the
underlying problem and, if not, how best to cope with that.
> ArrayUtils.toArray(T... items) has unsafe use of varargs
>
>
> Key: LANG-1295
> URL: https://issues.apache.org/jira/browse/LANG-1295
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.5
>Reporter: Duncan Jones
>Priority: Critical
>
> {{ArrayUtils.toArray(T... items)}} is marked as {{@SafeVarargs}}, but I
> suspect the use of the varargs is unsafe.
> An example, drawn heavily from [this StackOverflow
> answer|http://stackoverflow.com/a/14252221/474189], demonstrates this:
> {code:java}
> static T[] arrayOfTwo(T a, T b) {
> return ArrayUtils.toArray(a, b);
> }
> @Test
> public void testBadVarArgs() throws Exception {
> @SuppressWarnings("unused") // Need to assign to trigger exception
> String[] result = arrayOfTwo("foo", "bar");
> }
> {code}
> the above code throws an exception: {{java.lang.ClassCastException:
> [Ljava.lang.Object; cannot be cast to [Ljava.lang.String;}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (LANG-872) EqualsBuilder methods append(Object[],Object[]) and append(Object,Object) treats array class dirrerently
[
https://issues.apache.org/jira/browse/LANG-872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones closed LANG-872.
-
Resolution: Not A Problem
Assignee: Duncan Jones
Fix Version/s: (was: Discussion)
I've added an explanation to the Javadoc to explain how
{{append(Object[],Object[])}} works. I think that's sufficient to resolve this
issue.
Please re-open and comment if you disagree!.
{quote}
Repository: commons-lang
Updated Branches:
refs/heads/master 31fcd3bd8 -> f13d18cff
Javadoc change to address LANG-872.
Javadocs for append(Object[],Object[]) updated to indicate it only
compares the contents of the arrays, not the type of the arrays.
Project: http://git-wip-us.apache.org/repos/asf/commons-lang/repo
Commit: http://git-wip-us.apache.org/repos/asf/commons-lang/commit/f13d18cf
Tree: http://git-wip-us.apache.org/repos/asf/commons-lang/tree/f13d18cf
Diff: http://git-wip-us.apache.org/repos/asf/commons-lang/diff/f13d18cf
{quote}
> EqualsBuilder methods append(Object[],Object[]) and append(Object,Object)
> treats array class dirrerently
>
>
> Key: LANG-872
> URL: https://issues.apache.org/jira/browse/LANG-872
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.builder.*
>Affects Versions: 2.6, 3.1
>Reporter: Algirdas Raščius
>Assignee: Duncan Jones
>Priority: Minor
> Attachments: commons-lang3-LANG-872.patch
>
>
> Method {{EqualsBuilder.append(Object[],Object[])}} ignores classes of passed
> arrays and returns true if contents of both arrays are equal.
> Method {{EqualsBuilder.append(Object,Object)}} returns false immediately if
> types of passed array arguments are different.
> For example:
> {code}
> public void testEqualsArrays() {
> Object[] aArray = new Object[] {"Value"};
> Object[] bArray = new String[] {"Value"};
> boolean compareAsArrays = new EqualsBuilder().append(aArray,
> bArray).isEquals();
> // compareAsArrays is true
> Object aObj = aArray;
> Object bObj = bArray;
> boolean compareAsObjects = new EqualsBuilder().append(aObj,
> bObj).isEquals();
> // compareAsObjects is false
> assertTrue(compareAsArrays == compareAsObjects); //Fails
> }
> {code}
> Results of both methods should be consistent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (LANG-1056) StringEscapeUtils.unescapeHtml4 java.lang.IllegalArgumentException
[
https://issues.apache.org/jira/browse/LANG-1056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones closed LANG-1056.
--
Resolution: Duplicate
Assignee: Duncan Jones
I agree, seems an exact duplicate. I'm closing it as such.
> StringEscapeUtils.unescapeHtml4 java.lang.IllegalArgumentException
> --
>
> Key: LANG-1056
> URL: https://issues.apache.org/jira/browse/LANG-1056
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.3.2
> Environment: Ubuntu 64
>Reporter: Jakub
>Assignee: Duncan Jones
>
> When I try to unescape
> {code:java}
> String test = "test �";
> StringEscapeUtils.unescapeHtml4(test);
> {code}
> I got :
> {noformat}
> java.lang.IllegalArgumentException
> at java.lang.Character.toChars(Character.java:4982)
> at
> org.apache.commons.lang3.text.translate.NumericEntityUnescaper.translate(NumericEntityUnescaper.java:128)
> at
> org.apache.commons.lang3.text.translate.AggregateTranslator.translate(AggregateTranslator.java:52)
> at
> org.apache.commons.lang3.text.translate.CharSequenceTranslator.translate(CharSequenceTranslator.java:85)
> at
> org.apache.commons.lang3.text.translate.CharSequenceTranslator.translate(CharSequenceTranslator.java:59)
> at
> org.apache.commons.lang3.StringEscapeUtils.unescapeHtml4(StringEscapeUtils.java:627)
> at unescapeHtml4Test.Main.main(Main.java:10)
> {noformat}
> It is a bug or not? Method should return "test �" without exception
> or not?.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1148) StringUtils.isBlank does not work correctly with strings containing non-breakable whitespace characters
[
https://issues.apache.org/jira/browse/LANG-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15742198#comment-15742198
]
Duncan Jones commented on LANG-1148:
FYI - [~pascalschumacher] has updated the Javadoc for this method to make it
clear which test is used:
{quote}
Checks if a CharSequence is empty (""), null or whitespace only.
Whitespace is defined by {{Character.isWhitespace(char)}}.
{quote}
Since the test is now clearly defined and there isn't much appetite for
breaking backwards compatibility, I vote we don't attempt to fix this.
> StringUtils.isBlank does not work correctly with strings containing
> non-breakable whitespace characters
> ---
>
> Key: LANG-1148
> URL: https://issues.apache.org/jira/browse/LANG-1148
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 2.6
> Environment: Windows 8.1 x64 , Java 1.8, but can be reproduced in any
> environment with an official Oracle JDK or JRE
>Reporter: Aleksandr Bogush
>Priority: Minor
> Labels: test
> Fix For: 4.0
>
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> isBlank uses java.lang.Character.isWhitespace(char ch) method, which has not
> been changed for a long time for backward compatibility. Over the years
> non-breakable whitespaces were introduced and are now used in some cases. So
> if we execute the code
> {noformat}org.apache.commons.lang.StringUtils.isBlank("\u00A0"); //returns
> false
> org.apache.commons.lang.StringUtils.isBlank("\u202F"); //returns false
> org.apache.commons.lang.StringUtils.isBlank("\u2007"); //returns
> false{noformat}
> we will get 3 falses, which is not right, according to StringUtils.isBlank
> documentation: {noformat}Checks if a String is whitespace, empty ("") or
> null.{noformat}
> I suggest fixing it by using regex pattern {noformat}"^[\\p{Z}]*$"{noformat}
> instead of looping over the string characters. I know that it is a bit less
> fast than it works now, but it will work much more correctly. I would be glad
> to do it myself and write unit tests for it, so if you want, please contact
> me via email alex.boh...@gmail.com
> Additionally, I would modify the documentation itself too, because it does
> not tell that it returns true when meeting multiple whitespaces.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (LANG-1296) ArrayUtils.addAll() has unsafe use of varargs
Duncan Jones created LANG-1296:
--
Summary: ArrayUtils.addAll() has unsafe use of varargs
Key: LANG-1296
URL: https://issues.apache.org/jira/browse/LANG-1296
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.5
Reporter: Duncan Jones
Priority: Critical
{{ArrayUtils.addAll()}} is marked as {{@SafeVarargs}}, but I suspect the use of
the varargs is unsafe.
An example, drawn heavily from [this StackOverflow
answer|http://stackoverflow.com/a/14252221/474189], demonstrates this:
{code:java}
static T[] arrayOfTwo(T a, T b) {
return ArrayUtils.addAll(null, a, b);
}
@Test
public void testBadVarArgs() throws Exception {
@SuppressWarnings("unused") // Need to assign to trigger exception
String[] result = arrayOfTwo("foo", "bar");
}
{code}
the above code throws an exception: {{java.lang.ClassCastException:
[Ljava.lang.Object; cannot be cast to [Ljava.lang.String;}}.
Here, the {{null}} input array causes the method to return a clone of the
vararg array. This is what triggers the problem.
I faced a similar issue when adding the {{ArrayUtils.insert(...)}} methods and
I solved it by returning {{null}} if the input array is {{null}}. We can't do
this here without breaking behaviour.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1295) ArrayUtils.toArray(T... items) has unsafe use of varargs
[
https://issues.apache.org/jira/browse/LANG-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones updated LANG-1295:
---
Summary: ArrayUtils.toArray(T... items) has unsafe use of varargs (was:
ArrayUtils has unsafe use of varargs, which are marked as safe)
> ArrayUtils.toArray(T... items) has unsafe use of varargs
>
>
> Key: LANG-1295
> URL: https://issues.apache.org/jira/browse/LANG-1295
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.5
>Reporter: Duncan Jones
>Priority: Critical
>
> {{ArrayUtils.toArray(T... items)}} is marked as {{@SafeVarargs}}, but I
> suspect the use of the varargs is unsafe.
> An example, drawn heavily from [this StackOverflow
> answer|http://stackoverflow.com/a/14252221/474189], demonstrates this:
> {code:java}
> static T[] arrayOfTwo(T a, T b) {
> return ArrayUtils.toArray(a, b);
> }
> @Test
> public void testBadVarArgs() throws Exception {
> @SuppressWarnings("unused") // Need to assign to trigger exception
> String[] result = arrayOfTwo("foo", "bar");
> }
> {code}
> the above code throws an exception: {{java.lang.ClassCastException:
> [Ljava.lang.Object; cannot be cast to [Ljava.lang.String;}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1295) ArrayUtils has unsafe use of varargs, which are marked as safe
[
https://issues.apache.org/jira/browse/LANG-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones updated LANG-1295:
---
Affects Version/s: 3.5
Description:
{{ArrayUtils.toArray(T... items)}} is marked as {{@SafeVarargs}}, but I suspect
the use of the varargs is unsafe.
An example, drawn heavily from [this StackOverflow
answer|http://stackoverflow.com/a/14252221/474189], demonstrates this:
{code:java}
static T[] arrayOfTwo(T a, T b) {
return ArrayUtils.toArray(a, b);
}
@Test
public void testBadVarArgs() throws Exception {
@SuppressWarnings("unused") // Need to assign to trigger exception
String[] result = arrayOfTwo("foo", "bar");
}
{code}
the above code throws an exception: {{java.lang.ClassCastException:
[Ljava.lang.Object; cannot be cast to [Ljava.lang.String;}}.
was:
{{ArrayUtils.toArray(T... items)}} is marked as {{@SafeVarargs}}, but I suspect
the use of the varargs is unsafe.
An example, drawn heavily from [this StackOverflow
answer|http://stackoverflow.com/a/14252221/474189], demonstrates this:
{code:java}
static T[] arrayOfTwo(T a, T b) {
return ArrayUtils.toArray(a, b);
}
@Test
public void testBadVarArgs() throws Exception {
@SuppressWarnings("unused") // Need to assign to trigger exception
String[] result = arrayOfTwo("foo", "bar");
}
{code}
the above code throws an exception: {{java.lang.ClassCastException:
[Ljava.lang.Object; cannot be cast to [Ljava.lang.String;}}.
The method {{ArrayUtils.addAll(null, a, b)}} looks unsafe for similar reasons.
However, {{ArrayUtils.removeElements(final T[] array, final T... values)}}
looks safe.
Unfortunately, this method seems to do exactly what you're not supposed to do
with varargs.
We may have to deprecate this and warn people off using it.
I'm going to create another issue for the {{addAll}} method, since the solution
(and discussion thereof) is likely to be different.
> ArrayUtils has unsafe use of varargs, which are marked as safe
> --
>
> Key: LANG-1295
> URL: https://issues.apache.org/jira/browse/LANG-1295
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.5
>Reporter: Duncan Jones
>Priority: Critical
>
> {{ArrayUtils.toArray(T... items)}} is marked as {{@SafeVarargs}}, but I
> suspect the use of the varargs is unsafe.
> An example, drawn heavily from [this StackOverflow
> answer|http://stackoverflow.com/a/14252221/474189], demonstrates this:
> {code:java}
> static T[] arrayOfTwo(T a, T b) {
> return ArrayUtils.toArray(a, b);
> }
> @Test
> public void testBadVarArgs() throws Exception {
> @SuppressWarnings("unused") // Need to assign to trigger exception
> String[] result = arrayOfTwo("foo", "bar");
> }
> {code}
> the above code throws an exception: {{java.lang.ClassCastException:
> [Ljava.lang.Object; cannot be cast to [Ljava.lang.String;}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1295) ArrayUtils has unsafe use of varargs, which are marked as safe
[
https://issues.apache.org/jira/browse/LANG-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones updated LANG-1295:
---
Description:
{{ArrayUtils.toArray(T... items)}} is marked as {{@SafeVarargs}}, but I suspect
the use of the varargs is unsafe.
An example, drawn heavily from [this StackOverflow
answer|http://stackoverflow.com/a/14252221/474189], demonstrates this:
{code:java}
static T[] arrayOfTwo(T a, T b) {
return ArrayUtils.toArray(a, b);
}
@Test
public void testBadVarArgs() throws Exception {
@SuppressWarnings("unused") // Need to assign to trigger exception
String[] result = arrayOfTwo("foo", "bar");
}
{code}
the above code throws an exception: {{java.lang.ClassCastException:
[Ljava.lang.Object; cannot be cast to [Ljava.lang.String;}}.
The method {{ArrayUtils.addAll(null, a, b)}} looks unsafe for similar reasons.
However, {{ArrayUtils.removeElements(final T[] array, final T... values)}}
looks safe.
was:
{{ArrayUtils.addAll()}} is marked as {{@SafeVarargs}}, but I suspect the use of
the varargs is unsafe.
An example, drawn heavily from [this StackOverflow
answer|http://stackoverflow.com/a/14252221/474189], demonstrates this:
{code:java}
static T[] arrayOfTwo(T a, T b) {
return ArrayUtils.addAll(null, a, b);
}
@Test
public void testBadVarArgs() throws Exception {
@SuppressWarnings("unused") // Need to assign to trigger exception
String[] result = arrayOfTwo("foo", "bar");
}
{code}
the above code throws an exception: {{java.lang.ClassCastException:
[Ljava.lang.Object; cannot be cast to [Ljava.lang.String;}}.
The method {{ArrayUtils.toArray(final T... items)}} looks unsafe for the same
reason. However, {{ArrayUtils.removeElements(final T[] array, final T...
values)}} looks safe.
> ArrayUtils has unsafe use of varargs, which are marked as safe
> --
>
> Key: LANG-1295
> URL: https://issues.apache.org/jira/browse/LANG-1295
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Reporter: Duncan Jones
>Priority: Critical
>
> {{ArrayUtils.toArray(T... items)}} is marked as {{@SafeVarargs}}, but I
> suspect the use of the varargs is unsafe.
> An example, drawn heavily from [this StackOverflow
> answer|http://stackoverflow.com/a/14252221/474189], demonstrates this:
> {code:java}
> static T[] arrayOfTwo(T a, T b) {
> return ArrayUtils.toArray(a, b);
> }
> @Test
> public void testBadVarArgs() throws Exception {
> @SuppressWarnings("unused") // Need to assign to trigger exception
> String[] result = arrayOfTwo("foo", "bar");
> }
> {code}
> the above code throws an exception: {{java.lang.ClassCastException:
> [Ljava.lang.Object; cannot be cast to [Ljava.lang.String;}}.
> The method {{ArrayUtils.addAll(null, a, b)}} looks unsafe for similar
> reasons. However, {{ArrayUtils.removeElements(final T[] array, final T...
> values)}} looks safe.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (LANG-660) Add methods to insert arrays into arrays at an index
[
https://issues.apache.org/jira/browse/LANG-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15741988#comment-15741988
]
Duncan Jones edited comment on LANG-660 at 12/12/16 2:08 PM:
-
Thanks to everyone for their input into this. In the end, I wrote fresh
implementations of these methods as I felt happier using {{arrayCopy}} rather
than some of the object-based methods in the supplied patches.
I've also deprecated the {{add(array, index, element)}} methods, which are now
superseded by the new methods.
In order to keep the behaviour of these new methods consistent with one
another, while avoiding creating an unsafe use of varargs, I've opted to change
the handling of {{null}} array inputs. I've referred to this in the deprecation
comments.
Thoughts on this welcome.
{quote}
Repository: commons-lang
Updated Branches:
refs/heads/master 0136218fa -> 795fe5d86
Added new vararg methods to insert values into an array at an index.
This implements LANG-660. This commit also deprecates the add() methods
that inserted a single value into an array at an index.
Project: http://git-wip-us.apache.org/repos/asf/commons-lang/repo
Commit: http://git-wip-us.apache.org/repos/asf/commons-lang/commit/795fe5d8
Tree: http://git-wip-us.apache.org/repos/asf/commons-lang/tree/795fe5d8
Diff: http://git-wip-us.apache.org/repos/asf/commons-lang/diff/795fe5d8
{quote}
was (Author: dmjones500):
Thanks to everyone for their input into this. In the end, I wrote fresh
implementations of these methods as I felt happier using {{arrayCopy}} rather
than some of the object-based methods in the supplied patches.
I've also deprecated the {{add(array, index, element)}} methods, which are now
superseded by the new methods.
In order to keep the behaviour of these new methods consistent with one
another, while avoiding creating an unsafe use of varargs, I've opted to change
the handling of {{null}} array inputs. I've referred to this in the deprecation
comments.
Thoughts on this welcome.
Repository: commons-lang
Updated Branches:
refs/heads/master 0136218fa -> 795fe5d86
Added new vararg methods to insert values into an array at an index.
This implements LANG-660. This commit also deprecates the add() methods
that inserted a single value into an array at an index.
Project: http://git-wip-us.apache.org/repos/asf/commons-lang/repo
Commit: http://git-wip-us.apache.org/repos/asf/commons-lang/commit/795fe5d8
Tree: http://git-wip-us.apache.org/repos/asf/commons-lang/tree/795fe5d8
Diff: http://git-wip-us.apache.org/repos/asf/commons-lang/diff/795fe5d8
> Add methods to insert arrays into arrays at an index
>
>
> Key: LANG-660
> URL: https://issues.apache.org/jira/browse/LANG-660
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 2.5
>Reporter: Aaron Digulla
>Assignee: Duncan Jones
>Priority: Minor
> Fix For: 3.6
>
> Attachments: ArrayUtils.txt, ArrayUtilsAddTest.txt,
> ArrayUtilsAddTest_addAll.patch, ArrayUtils_addAll.patch
>
>
> Please add methods with this signature: ArrayUtils.addAll(int[] target, int
> index, int[] source) (i.e. insert an array into an array at a certain
> position).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (LANG-660) Add methods to insert arrays into arrays at an index
[
https://issues.apache.org/jira/browse/LANG-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones closed LANG-660.
-
Resolution: Implemented
Fix Version/s: (was: Review Patch)
3.6
Thanks to everyone for their input into this. In the end, I wrote fresh
implementations of these methods as I felt happier using {{arrayCopy}} rather
than some of the object-based methods in the supplied patches.
I've also deprecated the {{add(array, index, element)}} methods, which are now
superseded by the new methods.
In order to keep the behaviour of these new methods consistent with one
another, while avoiding creating an unsafe use of varargs, I've opted to change
the handling of {{null}} array inputs. I've referred to this in the deprecation
comments.
Thoughts on this welcome.
Repository: commons-lang
Updated Branches:
refs/heads/master 0136218fa -> 795fe5d86
Added new vararg methods to insert values into an array at an index.
This implements LANG-660. This commit also deprecates the add() methods
that inserted a single value into an array at an index.
Project: http://git-wip-us.apache.org/repos/asf/commons-lang/repo
Commit: http://git-wip-us.apache.org/repos/asf/commons-lang/commit/795fe5d8
Tree: http://git-wip-us.apache.org/repos/asf/commons-lang/tree/795fe5d8
Diff: http://git-wip-us.apache.org/repos/asf/commons-lang/diff/795fe5d8
> Add methods to insert arrays into arrays at an index
>
>
> Key: LANG-660
> URL: https://issues.apache.org/jira/browse/LANG-660
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 2.5
>Reporter: Aaron Digulla
>Assignee: Duncan Jones
>Priority: Minor
> Fix For: 3.6
>
> Attachments: ArrayUtils.txt, ArrayUtilsAddTest.txt,
> ArrayUtilsAddTest_addAll.patch, ArrayUtils_addAll.patch
>
>
> Please add methods with this signature: ArrayUtils.addAll(int[] target, int
> index, int[] source) (i.e. insert an array into an array at a certain
> position).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (LANG-1295) ArrayUtils has unsafe use of varargs, which are marked as safe
Duncan Jones created LANG-1295:
--
Summary: ArrayUtils has unsafe use of varargs, which are marked as
safe
Key: LANG-1295
URL: https://issues.apache.org/jira/browse/LANG-1295
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Reporter: Duncan Jones
Priority: Critical
{{ArrayUtils.addAll()}} is marked as {{@SafeVarargs}}, but I suspect the use of
the varargs is unsafe.
An example, drawn heavily from [this StackOverflow
answer|http://stackoverflow.com/a/14252221/474189], demonstrates this:
{code:java}
static T[] arrayOfTwo(T a, T b) {
return ArrayUtils.addAll(null, a, b);
}
@Test
public void testBadVarArgs() throws Exception {
@SuppressWarnings("unused") // Need to assign to trigger exception
String[] result = arrayOfTwo("foo", "bar");
}
{code}
the above code throws an exception: {{java.lang.ClassCastException:
[Ljava.lang.Object; cannot be cast to [Ljava.lang.String;}}.
The method {{ArrayUtils.toArray(final T... items)}} looks unsafe for the same
reason. However, {{ArrayUtils.removeElements(final T[] array, final T...
values)}} looks safe.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-903) Add XML implementation of ToStringStyle
[ https://issues.apache.org/jira/browse/LANG-903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duncan Jones updated LANG-903: -- Fix Version/s: (was: Review Patch) Removing the "review patch" tag, as there isn't a valid pull request to review. > Add XML implementation of ToStringStyle > --- > > Key: LANG-903 > URL: https://issues.apache.org/jira/browse/LANG-903 > Project: Commons Lang > Issue Type: Improvement > Components: lang.builder.* >Affects Versions: 3.1 >Reporter: Dave Hughes >Priority: Minor > Original Estimate: 24h > Remaining Estimate: 24h > > Lang 1.1 included a commented out implementation of XMLToStringStyle. This > disappeared in later versions, but is a very useful implementation. > (JSONToStringStyle would also be very nice) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (LANG-1294) WordUtils.capitalize() can't handle 1:M conversions
Duncan Jones created LANG-1294:
--
Summary: WordUtils.capitalize() can't handle 1:M conversions
Key: LANG-1294
URL: https://issues.apache.org/jira/browse/LANG-1294
Project: Commons Lang
Issue Type: Bug
Components: lang.text.*
Affects Versions: 3.5
Reporter: Duncan Jones
Some case conversions are not 1:1, for instance the German letter ß, which is
normally capitalised to 'SS'.
{code:java}
// Failing test
assertEquals("SS", WordUtils.capitalize("\u00DF"));
{code}
If we were using upper case and not title case, a solution such as the
following would work:
{code:java}
public static String capitalize(final String str, final char... delimiters) {
final int delimLen = delimiters == null ? -1 : delimiters.length;
if (StringUtils.isEmpty(str) || delimLen == 0) {
return str;
}
final StringBuffer buffer = new StringBuffer(str.length());
final char[] chars = str.toCharArray();
boolean capitalizeNext = true;
for (int i = 0; i < chars.length; i++) {
final char ch = chars[i];
if (isDelimiter(ch, delimiters)) {
capitalizeNext = true;
buffer.append(ch);
} else if (capitalizeNext) {
// Use ENGLISH locale to be backwards compatible with previous
releases, which
// used Character.toUpperCase()
buffer.append(String.valueOf(ch).toUpperCase(Locale.ENGLISH));
capitalizeNext = false;
} else {
buffer.append(ch);
}
}
return buffer.toString();
}
{code}
... but as we use title case, we can't use the String class to convert for us.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (LANG-1108) Function to replace multiple whitespaces by a character and trim
[
https://issues.apache.org/jira/browse/LANG-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones closed LANG-1108.
--
Resolution: Workaround
Assignee: Duncan Jones
Fix Version/s: (was: Discussion)
> Function to replace multiple whitespaces by a character and trim
>
>
> Key: LANG-1108
> URL: https://issues.apache.org/jira/browse/LANG-1108
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Reporter: Marco Janc
>Assignee: Duncan Jones
>
> In form applications where user can input data its very often not wished to
> have successive whitespace characters.
> A function that will replace multiple whitespace characters with a single
> space (or passed string/character) would be a nice feature since I myself
> repeat this method in many applications.
> Something like a shortcut for:
> value.replace("\\s+", " ").trim()
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1108) Function to replace multiple whitespaces by a character and trim
[
https://issues.apache.org/jira/browse/LANG-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15720630#comment-15720630
]
Duncan Jones commented on LANG-1108:
bq. A function that will replace multiple whitespace characters with a single
space (or passed string/character) would be a nice feature
[{{StringUtils.normalizeSpace()}}|http://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/StringUtils.html#normalizeSpace-java.lang.String-]
solves the first part of this problem. Do we need to solve the remainder?
> Function to replace multiple whitespaces by a character and trim
>
>
> Key: LANG-1108
> URL: https://issues.apache.org/jira/browse/LANG-1108
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Reporter: Marco Janc
> Fix For: Discussion
>
>
> In form applications where user can input data its very often not wished to
> have successive whitespace characters.
> A function that will replace multiple whitespace characters with a single
> space (or passed string/character) would be a nice feature since I myself
> repeat this method in many applications.
> Something like a shortcut for:
> value.replace("\\s+", " ").trim()
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1203) Separated annotations HashCodeExclude and EqualsExclude break the general contract for the hashCode method in java.lang.Object
[
https://issues.apache.org/jira/browse/LANG-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15720199#comment-15720199
]
Duncan Jones commented on LANG-1203:
There may be some reasons why excluding a value from a hash code makes sense.
See [this StackOverflow
question|http://stackoverflow.com/questions/4748211/java-equal-and-hashcode-based-on-different-fields]
for some discussion on that topic.
I think there's an argument for having two annotations:
* HashCodeExclude
* EqualsAndHashCodeExclude
I can't see how you can exclude something from equals and not from hash code.
> Separated annotations HashCodeExclude and EqualsExclude break the general
> contract for the hashCode method in java.lang.Object
> --
>
> Key: LANG-1203
> URL: https://issues.apache.org/jira/browse/LANG-1203
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.builder.*
>Affects Versions: 3.5
>Reporter: Frank Forster
>
> Since version 3.5-SNAPSHOT the annotations HashCodeExclude and EqualsExclude
> exist in component
> [lang.builder.*|https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=tree;f=src/main/java/org/apache/commons/lang3/builder;hb=HEAD].
> A separated handling of both annotations breaks the general contract for the
> hashCode method in java.lang.Object ("If two objects are equal according to
> the equals(Object) method, then calling the hashCode method on each of the
> two objects must produce the same integer result.").
> Rather there should exist only one exclude annotation dedicated to both
> methods, like 'EqualsAndHashCodeExclude'.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1282) StringUtils#normalizeSpace normalizeSpace should not replace non-breaking spaces with normal whitespace
[
https://issues.apache.org/jira/browse/LANG-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15719574#comment-15719574
]
Duncan Jones commented on LANG-1282:
I agree with this.
If {{Character.isWhitespace()}} is the test, then the Javadocs also need to be
updated to make this crystal clear. The current documentation waffles on a bit
about XML vs Java white-space conventions; IMO we should just concisely explain
what this method does.
> StringUtils#normalizeSpace normalizeSpace should not replace non-breaking
> spaces with normal whitespace
> ---
>
> Key: LANG-1282
> URL: https://issues.apache.org/jira/browse/LANG-1282
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: Pascal Schumacher
>
> As of 3.4 StringUtils#normalizeSpace does not normalize non-breaking
> whitespace anymore. Therefore it shouldn't replace a non-breaking whitespace
> white breaking whitespace, but both assertions succeed:
> {code}
> assertEquals("a b", StringUtils.normalizeSpace("a\u00A0b"));
> assertEquals("a b", StringUtils.normalizeSpace("a\u00A0 b"));
> {code}
> source: https://github.com/apache/commons-lang/pull/184
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1272) Array shuffling
[
https://issues.apache.org/jira/browse/LANG-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15719475#comment-15719475
]
Duncan Jones commented on LANG-1272:
Are you suggesting we expose the implementation from RNG via a new method
within Lang (perhaps using shading)? I could be in favour of that.
I'm trying to avoid the case where someone uses Lang for most of their array
manipulation needs, but needs to incorporate another Commons component to
shuffle it. IMO, having related capabilities split across different artifacts
would be frustrating to our users.
> Array shuffling
> ---
>
> Key: LANG-1272
> URL: https://issues.apache.org/jira/browse/LANG-1272
> Project: Commons Lang
> Issue Type: Improvement
>Reporter: Emmanuel Bourg
>Priority: Minor
> Fix For: 3.6
>
>
> I'd like to suggest the addition of methods in ArrayUtils shuffling the
> content of an array (Objects or primitives). This would be similar to the
> {{java.util.Collections.shuffle()}} methods.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (LANG-1292) WordUtils.wrap throws StringIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/LANG-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones closed LANG-1292.
--
Resolution: Fixed
> WordUtils.wrap throws StringIndexOutOfBoundsException
> -
>
> Key: LANG-1292
> URL: https://issues.apache.org/jira/browse/LANG-1292
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: Mirek Hankus
>Assignee: Duncan Jones
>Priority: Critical
> Fix For: 3.6
>
>
> Running following line of code results in StringIndexOutOfBoundsException (in
> 3.5 release)
> {code}
> WordUtils.wrap("aaa
> aaa
> a",70);
> {code}
> {code}
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> at java.lang.String.substring(String.java:1967)
> at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:328)
> at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:176)
> at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:100)
> at
> pl.netpr.commons.string.TextToolsTest.testWrap(TextToolsTest.java:245)
>
> {code}
> It worked fine with 3.4 releae.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1292) WordUtils.wrap throws StringIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/LANG-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones updated LANG-1292:
---
Fix Version/s: (was: Patch Needed)
3.6
> WordUtils.wrap throws StringIndexOutOfBoundsException
> -
>
> Key: LANG-1292
> URL: https://issues.apache.org/jira/browse/LANG-1292
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: Mirek Hankus
>Assignee: Duncan Jones
>Priority: Critical
> Fix For: 3.6
>
>
> Running following line of code results in StringIndexOutOfBoundsException (in
> 3.5 release)
> {code}
> WordUtils.wrap("aaa
> aaa
> a",70);
> {code}
> {code}
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> at java.lang.String.substring(String.java:1967)
> at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:328)
> at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:176)
> at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:100)
> at
> pl.netpr.commons.string.TextToolsTest.testWrap(TextToolsTest.java:245)
>
> {code}
> It worked fine with 3.4 releae.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1292) WordUtils.wrap throws StringIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/LANG-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15712850#comment-15712850
]
Duncan Jones commented on LANG-1292:
Thanks for reporting this. Now fixed:
{quote}
Repository: commons-lang
Updated Branches:
refs/heads/master 8c1a0d2ee -> a08ec31db
Fixes LANG-1292: WordUtils.wrap throws StringIndexOutOfBoundsException
Project: http://git-wip-us.apache.org/repos/asf/commons-lang/repo
Commit: http://git-wip-us.apache.org/repos/asf/commons-lang/commit/a08ec31d
Tree: http://git-wip-us.apache.org/repos/asf/commons-lang/tree/a08ec31d
Diff: http://git-wip-us.apache.org/repos/asf/commons-lang/diff/a08ec31d
{quote}
> WordUtils.wrap throws StringIndexOutOfBoundsException
> -
>
> Key: LANG-1292
> URL: https://issues.apache.org/jira/browse/LANG-1292
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: Mirek Hankus
>Assignee: Duncan Jones
>Priority: Critical
> Fix For: 3.6
>
>
> Running following line of code results in StringIndexOutOfBoundsException (in
> 3.5 release)
> {code}
> WordUtils.wrap("aaa
> aaa
> a",70);
> {code}
> {code}
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> at java.lang.String.substring(String.java:1967)
> at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:328)
> at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:176)
> at org.apache.commons.lang3.text.WordUtils.wrap(WordUtils.java:100)
> at
> pl.netpr.commons.string.TextToolsTest.testWrap(TextToolsTest.java:245)
>
> {code}
> It worked fine with 3.4 releae.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1272) Array shuffling
[
https://issues.apache.org/jira/browse/LANG-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15694279#comment-15694279
]
Duncan Jones commented on LANG-1272:
I think there is no harm in having two variations in different components,
which serve different needs.
The RNG implementation would be for people seeking faster or better
randomisation for their shuffling. The Lang implementation would use Java's
{{Random}} class and err on the side of simplicity.
I think both can coexist, what do you think?
> Array shuffling
> ---
>
> Key: LANG-1272
> URL: https://issues.apache.org/jira/browse/LANG-1272
> Project: Commons Lang
> Issue Type: Improvement
>Reporter: Emmanuel Bourg
>Priority: Minor
> Fix For: 3.6
>
>
> I'd like to suggest the addition of methods in ArrayUtils shuffling the
> content of an array (Objects or primitives). This would be similar to the
> {{java.util.Collections.shuffle()}} methods.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1272) Array shuffling
[
https://issues.apache.org/jira/browse/LANG-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15691319#comment-15691319
]
Duncan Jones commented on LANG-1272:
I think this could be a good fit for Lang. I would suggest we mimic the
behaviour of Collections.shuffle(), offering two methods (one with a source of
randomness and one without), and shuffling in a similar or identical manner.
bq. I want to be more involved in contribution to commons lang
That's good to hear. You might want to join the developer mailing list and post
a question about this enhancement there. Debate is easier over email than in
Jira comments.
> Array shuffling
> ---
>
> Key: LANG-1272
> URL: https://issues.apache.org/jira/browse/LANG-1272
> Project: Commons Lang
> Issue Type: Improvement
>Reporter: Emmanuel Bourg
>Priority: Minor
> Fix For: 3.6
>
>
> I'd like to suggest the addition of methods in ArrayUtils shuffling the
> content of an array (Objects or primitives). This would be similar to the
> {{java.util.Collections.shuffle()}} methods.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1283) RecursiveToStringStyle does not handle nested Maps correctly
[
https://issues.apache.org/jira/browse/LANG-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15691158#comment-15691158
]
Duncan Jones commented on LANG-1283:
Thanks for the test case patch, I've applied that in commit 41bc4cd02.
> RecursiveToStringStyle does not handle nested Maps correctly
>
>
> Key: LANG-1283
> URL: https://issues.apache.org/jira/browse/LANG-1283
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.builder.*
>Affects Versions: 3.4
>Reporter: Dominik Stadler
> Attachments:
> LANG_1283__Make_RecursiveToStringStyleTest_actually_test_the_correct_class.patch,
> RecursiveToStringTest.java
>
>
> When using {{RecursiveToStringStyle}} to include all member fields of all
> nested objects, it works for simple Maps, but as soon as I have Maps as
> values inside another Map, the contents is not included any more, but only a
> Object.toString() seems to be appended for the objects instead.
> A possible fix would be to add the following to RecursiveToStringStyle,
> although there might be a better way to fix this:
> {code}
> @Override
> protected void appendDetail(StringBuffer buffer, String fieldName,
> Map map) {
> appendClassName(buffer, map);
> appendIdentityHashCode(buffer, map);
> appendDetail(buffer, fieldName, map.entrySet());
> }
> {code}
> See the attached unit-test for a reproducer.
> Please also note that {{RecursiveToStringStyleTest}} in commons-lang seems to
> mostly work on the DefaultStyle instead, see
> https://github.com/apache/commons-lang/blob/master/src/test/java/org/apache/commons/lang3/builder/RecursiveToStringStyleTest.java#L38,
> only one method, {{testPerson()}}, seems to actually do a real test here!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (LANG-1286) RandomStringUtils random method can overflow and return characters outside of specified range
Duncan Jones created LANG-1286:
--
Summary: RandomStringUtils random method can overflow and return
characters outside of specified range
Key: LANG-1286
URL: https://issues.apache.org/jira/browse/LANG-1286
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.5
Reporter: Duncan Jones
{{RandomStringUtils.random()}} can overflow and return characters that are
outside the range specified by the {{start}} and {{end}} parameters. This is
because it casts a random integer in the range {{[start,end)}} to a character,
without checking if this will overflow.
Example failing test case:
{code}
@Test
public void testCharOverflow() throws Exception {
int start = 65535;
int end = Integer.MAX_VALUE;
@SuppressWarnings("serial")
Random fixedRandom = new Random() {
@Override
public int nextInt(int n) {
// Prevents selection of 'start' as the character
return 1;
}
};
String result = RandomStringUtils.random(1, start, end, false, false, null,
fixedRandom);
char c = result.charAt(0);
assertTrue(c >= start && c < end);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1283) RecursiveToStringStyle does not handle nested Maps correctly
[
https://issues.apache.org/jira/browse/LANG-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones updated LANG-1283:
---
Fix Version/s: (was: Review Patch)
> RecursiveToStringStyle does not handle nested Maps correctly
>
>
> Key: LANG-1283
> URL: https://issues.apache.org/jira/browse/LANG-1283
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.builder.*
>Affects Versions: 3.4
>Reporter: Dominik Stadler
> Attachments:
> LANG_1283__Make_RecursiveToStringStyleTest_actually_test_the_correct_class.patch,
> RecursiveToStringTest.java
>
>
> When using {{RecursiveToStringStyle}} to include all member fields of all
> nested objects, it works for simple Maps, but as soon as I have Maps as
> values inside another Map, the contents is not included any more, but only a
> Object.toString() seems to be appended for the objects instead.
> A possible fix would be to add the following to RecursiveToStringStyle,
> although there might be a better way to fix this:
> {code}
> @Override
> protected void appendDetail(StringBuffer buffer, String fieldName,
> Map map) {
> appendClassName(buffer, map);
> appendIdentityHashCode(buffer, map);
> appendDetail(buffer, fieldName, map.entrySet());
> }
> {code}
> See the attached unit-test for a reproducer.
> Please also note that {{RecursiveToStringStyleTest}} in commons-lang seems to
> mostly work on the DefaultStyle instead, see
> https://github.com/apache/commons-lang/blob/master/src/test/java/org/apache/commons/lang3/builder/RecursiveToStringStyleTest.java#L38,
> only one method, {{testPerson()}}, seems to actually do a real test here!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1283) RecursiveToStringStyle does not handle nested Maps correctly
[
https://issues.apache.org/jira/browse/LANG-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones updated LANG-1283:
---
Fix Version/s: Review Patch
> RecursiveToStringStyle does not handle nested Maps correctly
>
>
> Key: LANG-1283
> URL: https://issues.apache.org/jira/browse/LANG-1283
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.builder.*
>Affects Versions: 3.4
>Reporter: Dominik Stadler
> Attachments:
> LANG_1283__Make_RecursiveToStringStyleTest_actually_test_the_correct_class.patch,
> RecursiveToStringTest.java
>
>
> When using {{RecursiveToStringStyle}} to include all member fields of all
> nested objects, it works for simple Maps, but as soon as I have Maps as
> values inside another Map, the contents is not included any more, but only a
> Object.toString() seems to be appended for the objects instead.
> A possible fix would be to add the following to RecursiveToStringStyle,
> although there might be a better way to fix this:
> {code}
> @Override
> protected void appendDetail(StringBuffer buffer, String fieldName,
> Map map) {
> appendClassName(buffer, map);
> appendIdentityHashCode(buffer, map);
> appendDetail(buffer, fieldName, map.entrySet());
> }
> {code}
> See the attached unit-test for a reproducer.
> Please also note that {{RecursiveToStringStyleTest}} in commons-lang seems to
> mostly work on the DefaultStyle instead, see
> https://github.com/apache/commons-lang/blob/master/src/test/java/org/apache/commons/lang3/builder/RecursiveToStringStyleTest.java#L38,
> only one method, {{testPerson()}}, seems to actually do a real test here!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (LANG-1284) RandomStringUtils' random method goes into an infinite loop
[
https://issues.apache.org/jira/browse/LANG-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15659193#comment-15659193
]
Duncan Jones edited comment on LANG-1284 at 11/12/16 7:22 AM:
--
I'm not sure if this can be prevented without very inefficient scanning of the
input array. Perhaps the best approach here is a warning in the Javadocs.
The Javadocs need a clean up anyway, I can't really understand the opening
paragraphs:
{quote}
If start and end are both 0, start and end are set to ' ' and 'z', the ASCII
printable characters, will be used, unless letters and numbers are both false,
in which case, start and end are set to 0 and Integer.MAX_VALUE.
If set is not null, characters between start and end are chosen.{quote}
was (Author: dmjones500):
I'm not sure if this can be prevented with very inefficient scanning of the
input array. Perhaps the best approach here is a warning in the Javadocs.
The Javadocs need a clean up anyway, I can't really understand the opening
paragraphs:
{quote}
If start and end are both 0, start and end are set to ' ' and 'z', the ASCII
printable characters, will be used, unless letters and numbers are both false,
in which case, start and end are set to 0 and Integer.MAX_VALUE.
If set is not null, characters between start and end are chosen.{quote}
> RandomStringUtils' random method goes into an infinite loop
> ---
>
> Key: LANG-1284
> URL: https://issues.apache.org/jira/browse/LANG-1284
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: Arul Nedumaran
>
> The following code goes into an infinite loop.
> {code}
> RandomStringUtils.random(1, 0, 0, false, true, new char[]{ 'a' })
> {code}
> I know it doesn't make sense to pass letters=false and then a letter array,
> but a bug in the caller's code will make him fall into this trap.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1284) RandomStringUtils' random method goes into an infinite loop
[
https://issues.apache.org/jira/browse/LANG-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15659193#comment-15659193
]
Duncan Jones commented on LANG-1284:
I'm not sure if this can be prevented with very inefficient scanning of the
input array. Perhaps the best approach here is a warning in the Javadocs.
The Javadocs need a clean up anyway, I can't really understand the opening
paragraphs:
{quote}
If start and end are both 0, start and end are set to ' ' and 'z', the ASCII
printable characters, will be used, unless letters and numbers are both false,
in which case, start and end are set to 0 and Integer.MAX_VALUE.
If set is not null, characters between start and end are chosen.{quote}
> RandomStringUtils' random method goes into an infinite loop
> ---
>
> Key: LANG-1284
> URL: https://issues.apache.org/jira/browse/LANG-1284
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: Arul Nedumaran
>
> The following code goes into an infinite loop.
> {code}
> RandomStringUtils.random(1, 0, 0, false, true, new char[]{ 'a' })
> {code}
> I know it doesn't make sense to pass letters=false and then a letter array,
> but a bug in the caller's code will make him fall into this trap.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1209) FastDateFormat does not support the 'u' pattern element
[ https://issues.apache.org/jira/browse/LANG-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15174393#comment-15174393 ] Duncan Jones commented on LANG-1209: Thanks Charles! > FastDateFormat does not support the 'u' pattern element > --- > > Key: LANG-1209 > URL: https://issues.apache.org/jira/browse/LANG-1209 > Project: Commons Lang > Issue Type: Bug >Affects Versions: 2.6, 3.4 >Reporter: Glenn McGregor > > java.lang.IllegalArgumentException: Illegal pattern component: u -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1209) FastDateFormat does not support the 'u' pattern element
[ https://issues.apache.org/jira/browse/LANG-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172517#comment-15172517 ] Duncan Jones commented on LANG-1209: I can reproduce this with the 3.4 release, but not the latest code in Git. Clearly something has "solved" the problem, although looking at recent commits I'm struggling to pin down where the fix happened, inadvertent or otherwise. Not sure we can take this much further without a reproducible issue to fix. > FastDateFormat does not support the 'u' pattern element > --- > > Key: LANG-1209 > URL: https://issues.apache.org/jira/browse/LANG-1209 > Project: Commons Lang > Issue Type: Bug >Affects Versions: 2.6, 3.4 >Reporter: Glenn McGregor > > java.lang.IllegalArgumentException: Illegal pattern component: u -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1209) FastDateFormat does not support the 'u' pattern element
[ https://issues.apache.org/jira/browse/LANG-1209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15171171#comment-15171171 ] Duncan Jones commented on LANG-1209: Please can you include a code sample to reproduce this issue? > FastDateFormat does not support the 'u' pattern element > --- > > Key: LANG-1209 > URL: https://issues.apache.org/jira/browse/LANG-1209 > Project: Commons Lang > Issue Type: Bug >Affects Versions: 2.6, 3.4 >Reporter: Glenn McGregor > > java.lang.IllegalArgumentException: Illegal pattern component: u -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (LANG-1058) StringUtils.uncapitalize performance improvement
[ https://issues.apache.org/jira/browse/LANG-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duncan Jones resolved LANG-1058. Resolution: Implemented Fix Version/s: (was: Review Patch) 3.5 Author: djones Date: Wed Apr 15 19:59:50 2015 New Revision: 1673944 URL: http://svn.apache.org/r1673944 Log: Updates for LANG-1058: StringUtils.uncapitalize performance improvement. Similar fix also applied to StringUtils.capitalize (as mentioned in issue). Thanks to Leo Wang. Modified: commons/proper/lang/trunk/src/changes/changes.xml commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/StringUtils.java > StringUtils.uncapitalize performance improvement > > > Key: LANG-1058 > URL: https://issues.apache.org/jira/browse/LANG-1058 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Reporter: Leo Wang >Assignee: Duncan Jones > Fix For: 3.5 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (LANG-1058) StringUtils.uncapitalize performance improvement
[
https://issues.apache.org/jira/browse/LANG-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones updated LANG-1058:
---
Assignee: Duncan Jones
Looks good to me, thanks for the suggestion. Just to verify, I created a simple
Google Caliper test to ensure your version is faster (I didn't test memory).
The results are clear:
{noformat}
benchmarkns linear runtime
OriginalCode 193.9 ==
NewCode 90.2 =
vm: java
trial: 0
{noformat}
I'll also look to apply the same fixes to {{capitalize}} too. Watch this
space...
> StringUtils.uncapitalize performance improvement
>
>
> Key: LANG-1058
> URL: https://issues.apache.org/jira/browse/LANG-1058
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Reporter: Leo Wang
>Assignee: Duncan Jones
> Fix For: Review Patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1058) StringUtils.uncapitalize performance improvement
[ https://issues.apache.org/jira/browse/LANG-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14491356#comment-14491356 ] Duncan Jones commented on LANG-1058: I adjusted the Javadocs, thanks for pointing it out. http://svn.apache.org/r1672988 > StringUtils.uncapitalize performance improvement > > > Key: LANG-1058 > URL: https://issues.apache.org/jira/browse/LANG-1058 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Reporter: Leo Wang > Fix For: Review Patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (LANG-1069) CharSet.getInstance documentation does not clearly explain how to include negation character in set
[
https://issues.apache.org/jira/browse/LANG-1069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones resolved LANG-1069.
Resolution: Fixed
Fix Version/s: (was: Review Patch)
3.5
Assignee: Duncan Jones
Thanks for the patch. I edited it a little and have now committed it:
Author: djones
Date: Sat Apr 11 06:02:34 2015
New Revision: 1672833
URL: http://svn.apache.org/r1672833
Log:
Update for LANG-1069: CharSet.getInstance documentation does not clearly
explain how to include negation character in set. Javadoc expanded and unit
tests added to match examples. Based on patch by Arno Noordover.
Modified:
commons/proper/lang/trunk/src/changes/changes.xml
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/CharSet.java
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/CharSetTest.java
> CharSet.getInstance documentation does not clearly explain how to include
> negation character in set
> ---
>
> Key: LANG-1069
> URL: https://issues.apache.org/jira/browse/LANG-1069
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.3.2
>Reporter: Duncan Jones
>Assignee: Duncan Jones
>Priority: Minor
> Fix For: 3.5
>
> Attachments: CharSet-1069.patch
>
>
> As discussed in [this Stack Overflow
> question|http://stackoverflow.com/questions/27070515/how-can-i-include-the-caret-character-in-an-apache-commons-charset],
> the documentation for {{CharSet.getInstance()}} don't explain clearly how to
> include the negation character ({{^}}) as a literal character.
> The two solutions suggested in the SO question are:
> {code:java}
> // Add the '^' on its own
> CharSet.getInstance("^", "otherlettershere");
> // Add the '^' as the last character
> CharSet.getInstance("otherlettershere^")
> {code}
> If those are the best options, we should add a line to the Javadoc to
> indicate this. If there is a better way, clearly that should be documented
> instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1065) Merge date and time together
[ https://issues.apache.org/jira/browse/LANG-1065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duncan Jones updated LANG-1065: --- Fix Version/s: (was: Review Patch) Discussion > Merge date and time together > > > Key: LANG-1065 > URL: https://issues.apache.org/jira/browse/LANG-1065 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Paul Benedict >Priority: Minor > Fix For: Discussion > > Original Estimate: 1h > Remaining Estimate: 1h > > I have 2 java.util.Date objects -- one with the correct date and one with the > correct time. This enhancement will create a new method to apply the > respective fragments to a new java.util.Date instance. > Possible signature: > public static Date merge(Date date, Date time); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (LANG-1109) Number percentage formatting with fractional digits
[
https://issues.apache.org/jira/browse/LANG-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones updated LANG-1109:
---
Fix Version/s: (was: Review Patch)
Discussion
Thanks for submitting your suggestion. I've marked this as "Discussion" as
we'll have to discuss whether the functionality is something that suits Lang.
If we decide to go ahead with this, it would be much easier to add this if you
can provide a patch file that also includes your unit tests. Some general
advice on submitting patches can be found
[here|https://commons.apache.org/patches.html].
> Number percentage formatting with fractional digits
> ---
>
> Key: LANG-1109
> URL: https://issues.apache.org/jira/browse/LANG-1109
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
>Reporter: Marco Janc
> Fix For: Discussion
>
>
> Java built-in number formatter does formats Number locale aware with
> fractional digits defined by the defined scale of the Number, aswell the
> required precision (trims trailing zeros).
> For some reason Java's built-in percentage number formatter does not formats
> fractional digits. So i wrote a function which has same behavior as the Java
> built-in number formatter but with percentage formatting.
> {code:java}
> /**
>* Formats the given Number as percentage with necessary precision.
>* This serves as a workaround for {@link
> NumberFormat#getPercentInstance()} which does not renders fractional
>* digits.
>*
>* @param number
>* @param locale
>*
>* @return
>*/
> public static String formatPercentFraction(final Number number, final
> Locale locale)
> {
> if (number == null)
> return null;
> // get string representation with dot
> final String strNumber =
> NumberFormat.getNumberInstance(Locale.US).format(number.doubleValue());
> // create exact BigDecimal and convert to get scale
> final BigDecimal dNumber = new
> BigDecimal(strNumber).multiply(new BigDecimal(100));
> final NumberFormat percentScaleFormat =
> NumberFormat.getPercentInstance(locale);
> percentScaleFormat.setMaximumFractionDigits(Math.max(0,
> dNumber.scale()));
> // convert back for locale percent formatter
> return percentScaleFormat.format(dNumber.multiply(new
> BigDecimal(0.01)));
> }
> {code}
> I also unit tested it with many inputs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (LANG-1050) Change nullToEmpty methods to generics
[ https://issues.apache.org/jira/browse/LANG-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duncan Jones resolved LANG-1050. Resolution: Implemented Fix Version/s: (was: Review Patch) 3.5 Thanks for the patch James. Now applied to trunk: Author: djones Date: Thu Apr 9 06:27:15 2015 New Revision: 1672244 URL: http://svn.apache.org/r1672244 Log: Implements LANG-1050: Change nullToEmpty methods to generics. Thanks to James Sawle. This closes #33 in GitHub too. Modified: commons/proper/lang/trunk/src/changes/changes.xml commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/ArrayUtilsTest.java > Change nullToEmpty methods to generics > -- > > Key: LANG-1050 > URL: https://issues.apache.org/jira/browse/LANG-1050 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Reporter: James Sawle >Assignee: Duncan Jones > Fix For: 3.5 > > > Currently there are multiple Object based methods which could be replaced by > a single generic method. > - public static Long[] nullToEmpty(final Long[] array) > - public static Integer[] nullToEmpty(final Integer[] array) > - public static Short[] nullToEmpty(final Short[] array) > - public static Character[] nullToEmpty(final Character[] array) > - public static Byte[] nullToEmpty(final Byte[] array) > - public static Double[] nullToEmpty(final Double[] array) > - public static Float[] nullToEmpty(final Float[] array) > - public static Boolean[] nullToEmpty(final Boolean[] array) > Recommendation, replace all of these with a single method that would also > allow a defensive programming style when not using wrapped primitives. > - public static T[] nullToEmpty(final T[] array) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1050) Change nullToEmpty methods to generics
[
https://issues.apache.org/jira/browse/LANG-1050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14484958#comment-14484958
]
Duncan Jones commented on LANG-1050:
I'm happy to take a look at this. But I'm struggling to apply the patch (I
don't currently use git locally). I tried to apply
https://patch-diff.githubusercontent.com/raw/apache/commons-lang/pull/33.patch,
but it was rejected:
{noformat}
C:\Users\Duncan\workspace\lang>svn patch --dry-run C:\tmp\33.patch.txt
U src\main\java\org\apache\commons\lang3\ArrayUtils.java
> applied hunk @@ -462,6 +462,23 @@ with offset 2
U src\test\java\org\apache\commons\lang3\ArrayUtilsTest.java
> applied hunk @@ -363,6 +363,31 @@ with offset -7
C src\main\java\org\apache\commons\lang3\ArrayUtils.java
> rejected hunk @@ -465,9 +465,13 @@
U src\test\java\org\apache\commons\lang3\ArrayUtilsTest.java
> applied hunk @@ -32,7 +32,9 @@ with offset -7
> applied hunk @@ -42,6 +44,9 @@ with offset -7
> applied hunk @@ -390,6 +395,15 @@ with offset -32 and fuzz 1
C src\test\java\org\apache\commons\lang3\ArrayUtilsTest.java
> rejected hunk @@ -25,9 +25,15 @@
> rejected hunk @@ -37,9 +43,6 @@
> rejected hunk @@ -387,11 +390,8 @@
Summary of conflicts:
Text conflicts: 2
{noformat}
Could you kindly confirm the patch is still valid and, if so, attach an SVN
patch to this issue for review? I think until we make the complete transition
to GitHub, that's the "official" way of providing a patch.
> Change nullToEmpty methods to generics
> --
>
> Key: LANG-1050
> URL: https://issues.apache.org/jira/browse/LANG-1050
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Reporter: James Sawle
>Assignee: Duncan Jones
> Fix For: Review Patch
>
>
> Currently there are multiple Object based methods which could be replaced by
> a single generic method.
> - public static Long[] nullToEmpty(final Long[] array)
> - public static Integer[] nullToEmpty(final Integer[] array)
> - public static Short[] nullToEmpty(final Short[] array)
> - public static Character[] nullToEmpty(final Character[] array)
> - public static Byte[] nullToEmpty(final Byte[] array)
> - public static Double[] nullToEmpty(final Double[] array)
> - public static Float[] nullToEmpty(final Float[] array)
> - public static Boolean[] nullToEmpty(final Boolean[] array)
> Recommendation, replace all of these with a single method that would also
> allow a defensive programming style when not using wrapped primitives.
> - public static T[] nullToEmpty(final T[] array)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1074) Add a method to ArrayUtils for removing all occurrences of a given element
[
https://issues.apache.org/jira/browse/LANG-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14484947#comment-14484947
]
Duncan Jones commented on LANG-1074:
While I agree that's probably the typical use case, I have a slight preference
for the consistency of always cloning.
Other methods in the class seem to act this way too (see {{addAll}} for
example).
> Add a method to ArrayUtils for removing all occurrences of a given element
> --
>
> Key: LANG-1074
> URL: https://issues.apache.org/jira/browse/LANG-1074
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.3.2
>Reporter: haiyang li
>Assignee: Duncan Jones
>Priority: Minor
> Fix For: 3.5
>
> Attachments: LANG-1074.patch.txt, LANG-1074_20150320.patch
>
>
> Could we add the method: removeElementAll to remove all the occurrences of
> the specified element from the specified
> (boolean/char/byte/short/int/long/float/double/Object) array:
> {code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
> public static T[] removeElementAll(final T[] array, final Object
> element) {
> int index = indexOf(array, element);
> if (index == INDEX_NOT_FOUND) {
> return clone(array);
> }
> int[] indices = new int[array.length - index];
> int count = 0;
> indices[count++] = index;
> for (;;) {
> index = indexOf(array, element, ++index);
> if (index == INDEX_NOT_FOUND) {
> break;
> } else {
> indices[count++] = index;
> }
> }
> return (T[]) removeAll((Object) array, Arrays.copyOfRange(indices, 0,
> count));
> }
> {code}
> or maybe better:
> {code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
>public static T[] removeElement(final T[] a, final Object element,
> boolean removeAll) {
> int index = indexOf(a, element);
> if (index == INDEX_NOT_FOUND) {
> return clone(a);
> } else if (!removeAll || index >= a.length - 1) {
> return remove(a, index);
> } else {
> int[] indices = new int[a.length - index];
> int count = 0;
> indices[count++] = index++;
>
> for (int len = a.length; index < len; index++) {
> if ((a[index] == null) ? element == null : (element == null ?
> false : a[index].equals(element))) {
> indices[count++] = index;
> }
> }
> return (T[]) removeAll((Object) a, Arrays.copyOfRange(indices, 0,
> count));
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (LANG-1074) Add a method to ArrayUtils for removing all occurrences of a given element
[
https://issues.apache.org/jira/browse/LANG-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones resolved LANG-1074.
Resolution: Implemented
Fix Version/s: (was: Review Patch)
3.5
Assignee: Duncan Jones
I made a few minor changes to your patch and applied it. Thanks for your
contribution.
Author: djones
Date: Wed Apr 8 07:53:49 2015
New Revision: 1672025
URL: http://svn.apache.org/r1672025
Log:
Implements LANG-1074: Add a method to ArrayUtils for removing all occurrences
of a given element. Thanks to Haiyang Li.
Modified:
commons/proper/lang/trunk/src/changes/changes.xml
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/ArrayUtils.java
commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/ArrayUtilsRemoveTest.java
> Add a method to ArrayUtils for removing all occurrences of a given element
> --
>
> Key: LANG-1074
> URL: https://issues.apache.org/jira/browse/LANG-1074
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.3.2
>Reporter: haiyang li
>Assignee: Duncan Jones
>Priority: Minor
> Fix For: 3.5
>
> Attachments: LANG-1074.patch.txt, LANG-1074_20150320.patch
>
>
> Could we add the method: removeElementAll to remove all the occurrences of
> the specified element from the specified
> (boolean/char/byte/short/int/long/float/double/Object) array:
> {code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
> public static T[] removeElementAll(final T[] array, final Object
> element) {
> int index = indexOf(array, element);
> if (index == INDEX_NOT_FOUND) {
> return clone(array);
> }
> int[] indices = new int[array.length - index];
> int count = 0;
> indices[count++] = index;
> for (;;) {
> index = indexOf(array, element, ++index);
> if (index == INDEX_NOT_FOUND) {
> break;
> } else {
> indices[count++] = index;
> }
> }
> return (T[]) removeAll((Object) array, Arrays.copyOfRange(indices, 0,
> count));
> }
> {code}
> or maybe better:
> {code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
>public static T[] removeElement(final T[] a, final Object element,
> boolean removeAll) {
> int index = indexOf(a, element);
> if (index == INDEX_NOT_FOUND) {
> return clone(a);
> } else if (!removeAll || index >= a.length - 1) {
> return remove(a, index);
> } else {
> int[] indices = new int[a.length - index];
> int count = 0;
> indices[count++] = index++;
>
> for (int len = a.length; index < len; index++) {
> if ((a[index] == null) ? element == null : (element == null ?
> false : a[index].equals(element))) {
> indices[count++] = index;
> }
> }
> return (T[]) removeAll((Object) a, Arrays.copyOfRange(indices, 0,
> count));
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1074) Add a method to ArrayUtils for removing all occurrences of a given element
[
https://issues.apache.org/jira/browse/LANG-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14483709#comment-14483709
]
Duncan Jones commented on LANG-1074:
Not to worry, I've patched this on the command line. Reviewing now...
> Add a method to ArrayUtils for removing all occurrences of a given element
> --
>
> Key: LANG-1074
> URL: https://issues.apache.org/jira/browse/LANG-1074
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.3.2
>Reporter: haiyang li
>Priority: Minor
> Fix For: Review Patch
>
> Attachments: LANG-1074.patch.txt, LANG-1074_20150320.patch
>
>
> Could we add the method: removeElementAll to remove all the occurrences of
> the specified element from the specified
> (boolean/char/byte/short/int/long/float/double/Object) array:
> {code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
> public static T[] removeElementAll(final T[] array, final Object
> element) {
> int index = indexOf(array, element);
> if (index == INDEX_NOT_FOUND) {
> return clone(array);
> }
> int[] indices = new int[array.length - index];
> int count = 0;
> indices[count++] = index;
> for (;;) {
> index = indexOf(array, element, ++index);
> if (index == INDEX_NOT_FOUND) {
> break;
> } else {
> indices[count++] = index;
> }
> }
> return (T[]) removeAll((Object) array, Arrays.copyOfRange(indices, 0,
> count));
> }
> {code}
> or maybe better:
> {code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
>public static T[] removeElement(final T[] a, final Object element,
> boolean removeAll) {
> int index = indexOf(a, element);
> if (index == INDEX_NOT_FOUND) {
> return clone(a);
> } else if (!removeAll || index >= a.length - 1) {
> return remove(a, index);
> } else {
> int[] indices = new int[a.length - index];
> int count = 0;
> indices[count++] = index++;
>
> for (int len = a.length; index < len; index++) {
> if ((a[index] == null) ? element == null : (element == null ?
> false : a[index].equals(element))) {
> indices[count++] = index;
> }
> }
> return (T[]) removeAll((Object) a, Arrays.copyOfRange(indices, 0,
> count));
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLI-248) dead links on doc page
[ https://issues.apache.org/jira/browse/CLI-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duncan Jones resolved CLI-248. -- Resolution: Fixed Fix Version/s: 1.3 Assignee: Duncan Jones Thanks for spotting that. Assuming the Javadocs end up where they were before, this will fix it. Author: djones Date: Tue Apr 7 13:54:37 2015 New Revision: 1671849 URL: http://svn.apache.org/r1671849 Log: Fixed links to Javadoc (closes CLI-248). Modified: commons/proper/cli/trunk/src/changes/changes.xml commons/proper/cli/trunk/src/site/xdoc/introduction.xml > dead links on doc page > -- > > Key: CLI-248 > URL: https://issues.apache.org/jira/browse/CLI-248 > Project: Commons CLI > Issue Type: Bug > Components: Documentation >Reporter: Gerard Weatherby >Assignee: Duncan Jones >Priority: Minor > Labels: web-site > Fix For: 1.3 > > Original Estimate: 24h > Remaining Estimate: 24h > > http://commons.apache.org/proper/commons-cli/introduction.html > Links to Option, Options, Command Line et. al. are dead (e.g. > http://commons.apache.org/proper/commons-cli/api-release/org/apache/commons/cli/Options.html > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLI-244) Non-existing option is not reported as a failure when it follows an option that accepts multiple values
[
https://issues.apache.org/jira/browse/CLI-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14482671#comment-14482671
]
Duncan Jones commented on CLI-244:
--
Marking this as blocked by CLI-221. Until the correct behaviour is determined,
this issue cannot be examined.
> Non-existing option is not reported as a failure when it follows an option
> that accepts multiple values
> ---
>
> Key: CLI-244
> URL: https://issues.apache.org/jira/browse/CLI-244
> Project: Commons CLI
> Issue Type: Bug
> Components: CLI-1.x
>Affects Versions: 1.2
> Environment: Java 7
> Linux/Windows
>Reporter: Ivan C
>Priority: Critical
>
> If I define the following options:
> {code:java}
> Option dest = OptionBuilder
> .withArgName("-d")
> .withDescription("Destination")
> .hasArg()
> .create("-d");
> dest.setRequired(true);
> Option filenames = OptionBuilder
> .withArgName("-f")
> .withDescription("Filenames; comma separated")
> .hasArgs()
> .withValueSeparator(',')
> .create("-f");
> {code}
> when I parse the following arguments
> {code}
> -d c:\development\test -f abc.txt -qa hello
> {code}
> rather than getting a ParseException, the code thinks abc.txt, -qa, hello are
> the values for the -f option.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLI-221) cli's with last option as list type values and have argument are not parsed correctly
[
https://issues.apache.org/jira/browse/CLI-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14482665#comment-14482665
]
Duncan Jones commented on CLI-221:
--
The Javadocs do not make this sound optional. From
{{OptionBuilder::withValueSeparator}}:
bq. The next Option created uses sep as a means to separate argument values
At the very least, the Javadocs should be updated to make it clear that
whitespace will always remain a valid separator. We may also consider a new
method that exclusively uses the supplied separator.
Personally I find the current behaviour non-intuitive and I'm struggling to
imagine a use for it.
> cli's with last option as list type values and have argument are not parsed
> correctly
> -
>
> Key: CLI-221
> URL: https://issues.apache.org/jira/browse/CLI-221
> Project: Commons CLI
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.2
>Reporter: Gagan Jain
>
> I have set the value separator for an option to be comma (',').
> Consider the following cli:
> cli definition : cmd1 -o1 a1
> command name: 'cmd1'
> options: 'o1' accpets list of values separated by ','
> arguments: 'a1' single valued argument
> {code}cmd1 -o1 o1v1,o1v2,o1v3 a1v1{code}
> GnuParser parses this the cli with o1 having values {o1v1, o1v2, o1v3, a1v1}
> instead of {o1v1,o1v2,o1v3}
> Bug seems to be in org.apache.commons.cli.Parser's class processArgs method.
> {code:java}
> public void processArgs(Option opt, ListIterator iter) throws
> ParseException
> {
> // loop until an option is found
> while (iter.hasNext())
> {
> String str = (String) iter.next();
> // found an Option, not an argument
> if (getOptions().hasOption(str) && str.startsWith("-"))
> {
> iter.previous();
> break;
> }
> // found a value
> try
> {
>
> opt.addValueForProcessing(Util.stripLeadingAndTrailingQuotes(str));
> }
> catch (RuntimeException exp)
> {
> iter.previous();
> break;
> }
> }
> if (opt.getValues() == null && !opt.hasOptionalArg())
> {
> throw new MissingArgumentException(opt);
> }
> }
> {code}
> In my opinion, if a value separator is defined for option, and is other than
> space (' '), loop should break immediately after one iteration.
> Correct me, if I am wrong in my understanding.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (LANG-1074) Add a method to ArrayUtils for removing all occurrences of a given element
[
https://issues.apache.org/jira/browse/LANG-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14382087#comment-14382087
]
Duncan Jones edited comment on LANG-1074 at 3/26/15 3:53 PM:
-
Sorry, still doesn't work for me.
If you are using Eclipse, please do the following to create a valid patch:
# Right-click on project > Team > Create Patch...
# Select "In file system" and choose somewhere to store the patch file
# On the Advanced options, ensure Patch Root = Project. Selected patch options
should be:
- "Recurse into sub-folders"
- "Process deleted resources"
- "Process new resources"
See also https://commons.apache.org/patches.html (although this essentially
says the same thing).
I think in your first patch, you perhaps used the workspace as the patch root.
was (Author: dmjones500):
Sorry, still doesn't work for me.
If you are using Eclipse, please do the following to create a valid patch:
# Right-click on project > Team > Create Patch...
# Select "In file system" and choose somewhere to store the patch file
# On the Advanced options, ensure Patch Root = Project. Selected patch options
should be:
- "Recurse into sub-folders"
- "Process deleted resources"
- "Process new resources"
See also https://commons.apache.org/patches.html (although this essentially
says the same thing).
> Add a method to ArrayUtils for removing all occurrences of a given element
> --
>
> Key: LANG-1074
> URL: https://issues.apache.org/jira/browse/LANG-1074
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.3.2
>Reporter: haiyang li
>Priority: Minor
> Fix For: Review Patch
>
> Attachments: LANG-1074.patch.txt, LANG-1074_20150320.patch
>
>
> Could we add the method: removeElementAll to remove all the occurrences of
> the specified element from the specified
> (boolean/char/byte/short/int/long/float/double/Object) array:
> {code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
> public static T[] removeElementAll(final T[] array, final Object
> element) {
> int index = indexOf(array, element);
> if (index == INDEX_NOT_FOUND) {
> return clone(array);
> }
> int[] indices = new int[array.length - index];
> int count = 0;
> indices[count++] = index;
> for (;;) {
> index = indexOf(array, element, ++index);
> if (index == INDEX_NOT_FOUND) {
> break;
> } else {
> indices[count++] = index;
> }
> }
> return (T[]) removeAll((Object) array, Arrays.copyOfRange(indices, 0,
> count));
> }
> {code}
> or maybe better:
> {code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
>public static T[] removeElement(final T[] a, final Object element,
> boolean removeAll) {
> int index = indexOf(a, element);
> if (index == INDEX_NOT_FOUND) {
> return clone(a);
> } else if (!removeAll || index >= a.length - 1) {
> return remove(a, index);
> } else {
> int[] indices = new int[a.length - index];
> int count = 0;
> indices[count++] = index++;
>
> for (int len = a.length; index < len; index++) {
> if ((a[index] == null) ? element == null : (element == null ?
> false : a[index].equals(element))) {
> indices[count++] = index;
> }
> }
> return (T[]) removeAll((Object) a, Arrays.copyOfRange(indices, 0,
> count));
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1074) Add a method to ArrayUtils for removing all occurrences of a given element
[
https://issues.apache.org/jira/browse/LANG-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14382087#comment-14382087
]
Duncan Jones commented on LANG-1074:
Sorry, still doesn't work for me.
If you are using Eclipse, please do the following to create a valid patch:
# Right-click on project > Team > Create Patch...
# Select "In file system" and choose somewhere to store the patch file
# On the Advanced options, ensure Patch Root = Project. Selected patch options
should be:
- "Recurse into sub-folders"
- "Process deleted resources"
- "Process new resources"
See also https://commons.apache.org/patches.html (although this essentially
says the same thing).
> Add a method to ArrayUtils for removing all occurrences of a given element
> --
>
> Key: LANG-1074
> URL: https://issues.apache.org/jira/browse/LANG-1074
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.3.2
>Reporter: haiyang li
>Priority: Minor
> Fix For: Review Patch
>
> Attachments: LANG-1074.patch.txt, LANG-1074_20150320.patch
>
>
> Could we add the method: removeElementAll to remove all the occurrences of
> the specified element from the specified
> (boolean/char/byte/short/int/long/float/double/Object) array:
> {code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
> public static T[] removeElementAll(final T[] array, final Object
> element) {
> int index = indexOf(array, element);
> if (index == INDEX_NOT_FOUND) {
> return clone(array);
> }
> int[] indices = new int[array.length - index];
> int count = 0;
> indices[count++] = index;
> for (;;) {
> index = indexOf(array, element, ++index);
> if (index == INDEX_NOT_FOUND) {
> break;
> } else {
> indices[count++] = index;
> }
> }
> return (T[]) removeAll((Object) array, Arrays.copyOfRange(indices, 0,
> count));
> }
> {code}
> or maybe better:
> {code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
>public static T[] removeElement(final T[] a, final Object element,
> boolean removeAll) {
> int index = indexOf(a, element);
> if (index == INDEX_NOT_FOUND) {
> return clone(a);
> } else if (!removeAll || index >= a.length - 1) {
> return remove(a, index);
> } else {
> int[] indices = new int[a.length - index];
> int count = 0;
> indices[count++] = index++;
>
> for (int len = a.length; index < len; index++) {
> if ((a[index] == null) ? element == null : (element == null ?
> false : a[index].equals(element))) {
> indices[count++] = index;
> }
> }
> return (T[]) removeAll((Object) a, Arrays.copyOfRange(indices, 0,
> count));
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1074) Add a method to ArrayUtils for removing all occurrences of a given element
[
https://issues.apache.org/jira/browse/LANG-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371514#comment-14371514
]
Duncan Jones commented on LANG-1074:
[~lihy70] I'm struggling to apply your new patch. It seems to be in an
Eclipse-specific format rather than an SVN patch?
> Add a method to ArrayUtils for removing all occurrences of a given element
> --
>
> Key: LANG-1074
> URL: https://issues.apache.org/jira/browse/LANG-1074
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.3.2
>Reporter: haiyang li
>Priority: Minor
> Fix For: Review Patch
>
> Attachments: LANG-1074.patch.txt
>
>
> Could we add the method: removeElementAll to remove all the occurrences of
> the specified element from the specified
> (boolean/char/byte/short/int/long/float/double/Object) array:
> {code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
> public static T[] removeElementAll(final T[] array, final Object
> element) {
> int index = indexOf(array, element);
> if (index == INDEX_NOT_FOUND) {
> return clone(array);
> }
> int[] indices = new int[array.length - index];
> int count = 0;
> indices[count++] = index;
> for (;;) {
> index = indexOf(array, element, ++index);
> if (index == INDEX_NOT_FOUND) {
> break;
> } else {
> indices[count++] = index;
> }
> }
> return (T[]) removeAll((Object) array, Arrays.copyOfRange(indices, 0,
> count));
> }
> {code}
> or maybe better:
> {code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
>public static T[] removeElement(final T[] a, final Object element,
> boolean removeAll) {
> int index = indexOf(a, element);
> if (index == INDEX_NOT_FOUND) {
> return clone(a);
> } else if (!removeAll || index >= a.length - 1) {
> return remove(a, index);
> } else {
> int[] indices = new int[a.length - index];
> int count = 0;
> indices[count++] = index++;
>
> for (int len = a.length; index < len; index++) {
> if ((a[index] == null) ? element == null : (element == null ?
> false : a[index].equals(element))) {
> indices[count++] = index;
> }
> }
> return (T[]) removeAll((Object) a, Arrays.copyOfRange(indices, 0,
> count));
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1094) Javadoc is not encoding spaces correctly
[
https://issues.apache.org/jira/browse/LANG-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14358848#comment-14358848
]
Duncan Jones commented on LANG-1094:
I was using Chrome. However, I've looked at other Javadocs (most notably the
main Oracle docs) and I don't see this problem. So something different is
happening with the Lang docs. I'm happy to change this issue to a different
type or close it and continue discussion on the ML if that's preferable.
> Javadoc is not encoding spaces correctly
>
>
> Key: LANG-1094
> URL: https://issues.apache.org/jira/browse/LANG-1094
> Project: Commons Lang
> Issue Type: Bug
> Components: General
>Reporter: Duncan Jones
>Priority: Minor
>
> I've noticed the Javadocs include links to methods with spaces incorrectly
> encoded. For example, the Javadocs for
> [DateUtils|http://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/time/DateUtils.html]
> describes a method:
> {code:java}
> public static boolean isSameDay(Calendar cal1, Calendar cal2)
> {code}
> The link to this is:
> {noformat}
> [...]/DateUtils.html#isSameDay(java.util.Calendar, java.util.Calendar)
> {noformat}
> whereas it should be:
> {noformat}
> [...]/DateUtils.html#isSameDay(java.util.Calendar,%20java.util.Calendar)
> {noformat}
> Not sure what's causing this problem. But it certainly hinders efforts to
> link to our docs from other sites (like Stack Overflow).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1094) Javadoc is not encoding spaces correctly
[
https://issues.apache.org/jira/browse/LANG-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones updated LANG-1094:
---
Fix Version/s: (was: Patch Needed)
> Javadoc is not encoding spaces correctly
>
>
> Key: LANG-1094
> URL: https://issues.apache.org/jira/browse/LANG-1094
> Project: Commons Lang
> Issue Type: Bug
> Components: General
>Reporter: Duncan Jones
>Priority: Minor
>
> I've noticed the Javadocs include links to methods with spaces incorrectly
> encoded. For example, the Javadocs for
> [DateUtils|http://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/time/DateUtils.html]
> describes a method:
> {code:java}
> public static boolean isSameDay(Calendar cal1, Calendar cal2)
> {code}
> The link to this is:
> {noformat}
> [...]/DateUtils.html#isSameDay(java.util.Calendar, java.util.Calendar)
> {noformat}
> whereas it should be:
> {noformat}
> [...]/DateUtils.html#isSameDay(java.util.Calendar,%20java.util.Calendar)
> {noformat}
> Not sure what's causing this problem. But it certainly hinders efforts to
> link to our docs from other sites (like Stack Overflow).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1094) Javadoc is not encoding spaces correctly
[
https://issues.apache.org/jira/browse/LANG-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14358726#comment-14358726
]
Duncan Jones commented on LANG-1094:
I'm not sure, but I wanted to raise it before I forgot about it. It could be an
error in how we've configured our Javadoc output or it might be that we need to
choose a different version of a Javadoc plugin to avoid a bug in Javadoc.
I've removed the "patch needed" label, since we don't' know what we're dealing
with yet.
> Javadoc is not encoding spaces correctly
>
>
> Key: LANG-1094
> URL: https://issues.apache.org/jira/browse/LANG-1094
> Project: Commons Lang
> Issue Type: Bug
> Components: General
>Reporter: Duncan Jones
>Priority: Minor
>
> I've noticed the Javadocs include links to methods with spaces incorrectly
> encoded. For example, the Javadocs for
> [DateUtils|http://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/time/DateUtils.html]
> describes a method:
> {code:java}
> public static boolean isSameDay(Calendar cal1, Calendar cal2)
> {code}
> The link to this is:
> {noformat}
> [...]/DateUtils.html#isSameDay(java.util.Calendar, java.util.Calendar)
> {noformat}
> whereas it should be:
> {noformat}
> [...]/DateUtils.html#isSameDay(java.util.Calendar,%20java.util.Calendar)
> {noformat}
> Not sure what's causing this problem. But it certainly hinders efforts to
> link to our docs from other sites (like Stack Overflow).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (LANG-1094) Javadoc is not encoding spaces correctly
Duncan Jones created LANG-1094:
--
Summary: Javadoc is not encoding spaces correctly
Key: LANG-1094
URL: https://issues.apache.org/jira/browse/LANG-1094
Project: Commons Lang
Issue Type: Bug
Components: General
Reporter: Duncan Jones
Priority: Minor
Fix For: Patch Needed
I've noticed the Javadocs include links to methods with spaces incorrectly
encoded. For example, the Javadocs for
[DateUtils|http://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/time/DateUtils.html]
describes a method:
{code:java}
public static boolean isSameDay(Calendar cal1, Calendar cal2)
{code}
The link to this is:
{noformat}
[...]/DateUtils.html#isSameDay(java.util.Calendar, java.util.Calendar)
{noformat}
whereas it should be:
{noformat}
[...]/DateUtils.html#isSameDay(java.util.Calendar,%20java.util.Calendar)
{noformat}
Not sure what's causing this problem. But it certainly hinders efforts to link
to our docs from other sites (like Stack Overflow).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1049) SerializationUtils.deserialize() can not be used within OSGi
[
https://issues.apache.org/jira/browse/LANG-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328932#comment-14328932
]
Duncan Jones commented on LANG-1049:
Understood. I propose we leave this as it is then, since the comment thread
explains the direction we wish to go.
Patches welcome for {{SerializationUtils.deserialize()}}.
> SerializationUtils.deserialize() can not be used within OSGi
>
>
> Key: LANG-1049
> URL: https://issues.apache.org/jira/browse/LANG-1049
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 2.6
> Environment: Equinox
>Reporter: Marcus Klein
>Priority: Blocker
>
> SerializationUtils.deserialize() throws a SerializationException if objects
> should be deserialized that can not be resolved by OSGi classloader of
> org.apache.commons.lang bundle.
> To solve this problem I suggest to allow buddy classloading within
> commons.lang to allow other bundles to register their class loaders.
> Please add
> Eclipse-BuddyPolicy: registered
> to the MANIFEST.MF of commons.lang to solve this problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (LANG-1070) confusing example in ArrayUtils.add()
[
https://issues.apache.org/jira/browse/LANG-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328904#comment-14328904
]
Duncan Jones edited comment on LANG-1070 at 2/20/15 1:25 PM:
-
The Javadoc is inconsistent. It gives the example of {{ArrayUtils.add(null,
null) = \[null\]}} and states that {{array}} and {{element}} can both be null.
But later it describes the behaviour differently:
bq. [The method returns] a new array containing the existing elements plus the
new element The returned array type will be that of the input array (unless
null), in which case it will have the same type as the element. _If both are
null, an IllegalArgumentException is thrown_
It's not clear to me whether we can adjust the behaviour under the
justification that it's a bug (versus documented behaviour).
was (Author: dmjones500):
The Javadoc is inconsistent. It gives the example of {{ArrayUtils.add(null,
null) = \[null\]}} and states that {{array}} and {{element}} can both be null.
But later it describes the behaviour differently:
bq. [The method returns] a new array containing the existing elements plus the
new element The returned array type will be that of the input array (unless
null), in which case it will have the same type as the element. _If both are
null, an IllegalArgumentException is thrown_
> confusing example in ArrayUtils.add()
> -
>
> Key: LANG-1070
> URL: https://issues.apache.org/jira/browse/LANG-1070
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.3.2
>Reporter: Paul Pogonyshev
>Priority: Trivial
>
> Method documentation claims that
> ArrayUtils.add(null, null) = null
> However, this is not true since this parameter combination leads to an
> exception.
> Either remove this line from documentation, or rewrite it to explicitly
> mention the exception. Maybe there are other related methods with similar
> problem in the docs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1070) confusing example in ArrayUtils.add()
[
https://issues.apache.org/jira/browse/LANG-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328904#comment-14328904
]
Duncan Jones commented on LANG-1070:
The Javadoc is inconsistent. It gives the example of {{ArrayUtils.add(null,
null) = \[null\]}} and states that {{array}} and {{element}} can both be null.
But later it describes the behaviour differently:
bq. [The method returns] a new array containing the existing elements plus the
new element The returned array type will be that of the input array (unless
null), in which case it will have the same type as the element. _If both are
null, an IllegalArgumentException is thrown_
> confusing example in ArrayUtils.add()
> -
>
> Key: LANG-1070
> URL: https://issues.apache.org/jira/browse/LANG-1070
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.3.2
>Reporter: Paul Pogonyshev
>Priority: Trivial
>
> Method documentation claims that
> ArrayUtils.add(null, null) = null
> However, this is not true since this parameter combination leads to an
> exception.
> Either remove this line from documentation, or rewrite it to explicitly
> mention the exception. Maybe there are other related methods with similar
> problem in the docs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1074) Add a method to ArrayUtils for removing all occurrences of a given element
[
https://issues.apache.org/jira/browse/LANG-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328896#comment-14328896
]
Duncan Jones commented on LANG-1074:
[~lihy70]: Are you willing to update the patch to address Benedikt's comments?
Specifically:
- Rename to {{removeAllOccurences(...)}}
- Drop the {{boolean removeAll}} parameter.
You should also add {{@since 3.4}} to the Javadoc for the new methods.
Then we can look to getting this added to trunk.
> Add a method to ArrayUtils for removing all occurrences of a given element
> --
>
> Key: LANG-1074
> URL: https://issues.apache.org/jira/browse/LANG-1074
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.3.2
>Reporter: haiyang li
>Priority: Minor
> Fix For: Review Patch
>
> Attachments: LANG-1074.patch.txt
>
>
> Could we add the method: removeElementAll to remove all the occurrences of
> the specified element from the specified
> (boolean/char/byte/short/int/long/float/double/Object) array:
> {code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
> public static T[] removeElementAll(final T[] array, final Object
> element) {
> int index = indexOf(array, element);
> if (index == INDEX_NOT_FOUND) {
> return clone(array);
> }
> int[] indices = new int[array.length - index];
> int count = 0;
> indices[count++] = index;
> for (;;) {
> index = indexOf(array, element, ++index);
> if (index == INDEX_NOT_FOUND) {
> break;
> } else {
> indices[count++] = index;
> }
> }
> return (T[]) removeAll((Object) array, Arrays.copyOfRange(indices, 0,
> count));
> }
> {code}
> or maybe better:
> {code:title=org.apache.commons.lang3.ArrayUtils.java|borderStyle=solid}
>public static T[] removeElement(final T[] a, final Object element,
> boolean removeAll) {
> int index = indexOf(a, element);
> if (index == INDEX_NOT_FOUND) {
> return clone(a);
> } else if (!removeAll || index >= a.length - 1) {
> return remove(a, index);
> } else {
> int[] indices = new int[a.length - index];
> int count = 0;
> indices[count++] = index++;
>
> for (int len = a.length; index < len; index++) {
> if ((a[index] == null) ? element == null : (element == null ?
> false : a[index].equals(element))) {
> indices[count++] = index;
> }
> }
> return (T[]) removeAll((Object) a, Arrays.copyOfRange(indices, 0,
> count));
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1049) SerializationUtils.deserialize() can not be used within OSGi
[ https://issues.apache.org/jira/browse/LANG-1049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328887#comment-14328887 ] Duncan Jones commented on LANG-1049: [~marcus.klein]: do you think this issue should become a feature request, asking for what Joerg describes? Or are you happy that we close this, because you have found an alternative option? > SerializationUtils.deserialize() can not be used within OSGi > > > Key: LANG-1049 > URL: https://issues.apache.org/jira/browse/LANG-1049 > Project: Commons Lang > Issue Type: Bug > Components: lang.* >Affects Versions: 2.6 > Environment: Equinox >Reporter: Marcus Klein >Priority: Blocker > > SerializationUtils.deserialize() throws a SerializationException if objects > should be deserialized that can not be resolved by OSGi classloader of > org.apache.commons.lang bundle. > To solve this problem I suggest to allow buddy classloading within > commons.lang to allow other bundles to register their class loaders. > Please add > Eclipse-BuddyPolicy: registered > to the MANIFEST.MF of commons.lang to solve this problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
