В чем разница между instanceof и getclass

// выполнить код, если obj является экземпляром SomeClass

Метод getClass() — это метод, доступный каждому объекту в Java, который возвращает ссылку на класс, к которому принадлежит объект. Например, у нас есть объект obj, и мы можем получить ссылку на его класс, используя метод getClass():

Class objClass = obj.getClass();

Полученная ссылка на класс может быть использована для проверки типа объекта, сравнения с другими классами и многое другое.

Определение instanceof

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

public class Main < public static void main(String[] args) < Object obj1 = new String("Пример строки"); Object obj2 = new Integer(10); if (obj1 instanceof String) < System.out.println("obj1 является экземпляром класса String"); >if (obj2 instanceof Integer) < System.out.println("obj2 является экземпляром класса Integer"); >> >

В данном примере оператор instanceof используется для проверки, является ли объект obj1 экземпляром класса String и объект obj2 экземпляром класса Integer . В результате выполнения программы будет выведено сообщение «obj1 является экземпляром класса String» и «obj2 является экземпляром класса Integer».

Определение getClass

Пример использования метода getClass() :

String str ="Пример строки"; Class strClass = str.getClass(); 

В данном примере переменная strClass будет содержать объект типа Class , представляющий класс String . Теперь можно использовать методы класса Class для доступа к информации о классе и его структуре.

Метод getClass() может быть полезен, когда нужно проверить тип объекта или выполнить какие-то действия в зависимости от его класса. Например:

Object obj = new String("Пример строки"); if (obj.getClass() == String.class) < System.out.println("Объект является строкой"); >else

В этом примере мы сравниваем класс объекта, полученный с помощью метода getClass() , с классом String.class . Если они равны, то объект является строкой. Иначе он не является строкой.

Разница между использованием instanceof и getClass

Оператор instanceof проверяет, является ли объект экземпляром указанного класса или его подкласса. Оператор возвращает логическое значение true, если объект является экземпляром указанного класса, и false в противном случае. Например:

Person person = new Person(); if (person instanceof Person)

Метод getClass() возвращает объект класса Class, который предоставляет информацию о типе объекта во время выполнения. Метод getClass() может быть вызван на любом объекте, и он вернет класс, к которому принадлежит объект. Например:

Person person = new Person(); Class classObject = person.getClass(); System.out.println("The class of person object is: " + classObject.getName()); 

Одно из отличий между instanceof и getClass() заключается в том, что instanceof проверяет, является ли объект экземпляром указанного класса или его подкласса, в то время как getClass() возвращает класс, к которому принадлежит объект. Это означает, что instanceof можно использовать для проверки типов наследования, в то время как getClass() возвращает конкретный класс, к которому принадлежит объект, не учитывая его подклассы.

Другое отличие состоит в том, что instanceof можно использовать для проверки наличия интерфейса, в то время как getClass() этого не позволяет. Например:

Person person = new Person(); if (person instanceof Serializable)

В то же время, getClass() не позволяет такое использование:

Person person = new Person(); Class classObject = person.getClass(); // Нельзя проверить наличие интерфейса if (classObject instanceof Serializable)

instanceof Vs getClass( )

Is there any guideline, which one to use getClass() or instanceOf ? Given a scenario: I know exact classes to be matched, that is String , Integer (these are final classes), etc. Is using instanceOf operator bad practise ?

15.8k 34 34 gold badges 116 116 silver badges 206 206 bronze badges
asked Feb 14, 2011 at 7:40
3,945 2 2 gold badges 31 31 silver badges 45 45 bronze badges
This is explained in: stackoverflow.com/questions/596462/….
Feb 14, 2011 at 7:43

Your timing method is causing artificial delays and producing incorrect timing results. Swap the order you do the checks and you’ll see the first check you do (either == or instanceof) will always be longer. I’d guess it’s the println()s. You should never include that stuff in your timing block.

Sep 14, 2012 at 18:30

Just one comment apart, to compare performance, use multiple cycle iterations (e.g. 10000) in order to improve accuracy. One single invocation is not a good measure.

Mar 18, 2014 at 10:28
How large is the difference?
Dec 16, 2020 at 14:30

4 Answers 4

The reason that the performance of instanceof and getClass() == . is different is that they are doing different things.

• instanceof tests whether the object reference on the left-hand side (LHS) is an instance of the type on the right-hand side (RHS) or some subtype.
• getClass() == . tests whether the types are identical.

