Метод equals() в Timestamp работает как раз нормально. Его в принципе нельзя так определить, чтобы не нарушить контракт, т.к. в общем случае Timestamp не равен Date из-за наличия дополнительных полей. Я не спорю, что унаследовав класс и переопределив некоторые методы, можно нарушить контракт, но в данном случае это классы из одной и той же библиотеки.

Лично мне кажется более корректным сравнивать именно классы, т.е. как делает IDEA:

Нет никаких общих случаев. 
Если используется публичное наследование, то класс наследник должен удовлетворять _всем_ контрактам класса родителя по определению.
Спорить по этому поводу я даже не буду.

В данном случае на метод Equals класса Date накладываются 
1) контракты класса оbject - они были вами процитированы
2) контракт класса Date (getTime = anotherDate.getTime)
В итоге контракт метода equals в классе Date является более _строгим_, чем у object. Никаких нарушений нет.

Класс Timestamp не выполняет контракт родителя, поэтому 
а) либо нужно не трогать Equals и добавить специальный метод сравнения только с timestamp
б) заменить наследование делегированием (единственной формой не паблик наследования в java).
Всё.


Смысл данной фразы ускользает от меня в заоблочные дали.
Нарушать контракт НЕЛЬЗЯ ни в каком случае, независимо от того в каких библиотеках находятся классы.
А если такое произошло, то винить нужно не класс родитель, а программиста выбравшего его в качестве такового.


Код, который создаёт IDEA для метода equals, удобен в одних случаях, но не удобен в других.
Н-р:


В конкретной задаче классы А и B, не смотря на разницу в типах (Z,Y), могут быть одинаковыми в смысле Х.

А какой пункт контракта из перечисленных нарушен в Timestamp? У Timestamp контракт более строгий чем у Date, ситуация аналогична Object - Date.

Я считаю что наследник, не должен быть равен "родителю". Рассмотрим такую ситуацию, есть у нас класс Shape, и у него есть два наследника Rectangle и Ellipse. Если в Shape опртеделить equals() вот так:

а в наследниках сделать обработку случая сравнения с Shape, то из свойства транзитивности будет следовать:

что вообще говоря "странно".


Я имел в виду, что если мы унаследуем от некого класса, и своими модификациями нарушим контракт, то виноваты будем мы, а не разработчик исходного класса.

Ну давайте устроим спор из разряда "в java всё передаётся по значению или по ссылке?".

Метод Equals у класса Timestamp правильно переопределяет метод Equals класса Object, но при этом нарушает контракт класса Date.
Если бы это было не так, то не было бы нарушения A.Equals(B)==B.Equals(A).

Если бы реализация метода Equals в Date была другая, то проблемы могло бы и не возникнуть, но поскольку _сначала_ был создан класс Date и именно с такой реализацией данного метода, а _потом_ от него отнаследовали класс Timestamp, то ошибка ложится на плечи авторов класса Timestamp.
Разве это не очевидно?


Опять двадцать пять.
Именно из-за таких "я считаю", каждый метод должен снобжаться явным описанием того, что он делает (а не описанием как). 

Если семантика метода Equals у Shape такова, что он должен проверять фигуры на их геометрическое тождество, то на лицо ошибочная реализация. Данный метод должен быть abstract в shape. Но даже в этом случае: квадрат с прямоугольником как сравнивать будете?  Нужно иметь ясное представление о том, что должен делать метод, преждем чем его создавать и уж тем более это важно при наследовании.

А если метода Equals предполагает сравнение центров фигур (такой у него контракт и ничего преступного тут нет), то всё в вашем примере работает просто замечательно: эллипс действительно будет равен прямоугольнику в этом смысле.


Вот и я о том же, разработчик Timestamp нарушил контракт исходного класса.

Позволю и себе задать маленький вопрос  Нужно написать функцию которая принимает целое число и возращает результат целочисленого деления на 32. Нельзя использовать в тексте арабские  цифры и символы +, -, /, *, % и циклы. Чем короче, тем лучше

Может сдвигать влево на 5??? 

так нельзя использовать арабские цифры (см. условие)

Пришло в голову вот такое решение, но без нуля я не обошелся:

Так тоже нельзя?

на так, не так нельзя, так как арабские цифры должны отсутствовать в коде

Добавлено @ 14:37 
2batigoal: операции -, +, *, / использоваит нельзя, а Вы использовали -, ну и 0 еще

А так можно?

Можно извратится так:

Ну или получить 4 а потом сдвиг.

Добавлено @ 14:46 

Тут есть минус, но в целом ход мысли верный. Надо только вычитание заменить сдвигом.

Угу, точно, проморгал.

2LSD:   а в своем коде Вы использовали ар. цифры - а этого делать нельзя. 
2shimopus: Вы использовали минус - ай-ай-ай  Но ход мысли действительно правильный. Но для этого нужно помнить коды символов, есть способ попроще;)

Я уже думал над этим. Но для сдвига надо либо взять первое число очень большим, либо второе получить очень маленьким