Как сравнить равенство 2 объекта StringBuffer / StringBuilder? [Дубликат]

 1.  System.out.println(sb1 == sb2);  

Метод equals StringBuffer возвращает true только тогда, когда объект StringBuffer сравнивается с самим собой. Он возвращает false по сравнению с любым другим StringBuffer, даже если два содержат одни и те же символы.

Это связано с тем, что «==» проверяет ссылочное равенство и поскольку оба sb1 и sb2 - разные ссылки на объекты, поэтому вывод в этом случае «false»

Тем не менее, если вы хотите проверить, равно ли содержимое в этих двух объектах StringBuffer, вы можете использовать это:

sb1.toString().equals(sb2.toString())

2. System.out.println(sb1.equals(sb2));

Это дает output как «false», потому что метод .equals () не был переопределен в классе StringBuffer. Поэтому он использует метод .equals () из своего родительского класса Object. В классе объектов .equals () записано для проверки ссылочного равенства.

Обратите внимание, что sb3.equals (sb4) вернет «true» в случае String. Поскольку метод .equals () был переопределен в классе String для проверки и сопоставления содержимого двух разных строк.

сравнивает две ссылки на объекты (sb1 - один, а sb2 - второй), поэтому оба они разные.

Если вы пытаетесь сравнить контент - используйте метод compareTo (...) в String class - это - сначала получить String содержимое StringBuffer, используя метод toString () (.toString (). compareTo).

Ps. с JDK 5 существует еще один гораздо более быстрый класс, который ведет себя точно так же, как StringBuffer - это StringBuilder и также не является потокобезопасным.

StringBuffer sb1 = new StringBuffer("Java"); 
StringBuffer sb2 = new StringBuffer("Java"); 

System.out.println(sb1.toString().compareTo(sb2.toString())); 

Интересно, почему StringBuffer не переопределяет метод equals. Вероятно, потому что содержимое объекта получается методом toString() и которое имеет желаемый метод.

Вы сравниваете ссылки на объекты StringBuffer, а не фактические строки внутри StringBuffer.

System.out.println(sb1.toString().equals(sb2.toString())) вернет true, и я предполагаю, что это то, чего вы ожидали или хотели достичь.

Строковый буфер equals() не переопределен. Он не сравнивает значения, он только сравнивает назначения ссылочных значений. Вот почему вы становитесь ложным, поскольку оба они ссылаются на разные объекты.

С JDK / 11 теперь можно сравнить два StringBuffer s без дополнительного toString, это можно сделать с использованием недавно введенного API -

public int compareTo​(StringBuffer another)

Сравнивает два StringBuffer экземпляра лексикографически. Этот метод следует тем же правилам для лексикографического сравнения, как определено в методе CharSequence.compare(this, another).

Замечание по реализации : этот метод синхронизирует на этот текущий объект, но а не StringBuffer другой , с которым сравнивается этот StringBuffer.

Возвращает : значение 0, если этот StringBuffer содержит ту же последовательность символов, что и аргумент StringBuffer; отрицательное целое число, если этот StringBuffer лексикографически меньше аргумента StringBuffer; или положительное целое число, если этот StringBuffer лексикографически больше аргумента StringBuffer.

Пример использования:

StringBuffer stringBuffer = new StringBuffer("null");
StringBuffer anotherStringBuffer = new StringBuffer("NULL");
System.out.println(stringBuffer.compareTo(anotherStringBuffer) == 0); // shall print 'false'

StringBuffer, кажется, не имеет собственного метода equals, поэтому я предполагаю, что StringBuffer наследует метод equals Object, который сравнивается с использованием sb1 == sb2. Поэтому оба метода дают одинаковый результат.

Простой ответ заключается в том, что StringBuffer (и StringBuilder) не переопределяют базовую семантику Object.equals (). Таким образом, equals в StringBuffer просто сравнивает ссылки на объекты.

Фактически, String, StringBuffer, StringBuilder и CharBuffer реализуют интерфейс CharSequence , а javadoc для этого интерфейса говорит this:

Этот интерфейс не уточняет общие контракты методов equals и hashCode. Таким образом, результат сравнения двух объектов, реализующих CharSequence, в общем случае не определен. Каждый объект может быть реализован другим классом, и нет гарантии, что каждый класс будет способен тестировать свои экземпляры для равенства с другими. Поэтому неуместно использовать произвольные экземпляры CharSequence в качестве элементов в наборе или как ключи на карте.