[jira] [Updated] (LANG-1475) StringUtils.unwrap incorrect throw StringIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/LANG-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Silence Tai updated LANG-1475:
--
Summary: StringUtils.unwrap incorrect throw StringIndexOutOfBoundsException
(was: StringUtils.unwrap StringIndexOutOfBoundsException)
> StringUtils.unwrap incorrect throw StringIndexOutOfBoundsException
> --
>
> Key: LANG-1475
> URL: https://issues.apache.org/jira/browse/LANG-1475
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Reporter: Silence Tai
>Priority: Major
> Fix For: 3.10
>
> Original Estimate: 10m
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Call
> {code:java} StringUtils.unwrap("a", 'a'); {code}
> or
> {code:java} StringUtils.unwrap("a", "a"); {code}
> Throw Exception:
> *java.lang.StringIndexOutOfBoundsException: begin 1, end 0, length 1*
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (LANG-1481) Add StringUtils.split() methods with String[] input.
[
https://issues.apache.org/jira/browse/LANG-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LANG-1481:
---
Description:
We already have {{StringUtils.split(String,*)`}}, but I want to work with many
inputs, so add {{StringUtils.split()}} methods with {{String[]}} inputs:
{code:java}
/**
* Splits the provided text array into an array, separator specified.
* This is an alternative to using StringTokenizer.
*
* The separator is not included in the returned String array.
* Adjacent separators are treated as one separator.
* For more control over the split use the StrTokenizer class.
*
* A {@code null} input String returns {@code null}.
*
*
* StringUtils.split([null], *) = null
* StringUtils.split([""], *)= []
* StringUtils.split(["", ""], *) = []
* StringUtils.split(["a.b.c"], '.') = ["a", "b", "c"]
* StringUtils.split(["a.b"],["c"], '.') = ["a", "b", "c"]
* StringUtils.split(["a"],["b"],["c"], '.') = ["a", "b", "c"]
* StringUtils.split(["a..b.c"], '.')= ["a", "b", "c"]
* StringUtils.split(["a:b:c"], '.') = ["a:b:c"]
* StringUtils.split(["a b c"], ' ') = ["a", "b", "c"]
*
*
* @param strArray the String[] to parse, may be null
* @param separatorChar the character used as the delimiter
* @return an array of parsed Strings, {@code null} if null String input
* @since 3.10
*/
{code}
Looking for feedback...
was:
We already have {{StringUtils.split(String,*)`}}, but I want to work with many
inputs, so add {{StringUtils.split()}} methods with {{String[]}} inputs:
{code:java}
/**
* Splits the provided text array into an array, separator specified.
* This is an alternative to using StringTokenizer.
*
* The separator is not included in the returned String array.
* Adjacent separators are treated as one separator.
* For more control over the split use the StrTokenizer class.
*
* A {@code null} input String returns {@code null}.
*
*
* StringUtils.split([null], *) = null
* StringUtils.split([""], *)= []
* StringUtils.split(["", ""], *) = []
* StringUtils.split(["a.b.c"], '.') = ["a", "b", "c"]
* StringUtils.split(["a.b"],["c"], '.') = ["a", "b", "c"]
* StringUtils.split(["a"],["b"],["c"], '.') = ["a", "b", "c"]
* StringUtils.split(["a..b.c"], '.')= ["a", "b", "c"]
* StringUtils.split(["a:b:c"], '.') = ["a:b:c"]
* StringUtils.split(["a b c"], ' ') = ["a", "b", "c"]
*
*
* @param strArray the String[] to parse, may be null
* @param separatorChar the character used as the delimiter
* @return an array of parsed Strings, {@code null} if null String input
* @since 3.10
*/
{code}
> Add StringUtils.split() methods with String[] input.
>
>
> Key: LANG-1481
> URL: https://issues.apache.org/jira/browse/LANG-1481
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> We already have {{StringUtils.split(String,*)`}}, but I want to work with
> many inputs, so add {{StringUtils.split()}} methods with {{String[]}} inputs:
> {code:java}
> /**
> * Splits the provided text array into an array, separator specified.
> * This is an alternative to using StringTokenizer.
> *
> * The separator is not included in the returned String array.
> * Adjacent separators are treated as one separator.
> * For more control over the split use the StrTokenizer class.
> *
> * A {@code null} input String returns {@code null}.
> *
> *
> * StringUtils.split([null], *) = null
> * StringUtils.split([""], *)= []
> * StringUtils.split(["", ""], *) = []
> * StringUtils.split(["a.b.c"], '.') = ["a", "b", "c"]
> * StringUtils.split(["a.b"],["c"], '.') = ["a", "b", "c"]
> * StringUtils.split(["a"],["b"],["c"], '.') = ["a", "b", "c"]
> * StringUtils.split(["a..b.c"], '.')= ["a", "b", "c"]
> * StringUtils.split(["a:b:c"], '.') = ["a:b:c"]
> * StringUtils.split(["a b c"], ' ') = ["a", "b", "c"]
> *
> *
> * @param strArray the String[] to parse, may be null
> * @param separatorChar the character used as the delimiter
> * @return an array of parsed Strings, {@code null} if null String input
> * @since 3.10
> */
> {code}
> Looking for feedback...
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (LANG-1481) Add StringUtils.split() methods with String[] input.
[
https://issues.apache.org/jira/browse/LANG-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LANG-1481:
---
Description:
We already have {{StringUtils.split(String,*)`}}, but I want to work with many
inputs, so add {{StringUtils.split()}} methods with {{String[]}} inputs:
{code:java}
/**
* Splits the provided text array into an array, separator specified.
* This is an alternative to using StringTokenizer.
*
* The separator is not included in the returned String array.
* Adjacent separators are treated as one separator.
* For more control over the split use the StrTokenizer class.
*
* A {@code null} input String returns {@code null}.
*
*
* StringUtils.split([null], *) = null
* StringUtils.split([""], *)= []
* StringUtils.split(["", ""], *) = []
* StringUtils.split(["a.b.c"], '.') = ["a", "b", "c"]
* StringUtils.split(["a.b"],["c"], '.') = ["a", "b", "c"]
* StringUtils.split(["a"],["b"],["c"], '.') = ["a", "b", "c"]
* StringUtils.split(["a..b.c"], '.')= ["a", "b", "c"]
* StringUtils.split(["a:b:c"], '.') = ["a:b:c"]
* StringUtils.split(["a b c"], ' ') = ["a", "b", "c"]
*
*
* @param strArray the String[] to parse, may be null
* @param separatorChar the character used as the delimiter
* @return an array of parsed Strings, {@code null} if null String input
* @since 3.10
*/
{code}
was:
We already have {{StringUtils.split(String,*)`}}, but I want to work with many
inputs, so add {{StringUtils.split()}} methods with {{String[]}} inputs:
> Add StringUtils.split() methods with String[] input.
>
>
> Key: LANG-1481
> URL: https://issues.apache.org/jira/browse/LANG-1481
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> We already have {{StringUtils.split(String,*)`}}, but I want to work with
> many inputs, so add {{StringUtils.split()}} methods with {{String[]}} inputs:
> {code:java}
> /**
> * Splits the provided text array into an array, separator specified.
> * This is an alternative to using StringTokenizer.
> *
> * The separator is not included in the returned String array.
> * Adjacent separators are treated as one separator.
> * For more control over the split use the StrTokenizer class.
> *
> * A {@code null} input String returns {@code null}.
> *
> *
> * StringUtils.split([null], *) = null
> * StringUtils.split([""], *)= []
> * StringUtils.split(["", ""], *) = []
> * StringUtils.split(["a.b.c"], '.') = ["a", "b", "c"]
> * StringUtils.split(["a.b"],["c"], '.') = ["a", "b", "c"]
> * StringUtils.split(["a"],["b"],["c"], '.') = ["a", "b", "c"]
> * StringUtils.split(["a..b.c"], '.')= ["a", "b", "c"]
> * StringUtils.split(["a:b:c"], '.') = ["a:b:c"]
> * StringUtils.split(["a b c"], ' ') = ["a", "b", "c"]
> *
> *
> * @param strArray the String[] to parse, may be null
> * @param separatorChar the character used as the delimiter
> * @return an array of parsed Strings, {@code null} if null String input
> * @since 3.10
> */
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (LANG-1481) Add StringUtils.split() methods with String[] input.
[
https://issues.apache.org/jira/browse/LANG-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LANG-1481:
---
Description:
We already have {{StringUtils.split(String,*)`}}, but I want to work with many
inputs, so add {{StringUtils.split()}} methods with {{String[]}} inputs:
was:We already have {{StringUtils.split(String,*)`}}, but I want to work with
many inputs, so add {{StringUtils.split()}} methods with {{String[]}} inputs.
> Add StringUtils.split() methods with String[] input.
>
>
> Key: LANG-1481
> URL: https://issues.apache.org/jira/browse/LANG-1481
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> We already have {{StringUtils.split(String,*)`}}, but I want to work with
> many inputs, so add {{StringUtils.split()}} methods with {{String[]}} inputs:
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (LANG-1481) Add StringUtils.split() methods with String[] input.
Gary Gregory created LANG-1481:
--
Summary: Add StringUtils.split() methods with String[] input.
Key: LANG-1481
URL: https://issues.apache.org/jira/browse/LANG-1481
Project: Commons Lang
Issue Type: New Feature
Reporter: Gary Gregory
Assignee: Gary Gregory
We already have {{StringUtils.split(String,*)`}}, but I want to work with many
inputs, so add {{StringUtils.split()}} methods with {{String[]}} inputs.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[GitHub] [commons-rng] coveralls edited a comment on issue #26: RNG-76: Added primitive long constructor to SplitMix64
coveralls edited a comment on issue #26: RNG-76: Added primitive long constructor to SplitMix64 URL: https://github.com/apache/commons-rng/pull/26#issuecomment-468841604 [](https://coveralls.io/builds/25297617) Coverage increased (+0.0006%) to 99.389% when pulling **66d01dd7b893532433df58f7ac8399ab3ec63876 on aherbert:improvement-RNG-76** into **6349c05f95c4ca606b23f833cd7bd3e38eb6d3d9 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Resolved] (LANG-1477) Implement castToXXX in Functions class
[
https://issues.apache.org/jira/browse/LANG-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Wiedmann resolved LANG-1477.
---
Fix Version/s: 3.10
Resolution: Fixed
> Implement castToXXX in Functions class
> --
>
> Key: LANG-1477
> URL: https://issues.apache.org/jira/browse/LANG-1477
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.9
>Reporter: Peter Verhas
>Assignee: Jochen Wiedmann
>Priority: Minor
> Labels: newbie
> Fix For: 3.10
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Proposal to implement functional interface conversion functions in the class
> {{org.apache.commons.lang3.Functions}} that convert {{FailableXXX}} to
> {{XXX}}.
> For example, the FailableRunnable can be converted with the method:
>
> {code:java}
> static Runnable castToRunnable(FailableRunnable s) {
>return () -> run(s);
> }{code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Reopened] (LANG-1477) Implement castToXXX in Functions class
[
https://issues.apache.org/jira/browse/LANG-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jochen Wiedmann reopened LANG-1477:
---
Assignee: Jochen Wiedmann
> Implement castToXXX in Functions class
> --
>
> Key: LANG-1477
> URL: https://issues.apache.org/jira/browse/LANG-1477
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.9
>Reporter: Peter Verhas
>Assignee: Jochen Wiedmann
>Priority: Minor
> Labels: newbie
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Proposal to implement functional interface conversion functions in the class
> {{org.apache.commons.lang3.Functions}} that convert {{FailableXXX}} to
> {{XXX}}.
> For example, the FailableRunnable can be converted with the method:
>
> {code:java}
> static Runnable castToRunnable(FailableRunnable s) {
>return () -> run(s);
> }{code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (RNG-76) Add a primitive constructor to SplitMix64
[
https://issues.apache.org/jira/browse/RNG-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16913660#comment-16913660
]
Alex D Herbert commented on RNG-76:
---
Updated the PR with restoration of the original code for setSeedInternal with a
comment that the Long constructor is to support the RandomSource factory
methods.
> Add a primitive constructor to SplitMix64
> -
>
> Key: RNG-76
> URL: https://issues.apache.org/jira/browse/RNG-76
> Project: Commons RNG
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.3
>Reporter: Alex D Herbert
>Assignee: Alex D Herbert
>Priority: Trivial
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The constructor for {{SplitMix64}} uses a {{Long}} for the seed. If
> constructed using a primitive {{long}} then auto-boxing will occur.
> I added a {{long}} version of the constructor to SplitMix64:
> {code:java}
> SplitMix64(Long seed);
> SplitMix64(long seed);
> {code}
> I modified the {{ConstructionPerformance}} benchmark to generate 5000 random
> seeds as {{Long}} or {{long}} then tested:
> {code:java}
> // Pre-generated Long
> new SplitMix64(Long seed);
> // Pre-generated long that is boxed to Long
> new SplitMix64(Long.valueOf(long seed));
> // Pre-generated long
> new SplitMix64(long seed);
> {code}
> Results:
> ||Method||Score||Error||Median||
> |newSplitMix64Long|34.70|0.85|34.57|
> |newSplitMix64LongValueOf|55.84|5.38|55.91|
> |newSplitMix64long|32.66|1.49|32.46|
> Given that the {{SplitMix64}} is the preferred RNG for seeding from a single
> {{long}} value it makes sense to add the constructor version that accepts a
> {{long}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (LANG-1477) Implement castToXXX in Functions class
[
https://issues.apache.org/jira/browse/LANG-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16913661#comment-16913661
]
Jochen Wiedmann commented on LANG-1477:
---
Is this, what you had in mind?
[https://gitbox.apache.org/repos/asf?p=commons-lang.git;a=commit;h=bc16e0109a30b819c50895e157830fe9b3f8e93f]
> Implement castToXXX in Functions class
> --
>
> Key: LANG-1477
> URL: https://issues.apache.org/jira/browse/LANG-1477
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.9
>Reporter: Peter Verhas
>Priority: Minor
> Labels: newbie
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Proposal to implement functional interface conversion functions in the class
> {{org.apache.commons.lang3.Functions}} that convert {{FailableXXX}} to
> {{XXX}}.
> For example, the FailableRunnable can be converted with the method:
>
> {code:java}
> static Runnable castToRunnable(FailableRunnable s) {
>return () -> run(s);
> }{code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[GitHub] [commons-lang] ham1 commented on issue #440: Fix static code issues
ham1 commented on issue #440: Fix static code issues URL: https://github.com/apache/commons-lang/pull/440#issuecomment-523964613 Could you explain your rational and what should I do differently next time to make the review easier? This PR is 86 lines of changes broken down into differet commits for each type of change. Should I create a PR for each file or each commit? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-lang] jochenw commented on issue #440: Fix static code issues
jochenw commented on issue #440: Fix static code issues URL: https://github.com/apache/commons-lang/pull/440#issuecomment-523960869 I'd be ready to accept these one by one, but not 15 files in one go. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Closed] (LANG-1479) Add Range.fit(T) to fit a value into a range
[
https://issues.apache.org/jira/browse/LANG-1479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed LANG-1479.
--
Fix Version/s: 3.10
Resolution: Fixed
In git master.
> Add Range.fit(T) to fit a value into a range
>
>
> Key: LANG-1479
> URL: https://issues.apache.org/jira/browse/LANG-1479
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 3.10
>
>
> Facilitates code like:
> {code:java}
> int max = ...;
> int result = max < 0 ? 0 : max > 64 ? 64 : max;
> {code}
> to simply be:
> {code:java}
> static final RANGE = Range.between(16, 64);
> int max = ...;
> int result = RANGE.fit(max);
> {code}
> Like this:
> {code:java}
> /**
> *
> * Fits the given element into this range by returning the given element
> or, if out of bounds, the range minimum if
> * below, or the range maximum if above.
> *
> *
> * @param element the element to check for, not null
> * @return the minimum, the element, or the maximum depending on the
> element's location relative to the range
> * @since 3.10
> */
> public T fit(final T element) {
> // Comparable API says throw NPE on null
> Validate.notNull(element, "Element is null");
> if (isAfter(element)) {
> return minimum;
> } else if (isBefore(element)) {
> return maximum;
> } else {
> return element;
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (RNG-76) Add a primitive constructor to SplitMix64
[
https://issues.apache.org/jira/browse/RNG-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16913306#comment-16913306
]
Gilles commented on RNG-76:
---
Is it necessary to change the other constructor (with a {{Long}} argument)?
For that non performance-critical constructor, I'd rather keep the uniformity
of the design (using {{setSeedInternal}}).
And to make it clear why the other constructor is added, that method could be
modified to avoid implicit unboxing:
{code}
private void setSeedInternal(Long seed) {
state = seed.longValue();
}
{code}
> Add a primitive constructor to SplitMix64
> -
>
> Key: RNG-76
> URL: https://issues.apache.org/jira/browse/RNG-76
> Project: Commons RNG
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.3
>Reporter: Alex D Herbert
>Assignee: Alex D Herbert
>Priority: Trivial
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The constructor for {{SplitMix64}} uses a {{Long}} for the seed. If
> constructed using a primitive {{long}} then auto-boxing will occur.
> I added a {{long}} version of the constructor to SplitMix64:
> {code:java}
> SplitMix64(Long seed);
> SplitMix64(long seed);
> {code}
> I modified the {{ConstructionPerformance}} benchmark to generate 5000 random
> seeds as {{Long}} or {{long}} then tested:
> {code:java}
> // Pre-generated Long
> new SplitMix64(Long seed);
> // Pre-generated long that is boxed to Long
> new SplitMix64(Long.valueOf(long seed));
> // Pre-generated long
> new SplitMix64(long seed);
> {code}
> Results:
> ||Method||Score||Error||Median||
> |newSplitMix64Long|34.70|0.85|34.57|
> |newSplitMix64LongValueOf|55.84|5.38|55.91|
> |newSplitMix64long|32.66|1.49|32.46|
> Given that the {{SplitMix64}} is the preferred RNG for seeding from a single
> {{long}} value it makes sense to add the constructor version that accepts a
> {{long}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[GitHub] [commons-lang] YuyuZha0 commented on issue #443: Optimize string split methods: 1. Use ThreadLocal to make reuse of th…
YuyuZha0 commented on issue #443: Optimize string split methods: 1. Use ThreadLocal to make reuse of th… URL: https://github.com/apache/commons-lang/pull/443#issuecomment-523889196 I know your opinion, but i was just thinking about where we lose the thread safety..., you see, there is a ThreadLocal. @jochenw What I'm warring about is the memory impact... This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (LANG-1478) ClassUtils getAbbreviatedName uses len one character shorter
[
https://issues.apache.org/jira/browse/LANG-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Verhas updated LANG-1478:
---
Description:
The {{ClassUtils}} method {{getAbbreviatedName}} calculates the required lenght
one character short. That way
{code}
final String ANY_CLASS_FULL_NAME = "";
assertEquals("ANY_CLASS_FULL_NAME ",
ClassUtils.getAbbreviatedName(ANY_CLASS_FULL_NAME , ANY_CLASS_FULL_NAME
.length()));
{code}
will abbreviate the class name, although we are asking exactly the same number
of characters as they are there. The solution is that
{code}
if (availableSpace > 0) {
{code}
has to be modified to
{code}
if (availableSpace >= 0) {
{code}
since the value zero means that we exactly used up the available character
width.
This is just a quick fix for this issue, but generally, the algorithm is
faulty. It runs many times out of the desired length. It actually uses the len
parameter, not as the desired final length but rather a length for which what
is out of the range on the left that has to be abbreviated. For that, the code
could be much simpler. (See LANG-1480.)
was:
The {{ClassUtils}} method {{getAbbreviatedName}} calculates the required lenght
one character short. That way
{code}
final String ANY_CLASS_FULL_NAME = "";
assertEquals("ANY_CLASS_FULL_NAME ",
ClassUtils.getAbbreviatedName(ANY_CLASS_FULL_NAME , ANY_CLASS_FULL_NAME
.length()));
{code}
will abbreviate the class name, although we are asking exactly the same number
of characters as they are there. The solution is that
{code}
if (availableSpace > 0) {
{code}
has to be modified to
{code}
if (availableSpace >= 0) {
{code}
since the value zero means that we exactly used up the available character
width.
This is just a quick fix for this issue, but generally, the algorithm is
faulty. It runs many times out of the desired length. It actually uses the len
parameter, not as the desired final length but rather a length for which what
is out of the range on the left that has to be abbreviated. For that, the code
could be much simpler.
> ClassUtils getAbbreviatedName uses len one character shorter
>
>
> Key: LANG-1478
> URL: https://issues.apache.org/jira/browse/LANG-1478
> Project: Commons Lang
> Issue Type: Bug
>Reporter: Peter Verhas
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The {{ClassUtils}} method {{getAbbreviatedName}} calculates the required
> lenght one character short. That way
> {code}
> final String ANY_CLASS_FULL_NAME = "";
> assertEquals("ANY_CLASS_FULL_NAME ",
> ClassUtils.getAbbreviatedName(ANY_CLASS_FULL_NAME , ANY_CLASS_FULL_NAME
> .length()));
> {code}
> will abbreviate the class name, although we are asking exactly the same
> number of characters as they are there. The solution is that
> {code}
> if (availableSpace > 0) {
> {code}
> has to be modified to
> {code}
> if (availableSpace >= 0) {
> {code}
> since the value zero means that we exactly used up the available character
> width.
> This is just a quick fix for this issue, but generally, the algorithm is
> faulty. It runs many times out of the desired length. It actually uses the
> len parameter, not as the desired final length but rather a length for which
> what is out of the range on the left that has to be abbreviated. For that,
> the code could be much simpler. (See LANG-1480.)
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (LANG-1478) ClassUtils getAbbreviatedName uses len one character shorter
[
https://issues.apache.org/jira/browse/LANG-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16913280#comment-16913280
]
Peter Verhas commented on LANG-1478:
The issue LANG-1480 suggests a total rewrite of the method (there is also a
pull request) that makes this request moot if LANG-1480 is accepted and merged.
> ClassUtils getAbbreviatedName uses len one character shorter
>
>
> Key: LANG-1478
> URL: https://issues.apache.org/jira/browse/LANG-1478
> Project: Commons Lang
> Issue Type: Bug
>Reporter: Peter Verhas
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The {{ClassUtils}} method {{getAbbreviatedName}} calculates the required
> lenght one character short. That way
> {code}
> final String ANY_CLASS_FULL_NAME = "";
> assertEquals("ANY_CLASS_FULL_NAME ",
> ClassUtils.getAbbreviatedName(ANY_CLASS_FULL_NAME , ANY_CLASS_FULL_NAME
> .length()));
> {code}
> will abbreviate the class name, although we are asking exactly the same
> number of characters as they are there. The solution is that
> {code}
> if (availableSpace > 0) {
> {code}
> has to be modified to
> {code}
> if (availableSpace >= 0) {
> {code}
> since the value zero means that we exactly used up the available character
> width.
> This is just a quick fix for this issue, but generally, the algorithm is
> faulty. It runs many times out of the desired length. It actually uses the
> len parameter, not as the desired final length but rather a length for which
> what is out of the range on the left that has to be abbreviated. For that,
> the code could be much simpler.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (LANG-1478) ClassUtils getAbbreviatedName uses len one character shorter
[
https://issues.apache.org/jira/browse/LANG-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16913278#comment-16913278
]
Peter Verhas commented on LANG-1478:
Issue 1480 suggest the change of the code more drastically that makes this
change invalid.
> ClassUtils getAbbreviatedName uses len one character shorter
>
>
> Key: LANG-1478
> URL: https://issues.apache.org/jira/browse/LANG-1478
> Project: Commons Lang
> Issue Type: Bug
>Reporter: Peter Verhas
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The {{ClassUtils}} method {{getAbbreviatedName}} calculates the required
> lenght one character short. That way
> {code}
> final String ANY_CLASS_FULL_NAME = "";
> assertEquals("ANY_CLASS_FULL_NAME ",
> ClassUtils.getAbbreviatedName(ANY_CLASS_FULL_NAME , ANY_CLASS_FULL_NAME
> .length()));
> {code}
> will abbreviate the class name, although we are asking exactly the same
> number of characters as they are there. The solution is that
> {code}
> if (availableSpace > 0) {
> {code}
> has to be modified to
> {code}
> if (availableSpace >= 0) {
> {code}
> since the value zero means that we exactly used up the available character
> width.
> This is just a quick fix for this issue, but generally, the algorithm is
> faulty. It runs many times out of the desired length. It actually uses the
> len parameter, not as the desired final length but rather a length for which
> what is out of the range on the left that has to be abbreviated. For that,
> the code could be much simpler.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Closed] (LANG-1474) JavaDoc was not updated of isAnyXXX in StringUtils
[
https://issues.apache.org/jira/browse/LANG-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Verhas closed LANG-1474.
--
Resolution: Fixed
> JavaDoc was not updated of isAnyXXX in StringUtils
> --
>
> Key: LANG-1474
> URL: https://issues.apache.org/jira/browse/LANG-1474
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.9
> Environment: Any environment.
>Reporter: Peter Verhas
>Priority: Trivial
> Labels: doc_cleanup
> Original Estimate: 5m
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The behavior of {{isAnyBlank}} and {{isAnyEmpty}} has changed for {{null}}
> argument from version 2.5 to 3.9. The documentation, however, was not
> changed. It still says
> {{ StringUtils.isAnyEmpty((String) null) = true}}
> and similarly for {{isAnyBlank}}.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Work logged] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[
https://issues.apache.org/jira/browse/LANG-1480?focusedWorklogId=299385&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-299385
]
ASF GitHub Bot logged work on LANG-1480:
Author: ASF GitHub Bot
Created on: 22/Aug/19 12:14
Start Date: 22/Aug/19 12:14
Worklog Time Spent: 10m
Work Description: coveralls commented on issue #446: LANG-1480
getAbbreviatedName refactored to create appropriate length …
URL: https://github.com/apache/commons-lang/pull/446#issuecomment-523879388
[](https://coveralls.io/builds/25285468)
Coverage decreased (-0.0006%) to 95.335% when pulling
**6a33956b3a48aa460c607171792397a16ab85338 on verhas:LANG-1480** into
**2f38c4b5a871bfa77a2f05e9a5859879eb7301bd on apache:master**.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 299385)
Remaining Estimate: 23h 40m (was: 23h 50m)
Time Spent: 20m (was: 10m)
> ClassUtils. getAbbreviatedName(String ,int) returns too long result
> ---
>
> Key: LANG-1480
> URL: https://issues.apache.org/jira/browse/LANG-1480
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.9
> Environment: Environment independent.
>Reporter: Peter Verhas
>Priority: Major
> Original Estimate: 24h
> Time Spent: 20m
> Remaining Estimate: 23h 40m
>
> In some cases, the algorithm decides incorrectly when to which package names
> to abbreviate. For example, abbreviating
> {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result
> {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}}
> (18 characters as requested). The reason for this is that the algorithm
> starts from the right and goes to the left abbreviating the packages and
> starts to abbreviate the packages when it runs out of the available space.
> Instead, the algorithm should start from the left and abbreviate all packages
> that would result in a too-long string without abbreviating the package name.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[GitHub] [commons-lang] coveralls commented on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length …
coveralls commented on issue #446: LANG-1480 getAbbreviatedName refactored to create appropriate length … URL: https://github.com/apache/commons-lang/pull/446#issuecomment-523879388 [](https://coveralls.io/builds/25285468) Coverage decreased (-0.0006%) to 95.335% when pulling **6a33956b3a48aa460c607171792397a16ab85338 on verhas:LANG-1480** into **2f38c4b5a871bfa77a2f05e9a5859879eb7301bd on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-lang] verhas opened a new pull request #446: LANG-1480 getAbbreviatedName refactored to create appropriate length …
verhas opened a new pull request #446: LANG-1480 getAbbreviatedName refactored to create appropriate length … URL: https://github.com/apache/commons-lang/pull/446 …short class names This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[
https://issues.apache.org/jira/browse/LANG-1480?focusedWorklogId=299378&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-299378
]
ASF GitHub Bot logged work on LANG-1480:
Author: ASF GitHub Bot
Created on: 22/Aug/19 12:02
Start Date: 22/Aug/19 12:02
Worklog Time Spent: 10m
Work Description: verhas commented on pull request #446: LANG-1480
getAbbreviatedName refactored to create appropriate length …
URL: https://github.com/apache/commons-lang/pull/446
…short class names
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 299378)
Remaining Estimate: 23h 50m (was: 24h)
Time Spent: 10m
> ClassUtils. getAbbreviatedName(String ,int) returns too long result
> ---
>
> Key: LANG-1480
> URL: https://issues.apache.org/jira/browse/LANG-1480
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.9
> Environment: Environment independent.
>Reporter: Peter Verhas
>Priority: Major
> Original Estimate: 24h
> Time Spent: 10m
> Remaining Estimate: 23h 50m
>
> In some cases, the algorithm decides incorrectly when to which package names
> to abbreviate. For example, abbreviating
> {{org.apache.commons.lang3.ClassUtils}} to the length 18 will result
> {{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}}
> (18 characters as requested). The reason for this is that the algorithm
> starts from the right and goes to the left abbreviating the packages and
> starts to abbreviate the packages when it runs out of the available space.
> Instead, the algorithm should start from the left and abbreviate all packages
> that would result in a too-long string without abbreviating the package name.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
Peter Verhas created LANG-1480:
--
Summary: ClassUtils. getAbbreviatedName(String ,int) returns too
long result
Key: LANG-1480
URL: https://issues.apache.org/jira/browse/LANG-1480
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.9
Environment: Environment independent.
Reporter: Peter Verhas
In some cases, the algorithm decides incorrectly when to which package names to
abbreviate. For example, abbreviating
{{org.apache.commons.lang3.ClassUtils}} to the length 18 will result
{{o.a.c.lang3.ClassUtils}} (22 characters) instead of {{o.a.c.l.ClassUtils}}
(18 characters as requested). The reason for this is that the algorithm starts
from the right and goes to the left abbreviating the packages and starts to
abbreviate the packages when it runs out of the available space.
Instead, the algorithm should start from the left and abbreviate all packages
that would result in a too-long string without abbreviating the package name.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (CONFIGURATION-753) Handling of interpolation is inconsistent
[
https://issues.apache.org/jira/browse/CONFIGURATION-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16913190#comment-16913190
]
Peter commented on CONFIGURATION-753:
-
Ok, I'll try and get a PR together to fix it. My preference would be to go with
the first example (first value only) so that it matches the return of
{{getString(String key)}}.
> Handling of interpolation is inconsistent
> -
>
> Key: CONFIGURATION-753
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-753
> Project: Commons Configuration
> Issue Type: Bug
> Components: Interpolation
>Affects Versions: 2.5
> Environment: Java 8, Configurations2 2.5
>Reporter: Peter
>Priority: Major
> Attachments: test.properties
>
>
> If a key is repeated in a configuration and then used in an interpolation
> elsewhere, the behaviour is inconsistent. There are other tickets/discussions
> about whether it should just pick the first value or not, but I don't think
> it should do both.
> {code:java|title=/tmp/test.properties}
> abc = hello
> abc = world
> foo.one = ${abc}
> foo.two = prefix ${abc} suffix
> {code}
> {code:java|title=Demo.java (main)}
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder builder = new
> FileBasedConfigurationBuilder(PropertiesConfiguration.class)
> .configure(params.fileBased()
> .setFileName("/tmp/test.properties")
> );
> try {
> FileBasedConfiguration config = builder.getConfiguration();
> System.out.println(config.getString("foo.one"));
> System.out.println(config.getString("foo.two"));
> } catch (ConfigurationException cex) {
> // pass
> }
> {code}
> The output from the above is
> {noformat}
> hello
> prefix [hello, world] suffix
> {noformat}
> In the first case, only the first value is being matched, in the second both
> values (and [, ]) are used.
> I'd expect the output to either be
> {noformat:title=First value only}
> hello
> prefix hello suffix
> {noformat}
> or
> {noformat:title=Both values used}
> [hello, world]
> prefix [hello, world] suffix
> {noformat}
> I can work around whichever style is chosen but think it'd be much more
> intuitive if both cases were handled the same.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[GitHub] [commons-lang] Sam-Kruglov commented on a change in pull request #398: Add ComparableUtils
Sam-Kruglov commented on a change in pull request #398: Add ComparableUtils
URL: https://github.com/apache/commons-lang/pull/398#discussion_r316578257
##
File path: src/test/java/org/apache/commons/lang3/ComparableUtilsTest.java
##
@@ -0,0 +1,178 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.lang3;
+
+import org.junit.jupiter.api.DisplayName;
+import org.junit.jupiter.api.Nested;
+import org.junit.jupiter.api.Test;
+
+import java.math.BigDecimal;
+
+import static org.apache.commons.lang3.ComparableUtils.is;
+import static org.junit.jupiter.api.Assertions.assertFalse;
+import static org.junit.jupiter.api.Assertions.assertTrue;
+
+class ComparableUtilsTest {
Review comment:
Just so I don't have to type the word "public" :D
Should I make it public?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [commons-lang] coveralls commented on issue #445: LAN-1478 class name abbreviation fix
coveralls commented on issue #445: LAN-1478 class name abbreviation fix URL: https://github.com/apache/commons-lang/pull/445#issuecomment-523807059 [](https://coveralls.io/builds/25282492) Coverage remained the same at 95.336% when pulling **ab803758b89639d0fc7b7bd8beecfc5c80c62190 on verhas:LANG-1478** into **2f38c4b5a871bfa77a2f05e9a5859879eb7301bd on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-lang] verhas opened a new pull request #445: LAN-1478 class name abbreviation fix
verhas opened a new pull request #445: LAN-1478 class name abbreviation fix URL: https://github.com/apache/commons-lang/pull/445 Fix ClassUtils class name abbreviation This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
