JDK-5082260 : StringBuffer should implement equals(Object), should take String, CharSequence
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2004-08-03
  • Updated: 2016-01-20
  • Resolved: 2004-08-03
Related Reports
Relates :  
JDK-8137326 - Methods for comparing CharSequence, StringBuilder, and StringBuffer
Description

Name: rmT116609			Date: 08/03/2004


A DESCRIPTION OF THE REQUEST :
Class java.lang.StringBuffer does not override method equals(Object).  It
probably should define equals(...)  to compare the string value currently
represented by the StringBuffer with the string value represented by the
argument.

It should obviously accept StringBufer objects.

It should accept String objects.

It should probably accept CharSequence objects.

Possibly it should also accept character array objects.




JUSTIFICATION :
Currently, there doesn't seem to be any efficient and convenient way to
compare the string represented by a string buffer with another string,
especially one represented by a String object.

You could use:
   string.equals( stringBuffer.toString() )
but  that (inefficiently) creates a second String object (which shouldn't be
necessary just to compare the represented strings).



EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
See proposal in Description section.
ACTUAL -
See description of current (main) option in Justification section.


(Incident Review ID: 295726) 
======================================================================
Comments
EVALUATION Whether StringBuffer *should* override equals is an interesting design question. Whether equals should compare the current values, or should return true only if the objects could *never* have different values, is not obvious. There is a school of thought that mutable objects like StringBuffer should never override equals. One reason is that it would allow hashtables to become corrupted. Presumably, if StringBuffer overrode equals(), it would also have to override hashCode(). But then in the sequence Map m = new HashMap(); StringBuffer sb = new StringBuffer(); sb.append("foo"); m.put(sb, 1) sb.append("bar"); m.get(sb); the get might fail, because the hashCode has changed, violating a Map invariant. Unfortunately, the JDK is not consistent on this point. Some classes are "safer", others "convenient". In any case, StringBuffer cannot now be modified, because of compatibility concerns. Similarly, StringBuilder has to be compatible with StringBuffer. ###@###.### 2004-08-03
03-08-2004