You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Daniel Trebbien (Created) (JIRA)" <ji...@apache.org> on 2012/01/20 20:52:40 UTC
[jira] [Created] (LANG-786) StringUtils equals() relies on
undefined behavior
StringUtils equals() relies on undefined behavior
-------------------------------------------------
Key: LANG-786
URL: https://issues.apache.org/jira/browse/LANG-786
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.0
Environment: java version "1.7.0_02"
Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
Fedora 15 AMD64
Reporter: Daniel Trebbien
Since the {{java.lang.CharSequence}} class was first introduced in 1.4, the JavaDoc block has contained the following note:
{quote}
This interface does not refine the general contracts of the equals and hashCode methods. The result of comparing two objects that implement CharSequence is therefore, in general, undefined. Each object may be implemented by a different class, and there is no guarantee that each class will be capable of testing its instances for equality with those of the other.
{quote}
When the signature of the StringUtils equals() method was changed from {{equals(String, String)}} to {{equals(CharSequence, CharSequence)}} in R920543, the implementation still relied on calling CharSequence#equals(Object) even though, in general, the result is undefined.
One example where {{equals(Object)}} returns {{false}} even though, as CharSequences, two objects represent equal sequences is when one object is an instance of {{javax.lang.model.element.Name}} and the other object is a String.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-786) StringUtils equals() relies on
undefined behavior
Posted by "Daniel Trebbien (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LANG-786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Trebbien updated LANG-786:
---------------------------------
Attachment: equals.patch
Fix
This re-introduces StringUtils#equals(String, String) and changes StringUtils#equals(CharSequence, CharSequence) to compare chars individually.
> StringUtils equals() relies on undefined behavior
> -------------------------------------------------
>
> Key: LANG-786
> URL: https://issues.apache.org/jira/browse/LANG-786
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
> Affects Versions: 3.0
> Environment: java version "1.7.0_02"
> Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
> Fedora 15 AMD64
> Reporter: Daniel Trebbien
> Labels: StringUtils
> Attachments: equals.patch
>
>
> Since the {{java.lang.CharSequence}} class was first introduced in 1.4, the JavaDoc block has contained the following note:
> {quote}
> This interface does not refine the general contracts of the equals and hashCode methods. The result of comparing two objects that implement CharSequence is therefore, in general, undefined. Each object may be implemented by a different class, and there is no guarantee that each class will be capable of testing its instances for equality with those of the other.
> {quote}
> When the signature of the StringUtils equals() method was changed from {{equals(String, String)}} to {{equals(CharSequence, CharSequence)}} in R920543, the implementation still relied on calling CharSequence#equals(Object) even though, in general, the result is undefined.
> One example where {{equals(Object)}} returns {{false}} even though, as CharSequences, two objects represent equal sequences is when one object is an instance of {{javax.lang.model.element.Name}} and the other object is a String.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-786) StringUtils equals() relies on
undefined behavior
Posted by "Daniel Trebbien (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LANG-786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Trebbien updated LANG-786:
---------------------------------
Affects Version/s: (was: 3.0)
3.x
> StringUtils equals() relies on undefined behavior
> -------------------------------------------------
>
> Key: LANG-786
> URL: https://issues.apache.org/jira/browse/LANG-786
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
> Affects Versions: 3.x
> Environment: java version "1.7.0_02"
> Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
> Fedora 15 AMD64
> Reporter: Daniel Trebbien
> Labels: StringUtils
> Attachments: equals.patch
>
>
> Since the {{java.lang.CharSequence}} class was first introduced in 1.4, the JavaDoc block has contained the following note:
> {quote}
> This interface does not refine the general contracts of the equals and hashCode methods. The result of comparing two objects that implement CharSequence is therefore, in general, undefined. Each object may be implemented by a different class, and there is no guarantee that each class will be capable of testing its instances for equality with those of the other.
> {quote}
> When the signature of the StringUtils equals() method was changed from {{equals(String, String)}} to {{equals(CharSequence, CharSequence)}} in R920543, the implementation still relied on calling CharSequence#equals(Object) even though, in general, the result is undefined.
> One example where {{equals(Object)}} returns {{false}} even though, as CharSequences, two objects represent equal sequences is when one object is an instance of {{javax.lang.model.element.Name}} and the other object is a String.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-786) StringUtils equals() relies on
undefined behavior
Posted by "Matt Benson (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LANG-786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Benson resolved LANG-786.
------------------------------
Resolution: Fixed
Hi, Daniel, and thanks for your contribution! Notwithstanding the obvious potential for arguments about OO design and method overloading, I have reworked your patch so that {{String-String}} comparisons are still handled in the body of the basic {{equals(CharSequence, CharSequence)}} method; thus no exception is needed in {{StringUtilsTest#testStringUtilsCharSequenceContract()}}. Specifically I have retained your {{StringUtilsEqualsIndexOfTest}} improvements.
{{Committed revision 1234915.}}
> StringUtils equals() relies on undefined behavior
> -------------------------------------------------
>
> Key: LANG-786
> URL: https://issues.apache.org/jira/browse/LANG-786
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
> Affects Versions: 3.x
> Environment: java version "1.7.0_02"
> Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
> Fedora 15 AMD64
> Reporter: Daniel Trebbien
> Labels: StringUtils
> Attachments: equals.patch
>
>
> Since the {{java.lang.CharSequence}} class was first introduced in 1.4, the JavaDoc block has contained the following note:
> {quote}
> This interface does not refine the general contracts of the equals and hashCode methods. The result of comparing two objects that implement CharSequence is therefore, in general, undefined. Each object may be implemented by a different class, and there is no guarantee that each class will be capable of testing its instances for equality with those of the other.
> {quote}
> When the signature of the StringUtils equals() method was changed from {{equals(String, String)}} to {{equals(CharSequence, CharSequence)}} in R920543, the implementation still relied on calling CharSequence#equals(Object) even though, in general, the result is undefined.
> One example where {{equals(Object)}} returns {{false}} even though, as CharSequences, two objects represent equal sequences is when one object is an instance of {{javax.lang.model.element.Name}} and the other object is a String.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-786) StringUtils equals() relies on
undefined behavior
Posted by "Henri Yandell (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LANG-786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Henri Yandell updated LANG-786:
-------------------------------
Fix Version/s: 3.2
> StringUtils equals() relies on undefined behavior
> -------------------------------------------------
>
> Key: LANG-786
> URL: https://issues.apache.org/jira/browse/LANG-786
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
> Affects Versions: 3.x
> Environment: java version "1.7.0_02"
> Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
> Fedora 15 AMD64
> Reporter: Daniel Trebbien
> Labels: StringUtils
> Fix For: 3.2
>
> Attachments: equals.patch
>
>
> Since the {{java.lang.CharSequence}} class was first introduced in 1.4, the JavaDoc block has contained the following note:
> {quote}
> This interface does not refine the general contracts of the equals and hashCode methods. The result of comparing two objects that implement CharSequence is therefore, in general, undefined. Each object may be implemented by a different class, and there is no guarantee that each class will be capable of testing its instances for equality with those of the other.
> {quote}
> When the signature of the StringUtils equals() method was changed from {{equals(String, String)}} to {{equals(CharSequence, CharSequence)}} in R920543, the implementation still relied on calling CharSequence#equals(Object) even though, in general, the result is undefined.
> One example where {{equals(Object)}} returns {{false}} even though, as CharSequences, two objects represent equal sequences is when one object is an instance of {{javax.lang.model.element.Name}} and the other object is a String.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-786) StringUtils equals() relies on
undefined behavior
Posted by "Dmitry Katsubo (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LANG-786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13479161#comment-13479161 ]
Dmitry Katsubo commented on LANG-786:
-------------------------------------
I think there is still area for improvement: [line 192 of CharSequenceUtils()|http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/CharSequenceUtils.java?revision=1199894&view=markup#l192] reads
{{TODO: Implement rather than convert to String}}
In my case I have {{CharSequence}} that implements a "lazy" string, and {{toString()}} implementation is very expensive plus can potentially cause OOM.
Thus {{CharSequenceUtils.regionMatches()}} should really do char-by-char comparison, leaving the optimization to underlying {{CharSequence}} implementation.
> StringUtils equals() relies on undefined behavior
> -------------------------------------------------
>
> Key: LANG-786
> URL: https://issues.apache.org/jira/browse/LANG-786
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
> Affects Versions: 3.x
> Environment: java version "1.7.0_02"
> Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
> Fedora 15 AMD64
> Reporter: Daniel Trebbien
> Labels: StringUtils
> Fix For: 3.2
>
> Attachments: equals.patch
>
>
> Since the {{java.lang.CharSequence}} class was first introduced in 1.4, the JavaDoc block has contained the following note:
> {quote}
> This interface does not refine the general contracts of the equals and hashCode methods. The result of comparing two objects that implement CharSequence is therefore, in general, undefined. Each object may be implemented by a different class, and there is no guarantee that each class will be capable of testing its instances for equality with those of the other.
> {quote}
> When the signature of the StringUtils equals() method was changed from {{equals(String, String)}} to {{equals(CharSequence, CharSequence)}} in R920543, the implementation still relied on calling CharSequence#equals(Object) even though, in general, the result is undefined.
> One example where {{equals(Object)}} returns {{false}} even though, as CharSequences, two objects represent equal sequences is when one object is an instance of {{javax.lang.model.element.Name}} and the other object is a String.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-786) StringUtils equals() relies on
undefined behavior
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LANG-786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13479203#comment-13479203 ]
Sebb commented on LANG-786:
---------------------------
@Dmitry: please raise this as a new JIRA issue (you can then link it to this one if you want).
We have already closed this issue, and your comment is about performance rather than correctness.
> StringUtils equals() relies on undefined behavior
> -------------------------------------------------
>
> Key: LANG-786
> URL: https://issues.apache.org/jira/browse/LANG-786
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
> Affects Versions: 3.x
> Environment: java version "1.7.0_02"
> Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
> Fedora 15 AMD64
> Reporter: Daniel Trebbien
> Labels: StringUtils
> Fix For: 3.2
>
> Attachments: equals.patch
>
>
> Since the {{java.lang.CharSequence}} class was first introduced in 1.4, the JavaDoc block has contained the following note:
> {quote}
> This interface does not refine the general contracts of the equals and hashCode methods. The result of comparing two objects that implement CharSequence is therefore, in general, undefined. Each object may be implemented by a different class, and there is no guarantee that each class will be capable of testing its instances for equality with those of the other.
> {quote}
> When the signature of the StringUtils equals() method was changed from {{equals(String, String)}} to {{equals(CharSequence, CharSequence)}} in R920543, the implementation still relied on calling CharSequence#equals(Object) even though, in general, the result is undefined.
> One example where {{equals(Object)}} returns {{false}} even though, as CharSequences, two objects represent equal sequences is when one object is an instance of {{javax.lang.model.element.Name}} and the other object is a String.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira