[jira] [Comment Edited] (LANG-898) StringEscapeUtils un/escapexml inconsistant with escaped whitespace
[
https://issues.apache.org/jira/browse/LANG-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13799973#comment-13799973
]
Thomas Neidhart edited comment on LANG-898 at 10/20/13 8:07 AM:
Afaik, it is not mandatory to escape CR LF in xml documents, thus it is also
not done by default when calling StringEscapeUtils.escapeXml.
You can create your own translater that will also escape LF like this:
{noformat}
StringEscapeUtils.ESCAPE_XML.with(NumericEntityEscaper.between(0x0F,
0x11)).translate(...);
{noformat}
was (Author: tn):
Afaik, it is not mandatory to escape CR LF in xml documents, thus it is also
not done by default when calling StringEscapeUtils.escapeXml.
You can create your own translater that will also escape LF like this:
{noformat}
StringEscapeUtils.ESCAPE_XML.with(NumericEntityEscaper.between(0x09,
0x11)).translate(...);
{noformat}
StringEscapeUtils un/escapexml inconsistant with escaped whitespace
---
Key: LANG-898
URL: https://issues.apache.org/jira/browse/LANG-898
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.1
Environment: Windows 7, Java 7
Reporter: Martin Barrs
Priority: Minor
{noformat}
In an escaped XML string with escaped whitespace, in this case linefeed (
#10; ), escapexml and unescapexml treat the linefeed inconsistently.
unescape converts #10; to a linefeed, yet escapexml does not convert
linefeed back to #10;
Here's code and output...
public static void main(String[] args) {
String escaped =
lt;?xml version=quot;1.0quot;
encoding=quot;iso-8859-1quot;?gt;#10;lt;?xml version=quot;1.0quot;
encoding=quot;iso-8859-1quot;?gt;;
System.out.println(escaped);
System.out.println();
System.out.println(StringEscapeUtils.unescapeXml(escaped));
System.out.println();
System.out.println(StringEscapeUtils.escapeXml(StringEscapeUtils
.unescapeXml(escaped)));
}
Output:
lt;?xml version=quot;1.0quot;
encoding=quot;iso-8859-1quot;?gt;#10;lt;?xml version=quot;1.0quot;
encoding=quot;iso-8859-1quot;?gt;
?xml version=1.0 encoding=iso-8859-1?
?xml version=1.0 encoding=iso-8859-1?
lt;?xml version=quot;1.0quot; encoding=quot;iso-8859-1quot;?gt;
lt;?xml version=quot;1.0quot; encoding=quot;iso-8859-1quot;?gt;
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (LANG-898) StringEscapeUtils un/escapexml inconsistant with escaped whitespace
[
https://issues.apache.org/jira/browse/LANG-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13799973#comment-13799973
]
Thomas Neidhart edited comment on LANG-898 at 10/20/13 8:09 AM:
Afaik, it is not mandatory to escape CR LF in xml documents, thus it is also
not done by default when calling StringEscapeUtils.escapeXml.
You can create your own translater that will also escape LF like this:
{noformat}
StringEscapeUtils.ESCAPE_XML.with(NumericEntityEscaper.between(0x09,
0x0B)).translate(...);
{noformat}
was (Author: tn):
Afaik, it is not mandatory to escape CR LF in xml documents, thus it is also
not done by default when calling StringEscapeUtils.escapeXml.
You can create your own translater that will also escape LF like this:
{noformat}
StringEscapeUtils.ESCAPE_XML.with(NumericEntityEscaper.between(0x0F,
0x11)).translate(...);
{noformat}
StringEscapeUtils un/escapexml inconsistant with escaped whitespace
---
Key: LANG-898
URL: https://issues.apache.org/jira/browse/LANG-898
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.1
Environment: Windows 7, Java 7
Reporter: Martin Barrs
Priority: Minor
{noformat}
In an escaped XML string with escaped whitespace, in this case linefeed (
#10; ), escapexml and unescapexml treat the linefeed inconsistently.
unescape converts #10; to a linefeed, yet escapexml does not convert
linefeed back to #10;
Here's code and output...
public static void main(String[] args) {
String escaped =
lt;?xml version=quot;1.0quot;
encoding=quot;iso-8859-1quot;?gt;#10;lt;?xml version=quot;1.0quot;
encoding=quot;iso-8859-1quot;?gt;;
System.out.println(escaped);
System.out.println();
System.out.println(StringEscapeUtils.unescapeXml(escaped));
System.out.println();
System.out.println(StringEscapeUtils.escapeXml(StringEscapeUtils
.unescapeXml(escaped)));
}
Output:
lt;?xml version=quot;1.0quot;
encoding=quot;iso-8859-1quot;?gt;#10;lt;?xml version=quot;1.0quot;
encoding=quot;iso-8859-1quot;?gt;
?xml version=1.0 encoding=iso-8859-1?
?xml version=1.0 encoding=iso-8859-1?
lt;?xml version=quot;1.0quot; encoding=quot;iso-8859-1quot;?gt;
lt;?xml version=quot;1.0quot; encoding=quot;iso-8859-1quot;?gt;
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800138#comment-13800138
]
Benedikt Ritter commented on LANG-916:
--
Setting this to Review Patch.
CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in
certain situations
Key: LANG-916
URL: https://issues.apache.org/jira/browse/LANG-916
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 3.1
Environment: Sun JDK 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
3.9.10-100.fc17.i686.PAE).
Reporter: Christian P. MOMON
Labels: patch
Fix For: 2.7, Review Patch
Attachments: LANG-916.patch
In LANG-538 issue, there is an unit test:
{noformat}
public void testFormat_CalendarIsoMsZulu() {
final String dateTime = 2009-10-16T16:42:16.000Z;
GregorianCalendar cal = new
GregorianCalendar(TimeZone.getTimeZone(GMT-8));
cal.clear();
cal.set(2009, 9, 16, 8, 42, 16);
cal.getTime();
FastDateFormat format =
FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(GMT));
assertEquals(dateTime, dateTime, format.format(cal));
}
{noformat}
This test passes successfully in lang-2.6 but failed in lang3-3.1:
{noformat}
org.junit.ComparisonFailure: dateTime expected:2009-10-16T[16]:42:16.000Z
but was:2009-10-16T[08]:42:16.000Z
{noformat}
Reproduced whit Sun Java version: 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
3.9.10-100.fc17.i686.PAE).
Moreover, I wrote another unit test showing that the timeZone parameter seems
to be ignored :
{noformat}
public void test() {
Calendar cal =
Calendar.getInstance(TimeZone.getTimeZone(Europe/Paris));
cal.set(2009, 9, 16, 8, 42, 16);
//
System.out.println(DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.format(cal));
System.out.println(long);
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getDefault()));
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Asia/Kolkata)));
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Europe/London)));
System.out.println(calendar);
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getDefault()));
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Asia/Kolkata)));
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Europe/London)));
System.out.println(calendar fast);
System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Europe/Paris)).format(cal));
System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Asia/Kolkata)).format(cal));
System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Europe/London)).format(cal));
}
{noformat}
Gives the following console logs:
{noformat}
long
2009-10-16T08:42:16+02:00
2009-10-16T12:12:16+05:30
2009-10-16T07:42:16+01:00
calendar
2009-10-16T08:42:16+02:00
2009-10-16T08:42:16+02:00
2009-10-16T08:42:16+02:00
calendar fast
2009-10-16T08:42:16.975Z
2009-10-16T08:42:16.975Z
2009-10-16T08:42:16.975Z
{noformat}
When DateFormatUtils.format takes a long parameter, the time string is good.
When DateFormatUtils.format takes a Calendar parameter, the time string is
wrong, the timezone parameter is IGNORED.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated LANG-916:
-
Fix Version/s: Review Patch
CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in
certain situations
Key: LANG-916
URL: https://issues.apache.org/jira/browse/LANG-916
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 3.1
Environment: Sun JDK 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
3.9.10-100.fc17.i686.PAE).
Reporter: Christian P. MOMON
Labels: patch
Fix For: 2.7, Review Patch
Attachments: LANG-916.patch
In LANG-538 issue, there is an unit test:
{noformat}
public void testFormat_CalendarIsoMsZulu() {
final String dateTime = 2009-10-16T16:42:16.000Z;
GregorianCalendar cal = new
GregorianCalendar(TimeZone.getTimeZone(GMT-8));
cal.clear();
cal.set(2009, 9, 16, 8, 42, 16);
cal.getTime();
FastDateFormat format =
FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(GMT));
assertEquals(dateTime, dateTime, format.format(cal));
}
{noformat}
This test passes successfully in lang-2.6 but failed in lang3-3.1:
{noformat}
org.junit.ComparisonFailure: dateTime expected:2009-10-16T[16]:42:16.000Z
but was:2009-10-16T[08]:42:16.000Z
{noformat}
Reproduced whit Sun Java version: 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
3.9.10-100.fc17.i686.PAE).
Moreover, I wrote another unit test showing that the timeZone parameter seems
to be ignored :
{noformat}
public void test() {
Calendar cal =
Calendar.getInstance(TimeZone.getTimeZone(Europe/Paris));
cal.set(2009, 9, 16, 8, 42, 16);
//
System.out.println(DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.format(cal));
System.out.println(long);
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getDefault()));
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Asia/Kolkata)));
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Europe/London)));
System.out.println(calendar);
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getDefault()));
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Asia/Kolkata)));
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Europe/London)));
System.out.println(calendar fast);
System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Europe/Paris)).format(cal));
System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Asia/Kolkata)).format(cal));
System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Europe/London)).format(cal));
}
{noformat}
Gives the following console logs:
{noformat}
long
2009-10-16T08:42:16+02:00
2009-10-16T12:12:16+05:30
2009-10-16T07:42:16+01:00
calendar
2009-10-16T08:42:16+02:00
2009-10-16T08:42:16+02:00
2009-10-16T08:42:16+02:00
calendar fast
2009-10-16T08:42:16.975Z
2009-10-16T08:42:16.975Z
2009-10-16T08:42:16.975Z
{noformat}
When DateFormatUtils.format takes a long parameter, the time string is good.
When DateFormatUtils.format takes a Calendar parameter, the time string is
wrong, the timezone parameter is IGNORED.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-905) Compare between arrays
[ https://issues.apache.org/jira/browse/LANG-905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated LANG-905: - Fix Version/s: Review Patch Compare between arrays -- Key: LANG-905 URL: https://issues.apache.org/jira/browse/LANG-905 Project: Commons Lang Issue Type: Bug Reporter: E Labels: patch Fix For: Review Patch Attachments: LANG-905.patch when comparing 2 arrays, EqualsBuilder returns true even if they contain different elements. example: Object[] o1 = new Object[1]; o1[0]=Hello; Object[] o2 = new Object[1]; o2[0]=Bye; System.out.println(EqualsBuilder.reflectionEquals(o1, o2, true)); -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-898) StringEscapeUtils un/escapexml inconsistant with escaped whitespace
[
https://issues.apache.org/jira/browse/LANG-898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated LANG-898:
-
Fix Version/s: Discussion
StringEscapeUtils un/escapexml inconsistant with escaped whitespace
---
Key: LANG-898
URL: https://issues.apache.org/jira/browse/LANG-898
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.1
Environment: Windows 7, Java 7
Reporter: Martin Barrs
Priority: Minor
Fix For: Discussion
{noformat}
In an escaped XML string with escaped whitespace, in this case linefeed (
#10; ), escapexml and unescapexml treat the linefeed inconsistently.
unescape converts #10; to a linefeed, yet escapexml does not convert
linefeed back to #10;
Here's code and output...
public static void main(String[] args) {
String escaped =
lt;?xml version=quot;1.0quot;
encoding=quot;iso-8859-1quot;?gt;#10;lt;?xml version=quot;1.0quot;
encoding=quot;iso-8859-1quot;?gt;;
System.out.println(escaped);
System.out.println();
System.out.println(StringEscapeUtils.unescapeXml(escaped));
System.out.println();
System.out.println(StringEscapeUtils.escapeXml(StringEscapeUtils
.unescapeXml(escaped)));
}
Output:
lt;?xml version=quot;1.0quot;
encoding=quot;iso-8859-1quot;?gt;#10;lt;?xml version=quot;1.0quot;
encoding=quot;iso-8859-1quot;?gt;
?xml version=1.0 encoding=iso-8859-1?
?xml version=1.0 encoding=iso-8859-1?
lt;?xml version=quot;1.0quot; encoding=quot;iso-8859-1quot;?gt;
lt;?xml version=quot;1.0quot; encoding=quot;iso-8859-1quot;?gt;
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (LANG-898) StringEscapeUtils un/escapexml inconsistant with escaped whitespace
[
https://issues.apache.org/jira/browse/LANG-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800139#comment-13800139
]
Benedikt Ritter commented on LANG-898:
--
Resolve as not a problem?
StringEscapeUtils un/escapexml inconsistant with escaped whitespace
---
Key: LANG-898
URL: https://issues.apache.org/jira/browse/LANG-898
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.1
Environment: Windows 7, Java 7
Reporter: Martin Barrs
Priority: Minor
Fix For: Discussion
{noformat}
In an escaped XML string with escaped whitespace, in this case linefeed (
#10; ), escapexml and unescapexml treat the linefeed inconsistently.
unescape converts #10; to a linefeed, yet escapexml does not convert
linefeed back to #10;
Here's code and output...
public static void main(String[] args) {
String escaped =
lt;?xml version=quot;1.0quot;
encoding=quot;iso-8859-1quot;?gt;#10;lt;?xml version=quot;1.0quot;
encoding=quot;iso-8859-1quot;?gt;;
System.out.println(escaped);
System.out.println();
System.out.println(StringEscapeUtils.unescapeXml(escaped));
System.out.println();
System.out.println(StringEscapeUtils.escapeXml(StringEscapeUtils
.unescapeXml(escaped)));
}
Output:
lt;?xml version=quot;1.0quot;
encoding=quot;iso-8859-1quot;?gt;#10;lt;?xml version=quot;1.0quot;
encoding=quot;iso-8859-1quot;?gt;
?xml version=1.0 encoding=iso-8859-1?
?xml version=1.0 encoding=iso-8859-1?
lt;?xml version=quot;1.0quot; encoding=quot;iso-8859-1quot;?gt;
lt;?xml version=quot;1.0quot; encoding=quot;iso-8859-1quot;?gt;
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-922) Add isOneTrue(booleans...) to BooleanUtils to preserve old behavior of BooleanUtils.xor(booleans...)
[ https://issues.apache.org/jira/browse/LANG-922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated LANG-922: - Fix Version/s: Discussion Add isOneTrue(booleans...) to BooleanUtils to preserve old behavior of BooleanUtils.xor(booleans...) Key: LANG-922 URL: https://issues.apache.org/jira/browse/LANG-922 Project: Commons Lang Issue Type: Bug Components: lang.* Reporter: Benedikt Ritter Assignee: Benedikt Ritter Fix For: 3.2, Discussion The old implementation (prior to r1532476) of BooleanUtils.xor(boolean...) checked if the provided array contained exactly one boolean with value true. This was changed because it is not the correct behavior for an XOR operation. To preserve the behavior we should add BooleanUtils.isOneTrue(boolean...) and BooleanUtils.isOneTrue(Boolean...) (and possibly the equivalents for isOneFalse). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-922) Add isOneTrue(booleans...) to BooleanUtils to preserve old behavior of BooleanUtils.xor(booleans...)
[ https://issues.apache.org/jira/browse/LANG-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800140#comment-13800140 ] Benedikt Ritter commented on LANG-922: -- I like frequency(T, T...) Add isOneTrue(booleans...) to BooleanUtils to preserve old behavior of BooleanUtils.xor(booleans...) Key: LANG-922 URL: https://issues.apache.org/jira/browse/LANG-922 Project: Commons Lang Issue Type: Bug Components: lang.* Reporter: Benedikt Ritter Assignee: Benedikt Ritter Fix For: 3.2, Discussion The old implementation (prior to r1532476) of BooleanUtils.xor(boolean...) checked if the provided array contained exactly one boolean with value true. This was changed because it is not the correct behavior for an XOR operation. To preserve the behavior we should add BooleanUtils.isOneTrue(boolean...) and BooleanUtils.isOneTrue(Boolean...) (and possibly the equivalents for isOneFalse). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-922) Add isOneTrue(booleans...) to BooleanUtils to preserve old behavior of BooleanUtils.xor(booleans...)
[
https://issues.apache.org/jira/browse/LANG-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800142#comment-13800142
]
Benedikt Ritter commented on LANG-922:
--
{quote}
Thus old BooleanUtils.xor(args) would now be ArrayUtils.count(true, args) == 1.
{quote}
IMHO we should not change BooleanUtils.xor(boolean...) back the old behavior
(which was counting true values), because it was simply wrong :-) You can have
a boolean array with more than one true value and still the result of XOR can
be true:
{code}
true ^ true ^ true
= false ^ true
= true
{code}
So the first thing to do was fixing this bug. Now we need to decide if we want
to preserve the old behavior and possibly add other convenience methods like
isAnyTrue, isExactlyOneFalse and the like.
Add isOneTrue(booleans...) to BooleanUtils to preserve old behavior of
BooleanUtils.xor(booleans...)
Key: LANG-922
URL: https://issues.apache.org/jira/browse/LANG-922
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Reporter: Benedikt Ritter
Assignee: Benedikt Ritter
Fix For: 3.2, Discussion
The old implementation (prior to r1532476) of BooleanUtils.xor(boolean...)
checked if the provided array contained exactly one boolean with value true.
This was changed because it is not the correct behavior for an XOR operation.
To preserve the behavior we should add BooleanUtils.isOneTrue(boolean...) and
BooleanUtils.isOneTrue(Boolean...) (and possibly the equivalents for
isOneFalse).
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (COLLECTIONS-483) Cyclic dependencies among several packages.
[ https://issues.apache.org/jira/browse/COLLECTIONS-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800160#comment-13800160 ] Thomas Neidhart commented on COLLECTIONS-483: - Hi Brahim, first of all, thanks for all the effort that you have put into this. It is a proposal that would involve very radical changes to the codebase, also going away from the convention to put the interfaces and util classes in the base package and all implementations in sub-packages. Such a change should be discussed on the dev mailinglist, where it would get a greater audience. So I would suggest that you post a message there in case you want to continue with this change. Keep in mind that our plans are to release a 4.0 quite soon, thus a change like this should happen either fast or will have to wait for a (potential) 5.0 release. Cyclic dependencies among several packages. --- Key: COLLECTIONS-483 URL: https://issues.apache.org/jira/browse/COLLECTIONS-483 Project: Commons Collections Issue Type: Improvement Affects Versions: 4.0, 4.0-alpha1 Reporter: Brahim Djoudi Priority: Minor Attachments: c4.png, c4-refactored.png, c4-refactoring.pdf, c4-src.zip Original Estimate: 4h Remaining Estimate: 4h Many packages have mutual dependency, directly or undirectly. These dependencies may be avoided just by moving some classes and interfaces within different packages. This refactoring breaks API compatibility but enhances the useability and the maintainability (hopefully) of the library. In addition, few issues in dynamic environments (like OSGi) less occur. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (COLLECTIONS-485) Collection copy-constructors should accept wildcarded input
[ https://issues.apache.org/jira/browse/COLLECTIONS-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800211#comment-13800211 ] Thomas Neidhart commented on COLLECTIONS-485: - Hi Hollis, thanks for your patch, it looks good after a few minor modifications. Regarding the wildcards, we can only add them in these cases: * copy-constructors where the data is really copied * decorators /classes that are unmodifiable (do not alter the wrapped collection) For the special cases of sorted / ordered collections: * the key type shall be fixed, whereas the value type may be using a wildcard Collection copy-constructors should accept wildcarded input --- Key: COLLECTIONS-485 URL: https://issues.apache.org/jira/browse/COLLECTIONS-485 Project: Commons Collections Issue Type: Improvement Components: Bag, BidiMap, Collection, List, Map, Set Affects Versions: 4.0-alpha1 Reporter: Hollis Waite Attachments: wildcards.patch Many Collection constructors copy input in order to self-populate. For convenience (and consistency with standard Java collections library), wildcarded parameters should be accepted where possible. Unmodifiable* classes might also benefit from less restrictive generic signatures. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (MATH-1039) Logarithmic probability and density calculations for the distributions
[ https://issues.apache.org/jira/browse/MATH-1039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated MATH-1039: -- Fix Version/s: 4.0 Patch committed with only one material change in r1533974 * New logDensity methods were not added to interfaces; only to abstract parents. Leaving this open so we do not forget to lift to interfaces in 4.0. Many thanks for the patch! Logarithmic probability and density calculations for the distributions -- Key: MATH-1039 URL: https://issues.apache.org/jira/browse/MATH-1039 Project: Commons Math Issue Type: New Feature Reporter: Aleksei Dievskii Assignee: Phil Steitz Priority: Minor Labels: features, patch Fix For: 4.0 Attachments: LOGDENSITY.patch A person working with fairly small probabilities and densities often employs their logarithms to increase precision and decrease the chance of an underflow. However, just taking a log of the probability() or density() return value doesn't necessarily solve the problem, as these methods themselves could have lost precision or underflowed. This patch introduces new logProbability() and logDensity() methods overriden for many relevant distribution. The patch also introduces tests of these new methods. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (COLLECTIONS-485) Collection copy-constructors should accept wildcarded input
[ https://issues.apache.org/jira/browse/COLLECTIONS-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800236#comment-13800236 ] Thomas Neidhart commented on COLLECTIONS-485: - Applied patch in r1533984 together with other modifications: * suppress generics warnings * add wildcards to all copy-constructors of collection classes Still need to review packages comparators, functors and keyvalue. Collection copy-constructors should accept wildcarded input --- Key: COLLECTIONS-485 URL: https://issues.apache.org/jira/browse/COLLECTIONS-485 Project: Commons Collections Issue Type: Improvement Components: Bag, BidiMap, Collection, List, Map, Set Affects Versions: 4.0-alpha1 Reporter: Hollis Waite Attachments: wildcards.patch Many Collection constructors copy input in order to self-populate. For convenience (and consistency with standard Java collections library), wildcarded parameters should be accepted where possible. Unmodifiable* classes might also benefit from less restrictive generic signatures. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (COLLECTIONS-485) Collection copy-constructors should accept wildcarded input
[ https://issues.apache.org/jira/browse/COLLECTIONS-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800290#comment-13800290 ] Hollis Waite commented on COLLECTIONS-485: -- I believe that BagUtils UnmodifiableSortedBag can also be updated. Collection copy-constructors should accept wildcarded input --- Key: COLLECTIONS-485 URL: https://issues.apache.org/jira/browse/COLLECTIONS-485 Project: Commons Collections Issue Type: Improvement Components: Bag, BidiMap, Collection, List, Map, Set Affects Versions: 4.0-alpha1 Reporter: Hollis Waite Attachments: wildcards.patch Many Collection constructors copy input in order to self-populate. For convenience (and consistency with standard Java collections library), wildcarded parameters should be accepted where possible. Unmodifiable* classes might also benefit from less restrictive generic signatures. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-898) StringEscapeUtils un/escapexml inconsistant with escaped whitespace
[
https://issues.apache.org/jira/browse/LANG-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800305#comment-13800305
]
Sebb commented on LANG-898:
---
Agreed; not a problem. There's an easy work-round.
StringEscapeUtils un/escapexml inconsistant with escaped whitespace
---
Key: LANG-898
URL: https://issues.apache.org/jira/browse/LANG-898
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.1
Environment: Windows 7, Java 7
Reporter: Martin Barrs
Priority: Minor
Fix For: Discussion
{noformat}
In an escaped XML string with escaped whitespace, in this case linefeed (
#10; ), escapexml and unescapexml treat the linefeed inconsistently.
unescape converts #10; to a linefeed, yet escapexml does not convert
linefeed back to #10;
Here's code and output...
public static void main(String[] args) {
String escaped =
lt;?xml version=quot;1.0quot;
encoding=quot;iso-8859-1quot;?gt;#10;lt;?xml version=quot;1.0quot;
encoding=quot;iso-8859-1quot;?gt;;
System.out.println(escaped);
System.out.println();
System.out.println(StringEscapeUtils.unescapeXml(escaped));
System.out.println();
System.out.println(StringEscapeUtils.escapeXml(StringEscapeUtils
.unescapeXml(escaped)));
}
Output:
lt;?xml version=quot;1.0quot;
encoding=quot;iso-8859-1quot;?gt;#10;lt;?xml version=quot;1.0quot;
encoding=quot;iso-8859-1quot;?gt;
?xml version=1.0 encoding=iso-8859-1?
?xml version=1.0 encoding=iso-8859-1?
lt;?xml version=quot;1.0quot; encoding=quot;iso-8859-1quot;?gt;
lt;?xml version=quot;1.0quot; encoding=quot;iso-8859-1quot;?gt;
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (CONFIGURATION-557) Regression: MapConfiguration no longer accepts a MapString, String (compilation error)
[ https://issues.apache.org/jira/browse/CONFIGURATION-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen updated CONFIGURATION-557: - Attachment: TestMapConfigurationRegression.java test case that fails compilation under 1.8 and 1.9 Regression: MapConfiguration no longer accepts a MapString, String (compilation error) Key: CONFIGURATION-557 URL: https://issues.apache.org/jira/browse/CONFIGURATION-557 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.8, 1.9 Reporter: Henning Schmiedehausen Fix For: 1.10 Attachments: TestMapConfigurationRegression.java The attached test runs fine with configuration 1.7. It has a compilation error with 1.8 and 1.9. The attached patch fixes the problem, which is a pure compiler verification problem. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (CONFIGURATION-557) Regression: MapConfiguration no longer accepts a MapString, String (compilation error)
Henning Schmiedehausen created CONFIGURATION-557: Summary: Regression: MapConfiguration no longer accepts a MapString, String (compilation error) Key: CONFIGURATION-557 URL: https://issues.apache.org/jira/browse/CONFIGURATION-557 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.9, 1.8 Reporter: Henning Schmiedehausen Fix For: 1.10 Attachments: TestMapConfigurationRegression.java The attached test runs fine with configuration 1.7. It has a compilation error with 1.8 and 1.9. The attached patch fixes the problem, which is a pure compiler verification problem. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CONFIGURATION-557) Regression: MapConfiguration no longer accepts a MapString, String (compilation error)
[ https://issues.apache.org/jira/browse/CONFIGURATION-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen updated CONFIGURATION-557: - Attachment: CONFIGURATION-557-fix.patch this patch fixes the problem. Regression: MapConfiguration no longer accepts a MapString, String (compilation error) Key: CONFIGURATION-557 URL: https://issues.apache.org/jira/browse/CONFIGURATION-557 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.8, 1.9 Reporter: Henning Schmiedehausen Fix For: 1.10 Attachments: CONFIGURATION-557-fix.patch, TestMapConfigurationRegression.java The attached test runs fine with configuration 1.7. It has a compilation error with 1.8 and 1.9. The attached patch fixes the problem, which is a pure compiler verification problem. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-925) Deprecate o.a.c.lang.time.* package
[ https://issues.apache.org/jira/browse/LANG-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-925: --- Fix Version/s: Discussion Deprecate o.a.c.lang.time.* package --- Key: LANG-925 URL: https://issues.apache.org/jira/browse/LANG-925 Project: Commons Lang Issue Type: Task Components: lang.time.* Affects Versions: 3.1 Reporter: Benedikt Ritter Fix For: 3.2, Discussion We have discussed [1] to deprecate the time package, because it will become obsolete in Java 8. [1] http://markmail.org/message/uw3lggwkt5ul5b7k -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-848) Improve StringUtils.is(Not)Blank with a CharSequence... version
[
https://issues.apache.org/jira/browse/LANG-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-848:
---
Fix Version/s: Discussion
Improve StringUtils.is(Not)Blank with a CharSequence... version
---
Key: LANG-848
URL: https://issues.apache.org/jira/browse/LANG-848
Project: Commons Lang
Issue Type: Improvement
Components: lang.*
Affects Versions: 3.1
Reporter: Alexander Muthmann
Fix For: 3.2, Discussion
Currently it's only possible to compare a single CharSequence per
is(Not)Blank/is(Not)Empty call.
This should be changed to support multiple CharSequences in a single call.
{code}
if(StringUtils.isNotBlank(foo) StringUtils.isNotBlank(bar) ...)
{code}
could be changed to
{code}
if(StringUtils.isNotBlank(foo, bar, ...)
{code}
As there are two possible ways to combine the results (AND and OR), it'd be
necessary to create multiple methods.
{code}
isAnyBlank(CharSequence... cs)
isNoneBlank(CharSequence... cs)
isAnyEmpty(CharSequence... cs)
isNoneEmpty(CharSequence... cs)
{code}
I could implement those methods and contribute them via github if there is
any interest from project's side.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800363#comment-13800363
]
Henri Yandell commented on LANG-916:
Is the fix version here 2.7 or 3.2? Sounds like it's an issue in 3.1 rather
than 2.6.
CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in
certain situations
Key: LANG-916
URL: https://issues.apache.org/jira/browse/LANG-916
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 3.1
Environment: Sun JDK 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
3.9.10-100.fc17.i686.PAE).
Reporter: Christian P. MOMON
Labels: patch
Fix For: 2.7, Review Patch
Attachments: LANG-916.patch
In LANG-538 issue, there is an unit test:
{noformat}
public void testFormat_CalendarIsoMsZulu() {
final String dateTime = 2009-10-16T16:42:16.000Z;
GregorianCalendar cal = new
GregorianCalendar(TimeZone.getTimeZone(GMT-8));
cal.clear();
cal.set(2009, 9, 16, 8, 42, 16);
cal.getTime();
FastDateFormat format =
FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(GMT));
assertEquals(dateTime, dateTime, format.format(cal));
}
{noformat}
This test passes successfully in lang-2.6 but failed in lang3-3.1:
{noformat}
org.junit.ComparisonFailure: dateTime expected:2009-10-16T[16]:42:16.000Z
but was:2009-10-16T[08]:42:16.000Z
{noformat}
Reproduced whit Sun Java version: 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
3.9.10-100.fc17.i686.PAE).
Moreover, I wrote another unit test showing that the timeZone parameter seems
to be ignored :
{noformat}
public void test() {
Calendar cal =
Calendar.getInstance(TimeZone.getTimeZone(Europe/Paris));
cal.set(2009, 9, 16, 8, 42, 16);
//
System.out.println(DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.format(cal));
System.out.println(long);
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getDefault()));
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Asia/Kolkata)));
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Europe/London)));
System.out.println(calendar);
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getDefault()));
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Asia/Kolkata)));
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Europe/London)));
System.out.println(calendar fast);
System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Europe/Paris)).format(cal));
System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Asia/Kolkata)).format(cal));
System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Europe/London)).format(cal));
}
{noformat}
Gives the following console logs:
{noformat}
long
2009-10-16T08:42:16+02:00
2009-10-16T12:12:16+05:30
2009-10-16T07:42:16+01:00
calendar
2009-10-16T08:42:16+02:00
2009-10-16T08:42:16+02:00
2009-10-16T08:42:16+02:00
calendar fast
2009-10-16T08:42:16.975Z
2009-10-16T08:42:16.975Z
2009-10-16T08:42:16.975Z
{noformat}
When DateFormatUtils.format takes a long parameter, the time string is good.
When DateFormatUtils.format takes a Calendar parameter, the time string is
wrong, the timezone parameter is IGNORED.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-591) A more complex Levenshtein distance would be useful
[ https://issues.apache.org/jira/browse/LANG-591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-591: --- Fix Version/s: (was: 3.x) Review Patch A more complex Levenshtein distance would be useful --- Key: LANG-591 URL: https://issues.apache.org/jira/browse/LANG-591 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 3.0 Reporter: Benson Margulies Fix For: Review Patch Attachments: LANG-591.patch For some applications, it is necessary to get insert/delete/substitution counts from the distance algorithm. I am attaching a patch that provides this. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (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:all-tabpanel ] Henri Yandell updated LANG-696: --- Fix Version/s: (was: 3.x) Discussion 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 Fix For: Discussion Added two null-safe ClassUtils.getSimpleName() APIs. -- Forwarded message -- From: Gary Gregory garydgreg...@gmail.com Date: Mon, Apr 11, 2011 at 10:18 AM Subject: [Lang] ClassUtils getShortClassName != Class getSimpleName To: Commons Developers List d...@commons.apache.org 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 (v6.1#6144)
[jira] [Updated] (LANG-690) Move CharSet over to Range and remove the now package-private CharRange class
[ https://issues.apache.org/jira/browse/LANG-690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-690: --- Fix Version/s: (was: 3.x) Patch Needed Move CharSet over to Range and remove the now package-private CharRange class - Key: LANG-690 URL: https://issues.apache.org/jira/browse/LANG-690 Project: Commons Lang Issue Type: Improvement Components: lang.* Reporter: Henri Yandell Fix For: Patch Needed -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-699) Consider implementing Formattable on various classes with toString
[ https://issues.apache.org/jira/browse/LANG-699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-699: --- Fix Version/s: (was: 3.x) Patch Needed Consider implementing Formattable on various classes with toString -- Key: LANG-699 URL: https://issues.apache.org/jira/browse/LANG-699 Project: Commons Lang Issue Type: Improvement Components: lang.* Reporter: Henri Yandell Fix For: Patch Needed For example Fraction, StopWatch, Range. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-680) StringUtils - Longest Common Substring / Longest common susequence
[ https://issues.apache.org/jira/browse/LANG-680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-680: --- Fix Version/s: (was: 3.x) Review Patch StringUtils - Longest Common Substring / Longest common susequence -- Key: LANG-680 URL: https://issues.apache.org/jira/browse/LANG-680 Project: Commons Lang Issue Type: New Feature Components: lang.* Reporter: Andrea Vacondio Labels: LCS,, Longest, common, substring Fix For: Review Patch Attachments: LANG-680.patch I recently needed to perform Longest commons substring on a collection of filenames and I think it could be usefull to have it in StringUtils (I couldn't find any discussion about it). Some detail here http://en.wikipedia.org/wiki/Longest_common_substring and here http://en.wikipedia.org/wiki/Longest_common_subsequence_problem -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-774) Add isStarted isStopped and isSuspended to StopWatch
[ https://issues.apache.org/jira/browse/LANG-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-774: --- Fix Version/s: (was: 3.x) Review Patch Add isStarted isStopped and isSuspended to StopWatch Key: LANG-774 URL: https://issues.apache.org/jira/browse/LANG-774 Project: Commons Lang Issue Type: Improvement Components: lang.time.* Affects Versions: 3.1 Reporter: Michael Akerman Priority: Minor Labels: features Fix For: Review Patch Attachments: LANG774_1.diff, LANG774_2.patch, LANG774.diff, StopWatch.java Original Estimate: 2h Remaining Estimate: 2h It would be nice to have: isStarted isStopped isSuspended On StopWatch -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (LANG-532) Consider code in Collections
[ https://issues.apache.org/jira/browse/LANG-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-532. -- Resolution: Won't Fix Fix Version/s: (was: 3.x) Collections is alive again, so resolving this as not needed. Consider code in Collections Key: LANG-532 URL: https://issues.apache.org/jira/browse/LANG-532 Project: Commons Lang Issue Type: Task Components: General Reporter: Henri Yandell If and only if Collections be considered dead for 4.x and beyond, then consider if there is any code that wants to be scavenged to live in Lang 3.x. Basic rules: * No implementations of Collections. * If a successor of Collections defined, then not something it has. Basically potential additions to java.util.Collections I suspect. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-370) Document thread safety of classes
[ https://issues.apache.org/jira/browse/LANG-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-370: --- Fix Version/s: (was: 3.x) Patch Needed Document thread safety of classes - Key: LANG-370 URL: https://issues.apache.org/jira/browse/LANG-370 Project: Commons Lang Issue Type: Wish Components: General Reporter: Sebb Fix For: Patch Needed Few if any of the LANG classes state whether they are intended to be thread-safe or not. As a library, such documentation is essential IMO. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-740) Add a Memoizer class
[
https://issues.apache.org/jira/browse/LANG-740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-740:
---
Fix Version/s: (was: 3.x)
Patch Needed
Add a Memoizer class
Key: LANG-740
URL: https://issues.apache.org/jira/browse/LANG-740
Project: Commons Lang
Issue Type: New Feature
Components: lang.concurrent.*
Reporter: Gary Gregory
Assignee: Gary Gregory
Fix For: Patch Needed
I am currently using a class like the Memoizer class [1] from Java
Concurrency in Practice [2], a great book.
It would fit perfectly in org.apache.commons.lang3.concurrent.
[1] http://jcip.net/listings/Memoizer.java
[2] http://jcip.net/
There is no licensing issue because the code is in the public domain:
{noformat}
-- Forwarded message --
From: Brian Goetz br...@briangoetz.com
Date: Tue, Aug 9, 2011 at 5:40 PM
Subject: Re: Apache Commons Lang and Memoizer
To: Gary Gregory ggreg...@apache.org, Tim Peierls t...@peierls.net
No license issues -- the code is in the public domain:
Written by Brian Goetz and Tim Peierls with assistance from members of
JCP JSR-166 Expert Group and released to the public domain, as explained at
http://creativecommons.org/licenses/publicdomain
Code for the samples can be downloaded from http://www.jcip.net/listings.html.
Cheers,
-Brian
On 8/9/2011 5:38 PM, Gary Gregory wrote:
Hi Brian,
I would like to include a Memoizer in the next release of Apache
Commons Lang [1].
Can we use the Memoizer pattern from Java Concurrency in Practice? I
think I would reuse the code from the class Memoizer and change names,
things like that.
We are talking about this on the Lang mailing list and are wondering
if there are any licensing issues.
[1] https://commons.apache.org/lang/
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-642) Need varargs form of NumberUtils.max(), etc
[ https://issues.apache.org/jira/browse/LANG-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-642: --- Fix Version/s: (was: 3.x) Patch Needed Need varargs form of NumberUtils.max(), etc --- Key: LANG-642 URL: https://issues.apache.org/jira/browse/LANG-642 Project: Commons Lang Issue Type: Improvement Components: lang.math.* Reporter: david cogen Priority: Minor Fix For: Patch Needed There should be a varargs form of the NumberUtils.max() and min() functions. E.g. int max (int... numbers) This might conflict with the existing int max (int[] numbers) but that function would in fact not be needed if the varargs form existed because an array could be supplied to it just as easily. Or, if it is undesirable to remove max(int[] numbers), then a varargs function could be defined as int max (int number1, int... moreNumbers) which would work for any number of arguments greater than 0. Of course this function should be implemented for all number types (byte, short, float, double, etc) and both max() and min() should be provided. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-622) StringUtils.lastIndexOfAnyBut() function desired
[ https://issues.apache.org/jira/browse/LANG-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-622: --- Fix Version/s: (was: 3.x) Patch Needed StringUtils.lastIndexOfAnyBut() function desired Key: LANG-622 URL: https://issues.apache.org/jira/browse/LANG-622 Project: Commons Lang Issue Type: Improvement Components: lang.* Reporter: david cogen Priority: Minor Fix For: Patch Needed Attachments: LANG-622.patch, StringUtilslLastIndexOfAnyButTest.java class StringUtils needs the function lastIndexOfAnyBut() This would be like indexOfAnyBut() except searches from the end rather than the beginning. It would be like lastIndexOfAny() except looks for a character other than those in the string rather than for those in the string. This is the only one of the four combinations of from beginning/from end and for any/for any but that is not provided. Interestingly, the class header doc. mentions LastIndexOfAnyBut but the function does not exist - even as a private, as determined by class introspection. (This is not a frivolous request. I actually did need this function and ended up having to code a search loop.) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-536) Add isSorted() to ArrayUtils
[
https://issues.apache.org/jira/browse/LANG-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-536:
---
Fix Version/s: (was: 3.x)
Patch Needed
Add isSorted() to ArrayUtils
Key: LANG-536
URL: https://issues.apache.org/jira/browse/LANG-536
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Reporter: Sergei Ivanov
Priority: Minor
Fix For: Patch Needed
In my unit tests I often need to verify that an array is correctly sorted.
In order to achieve this, I've got two helper methods as follows.
Is it possible to integrate these methods into ArrayUtils?
{code}
/**
* Checks that the specified array of objects is in an ascending order
* according to the specified comparator. All elements in the array must
be
* imutually comparable/i by the specified comparator (that is,
* ttc.compare(e1, e2)/tt must not throw a ttClassCastException/tt
* for any elements tte1/tt and tte2/tt in the array).
*
* @param a the array to be checked.
* @param c the comparator to determine the order of the array. A
* ttnull/tt value indicates that the elements'
* {@linkplain Comparable natural ordering} should be used.
* @return {@code true}, if the array is sorted; {@code false}, otherwise.
* @throws ClassCastException if the array contains elements that are
* not imutually comparable/i using the specified comparator.
*/
public static T boolean isSorted(final T[] a, final Comparator? super
T c) {
if (a.length = 1) {
// Empty or singleton arrays are always sorted
return true;
}
// Otherwise, check that every element is not smaller than the
previous
T previous = a[0];
for (int i = 1, n = a.length; i n; i++) {
final T current = a[i];
if (c.compare(previous, current) 0) {
return false;
}
previous = current;
}
return true;
}
/**
* Checks that the specified array of objects is in an ascending order,
* according to the {@linkplain Comparable natural ordering} of its
elements.
* All elements in the array must implement the {@link Comparable}
interface.
* Furthermore, all elements in the array must be imutually
comparable/i
* (that is, tte1.compareTo(e2)/tt must not throw a
ttClassCastException/tt
* for any elements tte1/tt and tte2/tt in the array).
*
* @param a the array to be checked.
* @return {@code true}, if the array is sorted; {@code false}, otherwise.
* @throws ClassCastException if the array contains elements that are not
* imutually comparable/i (for example, strings and integers).
*/
@SuppressWarnings({unchecked})
public static T boolean isSorted(final T[] a) {
if (a.length = 1) {
// Empty or singleton arrays are always sorted
return true;
}
// Otherwise, check that every element is not smaller than the
previous
T previous = a[0];
for (int i = 1, n = a.length; i n; i++) {
final T current = a[i];
if (((Comparable? super T) previous).compareTo(previous) 0) {
return false;
}
previous = current;
}
return true;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-613) ConstructorUtils.getAccessibleConstructor() Does Not Check the Accessibility of Enclosing Classes
[ https://issues.apache.org/jira/browse/LANG-613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-613: --- Fix Version/s: (was: 3.x) Review Patch ConstructorUtils.getAccessibleConstructor() Does Not Check the Accessibility of Enclosing Classes - Key: LANG-613 URL: https://issues.apache.org/jira/browse/LANG-613 Project: Commons Lang Issue Type: Bug Components: lang.reflect.* Affects Versions: 3.0 Reporter: David M. Sledge Priority: Minor Labels: patch Fix For: Review Patch Attachments: LANG-613_Recursive_visibility_check_up_the_enclosing_tree.patch ConstructorUtils.getAccessibleConstructor() checks if the declaring class is public but not whether it's a top-level class or an enclosed one. Consequently, with enclosed declaring classes, the method does not check if the enclosing class is public, or it's enclosing class, or it's enclosing class, etc... -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-733) Add containsAny(CharSequence cs, CharSequence... searchChars) to StringUtils
[
https://issues.apache.org/jira/browse/LANG-733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-733:
---
Fix Version/s: (was: 3.x)
Patch Needed
Add containsAny(CharSequence cs, CharSequence... searchChars) to StringUtils
Key: LANG-733
URL: https://issues.apache.org/jira/browse/LANG-733
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Affects Versions: 3.0
Reporter: Eugen Paraschiv
Priority: Minor
Fix For: Patch Needed
This method is missing from StringUtils. The corresponding method:
public static boolean containsAny(CharSequence cs, char... searchChars) {
does exist, so this was probably just forgotten.
Also
public static boolean containsIgnoreCase(CharSequence str, CharSequence...
searchStr) {
needs to be added as well.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Closed] (LANG-707) Add methods to avoid Sun JVM synchronisation overhead in new String(byte[] b, String enc)
[ https://issues.apache.org/jira/browse/LANG-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-707. -- Resolution: Not A Problem Fix Version/s: (was: 3.x) Closing per Gary's comments. Add methods to avoid Sun JVM synchronisation overhead in new String(byte[] b, String enc) - Key: LANG-707 URL: https://issues.apache.org/jira/browse/LANG-707 Project: Commons Lang Issue Type: Improvement Components: General Environment: https://issues.apache.org/bugzilla/show_bug.cgi?id=51400 Reporter: Sebb Attachments: LANG-707.diff According to Tomcat bug 51400, the use of new String(byte[] b, String enc) can fall foul of a Sun Java synchronisation bottleneck. Might be useful to add the code workround to Commons Lang. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Closed] (LANG-307) CloneUtils - utility class to enable cloning via various different mechanisms
[ https://issues.apache.org/jira/browse/LANG-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-307. -- Resolution: Won't Fix Fix Version/s: (was: 3.x) Closing this per Jörg's comments. CloneUtils - utility class to enable cloning via various different mechanisms - Key: LANG-307 URL: https://issues.apache.org/jira/browse/LANG-307 Project: Commons Lang Issue Type: New Feature Components: lang.* Reporter: Henri Yandell Attachments: AutoClone.java, lang-307.patch Taken from the tasks.html. No idea if we want to do it or not. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-671) Add indexOf() lastIndexOf() methods for Whitespace and Non-whitespae to StringUtils
[
https://issues.apache.org/jira/browse/LANG-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-671:
---
Fix Version/s: (was: 3.x)
Review Patch
Add indexOf() lastIndexOf() methods for Whitespace and Non-whitespae to
StringUtils
-
Key: LANG-671
URL: https://issues.apache.org/jira/browse/LANG-671
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Reporter: Niall Pemberton
Fix For: Review Patch
Attachments: LANG-671-StringUtils-whitespace.patch
Whitespace methods:
{code}
public static int indexOfWhitespace(CharSequence str, int startPos)
public static int lastIndexOfWhitespace(CharSequence str, int startPos)
{code}
Non-whitespace methods:
{code}
public static int indexOfNonWhitespace(CharSequence str, int startPos)
public static int lastIndexOfNonWhitespace(CharSequence str, int startPos)
{code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Closed] (LANG-542) Move StringBuffer APIs to Appendable
[ https://issues.apache.org/jira/browse/LANG-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-542. -- Resolution: Later Fix Version/s: (was: 3.x) Not seeing a great need to do this. Move StringBuffer APIs to Appendable Key: LANG-542 URL: https://issues.apache.org/jira/browse/LANG-542 Project: Commons Lang Issue Type: Task Components: General Reporter: Henri Yandell A few parts of the API accept StringBuffer. These should, unless blocked by the JDK API, be switched to Appendable. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-344) CollatorUtils - equivalent of StringUtils, but using Collators
[ https://issues.apache.org/jira/browse/LANG-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-344: --- Fix Version/s: (was: 3.x) Patch Needed CollatorUtils - equivalent of StringUtils, but using Collators -- Key: LANG-344 URL: https://issues.apache.org/jira/browse/LANG-344 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 2.3 Reporter: Niall Pemberton Priority: Minor Fix For: Patch Needed Stephen Kestle has pointed out that equalsIgnoreCase is an English/ASCII hack and that using the Collator class provides a more robust String comparison mechanism. - Most recently this came up when adding new ignore case methods to StringUtils for LANG-326 (also http://tinyurl.com/3d2jjk ) - Raised in regarding case insensitivity for EqualsBuilder and HashCodeBuilder in LANG-316 Creating this issue ticket so this doesn't get forgotten -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-288) StrTokenizer needs to support access to the token separators
[ https://issues.apache.org/jira/browse/LANG-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-288: --- Fix Version/s: (was: 3.x) Patch Needed StrTokenizer needs to support access to the token separators Key: LANG-288 URL: https://issues.apache.org/jira/browse/LANG-288 Project: Commons Lang Issue Type: Improvement Components: lang.text.* Reporter: Stephen Colebourne Priority: Minor Fix For: Patch Needed With StrTokenizer at present you cannot extract the separators between the tokens, a feature which is possible with StringTokenizer. Thus tokenizing a.b@c.d using .@ would return a,b,c,d but you wouldn't know where the @ was. This could probably best be part of the API as a lastSeparator() method that can only be called after next(), returning the separator(s) between that token and the previous token. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-577) Add ObjectReference interface and two implementations
[
https://issues.apache.org/jira/browse/LANG-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-577:
---
Fix Version/s: (was: 3.x)
Review Patch
Add ObjectReference interface and two implementations
-
Key: LANG-577
URL: https://issues.apache.org/jira/browse/LANG-577
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Reporter: Joerg Schaible
Assignee: Joerg Schaible
Priority: Minor
Fix For: Review Patch
Attachments: reference.diff
In some situations it would be helpful to use a reference to an object, e.g.
for parameters by reference
{code:java}
void doSomething(ObjectReferenceString ref) {
ref.set(Hello);
}
{code}
or for anonymous methods
{code:java}
final ObjectReferenceString ref = new MemoryReferenceString();
final Runnable r = new Runnable() {
void run() {
ref.set(Hello);
}
}
r.run();
{code}
Additionally it is sometimes useful to keep the reference in other places
than in shared memory, e.g. in a ThreadLocal or in case of a web application
in a scoped reference or even in combination with some other persistence
mechanism. Basically I am proposing the interface ObjectReference:
{code:Java}
/**
* Interface to reference an object.
*
* @param T the type of the referenced object
* @author Apache Software Foundation
* @since 3.0
*/
public interface ObjectReferenceT {
/**
* Getter for the referenced object.
*
* @return the object or codenull/code
*/
T get();
/**
* Setter for the reference.
*
* @param object the object to reference (may be codenull/code)
*/
void set(T object);
}
{code}
and the two implementations MemoryReference and ThreadLocalReference in the
new package org.apache.commons.lang3.reference. I've seen such or similar
types in various libraries.
Comments?
Unit test will be provided also.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-411) HashCodeBuilder: expose typed hashing methods
[ https://issues.apache.org/jira/browse/LANG-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-411: --- Fix Version/s: (was: 3.x) Patch Needed HashCodeBuilder: expose typed hashing methods - Key: LANG-411 URL: https://issues.apache.org/jira/browse/LANG-411 Project: Commons Lang Issue Type: Wish Components: lang.builder.* Affects Versions: 2.3 Reporter: Paul Benedict Priority: Minor Fix For: Patch Needed Attachments: ObjectUtils-Patch-Addresses-LANG-411-and-LANG-627.txt, ObjectUtilsTest-Patch-Adds-Tests-For-Changes-To-Address-LANG-411-and-LANG-627.txt HashCodeBuilder encapsulates the good advice of Joshua Bloch. He details how each java.lang type should be hashed. I want to use those too ... but without reflection. Please expose those as static methods: hashInt, hashBoolean, etc. They should take two parameters: the field value, and the hash multiplier value. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-426) String splitting with escaped delimiter
[
https://issues.apache.org/jira/browse/LANG-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-426:
---
Fix Version/s: (was: 3.x)
Review Patch
String splitting with escaped delimiter
---
Key: LANG-426
URL: https://issues.apache.org/jira/browse/LANG-426
Project: Commons Lang
Issue Type: New Feature
Components: lang.text.*
Affects Versions: 2.4
Reporter: Emmanuel Bourg
Priority: Minor
Fix For: Review Patch
Attachments: StringUtils.java
In Commons Configuration we use a custom split method that supports the
concept of an escaped delimiter, that may be nice if this was available in
Commons Lang (as a method in StringUtils, or as a setting in StrTokenizer).
Example:
{code}
a,b\,c,d-[a, b,c, d]
{code}
Here is the code of the method:
{code:java}
public static ListString split(String s, char delimiter)
{
if (s == null)
{
return new ArrayListString();
}
ListString list = new ArrayListString();
StringBuilder token = new StringBuilder();
int begin = 0;
boolean inEscape = false;
while (begin s.length())
{
char c = s.charAt(begin);
if (inEscape)
{
// last character was the escape marker
// can current character be escaped?
if (c != delimiter c != LIST_ESC_CHAR)
{
// no, also add escape character
token.append(LIST_ESC_CHAR);
}
token.append(c);
inEscape = false;
}
else
{
if (c == delimiter)
{
// found a list delimiter - add token and reset buffer
list.add(token.toString().trim());
token = new StringBuilder();
}
else if (c == LIST_ESC_CHAR)
{
// eventually escape next character
inEscape = true;
}
else
{
token.append(c);
}
}
begin++;
}
// Trailing delimiter?
if (inEscape)
{
token.append(LIST_ESC_CHAR);
}
// Add last token
list.add(token.toString().trim());
return list;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-417) ClassUtils: method for turning FQN into resource path
[
https://issues.apache.org/jira/browse/LANG-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-417:
---
Fix Version/s: (was: 3.x)
Patch Needed
ClassUtils: method for turning FQN into resource path
-
Key: LANG-417
URL: https://issues.apache.org/jira/browse/LANG-417
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Reporter: Paul Benedict
Fix For: Patch Needed
I commonly need a FQ path to a resource within the same location as a class
file. I recommend the addition of this method:
public String getPackageResourcePath(Class clazz, String resourceName)
StringBuffer buf = new StringBuffer();
buf.append(ClassUtils.getPackageName(getClass()).replace('.', '/'));
buf.append(/);
buf.append(resourceName);
return buf.toString();
}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-660) Add methods to insert arrays into arrays at an index
[ https://issues.apache.org/jira/browse/LANG-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-660: --- Fix Version/s: (was: 3.x) Review Patch Add methods to insert arrays into arrays at an index Key: LANG-660 URL: https://issues.apache.org/jira/browse/LANG-660 Project: Commons Lang Issue Type: Improvement Components: lang.* Affects Versions: 2.5 Reporter: Aaron Digulla Priority: Minor Fix For: Review Patch Attachments: ArrayUtils_addAll.patch, ArrayUtilsAddTest_addAll.patch, ArrayUtilsAddTest.txt, ArrayUtils.txt Please add methods with this signature: ArrayUtils.addAll(int[] target, int index, int[] source) (i.e. insert an array into an array at a certain position). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-607) StringUtils methods do not handle Unicode 2.0+ supplementary characters correctly.
[ https://issues.apache.org/jira/browse/LANG-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-607: --- Fix Version/s: (was: 3.x) Patch Needed StringUtils methods do not handle Unicode 2.0+ supplementary characters correctly. -- Key: LANG-607 URL: https://issues.apache.org/jira/browse/LANG-607 Project: Commons Lang Issue Type: Bug Components: lang.* Affects Versions: 2.5 Environment: java version 1.6.0_16 Java(TM) SE Runtime Environment (build 1.6.0_16-b01) Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode) Microsoft Windows [Version 6.0.6002] Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700) Java version: 1.6.0_16 Java home: C:\Program Files\Java\jdk1.6.0_16\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows vista version: 6.0 arch: amd64 Family: windows Reporter: Gary Gregory Assignee: Gary Gregory Priority: Minor Fix For: Patch Needed Attachments: LANG-607.diff StringUtils.containsAny methods incorrectly matches Unicode 2.0+ supplementary characters. For example, define a test fixture to be the Unicode character U+2 where U+2 is written in Java source as \uD840\uDC00 private static final String CharU2 = \uD840\uDC00; private static final String CharU20001 = \uD840\uDC01; You can see Unicode supplementary characters correctly implemented in the JRE call: assertEquals(-1, CharU2.indexOf(CharU20001)); But this is broken: assertEquals(false, StringUtils.containsAny(CharU2, CharU20001)); assertEquals(false, StringUtils.containsAny(CharU20001, CharU2)); This is fine: assertEquals(true, StringUtils.contains(CharU2 + CharU20001, CharU2)); assertEquals(true, StringUtils.contains(CharU2 + CharU20001, CharU20001)); assertEquals(true, StringUtils.contains(CharU2, CharU2)); assertEquals(false, StringUtils.contains(CharU2, CharU20001)); because the method calls the JRE to perform the match. More than you want to know: - http://java.sun.com/developer/technicalArticles/Intl/Supplementary/ -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (CONFIGURATION-556) Regression with SystemProperties in 1.8 and 1.9
[ https://issues.apache.org/jira/browse/CONFIGURATION-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Schmiedehausen updated CONFIGURATION-556: - Fix Version/s: 1.10 Regression with SystemProperties in 1.8 and 1.9 --- Key: CONFIGURATION-556 URL: https://issues.apache.org/jira/browse/CONFIGURATION-556 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.8, 1.9 Reporter: Henning Schmiedehausen Fix For: 1.10 Attachments: CONFIGURATION-556-fix.patch, TestSystemConfigurationRegression.java The attached test case succeeds in commons configuration 1.7 but fails in 1.8 and 1.9. It does succeed on trunk again, probably due to the use properties directly changes in SystemProperties. As 2.0 is not yet released, it would be nice to get a 1.9.1 that is 1.9 + this bug fixed. (The test uses the old junit framework style to be drop in compatible with 1.7, 1.8 and 1.9). -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-332) EqualsBuilder to alternatively use method properties
[ https://issues.apache.org/jira/browse/LANG-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-332: --- Fix Version/s: (was: 3.x) Patch Needed EqualsBuilder to alternatively use method properties Key: LANG-332 URL: https://issues.apache.org/jira/browse/LANG-332 Project: Commons Lang Issue Type: Improvement Components: lang.builder.* Affects Versions: 2.3 Reporter: Paul Benedict Fix For: Patch Needed While it is very nice reflection can be used to build a nice equals method, the strategy to focus on private properties is non-negotiable. This strategy is incompatible with CGLIB proxies which rely on method invocations to delegate to the properties of the inner target. I would prefer a switch to dynamically invoke public get* methods over direct property access. PS: Same thoughts on ReflectionToStringBuilder and HashCodeBuilder -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-395) annotations based builders
[
https://issues.apache.org/jira/browse/LANG-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-395:
---
Fix Version/s: (was: 3.x)
Patch Needed
annotations based builders
--
Key: LANG-395
URL: https://issues.apache.org/jira/browse/LANG-395
Project: Commons Lang
Issue Type: New Feature
Components: lang.builder.*
Reporter: Jörg Gottschling
Fix For: Patch Needed
What about enabling the builders (ToStringBuilder, EqualsBuilder, etc.) that
use reflection to use annotations to find the field to include?
Something like:
ToStringBuilder.annotationsBasedToString(Object object, ClassAnnotation
class, Class? reflectUpToClass)
One could use the JPA-Annotation @ID for example, espescially for Equals- and
HashCodeBuilder. There should also be some default annotation comming with
LangTwo.
Usage:
public class User
{
@StringRepresentation
@EqualsAndHashCode
private String name
@StringRepresentation
private String email;
private String password;
// ...
@Override
public String toString()
{
return annotationsBasedToString(this);
}
@Override
public boolean equals(Object other)
{
return annotationsBasedEquals(this, other);
}
@Override
public int hashCode()
{
return annotationsBasedHashCode(this);
}
}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-341) [NumberUtils] Please add number byte[] methods
[
https://issues.apache.org/jira/browse/LANG-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-341:
---
Fix Version/s: (was: 3.x)
Review Patch
[NumberUtils] Please add number byte[] methods
-
Key: LANG-341
URL: https://issues.apache.org/jira/browse/LANG-341
Project: Commons Lang
Issue Type: New Feature
Components: lang.math.*
Reporter: Lilianne E. Blaze
Fix For: Review Patch
Attachments: 341-v1-src.patch, 341-v1-test.patch, LANG-341-2.patch,
LANG-341.patch
Hello,
I need a set of methods to convert Long to or from a byte[] array, as if
writing / reading from Data(Input/Output)Stream(
ByteArray(Input/Output)Stream ).
First, doing it with Streams seems a bit wasteful, second, it seems a
pretty general use. Would it be possible to add something like that to,
for example,
org.apache.commons.lang.math.NumberUtils?
Example code:
static public long toLong(byte[] b)
{
return toLong(b, 0);
}
static public long toLong(byte[] b, int offset)
{
return (((long)b[offset] 56) +
((long)(b[offset + 1] 255) 48) +
((long)(b[offset + 2] 255) 40) +
((long)(b[offset + 3] 255) 32) +
((long)(b[offset + 4] 255) 24) +
((b[offset + 5] 255) 16) +
((b[offset + 6] 255) 8) +
((b[offset + 7] 255) 0));
}
static public byte[] longToByteArray(long l)
{
byte b[] = new byte[8];
longToByteArray(l, b, 0);
return b;
}
static public void longToByteArray(long l, byte b[], int offset)
{
b[offset] = (byte)(l 56);
b[offset + 1] = (byte)(l 48);
b[offset + 2] = (byte)(l 40);
b[offset + 3] = (byte)(l 32);
b[offset + 4] = (byte)(l 24);
b[offset + 5] = (byte)(l 16);
b[offset + 6] = (byte)(l 8);
b[offset + 7] = (byte)(l 0);
}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-483) Add ComparisonUtils to Commons Lang
[ https://issues.apache.org/jira/browse/LANG-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-483: --- Fix Version/s: (was: 3.x) Review Patch Add ComparisonUtils to Commons Lang --- Key: LANG-483 URL: https://issues.apache.org/jira/browse/LANG-483 Project: Commons Lang Issue Type: New Feature Components: lang.compare.* Reporter: Benjamin McCann Fix For: Review Patch Attachments: ComparisonUtils.java, ComparisonUtilsTest.java It'd be impossible to guess how many times code as been written to find the position of the maximum element in an array or the value of the minimum element in a list, etc. This class will handle all of that. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-916) CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800375#comment-13800375
]
Thomas Neidhart commented on LANG-916:
--
The patch was created against trunk, so is for 3.2
CLONE - DateFormatUtils.format does not correctly change Calendar TimeZone in
certain situations
Key: LANG-916
URL: https://issues.apache.org/jira/browse/LANG-916
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 3.1
Environment: Sun JDK 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
3.9.10-100.fc17.i686.PAE).
Reporter: Christian P. MOMON
Labels: patch
Fix For: 2.7, Review Patch
Attachments: LANG-916.patch
In LANG-538 issue, there is an unit test:
{noformat}
public void testFormat_CalendarIsoMsZulu() {
final String dateTime = 2009-10-16T16:42:16.000Z;
GregorianCalendar cal = new
GregorianCalendar(TimeZone.getTimeZone(GMT-8));
cal.clear();
cal.set(2009, 9, 16, 8, 42, 16);
cal.getTime();
FastDateFormat format =
FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(GMT));
assertEquals(dateTime, dateTime, format.format(cal));
}
{noformat}
This test passes successfully in lang-2.6 but failed in lang3-3.1:
{noformat}
org.junit.ComparisonFailure: dateTime expected:2009-10-16T[16]:42:16.000Z
but was:2009-10-16T[08]:42:16.000Z
{noformat}
Reproduced whit Sun Java version: 1.6.0_45 and 1.7.0_21 on Fedora 17 (Linux
3.9.10-100.fc17.i686.PAE).
Moreover, I wrote another unit test showing that the timeZone parameter seems
to be ignored :
{noformat}
public void test() {
Calendar cal =
Calendar.getInstance(TimeZone.getTimeZone(Europe/Paris));
cal.set(2009, 9, 16, 8, 42, 16);
//
System.out.println(DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.format(cal));
System.out.println(long);
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getDefault()));
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Asia/Kolkata)));
System.out.println(DateFormatUtils.format(cal.getTimeInMillis(),
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Europe/London)));
System.out.println(calendar);
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getDefault()));
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Asia/Kolkata)));
System.out.println(DateFormatUtils.format(cal,
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern(),
TimeZone.getTimeZone(Europe/London)));
System.out.println(calendar fast);
System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Europe/Paris)).format(cal));
System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Asia/Kolkata)).format(cal));
System.out.println(FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(Europe/London)).format(cal));
}
{noformat}
Gives the following console logs:
{noformat}
long
2009-10-16T08:42:16+02:00
2009-10-16T12:12:16+05:30
2009-10-16T07:42:16+01:00
calendar
2009-10-16T08:42:16+02:00
2009-10-16T08:42:16+02:00
2009-10-16T08:42:16+02:00
calendar fast
2009-10-16T08:42:16.975Z
2009-10-16T08:42:16.975Z
2009-10-16T08:42:16.975Z
{noformat}
When DateFormatUtils.format takes a long parameter, the time string is good.
When DateFormatUtils.format takes a Calendar parameter, the time string is
wrong, the timezone parameter is IGNORED.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-403) HashcodeBuilder is broken for Annotations
[
https://issues.apache.org/jira/browse/LANG-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-403:
---
Fix Version/s: (was: 3.x)
Patch Needed
HashcodeBuilder is broken for Annotations
-
Key: LANG-403
URL: https://issues.apache.org/jira/browse/LANG-403
Project: Commons Lang
Issue Type: Improvement
Components: lang.builder.*
Affects Versions: 2.3
Reporter: Jay Liang
Fix For: Patch Needed
HashCodeBuilder does not produce a correct hashCode that conforms to java
language specs. Running the following code snippets, i get
@Simple$CustomAnnotation(name=blah, type=class java.lang.String) hashCode=
895255138
Simple$CustomAnnotationImpl@665753[_name=blah,_type=class java.lang.String]
hashCode= 122852694
hashCode should be 895255138
The hashCode should computed according to
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/annotation/Annotation.html#hashCode()
for annotations.
{code:java}
public class Simple{
@Retention(RetentionPolicy.RUNTIME)
@Target({FIELD, METHOD, PARAMETER})
private @interface CustomAnnotation{
public String name();
public Class? type();
}
private static class CustomAnnotationImpl implements CustomAnnotation{
final String _name;
final Class? _type;
public CustomAnnotationImpl(String name, Class? type) {
_name = name;
_type = type;
}
public String name() {
return _name;
}
public Class? type() {
return _type;
}
public Class? extends Annotation annotationType() {
return CustomAnnotation.class;
}
@Override
public int hashCode() {
return HashCodeBuilder.reflectionHashCode(this);
}
/**
* This conform to specs defined at
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/annotation/Annotation.html#hashCode
* @return good annotation hashCode
*/
public int goodHashCode() {
return (127 * name.hashCode() ^ _name.hashCode()) + (127
*type.hashCode() ^ _type.hashCode());
}
@Override
public String toString() {
return ToStringBuilder.reflectionToString(this);
}
}
private static class Test{
@CustomAnnotation(name=blah, type=String.class)
String _blah;
@Override
public String toString() {
return ToStringBuilder.reflectionToString(this);
}
}
public static void main(String[] args) throws Exception{
for(Field f : Test.class.getDeclaredFields()){
for(Annotation a : f.getAnnotations()){
System.out.println(a + hashCode= + a.hashCode());
CustomAnnotationImpl c = new Simple.CustomAnnotationImpl(blah,
String.class);
System.out.println(c + hashCode= + c.hashCode());
System.out.println(hashCode should be + c.goodHashCode());
}
}
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-456) HashCodeBuilder throws StackOverflowError in bidirectional navigable association
[ https://issues.apache.org/jira/browse/LANG-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-456: --- Fix Version/s: (was: 3.x) Patch Needed HashCodeBuilder throws StackOverflowError in bidirectional navigable association Key: LANG-456 URL: https://issues.apache.org/jira/browse/LANG-456 Project: Commons Lang Issue Type: Bug Components: lang.builder.* Affects Versions: 2.4 Environment: Widows XP. Sun JDK 1.5 or 1.6. Reporter: Bob Fields Fix For: Patch Needed Attachments: HashCodeBuilderStackOverflow.zip, StackOverflowError.zip This is not the reflection methods, it is the regular HashCodeBuilder append methods. It causes EqualsBuilder, ToStringBuilder, CompareToBuilder to also throw the StackOverflowException, but those methods work when one of the HashCodeBuilder bidirectional association attributes .hashCode() is commented out. The problem is that all of the builders call registerObject() which creates a hashCode, but only the reflectionAppend method checks if an object is registered. Bi-directional associations are a very common pattern in Jaxb and Hibernate. In this case, I generate code from a model in order to avoid the reflection penalty - I already know what the attributes are at compile time, so I use .append instead of .reflectionAppend. See attached example + unit test. One side of the bidirectional association must be commented out in the hashCode method. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-503) GetterMethodsReflectionToStringBuilder (code attached, proposal for integration)
[ https://issues.apache.org/jira/browse/LANG-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-503: --- Fix Version/s: (was: 3.x) Review Patch GetterMethodsReflectionToStringBuilder (code attached, proposal for integration) Key: LANG-503 URL: https://issues.apache.org/jira/browse/LANG-503 Project: Commons Lang Issue Type: Improvement Components: lang.builder.* Affects Versions: 2.4 Reporter: Michael Vorburger Fix For: Review Patch Attachments: GetterMethodsReflectionToStringBuilder.java, GetterMethodsReflectionToStringBuilderTest.java, SomeTestBean.java The ReflectionToStringBuilder reflects on fields... I needed one that works based on public getters(). This is useful for example with some kind of value objects where the internal private field structure is not really what you would want to see in a toString(), but which have a series of getters which were exactly what was frequently required to be dumped. There is probably other uses too (e.g. works even with a SecurityManager - that's not what I wrote it for, but could be an advantage over the ReflectionToStringBuilder?). I have hacked this and will attach a GetterMethodsReflectionToStringBuilder.java (which extends ReflectionToStringBuilder; works fine, for my use) with a GetterMethodsReflectionToStringBuilderTest (which may need some coverage extension, but is certainly a valid basic unit test) with its SomeTestBean. I'll attach for your consideration to integrate this. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (LANG-503) GetterMethodsReflectionToStringBuilder (code attached, proposal for integration)
[ https://issues.apache.org/jira/browse/LANG-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13800377#comment-13800377 ] Henri Yandell commented on LANG-503: This and LANG-332 are the same issue. GetterMethodsReflectionToStringBuilder (code attached, proposal for integration) Key: LANG-503 URL: https://issues.apache.org/jira/browse/LANG-503 Project: Commons Lang Issue Type: Improvement Components: lang.builder.* Affects Versions: 2.4 Reporter: Michael Vorburger Fix For: Review Patch Attachments: GetterMethodsReflectionToStringBuilder.java, GetterMethodsReflectionToStringBuilderTest.java, SomeTestBean.java The ReflectionToStringBuilder reflects on fields... I needed one that works based on public getters(). This is useful for example with some kind of value objects where the internal private field structure is not really what you would want to see in a toString(), but which have a series of getters which were exactly what was frequently required to be dumped. There is probably other uses too (e.g. works even with a SecurityManager - that's not what I wrote it for, but could be an advantage over the ReflectionToStringBuilder?). I have hacked this and will attach a GetterMethodsReflectionToStringBuilder.java (which extends ReflectionToStringBuilder; works fine, for my use) with a GetterMethodsReflectionToStringBuilderTest (which may need some coverage extension, but is certainly a valid basic unit test) with its SomeTestBean. I'll attach for your consideration to integrate this. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-706) Create a MutableNumber interface with methods common to all the mutable numbers
[
https://issues.apache.org/jira/browse/LANG-706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-706:
---
Fix Version/s: (was: 3.x)
Patch Needed
Create a MutableNumber interface with methods common to all the mutable
numbers
---
Key: LANG-706
URL: https://issues.apache.org/jira/browse/LANG-706
Project: Commons Lang
Issue Type: Improvement
Components: lang.mutable.*
Reporter: Juan Carlos Estibariz
Priority: Minor
Fix For: Patch Needed
With this interface it would be possible to perform generic operations on
mutable numbers without worrying about the specific type, e.g.
{code}
// these two could be created in a different methods
MutableNumber m = new MutableDouble();
Number n = ...;
// this would do the right thing
m.add(n);
{code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-686) StringUtils.replaceEachRepeatedly(aaa, new String[]{aa}, new String[]{aXa}); throw an exception
[
https://issues.apache.org/jira/browse/LANG-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-686:
---
Fix Version/s: (was: 3.x)
Review Patch
StringUtils.replaceEachRepeatedly(aaa, new String[]{aa}, new
String[]{aXa}); throw an exception
-
Key: LANG-686
URL: https://issues.apache.org/jira/browse/LANG-686
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 2.6
Environment: jdk 1.6.24, windows xp pro sp3, eclipse helios
Reporter: qed
Fix For: Review Patch
Attachments: LANG-686.patch
After executing line
StringUtils.replaceEachRepeatedly(aaa, new String[]{aa}, new
String[]{aXa});
exception is thrown:
Exception in thread main java.lang.IllegalStateException: TimeToLive of -1
is less than 0: aXaXa
at
org.apache.commons.lang.StringUtils.replaceEach(StringUtils.java:3986)
at
org.apache.commons.lang.StringUtils.replaceEach(StringUtils.java:4099)
at
org.apache.commons.lang.StringUtils.replaceEach(StringUtils.java:4099)
at
org.apache.commons.lang.StringUtils.replaceEachRepeatedly(StringUtils.java:3920)
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-627) Include a way to explicitly define a hash constant for each primitive type, along with the functionality described in LANG-411
[ https://issues.apache.org/jira/browse/LANG-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-627: --- Fix Version/s: (was: 3.x) Patch Needed Include a way to explicitly define a hash constant for each primitive type, along with the functionality described in LANG-411 -- Key: LANG-627 URL: https://issues.apache.org/jira/browse/LANG-627 Project: Commons Lang Issue Type: Improvement Components: lang.* Reporter: Sean Mickey Priority: Minor Fix For: Patch Needed Original Estimate: 8h Remaining Estimate: 8h Regarding LANG-411, the description mentions 2 parameters for each hash operation: the first a parameter to hold the type instance to be hashed, the second a hash multiplier. Shouldn't there also be a way to define a specific hash constant value as well? Joshua Bloch refers to this value as the starting value for result in his examples and the HashCodeBuilder code maintains an internal field named: iTotal for this value. It doesn't seem to make sense to add a parameter to the hashing operations for a starting hash constant value, but it probably makes sense to add mutators that allow setting this value across any given type. For example: setIntHashConstant, setBoolHashConstant, setLongHashConstant, etc. Default values could be defined so that explicit hash constants are not required. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-647) ToStringBuilder output makes it difficult to distinguich between an empty String array and an array of one empty String
[
https://issues.apache.org/jira/browse/LANG-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-647:
---
Fix Version/s: (was: 3.x)
Patch Needed
ToStringBuilder output makes it difficult to distinguich between an empty
String array and an array of one empty String
---
Key: LANG-647
URL: https://issues.apache.org/jira/browse/LANG-647
Project: Commons Lang
Issue Type: Improvement
Components: lang.builder.*
Affects Versions: 2.5
Reporter: pascal jacob
Priority: Minor
Fix For: Patch Needed
ToStringBuilder output is the same for an empty array (i.e. new String[0])
and for an array containing only a single empty string (i.e. new String[] {
} ). This makes it difficult in some case to see the true nature of
arrays.
For example I once had a JUnit test case that print the following trace
failure:
java.lang.AssertionError:
Expected: InputViewHelper[a={},b={},c={msg},d={time}
got: InputViewHelper[a={},b={},c={msg},d={time}
Apparently the two objects look like the same! But they are not: one had an
empty array; the other had an array with only a single empty string. With a
customized ToStringStyle the difference became apparent:
Expected: InputViewHelper[a={},b={},c={msg},d={time}
got: InputViewHelper[a={},b={},c={msg},d={time}
The fix is simple, change the method: protected void
appendDetail(StringBuffer buffer, String fieldName, Object value) to:
protected void appendDetail(StringBuffer buffer, String
fieldName, Object value) {
if((value instanceof String)
((String)value).isEmpty()) {
buffer.append(\\);
}
else {
super.appendDetail(buffer, fieldName,
value);
}
}
here is the test case that revealed the problem:
public void testToStringBuilder() {
ToStringBuilder builder1 = new ToStringBuilder(Builder1);
builder1.append(empty array, new String[0]);
builder1.append(array of one empty string, new String[] {
});
builder1.append(array of two empty strings, new String[] {
, });
String builder1Result = builder1.toString();
System.out.println(builder1Result);
// -
ToStringBuilder builder2 = new ToStringBuilder(Builder2, new
ToStringStyle() {
@Override
protected void appendDetail(StringBuffer buffer, String
fieldName, Object value) {
if((value instanceof String)
((String)value).isEmpty()) {
buffer.append(\\);
}
else {
super.appendDetail(buffer, fieldName,
value);
}
}
});
builder2.append(empty array, new String[0]);
builder2.append(array of one empty string, new String[] {
});
builder2.append(array of two empty strings, new String[] {
, });
String builder2Result = builder2.toString();
System.out.println(builder2Result);
}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-654) DateUtils.truncate method is buggy when dealing with DST switching hours
[ https://issues.apache.org/jira/browse/LANG-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-654: --- Fix Version/s: (was: 3.x) Patch Needed DateUtils.truncate method is buggy when dealing with DST switching hours - Key: LANG-654 URL: https://issues.apache.org/jira/browse/LANG-654 Project: Commons Lang Issue Type: Bug Components: lang.time.* Affects Versions: 2.4 Environment: Operating System: Linux Red Hat Reporter: Maxi Fix For: Patch Needed DateUtils.trucate() does not work properly with daylight saving time. e.g.: Date: 2010-10-10 05:16:14.0 DateUtils.truncate(date, Calendar.DATE) : Sun Oct 10 01:00:00 CLST 2010 Instead of showing 10/10/2010, it shows 10/10/2010 01:00:00 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-637) There should be a DifferenceBuilder with a ReflectionDifferenceBuilder implementation
[ https://issues.apache.org/jira/browse/LANG-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-637: --- Fix Version/s: (was: 3.x) Review Patch There should be a DifferenceBuilder with a ReflectionDifferenceBuilder implementation - Key: LANG-637 URL: https://issues.apache.org/jira/browse/LANG-637 Project: Commons Lang Issue Type: Improvement Components: lang.builder.* Reporter: Eric Lewis Priority: Minor Fix For: Review Patch Attachments: commons-lang3-LANG-637-complete.patch, commons-lang3-LANG-637.patch, Diffable.java, DiffBuilder.java, DiffBuilderTest.java, Diff.java, DiffList.java, DiffListTest.java, DiffTest.java The ToStringBuilder and ReflectionToStringBuilder are great tools for everyday development. We use them to show all the properties in an object, which comes handy especially for testing. However, JUnit with its assertEquals() just outputs the toString() of the two compared objects. For complex objects, this becomes unreadable. So, it would be great to have a DifferenceBuilder with a ReflectionDifferenceBuilder implementation to be able to get only the differing properties of two objects. The question is whether the two objects would have to be of the same type or not. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-544) ToStringStyle.registry ThreadLocal initialValue should return a Set that implements reference equality checking instead of object equality
[ https://issues.apache.org/jira/browse/LANG-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-544: --- Fix Version/s: (was: 3.x) Patch Needed ToStringStyle.registry ThreadLocal initialValue should return a Set that implements reference equality checking instead of object equality -- Key: LANG-544 URL: https://issues.apache.org/jira/browse/LANG-544 Project: Commons Lang Issue Type: Bug Components: lang.builder.* Affects Versions: 2.4 Reporter: Michael Richards Fix For: Patch Needed ToStringStyle.registry ThreadLocal initialValue should return a Set that implements reference equality checking instead of object equality. This change would still protect against cyclical object graphs, but also protect against the following conditions: * Incorrect implementations of hashCode/equals for any objects in the object graph * Unintended side effects of the hashCode/equals methods for any objects in the object graph Unfortunately, Java versions prior to 1.6 do not provide a simple built-in mechanism to create such a Set. This issue is discussed here in detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4479578 A possible work-around is to use an IdentityHashMap instead of a Set. This class is available in Java 1.4 and later. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (LANG-621) ReflectionToStringBuilder.toString does not debug 3rd party object fields within 3rd party object
[
https://issues.apache.org/jira/browse/LANG-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-621:
---
Fix Version/s: (was: 3.x)
Review Patch
ReflectionToStringBuilder.toString does not debug 3rd party object fields
within 3rd party object
-
Key: LANG-621
URL: https://issues.apache.org/jira/browse/LANG-621
Project: Commons Lang
Issue Type: Improvement
Components: lang.builder.*
Affects Versions: 2.5
Reporter: Philip Hodges
Priority: Minor
Fix For: Review Patch
Attachments: LANG-621.patch
{code:title=Reflect.java|borderStyle=solid}
import org.apache.commons.lang.builder.ReflectionToStringBuilder;
public class Reflect {
public static void main(String[] args) {
// You can also use the builder to debug 3rd party objects:
// System.out.println(An object: +
ReflectionToStringBuilder.toString(anObject));
// expected:
Reflect$Compound@a83b8a[instanceInt=67890,fixture=Reflect$Simple@1d1acd3[instanceInt=12345]]
// actual:
Reflect$Compound@a83b8a[instanceInt=67890,fixture=Reflect$Simple@1d1acd3]
System.out.println(ReflectionToStringBuilder.toString(new
Compound()));
}
static class Compound {
private int instanceInt = 67890;
private Simple fixture = new Simple();
}
static class Simple {
private int instanceInt = 12345;
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (LANG-598) DateUtils.isSameDay needs to factor in TimeZone
[ https://issues.apache.org/jira/browse/LANG-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-598: --- Fix Version/s: (was: 3.x) Review Patch DateUtils.isSameDay needs to factor in TimeZone --- Key: LANG-598 URL: https://issues.apache.org/jira/browse/LANG-598 Project: Commons Lang Issue Type: Improvement Components: lang.time.* Affects Versions: 2.5 Reporter: Dan Checkoway Fix For: Review Patch Attachments: LANG-598.patch DateUtils.isSameDay works great as long as you only care about the default system TimeZone. If you're trying to see if two Dates are the same day in *another* TimeZone, then you're hosed. For example, let's say the two dates being compared are: January 1, 2010 at 8:30pm PST January 1, 2010 at 9:30pm PST If your system TimeZone is PST, then sure, those two dates are on the same day. But they are NOT the same day in EST, for example. The fix would be simple. Add an isSameDay(Date, Date, TimeZone) method, and simply call setTimezone on each of the Calendar objects constructed. The isSameDay(Calendar, Calendar) method can probably be left alone, since the caller conceivably has called setTimeZone on the Calendar objects prior to calling isSameDay. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (LANG-917) Exception when combining custom and choice format in ExtendedMessageFormat
[
https://issues.apache.org/jira/browse/LANG-917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1384#comment-1384
]
Thomas Neidhart edited comment on LANG-917 at 10/21/13 5:56 AM:
The attached patch fixes the problem (+ unit test) for 3.2.
was (Author: tn):
The attached patch fixes the problem (+ unit test).
Exception when combining custom and choice format in ExtendedMessageFormat
--
Key: LANG-917
URL: https://issues.apache.org/jira/browse/LANG-917
Project: Commons Lang
Issue Type: Bug
Components: lang.text.*
Affects Versions: 2.5, 2.6
Reporter: Arne Burmeister
Labels: patch
Attachments: ExtendedMessageFormatTest.java, LANG-917.patch
When using a custom format registered and a choice format with an inner
format is used in the same message format, an IndexOutOfBoundsException
occurs in the custructor of ExtendedMessageFormat:
{code:java}new ExtendedMessageFormat(Hi {0,test,any}, got
{1,choice,0#none|1#one|1{1,number}}, Collections.singletonMap(test, new
TestFormatFactory()));{code}
{noformat}
java.lang.IndexOutOfBoundsException: Index: 2, Size: 2
at java.util.ArrayList.rangeCheck(ArrayList.java:604)
at java.util.ArrayList.get(ArrayList.java:382)
at
org.apache.commons.lang.text.ExtendedMessageFormat.insertFormats(ExtendedMessageFormat.java:364)
at
org.apache.commons.lang.text.ExtendedMessageFormat.applyPattern(ExtendedMessageFormat.java:192)
at
org.apache.commons.lang.text.ExtendedMessageFormat.init(ExtendedMessageFormat.java:127)
{noformat}
The problem occurs at the start of {{\{1,number\}}}.
As a workaround i registered the {{TestFormatFactory}} also for choice and
then returning {{new ChoiceFormat(arguments)}}, but that is not the idea.
I also checked the change logs, but there seems no change on this problem. I
have not tester, but I think the bug still is present in the current release.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Comment Edited] (LANG-905) Compare between arrays
[ https://issues.apache.org/jira/browse/LANG-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13799967#comment-13799967 ] Thomas Neidhart edited comment on LANG-905 at 10/21/13 5:57 AM: Attached a patch + unit test to fix the problem for 3.2. was (Author: tn): Attached a patch + unit test to fix the problem. Compare between arrays -- Key: LANG-905 URL: https://issues.apache.org/jira/browse/LANG-905 Project: Commons Lang Issue Type: Bug Reporter: E Labels: patch Fix For: Review Patch Attachments: LANG-905.patch when comparing 2 arrays, EqualsBuilder returns true even if they contain different elements. example: Object[] o1 = new Object[1]; o1[0]=Hello; Object[] o2 = new Object[1]; o2[0]=Bye; System.out.println(EqualsBuilder.reflectionEquals(o1, o2, true)); -- This message was sent by Atlassian JIRA (v6.1#6144)