So the recommendation is to ignore the performance issue and use the alternative that gives you the answer that you need.

Is using the instanceOf operator bad practice ?

Not necessarily. Overuse of either instanceOf or getClass() may be «design smell». If you are not careful, you end up with a design where the addition of new subclasses results in a significant amount of code reworking. In most situations, the preferred approach is to use polymorphism.

However, there are cases where these are NOT «design smell». For example, in equals(Object) you need to test the actual type of the argument, and return false if it doesn’t match. This is best done using getClass() .

Terms like «best practice», «bad practice», «design smell», «antipattern» and so on should be used sparingly and treated with suspicion. They encourage black-or-white thinking. It is better to make your judgements in context, rather than based purely on dogma; e.g. something that someone said is «best practice». I recommend that everyone read No Best Practices if they haven’t already done so.

В чем разница между instanceof и getclass

An equals method needs to check the type of its argument, and there’s two ways to do that: with an instanceof check, or with a getClass() check.

public boolean equals(Object obj) if (!(obj instanceof Foo)) return false; // . > public boolean equals(Object obj) if (obj == null || getClass() != obj.getClass()) return false; // . >

(Note, with instanceof you don’t need an explicit null check, because instanceof already does that for you.)

Both are valid, but unfortunately, EqualsVerifier needs to know which one you use and it can’t always tell the difference. EqualsVerifier prefers instanceof , so if you use getClass() and run into a problem, you can add usingGetClass() :

EqualsVerifier.forClass(Foo.class) .usingGetClass() .verify();

Why the preference for instanceof ? Many IDEs generate equals methods with getClass() checks by default. Or maybe you just prefer getClass() over instanceof .

The reason is that Josh Bloch, in his Effective Java, recommends using instanceof over getClass() because instanceof plays nicer with the Liskov substitution principle. EqualsVerifier follows this advice.

You might ask: why is this Liskov substitution principle important? Well, tools like Hibernate, and many mocking frameworks such as Mockito and EasyMock, use bytecode manipulation tricks to generate subclasses on the fly. That means that an object that you instantiate yourself could never be equal to an object that you fetch from the database, even if all the fields have the same values, simply because they’re not of the same type.

If you use getClass() and you forget to add usingGetClass() , you might get this error message:

Subclass: object is not equal to an instance of a trivial subclass with equal fields: nl.jqno.equalsverifier.Foo@123456 Maybe you forgot to add usingGetClass(). Otherwise, consider making the class final or use EqualsVerifier.simple(). 

This is an example where the Liskov substitution principle and getClass() clash. EqualsVerifier creates a subclass of Foo , but adds nothing to it. Then it expects that equals treats it the same as an actual Foo . It doesn’t because getClass() returns different values for Foo and for the subclass.

In code, it looks like this:

class Foo private final int i; // . > class SubFoo extends Foo <> Foo a = new Foo(); Foo b = new SubFoo(); System.out.println(a.equals(b));

Should this print true or false ? SubFoo doesn’t change anything about Foo, so true seems to make most sense. However, with getClass() , it prints false .

Making Foo final is another way to avoid this problem.

Finally, if you think this is too strict, you can suppress Warning.STRICT_INHERITANCE or use EqualsVerifier.simple() instead.

If you want to know more about this, read Effective Java’s chapter on equals .

Updated: November 16, 2023

В чем разница между instanceof и getclass

Продолжение ответов на вопросы.

Object.equals() + Object.hashCode()

1. Могут ли у разных объектов в памяти (ref0 != ref1) быть ref0.hashCode() == ref1.hashCode() ?

Да, могут. Метод hashCode() не гарантирует уникальность возвращаемого значения.

2. Могут ли у разных объектов в памяти (ref0 != ref1) быть ref0.equals(ref1) == true ?

Да, могут. Для этого в классе этих объектов должен быть переопределен метод equals() .

Если используется метод Object.equals(), то для двух ссылок x и y метод вернет true тогда и только тогда, когда обе ссылки указывают на один и тот же объект (т.е. x == y возвращает true ).

3. Могут ли у разных ссылок на один объект в памяти (ref0 == ref1) быть ref0.equals(ref1) == false ?

Нет, не может. Метод equals() должен гарантировать свойство рефлексивности: для любых ненулевых ссылок x метод x.equals(x) должен возвращать true .

4. Есть класс Point . Почему хэш-код в виде 31 \* x + y предпочтительнее чем x + y ?

