[jira] [Commented] (LANG-1482) Functions
[
https://issues.apache.org/jira/browse/LANG-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968903#comment-16968903
]
Peter Verhas commented on LANG-1482:
This is a long outstanding pull request. In the meantime, there were some
changes that made conflict with the master. I made the resolution. Could
someone please review it?
> Functions
> --
>
> Key: LANG-1482
> URL: https://issues.apache.org/jira/browse/LANG-1482
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Reporter: Peter Verhas
>Priority: Minor
> Fix For: 3.10
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The implementation of the methods {{asRunnable()}}, {{asConsumer()}},
> {{asCallable()}}, {{asBiConsumer()}} etc. is redundant and copy-paste. They
> are implemented with the structure (example from {{asRunnable()}}:
> {code}
> return () -> {
> try {
> pRunnable.run();
> } catch (Throwable t) {
> throw rethrow(t);
> }
> };
> {code}
> This try-catch structure is already implemented in the class and can be used
> here simplifying the method to
> {code}
> return () -> run(pRunnable);
> {code}
> Also, the tests for {{asPredicate()}} and {{asBiPredicate()}} are missing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LANG-1491) Unit tests visibility is non-conforming with JUnit 5
[
https://issues.apache.org/jira/browse/LANG-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948681#comment-16948681
]
Peter Verhas commented on LANG-1491:
There was some discussion about the visibility of the different tests.
There was a statement that we should not change the visibility of individual
methods one-by-one for consistency: as for now all test classes and methods are
`public`.
There was another statement not to change all the methods visibility because
(among other reasons) new pull requests may come in with public test methods
and it is hard manual work to review and refuse/ask modifications of those
pull-requests because of these. (Btw: that is also true if all the methods are
public: you can have pull requests that use package protected tests.)
After a long day of meeting and architecture documentation I thought it would
be fun to write a unit test that just checks if all the test classes and
methods are `public` (or the other way around NOT public if you ever decide to
have package private tests). As for now I do not want to create a pull request
for this. The major part of the code is here, just for demo:
https://github.com/verhas/commons-lang/blob/testPublic/src/test/java/org/apache/commons/lang3/TestVisibilityTest.java
What perplexed me is that the result on the current main I forked 2019-10-09
afternoon (Europe):
{code}
org.opentest4j.AssertionFailedError: Method
org.apache.commons.lang3.FunctionsTest#testAcceptBiConsumer is not public
Method org.apache.commons.lang3.FunctionsTest#testAcceptConsumer is not public
Method org.apache.commons.lang3.FunctionsTest#testAsRunnable is not public
Method org.apache.commons.lang3.FunctionsTest#testRunnable is not public
Method org.apache.commons.lang3.FunctionsTest#testAsConsumer is not public
Method org.apache.commons.lang3.FunctionsTest#testCallable is not public
Method org.apache.commons.lang3.FunctionsTest#testAsCallable is not public
Method org.apache.commons.lang3.FunctionsTest#testAsBiConsumer is not public
Class org.apache.commons.lang3.FunctionsTest should be public
Method
org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest#testLang1219
is not public
Class org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest should
be public
{code}
How should I attend to this problem? Would you like this test in a PR changing
the currently non public test to be public? Or should I include this test
testing package private into the PR that changes all test methods to package
private? Or should I just let this go altogether?
{panel:title=Side Note}
As a side note: I understand that such a unit test is not a perfect solution. I
suggest it as a temporary fix till a future release of CheckStyle will have a
check that does something similar. My son has already started working on that
(https://github.com/checkstyle/checkstyle/issues/7176).
{panel}
> Unit tests visibility is non-conforming with JUnit 5
>
>
> Key: LANG-1491
> URL: https://issues.apache.org/jira/browse/LANG-1491
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.9
>Reporter: Peter Verhas
>Priority: Major
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The used JUnit 5 library does not require that the unit test classes and
> methods be {{public}}.
> All these {{public}} keywords are only noise in the source code and have to
> be deleted. Otherwise, the code becomes inconsistent as the new and modified
> tests will be package protected as per required by the test library and the
> old tests remain public unnecessarily.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[
https://issues.apache.org/jira/browse/LANG-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939675#comment-16939675
]
Peter Verhas commented on LANG-1480:
One code reviewer (garydgregory) insists that the unit tests should be
consistent having all unit test methods and classes the same visibility. And he
is right.
On the other hand, I cannot ignore Robert C. Martin's instruction that says "Do
not ship shit." So instead of degrading the new or modified unit test applying
an outdated pattern that has no relevance any more just for the sake of
consistency I created the change in the linked issue to achieve the consistency
first and then there will be no blocking to make this bug fix merged.
> 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
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Original Estimate: 24h
> Time Spent: 7h 20m
> Remaining Estimate: 16h 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.4#803005)
[jira] [Commented] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[
https://issues.apache.org/jira/browse/LANG-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939674#comment-16939674
]
Peter Verhas commented on LANG-1480:
The code reviewer (garydgregory) insists that the unit tests should be
consistent having all unit test methods and classes the same visibility. And he
is right.
On the other hand, I cannot ignore Robert C. Martin's instruction that says "Do
not ship shit." So instead of degrading the new or modified unit test applying
an outdated pattern that has no relevance any more just for the sake of
consistency I created the change in the linked issue to achieve the consistency
first and then there will be no blocking to make this bug fix merged.
> 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
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Original Estimate: 24h
> Time Spent: 7h 20m
> Remaining Estimate: 16h 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.4#803005)
[jira] [Created] (LANG-1492) Code Cleanup
Peter Verhas created LANG-1492: -- Summary: Code Cleanup Key: LANG-1492 URL: https://issues.apache.org/jira/browse/LANG-1492 Project: Commons Lang Issue Type: Improvement Components: lang.* Affects Versions: 3.9 Reporter: Peter Verhas The code has a lot of legacy structure, which is outdated when we use Java 8 or later. These structures lessen the readability and generally lower the quality of the code. IntelliJ makes a good job analyzing these issues and the code should be cleaned up using after manual consideration. I created a branch with the modifications and I here is the pull request: https://github.com/apache/commons-lang/pull/462 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (LANG-1491) Unit tests visibility is non-conforming with JUnit 5
[
https://issues.apache.org/jira/browse/LANG-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939125#comment-16939125
]
Peter Verhas edited comment on LANG-1491 at 9/27/19 5:02 AM:
-
Here you are. Welcome.
https://github.com/apache/commons-lang/pull/461
was (Author: pe...@verhas.com):
Here you are. Welcome.
> Unit tests visibility is non-conforming with JUnit 5
>
>
> Key: LANG-1491
> URL: https://issues.apache.org/jira/browse/LANG-1491
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.9
>Reporter: Peter Verhas
>Priority: Major
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The used JUnit 5 library does not require that the unit test classes and
> methods be {{public}}.
> All these {{public}} keywords are only noise in the source code and have to
> be deleted. Otherwise, the code becomes inconsistent as the new and modified
> tests will be package protected as per required by the test library and the
> old tests remain public unnecessarily.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LANG-1491) Unit tests visibility is non-conforming with JUnit 5
[
https://issues.apache.org/jira/browse/LANG-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939125#comment-16939125
]
Peter Verhas commented on LANG-1491:
Here you are. Welcome.
> Unit tests visibility is non-conforming with JUnit 5
>
>
> Key: LANG-1491
> URL: https://issues.apache.org/jira/browse/LANG-1491
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.9
>Reporter: Peter Verhas
>Priority: Major
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The used JUnit 5 library does not require that the unit test classes and
> methods be {{public}}.
> All these {{public}} keywords are only noise in the source code and have to
> be deleted. Otherwise, the code becomes inconsistent as the new and modified
> tests will be package protected as per required by the test library and the
> old tests remain public unnecessarily.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (LANG-1491) Unit tests visibility is non-conforming with JUnit 5
[
https://issues.apache.org/jira/browse/LANG-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Verhas updated LANG-1491:
---
Description:
The used JUnit 5 library does not require that the unit test classes and
methods be {{public}}.
All these {{public}} keywords are only noise in the source code and have to be
deleted. Otherwise, the code becomes inconsistent as the new and modified tests
will be package protected as per required by the test library and the old tests
remain public unnecessarily.
was:
The used JUnit 5 library does not require that the unit test classes and
methods be {{public}}.
All these {{public}} keywords are only noise in the source code and have to be
deleted.
> Unit tests visibility is non-conforming with JUnit 5
>
>
> Key: LANG-1491
> URL: https://issues.apache.org/jira/browse/LANG-1491
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.9
>Reporter: Peter Verhas
>Priority: Major
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The used JUnit 5 library does not require that the unit test classes and
> methods be {{public}}.
> All these {{public}} keywords are only noise in the source code and have to
> be deleted. Otherwise, the code becomes inconsistent as the new and modified
> tests will be package protected as per required by the test library and the
> old tests remain public unnecessarily.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (LANG-1491) Unit tests visibility is non-conforming with JUnit 5
Peter Verhas created LANG-1491:
--
Summary: Unit tests visibility is non-conforming with JUnit 5
Key: LANG-1491
URL: https://issues.apache.org/jira/browse/LANG-1491
Project: Commons Lang
Issue Type: Improvement
Components: lang.*
Affects Versions: 3.9
Reporter: Peter Verhas
The used JUnit 5 library does not require that the unit test classes and
methods be {{public}}.
All these {{public}} keywords are only noise in the source code and have to be
deleted.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[
https://issues.apache.org/jira/browse/LANG-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16931253#comment-16931253
]
Peter Verhas commented on LANG-1480:
Is there anything I should do to get this pull request merged?
> 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
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Original Estimate: 24h
> Time Spent: 3.5h
> Remaining Estimate: 20.5h
>
> 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] (LANG-1482) Functions
[
https://issues.apache.org/jira/browse/LANG-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16927169#comment-16927169
]
Peter Verhas commented on LANG-1482:
You cannot find it, because it is not there. This is related to a modification
change that was developed (in a wrong style btw, hence this ticket) and not yet
merged. Also have alook at the pull request:
https://github.com/apache/commons-lang/pull/448
I created to fix the implementation and also adding some more tests as the
original developer did not cover all new code with test.
> Functions
> --
>
> Key: LANG-1482
> URL: https://issues.apache.org/jira/browse/LANG-1482
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Reporter: Peter Verhas
>Priority: Minor
> Fix For: 3.10
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The implementation of the methods {{asRunnable()}}, {{asConsumer()}},
> {{asCallable()}}, {{asBiConsumer()}} etc. is redundant and copy-paste. They
> are implemented with the structure (example from {{asRunnable()}}:
> {code}
> return () -> {
> try {
> pRunnable.run();
> } catch (Throwable t) {
> throw rethrow(t);
> }
> };
> {code}
> This try-catch structure is already implemented in the class and can be used
> here simplifying the method to
> {code}
> return () -> run(pRunnable);
> {code}
> Also, the tests for {{asPredicate()}} and {{asBiPredicate()}} are missing.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Comment Edited] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[
https://issues.apache.org/jira/browse/LANG-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915664#comment-16915664
]
Peter Verhas edited comment on LANG-1480 at 8/30/19 2:53 PM:
-
I updated the code to contain only the changes that are related to the issue.
The fact that the coverage in terms of percentage decreased is a good thing.
Think about it. I replaced a 100% covered but a complex and unnecessarily long
method with a shorter, but also 100% covered one. If nothing else changes and
the coverage of the whole project is less than 100% then the overall coverage
will decrease. E.g.: you have a 200 LOC project. Coverage is 50%. You replace a
20 LOC/100% covered method with a 10 LOC/100% covered one. The coverage will
decrease to 47.36%.
was (Author: pe...@verhas.com):
I updated the code to contain only the changes that are related to the issue.
The fact that the coverage in terms of percentage decreased is a good thing.
Think about it. I replaced a 100% covered but a complex and unnecessarily long
method with a shorter, but also 100% covered one. If nothing else changes and
the coverage of the whole project is less than 100% then the overall coverage
will decrease. E.g.: you have a 200 LOC project. Coverage is 50%. You replace a
20 LOC/100% covered method with a 10 LOC/100% covered one. The coverage will
decrease to 45%.
> 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
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Original Estimate: 24h
> Time Spent: 3.5h
> Remaining Estimate: 20.5h
>
> 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-1483) Demonstrate Java::Geci possible use
Peter Verhas created LANG-1483: -- Summary: Demonstrate Java::Geci possible use Key: LANG-1483 URL: https://issues.apache.org/jira/browse/LANG-1483 Project: Commons Lang Issue Type: Improvement Reporter: Peter Verhas This issue is to have a ticket number for the pull request/branch that will demonstrate the possible use of Java::Geci in Commons Lang. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (LANG-696) Deprecate ClassUtils getShortClassName in favor of Class getSimpleName
[ https://issues.apache.org/jira/browse/LANG-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916671#comment-16916671 ] Peter Verhas commented on LANG-696: --- I created a pull request for this issue, but not about the deprecation, rather extending the JavaDoc with more explanation and examples and also with some more explanatory unit tests. > Deprecate ClassUtils getShortClassName in favor of Class getSimpleName > -- > > Key: LANG-696 > URL: https://issues.apache.org/jira/browse/LANG-696 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Affects Versions: 2.6 >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: Discussion > > Time Spent: 10m > Remaining Estimate: 0h > > Added two null-safe ClassUtils.getSimpleName() APIs. > -- Forwarded message -- > From: Gary Gregory > Date: Mon, Apr 11, 2011 at 10:18 AM > Subject: [Lang] ClassUtils getShortClassName != Class getSimpleName > To: Commons Developers List > Hi All: > Should we deprecate ClassUtils getShortClassName in favor of Class > getSimpleName? > The behavior of getShortClassName is undocumented for arrays in the Javadoc > and is different from getSimpleName. > When I replace the guts of getShortClassName to call getSimpleName, one test > fails: > junit.framework.ComparisonFailure: null > expected:<[ToStringStyleTest.]Person[name=John Q. ...> but > was:<[]Person[name=John Q. ...> > at junit.framework.Assert.assertEquals(Assert.java:81) > at junit.framework.Assert.assertEquals(Assert.java:87) > at > org.apache.commons.lang3.builder.ShortPrefixToStringStyleTest.testPerson(ShortPrefixToStringStyleTest.java:86) > For now, I've made a note in the Javdoc to consider using getSimpleName. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (LANG-696) Deprecate ClassUtils getShortClassName in favor of Class getSimpleName
[ https://issues.apache.org/jira/browse/LANG-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916016#comment-16916016 ] Peter Verhas commented on LANG-696: --- getShortClass name will return the name of the class without the package structure in front of that, while getSimpleName returns the name of the class without the packages structure AND nesting class structure. So the two are not the same, as the unit test clearly show when testing the two for Map.Entry. > Deprecate ClassUtils getShortClassName in favor of Class getSimpleName > -- > > Key: LANG-696 > URL: https://issues.apache.org/jira/browse/LANG-696 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Affects Versions: 2.6 >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: Discussion > > > Added two null-safe ClassUtils.getSimpleName() APIs. > -- Forwarded message -- > From: Gary Gregory > Date: Mon, Apr 11, 2011 at 10:18 AM > Subject: [Lang] ClassUtils getShortClassName != Class getSimpleName > To: Commons Developers List > Hi All: > Should we deprecate ClassUtils getShortClassName in favor of Class > getSimpleName? > The behavior of getShortClassName is undocumented for arrays in the Javadoc > and is different from getSimpleName. > When I replace the guts of getShortClassName to call getSimpleName, one test > fails: > junit.framework.ComparisonFailure: null > expected:<[ToStringStyleTest.]Person[name=John Q. ...> but > was:<[]Person[name=John Q. ...> > at junit.framework.Assert.assertEquals(Assert.java:81) > at junit.framework.Assert.assertEquals(Assert.java:87) > at > org.apache.commons.lang3.builder.ShortPrefixToStringStyleTest.testPerson(ShortPrefixToStringStyleTest.java:86) > For now, I've made a note in the Javdoc to consider using getSimpleName. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (LANG-1482) Functions
[
https://issues.apache.org/jira/browse/LANG-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Verhas updated LANG-1482:
---
Description:
The implementation of the methods {{asRunnable()}}, {{asConsumer()}},
{{asCallable()}}, {{asBiConsumer()}} etc. is redundant and copy-paste. They are
implemented with the structure (example from {{asRunnable()}}:
{code}
return () -> {
try {
pRunnable.run();
} catch (Throwable t) {
throw rethrow(t);
}
};
{code}
This try-catch structure is already implemented in the class and can be used
here simplifying the method to
{code}
return () -> run(pRunnable);
{code}
Also, the tests for {{asPredicate()}} and {{asBiPredicate()}} are missing.
was:
The implementation of the methods {{asRunnable()}}, {{asConsumer()}},
{{asCallable()}}, {{asBiConsumer()}} etc. is redundant and copy-paste. They are
implemented with the structure (example from {{asRunnable()}}:
{code}
return () -> {
try {
pRunnable.run();
} catch (Throwable t) {
throw rethrow(t);
}
};
{code}
This try-catch structure is already implemented in the class and can be used
here simplifying the method to
{code}
return () -> run(pRunnable);
{code}
Also, the tests for these methods are missing (except for the one
{{asRunnable()}).
> Functions
> --
>
> Key: LANG-1482
> URL: https://issues.apache.org/jira/browse/LANG-1482
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Reporter: Peter Verhas
>Priority: Minor
> Fix For: 3.10
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The implementation of the methods {{asRunnable()}}, {{asConsumer()}},
> {{asCallable()}}, {{asBiConsumer()}} etc. is redundant and copy-paste. They
> are implemented with the structure (example from {{asRunnable()}}:
> {code}
> return () -> {
> try {
> pRunnable.run();
> } catch (Throwable t) {
> throw rethrow(t);
> }
> };
> {code}
> This try-catch structure is already implemented in the class and can be used
> here simplifying the method to
> {code}
> return () -> run(pRunnable);
> {code}
> Also, the tests for {{asPredicate()}} and {{asBiPredicate()}} are missing.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (LANG-1482) Functions
Peter Verhas created LANG-1482:
--
Summary: Functions
Key: LANG-1482
URL: https://issues.apache.org/jira/browse/LANG-1482
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Reporter: Peter Verhas
Fix For: 3.10
The implementation of the methods {{asRunnable()}}, {{asConsumer()}},
{{asCallable()}}, {{asBiConsumer()}} etc. is redundant and copy-paste. They are
implemented with the structure (example from {{asRunnable()}}:
{code}
return () -> {
try {
pRunnable.run();
} catch (Throwable t) {
throw rethrow(t);
}
};
{code}
This try-catch structure is already implemented in the class and can be used
here simplifying the method to
{code}
return () -> run(pRunnable);
{code}
Also, the tests for these methods are missing (except for the one
{{asRunnable()}).
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Commented] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[
https://issues.apache.org/jira/browse/LANG-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915675#comment-16915675
]
Peter Verhas commented on LANG-1480:
As for the Travis issue:
I fixed the import * to the original as part of the accidental reformatting.
The other Travis issues are related to Functions.java that contains tabs
instead of spaces, which is not part of this pull request. I did not change
that. Seems like some error in the master. PLEASE HELP
Note: Fact is that the change in Functions.java was suggested by me. But I did
not develop it. Somebody else of the team developed it and not the way I
suggested and it still got merged into the master. When I will have time I will
open a separate ticket, make the code simpler and create a pull request, but
that is a totally different issue.
> 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
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Original Estimate: 24h
> Time Spent: 3.5h
> Remaining Estimate: 20.5h
>
> 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] [Issue Comment Deleted] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[
https://issues.apache.org/jira/browse/LANG-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Verhas updated LANG-1480:
---
Comment: was deleted
(was: I updated the code to contain only the changes that are related to the
issue.
The fact that the coverage in terms of percentage decreased is a good thing.
Think about it. I replaced a 100% covered but a complex and unnecessarily long
method with a shorter, but also 100% covered one. If nothing else changes and
the coverage of the whole project is less than 100% then the overall coverage
will decrease. E.g.: you have a 200 LOC project. Coverage is 50%. You replace a
20 LOC/100% covered method with a 10 LOC/100% covered one. The coverage will
decrease to 45%.)
> 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
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Original Estimate: 24h
> Time Spent: 3h 20m
> Remaining Estimate: 20h 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)
[jira] [Commented] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[
https://issues.apache.org/jira/browse/LANG-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915665#comment-16915665
]
Peter Verhas commented on LANG-1480:
I updated the code to contain only the changes that are related to the issue.
The fact that the coverage in terms of percentage decreased is a good thing.
Think about it. I replaced a 100% covered but a complex and unnecessarily long
method with a shorter, but also 100% covered one. If nothing else changes and
the coverage of the whole project is less than 100% then the overall coverage
will decrease. E.g.: you have a 200 LOC project. Coverage is 50%. You replace a
20 LOC/100% covered method with a 10 LOC/100% covered one. The coverage will
decrease to 45%.
> 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
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Original Estimate: 24h
> Time Spent: 3h 10m
> Remaining Estimate: 20h 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] [Commented] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[
https://issues.apache.org/jira/browse/LANG-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915664#comment-16915664
]
Peter Verhas commented on LANG-1480:
I updated the code to contain only the changes that are related to the issue.
The fact that the coverage in terms of percentage decreased is a good thing.
Think about it. I replaced a 100% covered but a complex and unnecessarily long
method with a shorter, but also 100% covered one. If nothing else changes and
the coverage of the whole project is less than 100% then the overall coverage
will decrease. E.g.: you have a 200 LOC project. Coverage is 50%. You replace a
20 LOC/100% covered method with a 10 LOC/100% covered one. The coverage will
decrease to 45%.
> 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
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Original Estimate: 24h
> Time Spent: 3h 10m
> Remaining Estimate: 20h 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] [Commented] (LANG-1480) ClassUtils. getAbbreviatedName(String ,int) returns too long result
[
https://issues.apache.org/jira/browse/LANG-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16915506#comment-16915506
]
Peter Verhas commented on LANG-1480:
Here more than there. This is a change that, imho, should NOT go into 3.x This
is a major functionality change even though this is closer to the behavior
described by the documentation and thus the current implementation is the "more
faulty".
> 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
>Assignee: Bruno P. Kinoshita
>Priority: Major
> Original Estimate: 24h
> Time Spent: 1h 20m
> Remaining Estimate: 22h 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)
[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=16915505#comment-16915505
]
Peter Verhas commented on LANG-1478:
It is not only that case. It is in every case where `a.b.c.ddd. ...` would be
OK and just exactly the required length (`a`, `b`, `c` are abbreviated in this
sample, but `ddd` is not). The current algorithm will abbreviate it to
`a.b.c.d. ...` abbreviating `ddd` unnecessarily.
I agree with you that a change like that may not be introduced in a minor
release, but it does not seem to a strict policy. My project was broken
upgrading from 3.4 to 3.9 as `isAnyEmpty(null)` changed from true to false.
If the decision is that we have to wait for a major release then I suggest NOT
TO IMPLEMENT this change, but rather the one I suggested in LANG-1480.
What is your opinion about that?
> 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
>Affects Versions: 3.9
>Reporter: Peter Verhas
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Time Spent: 50m
> 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-1474) JavaDoc was not updated of isAnyXXX in StringUtils
[
https://issues.apache.org/jira/browse/LANG-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914256#comment-16914256
]
Peter Verhas commented on LANG-1474:
I cannot see here the comment I attached to the "open -> close" transition so
here it is again.
It is my mistake. I misread the documentation and I am sorry for that.
> 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] [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=16914252#comment-16914252
]
Peter Verhas commented on LANG-1477:
Yes, and no. This is the functionality I was looking for, but the
implementation is copy-paste. The same structure already exists in the static
method {{Functions.run(FailableRunnable pRunnable)}}. Therefore the
implementation of the functions has to be
{code:java}
static Runnable castToRunnable(FailableRunnable s) {
return () -> run(s);
}
{code}
And when I realized that the implementation is so simple, I am now less
convinced that we need this {{asRunnable(FailableRunnable pRunnable)}}
function /and the similar others/ at all.
Even though I suggested this change in the first place I would vote not to
implement it into the class {{Functions}} increasing the footprint of the API.
Instead, I would go for extending the documentation explaining that the already
available methods, like {{run(FailableRunnable pRunnable)}} can be used as
{{()->run(pRunnable)}} to convert a {{FailableRunnable}} to a {{Runnable}}.
> 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] [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=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=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] [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] [Created] (LANG-1478) ClassUtils getAbbreviatedName uses len one character shorter
Peter Verhas created LANG-1478:
--
Summary: 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
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-1477) Implement castToXXX in Functions class
[
https://issues.apache.org/jira/browse/LANG-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Verhas closed LANG-1477.
--
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
>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] [Updated] (LANG-1477) Implement castToXXX in Functions class
[
https://issues.apache.org/jira/browse/LANG-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Verhas updated LANG-1477:
---
Description:
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}
was:
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 () -> {
try {
s.run();
} catch (Throwable k) {
rethrow(k);
}
};
}{code}
I believe that these casting methods will have a huge user base for the
application when a lambda expression throws checked exception and is to be used
inside a stream chain. Apache Commons is a well-established library to become
the de-facto standard if it gets implemented.
I will implement the change and will issue a pull request as my free time
allows.
> 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)
[jira] [Updated] (LANG-1477) Implement castToXXX in Functions class
[
https://issues.apache.org/jira/browse/LANG-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Verhas updated LANG-1477:
---
Summary: Implement castToXXX in Functions class (was: Implement caseToXXX
in Functions class)
> 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 () -> {
> try {
> s.run();
> } catch (Throwable k) {
> rethrow(k);
> }
> };
> }{code}
>
> I believe that these casting methods will have a huge user base for the
> application when a lambda expression throws checked exception and is to be
> used inside a stream chain. Apache Commons is a well-established library to
> become the de-facto standard if it gets implemented.
>
> I will implement the change and will issue a pull request as my free time
> allows.
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (LANG-1477) Implement caseToXXX in Functions class
Peter Verhas created LANG-1477:
--
Summary: Implement caseToXXX 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
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 () -> {
try {
s.run();
} catch (Throwable k) {
rethrow(k);
}
};
}{code}
I believe that these casting methods will have a huge user base for the
application when a lambda expression throws checked exception and is to be used
inside a stream chain. Apache Commons is a well-established library to become
the de-facto standard if it gets implemented.
I will implement the change and will issue a pull request as my free time
allows.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] Created: (CONFIGURATION-354) XML configuration handles non-default list delimiter bad way
XML configuration handles non-default list delimiter bad way
Key: CONFIGURATION-354
URL: https://issues.apache.org/jira/browse/CONFIGURATION-354
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.5
Environment: Windows XP Home edition, Java 1.6.0_07
Reporter: Peter Verhas
Priority: Minor
When setting the list separator character the XML configuration engine does not
handle the lists properly. Sample code:
Junit test code:
{code}
public void testConfig() {
CompositeConfiguration conf = null;
try {
conf = (CompositeConfiguration) new
ConfigurationFactory(config.xml).getConfiguration();
} catch (ConfigurationException ex) {
Logger.getLogger(TestConfig.class.getName()).log(Level.SEVERE,
null, ex);
return;
}
PrintStream o = System.out;
conf.setListDelimiter(conf.getString(list.delimiter).charAt(0));
o.println(c= + conf.getString(c));
o.println(x=+conf.getString(key.subkey(1)));
o.print(System.getProperty(java.version));
}
{code}
The config.xml contains
{code}
?xml version=1.0 encoding=utf-8?
configuration
xml fileName=application.xml/
/configuration
{code}
and finally the application.xml is
{code}
?xml version=1.0 encoding=windows-1250?
konfig
listdelimiter\,/delimiter/list
key
subkeyone,two,three/subkey
subkey four/subkey
/key
c${key.subkey(1)}/c
/konfig
{code}
The resulting output is:
{code}
c=two
x=two
1.6.0_07
{code}
This is correct so far. This is the case when I comment out the
{{setListDelimiter}} code line. After this I change the application.xml to
{code}
?xml version=1.0 encoding=windows-1250?
konfig
listdelimiter;/delimiter/list
key
subkeyone;two;three/subkey
subkey four/subkey
/key
c${key.subkey(1)}/c
/konfig
{code}
even though I expect the same result what I got was:
{code}
c=four
x=four
1.6.0_07
{code}
Do I miss some point or {{setListDelimiter}} does not work for XML files?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (CONFIGURATION-354) XML configuration handles non-default list delimiter bad way
[
https://issues.apache.org/jira/browse/CONFIGURATION-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Verhas closed CONFIGURATION-354.
--
Resolution: Fixed
Fix Version/s: 1.5
I tried to modify the {{config.xml}} file as you pointed and it works fine.
This also means that now I did try it out for {{ConfigurationFactory}}. :-)
I was not aware that {{config.txt}} may also define the list delimiter.
As for my case this is a very good practice. I am developing company policy
regarding the use of commons config and I will discourage to use list inside
XML configuration. This means that listDelimiter will be set to something like
{code}
?xml version=1.0 encoding=utf-8?
configuration
xml fileName=application.xml listDelimiter=\u/
/configuration
{code}
which will prevent to interpret any probable character as list delimiter.
Thanks,
Peter
XML configuration handles non-default list delimiter bad way
Key: CONFIGURATION-354
URL: https://issues.apache.org/jira/browse/CONFIGURATION-354
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.5
Environment: Windows XP Home edition, Java 1.6.0_07
Reporter: Peter Verhas
Priority: Minor
Fix For: 1.5
When setting the list separator character the XML configuration engine does
not handle the lists properly. Sample code:
Junit test code:
{code}
public void testConfig() {
CompositeConfiguration conf = null;
try {
conf = (CompositeConfiguration) new
ConfigurationFactory(config.xml).getConfiguration();
} catch (ConfigurationException ex) {
Logger.getLogger(TestConfig.class.getName()).log(Level.SEVERE,
null, ex);
return;
}
PrintStream o = System.out;
conf.setListDelimiter(conf.getString(list.delimiter).charAt(0));
o.println(c= + conf.getString(c));
o.println(x=+conf.getString(key.subkey(1)));
o.print(System.getProperty(java.version));
}
{code}
The config.xml contains
{code}
?xml version=1.0 encoding=utf-8?
configuration
xml fileName=application.xml/
/configuration
{code}
and finally the application.xml is
{code}
?xml version=1.0 encoding=windows-1250?
konfig
listdelimiter\,/delimiter/list
key
subkeyone,two,three/subkey
subkey four/subkey
/key
c${key.subkey(1)}/c
/konfig
{code}
The resulting output is:
{code}
c=two
x=two
1.6.0_07
{code}
This is correct so far. This is the case when I comment out the
{{setListDelimiter}} code line. After this I change the application.xml to
{code}
?xml version=1.0 encoding=windows-1250?
konfig
listdelimiter;/delimiter/list
key
subkeyone;two;three/subkey
subkey four/subkey
/key
c${key.subkey(1)}/c
/konfig
{code}
even though I expect the same result what I got was:
{code}
c=four
x=four
1.6.0_07
{code}
Do I miss some point or {{setListDelimiter}} does not work for XML files?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
