[LANG-786] StringUtils equals() relies on undefined behavior

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 3.2
• Component/s: lang.*
• Labels: StringUtils

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

• Assignee: Unassigned
• Reporter: Daniel Trebbien
• Created: 20/Jan/12 19:50
• Updated: 21/Oct/13 05:46
• Resolved: 23/Jan/12 17:52

Description

Since the java.lang.CharSequence class was first introduced in 1.4, the JavaDoc block has contained the following note:

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.

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.