Множитель создает зависимость значения хэш-кода от очередности обработки полей, а это дает гораздо лучшую хэш-функцию.

5. Если у класса Point «правильно» реализовать метод equals (return ref0.x == ref1.x && ref0.y == ref1.y) , но сделать хэш-код в виде int hashCode() , то будут ли корректно такие точки помещаться и извлекаться из HashSet ?

HashSet использует HashMap для хранения элементов (в качестве ключа используется сам объект). При добавлении элемента в HashMap вычисляется хэшкод и позиция в массиве, куда будет вставлен новый элемент. У всех экземпляров класса Point одинаковый хэшкод, что приводит в вырождению хэш-таблицы в список. При возникновении коллизии осуществляется проверка на наличие уже такого элемента в текущем списке:

e.hash == hash && ((k = e.key) == key || key.equals(k))

Если элемент найден, то его значение перезаписывается. В нашем случае для разных объектов метод equals() будет возвращать false . Соответственно новый элемент будет добавлен в HashSet . Извлечение элемента также будет осуществляться успешно.

Но производительность такого кода будет низкой и преимущества хэш-таблиц использоваться не будут.

6. equals() порождает отношение эквивалентности. Какими из свойств обладает такое отношение: коммутативность, симметричность, рефлексивность, дистрибутивность, ассоциативность, транзитивность?

Метод equals() должен обеспечивать:

• симметричность (для любых ненулевых ссылок x и y метод x.equals(y) должен возвращать true тогда и только тогда, когда y.equals(x) возвращает true );
• рефлексивность (для любых ненулевых ссылок x метод x.equals(x) должен возвращать true .);
• транзитивность (для любых ненулевых ссылок x , y и z , если x.equals(y) возвращает true и y.equals(z) возвращает true , тогда и x.equals(z) должен возвращать true ).

Также есть ещё два свойства: постоянство и неравенство null .

7. Можно ли так реализовать equals(Object that) ?

Строго говоря нельзя, поскольку метод hashCode() не гарантирует уникальность значения для каждого объекта.

Однако для сравнения экземпляров класса Object такой код допустим, т.к. метод hashCode() в классе Object возвращает уникальные значения для разных объектов (вычисления основаны на использовании адреса объекта в памяти).

8. В equals требуется проверять, что аргумент (equals(Object that)) такого же типа как и сам объект. В чем разница между this.getClass() == that.getClass() и that instanceof MyClass ?

Оператор instanceof сравнивает объект и указанный тип. Его можно использовать для проверки является ли данный объект экземпляром некоторого класса, либо экземпляром его дочернего класса, либо экземпляром класса, который реализует указанный интерфейс.

getClass() = . проверяет два типа на идентичность.

Для корректной реализации контракта метода equals() необходимо использовать точное сравнение с помощью getClass().

9. Можно ли реализовать метод equals класса MyClass вот так: class MyClass > ?

Реализовать можно, но данный метод не переопределяет метод equals() класса Object, а перегружает его.

10. Будет ли работать HashMap , если все ключи будут возвращать int hashCode() ?

Да, будет. Но тогда хэш-таблица вырождается в связный список и теряет свои преимущества.

HashMap, HashSet

1. Зачем добавили HashMap , если уже был Hashtable ?

Класс Hashtable был введен в JDK 1.0 и не является частью Java Collection Framework. Методы класса Hashtable синхронизированы, что обеспечивает потокобезопасность, но это приводит к снижению производительности, поэтому и был введен класс HashMap , методы которого не синхронизированы.

Помимо этого класс HashMap обладает некоторыми другими отличиями: например, позволяет хранить один null ключ и множество null значений.

2. Согласно Кнуту и Кормену существует две основных реализации хэш-таблицы: на основе открытой адресацией и на основе метода цепочек. Как реализована HashMap ? Почему так сделали (по вашему мнению)? В чем минусы и плюсы каждого подхода?

Класс HashMap реализован с использованием метода цепочек, т.е. каждой ячейке массива соответствует свой связный список и при возникновении коллизии осуществляется добавление нового элемента в этот список.

Для метода цепочек коэффициент заполнения может быть больше 1, с увеличением числа элементов производительность убывает линейно. Такие таблицы удобно использовать, если заранее неизвестно количество хранимых элементов, либо их может быть достаточно много, что приводит к большим значениям коэффициента заполнения.

Среди методов открытой реализации различают:

• линейное пробирование;
• квадратичное пробирование;
• двойное хеширование.

Основные недостатки структур с методом открытой адресации:

• Количество элементов в таблице не может превышать размера массива. По мере увеличения числа элементов в таблице и повышения коэффициента заполнения (load factor) производительность структуры резко падает, поэтому необходимо проводить перехеширование.
• Сложно организовать удаление элемента.
• Также первые два метода открытой адресации приводят к проблеме первичной и вторичной группировок.

Основное преимущество хэш-таблицы с открытой адресацией — это отсутствие затрат на создание и хранение объектов списка. Также проще организовать сериализацию/десериализацию объекта.

3. Сколько переходов по ссылкам происходит, когда вы делаете HashMap.get(key) по ключу, который есть в таблице?

Возможно, я неправильно понял этот вопрос. За переходы по ссылке в данном ответе я считаю вызовы методов.

public V get(Object key)

Рассмотрим первый случай, когда ключ равен null : выполняем метод getForNullKey() .

private V getForNullKey() < if (size == 0) < return null; >for (Entry e = table[0]; e != null; e = e.next) < if (e.key == null) return e.value; >return null; >

В цикле foreach проходимся по списку значений для ключа и возвращаем нужное значение. Таким образом, получаем 1 переход.

Второй случай: ключ не равен null . Выполняем метод getEntry(key) .

final Entry getEntry(Object key) < if (size == 0) < return null; >int hash = (key == null) ? 0 : hash(key); for (Entry e = table[indexFor(hash, table.length)]; e != null; e = e.next) < Object k; if (e.hash == hash && ((k = e.key) == key || (key != null && key.equals(k)))) return e; >return null; >

Вычисляется хэш-код ключа (метод hash(key) ), затем определяется индекс ячейки массива, в которой будем искать значение (метод indexFor(hash, table.length) ).

После того, как нашли нужную пару «ключ-значение» возвращаем значение (метод entry.getValue() ). Таким образом, получаем 4 перехода.

4. Сколько создается новых объектов, когда вы добавляете новый элемент в HashMap ?

Один новый объект статического вложенного класса Entry .

5. Как работает HashMap при попытке сохранить в нее два элемента по ключам с одинаковым hashCode , но для которых equals == false ?

По значению hashCode вычисляется индекс ячейки массива, в список которой будет происходить добавление элемента. Перед добавлением осуществляется проверка на наличие уже элементов в этой ячейке. Если элементов нет, то происходит добавление. Если возникает коллизия, то итеративно осуществляется обход списка в поисках элемента с таким же ключом и хэш-кодом. Если такой элемент найден, то его значение перезаписывается, а старое — возвращается. Поскольку в условии сказано, что добавляемые ключи — разные, то второй элемент будет добавлен в начало списка.

6. HashMap может выродиться в список даже для ключей с разным hashCode . Как это возможно?

Это возможно в случае, если метод, определяющий номер ячейки массива по hashCode будет возвращать одинаковое значение.

7. Какое худшее время работы метода get(key) для ключа, которого нет в таблице (O(1), O(log(N)), O(N), O(N*log(N)), O(N*N)) ?

O(N). Худший случай — это поиск ключа в таблице, вырожденной в список, перебор ключей которой занимает линейно пропорциональное время количеству хранимых элементов.

8. Какое худшее время работы метода get(key) для ключа, который есть в таблице (O(1), O(log(N)), O(N), O(N*log(N)), O(N*N)) ?

O(N). Аналогичные рассуждения, что и для предыдущего вопроса.

9. Объясните смысл параметров в конструкторе HashMap(int initialCapacity, float loadFactor) .

int initialCapacity — исходный размер HashMap (количество корзин в хэш-таблице в момент её создания).

float loadFactor — коэффициент заполнения HashMap . Равен отношению числа хранимых элементов в таблице к её размеру. Является мерой заполнения таблицы элементами, при превышении которой происходит автоматической перехеширование.

10. В чем разница между HashMap и IdentityHashMap ? Для чего нужна IdentityHashMap ? Как может быть полезна для реализации сериализации или клонирования?

IdentityHashMap — это структура данных, реализующая интерфейс Map, но использующая сравнение ссылок вместо метода equals() при сравнении ключей (значений). Другими словами, в IdentityHashMap два ключа k1 и k2 будут рассматриваться равными, если выполняется условие k1 == k2 (в стандартной реализации интерфейса Map (например, HashMap) ключи k1 и k2 считаются равными, если выполняется условие (k1 == null ? k2 == null : k1.equals(k2)) ).

IdentityHashMap не использует метод hashCode() , вместо которого применяется метод System.identityHashCode(Object).

Другое отличие (как следствие) заключается в более высокой производительности IdentityHashMap по сравнению с HashMap , если последний хранит объекты с дорогостоящими методами equals() и hashCode() .

Одним из основных требований к использованию HashMap является неизменяемость ключа, однако это требование не распространяется на IdentityHashMap , который не использует методы equals() и hashCode() .

Согласно документации, такая структура данных может применяться для реализации сериализации/клонирования. Для выполнения подобных алгоритмов программе необходимо обслуживать таблицу со всеми ссылками на объекты, которые уже были обработаны. Такая таблица не должна рассматривать уникальные объекты как равные, даже если метод equals() возвращает true .

11. В чем разница между HashMap и WeakHashMap ? Для чего нужна WeakHashMap ?

Перед рассмотрением WeakHashMap кратко напомню, что такое WeakReference. В Java существует 4 типа ссылок: сильные ( strong reference ), мягкие (SoftReference), слабые ( WeakReference ) и фантомные (PhantomReference). Особенности каждого типа ссылок связаны с работой Garbage Collector. Если объект можно достичь только с помощью цепочки WeakReference (то есть на него не ссылаются сильные и мягкие ссылки), то данный объект будет отмечен для удаления. Хорошая статья с подробным описанием каждого типа ссылок — Understanding Weak References.

WeakHashMap — это структура данных, реализующая интерфейс Map и основанная на использовании WeakReference для хранения ключей. Таким образом, пара «ключ-значение» будет удалена из WeakHashMap , если на объект-ключ более не имеется сильных ссылок.

В качестве примера использования такой структуры данных можно привести следующую ситуацию: допустим имеются объекты, которые необходимо расширить дополнительной информацией, при этом изменение класса этих объектов нежелательно либо невозможно. В этом случае добавляем каждый объект в WeakHashMap в качестве ключа, а в качестве значения — нужную информацию. Таким образом, пока на объект имеется сильная ссылка (либо мягкая), можно проверять хэш-таблицу и извлекать информацию. Как только объект будет удален, то WeakReference для этого ключа будет помещен в ReferenceQueue и затем соответствующая запись для этой слабой ссылки будет удалена из WeakHashMap .

12. В WeakHashMap используются WeakReferences . А почему бы не создать SoftHashMap на SoftReferences ?

SoftHashMap представлена в стронних библиотеках, например, в Apache Commons.

13. В WeakHashMap используются WeakReferences . А почему бы не создать PhantomHashMap на PhantomReferences ?

PhantomReference при вызове метода get() возвращает всегда null , поэтому, я думаю, создание PhantomHashMap просто невозможно. Плюс назначение такой структуры данных тяжело представить.

14. Сделайте HashSet из HashMap (используйте только множество ключей, но не множество значений).

Set keySet = new HashSet<>(map.keySet());

15. Сделайте HashMap из HashSet (HashSet>) .

Map map = new HashMap<>(set.size()); for (Map.Entry entry : set)

Java getClass или instanceof для equals

Что лучше использовать для сравнения типов классов у переменных при написании equals ? Я уже описывал этот метод в специальной статье. С одной стороны, я часто видел использование instanceof :

Any reason to prefer getClass() over instanceof when generating .equals()?

I’m using Eclipse to generate .equals() and .hashCode() , and there is an option labeled «Use ‘instanceof’ to compare types». The default is for this option to be unchecked and use .getClass() to compare types. Is there any reason I should prefer .getClass() over instanceof ? Without using instanceof :

if (obj == null) return false; if (getClass() != obj.getClass()) return false; 

Using instanceof :

if (obj == null) return false; if (!(obj instanceof MyClass)) return false; 

I usually check the instanceof option, and then go in and remove the » if (obj == null) » check. (It is redundant since null objects will always fail instanceof .) Is there any reason that’s a bad idea?

asked Feb 27, 2009 at 20:14
108k 87 87 gold badges 234 234 silver badges 265 265 bronze badges

The expression x instanceof SomeClass is false if x is null . Hence, the second syntax doens’t need the null check.

Sep 6, 2017 at 10:46

@rds Yes, the paragraph immediately after the code snippet says this as well. It is in the code snippet because that is what Eclipse generates.

Sep 6, 2017 at 13:57

11 Answers 11

Josh Bloch favors your approach:

The reason that I favor the instanceof approach is that when you use the getClass approach, you have the restriction that objects are only equal to other objects of the same class, the same run time type. If you extend a class and add a couple of innocuous methods to it, then check to see whether some object of the subclass is equal to an object of the super class, even if the objects are equal in all important aspects, you will get the surprising answer that they aren’t equal. In fact, this violates a strict interpretation of the Liskov substitution principle, and can lead to very surprising behavior. In Java, it’s particularly important because most of the collections ( HashTable , etc.) are based on the equals method. If you put a member of the super class in a hash table as the key and then look it up using a subclass instance, you won’t find it, because they are not equal.

Effective Java chapter 3 also covers this.

1 1 1 silver badge
answered Feb 27, 2009 at 20:21
Michael Myers ♦ Michael Myers
191k 47 47 gold badges 292 292 silver badges 294 294 bronze badges

The problem with the instanceof approach is that it breaks the «symmetric» property of Object.equals() in that it becomes possible that x.equals(y) == true but y.equals(x) == false if x.getClass() != y.getClass(). I prefer not to break this property unless absolutely necessary (i.e., overriding equals() for managed or proxy objects).

Jun 25, 2013 at 23:13

The instanceof approach is proper when, and only when, the base class defines what equality among subclass objects should mean. Using getClass does not violate the LSP, since the LSP merely relates to what can be done with existing instances—not what kinds of instances can be constructed. The class returned by getClass is an immutable property of an object instance. The LSP does not imply that it should be possible to create a subclass where that property indicates any class other than the one which created it.

Jan 30, 2014 at 0:14

If you use instanceof , making your equals implementation final will preserve the symmetry contract of the method: x.equals(y) == y.equals(x) . If final seems restrictive, carefully examine your notion of object equivalence to make sure that your overriding implementations fully maintain the contract established by the Object class.

What I’m trying to get at here is that if you believe getClass() is the only reliable way to preserve symmetry, you are probably using equals() the wrong way.

Sure, it’s easy to use getClass() to preserve the symmetry required of equals() , but only because x.equals(y) and y.equals(x) are always false. Liskov substitutability would encourage you to find a symmetry-preserving implementation that can yield true when it makes sense. If a subclass has a radically different notion of equality, is it really a subclass?

answered Feb 27, 2009 at 21:11
268k 58 58 gold badges 397 397 silver badges 495 495 bronze badges
exactly that came to my mind when i read the josh bloch quote above. +1 🙂
Feb 27, 2009 at 21:43

definitely the key decision. symmetry must apply, and instanceof makes it very easy to be asymmetric accidentally

Mar 3, 2009 at 20:15

I’d also add that «if final seems restrictive» (on both equals and hashCode ) then use getClass() equality instead of instanceof in order to preserve the symmetry and transitivity requirements of the equals contract.

Jul 16, 2019 at 0:14

Angelika Langers Secrets of equals gets into that with a long and detailed discussion for a few common and well-known examples, including by Josh Bloch and Barbara Liskov, discovering a couple of problems in most of them. She also gets into the instanceof vs getClass . Some quote from it

Conclusions

Having dissected the four arbitrarily chosen examples of implementations of equals() , what do we conclude?

First of all: there are two substantially different ways of performing the check for type match in an implementation of equals() . A class can allow mixed-type comparison between super- and subclass objects by means of the instanceof operator, or a class can treat objects of different type as non-equal by means of the getClass() test. The examples above illustrated nicely that implementations of equals() using getClass() are generally more robust than those implementations using instanceof .

The instanceof test is correct only for final classes or if at least method equals() is final in a superclass. The latter essentially implies that no subclass must extend the superclass’s state, but can only add functionality or fields that are irrelevant for the object’s state and behavior, such as transient or static fields.

Implementations using the getClass() test on the other hand always comply to the equals() contract; they are correct and robust. They are, however, semantically very different from implementations that use the instanceof test. Implementations using getClass() do not allow comparison of sub- with superclass objects, not even when the subclass does not add any fields and would not even want to override equals() . Such a «trivial» class extension would for instance be the addition of a debug-print method in a subclass defined for exactly this «trivial» purpose. If the superclass prohibits mixed-type comparison via the getClass() check, then the trivial extension would not be comparable to its superclass. Whether or not this is a problem fully depends on the semantics of the class and the purpose of the extension.