такой вот код.




очевидно, что он не компилится.


Но смущает то, что выдает компилятор:

авторjava: m(java.lang.Number) in inheritanceTest.B cannot override m(java.lang.Number) in inheritanceTest.A
return type int is not compatible with void

Для меня override это полиморфизм... нет же никакого полиморфизма для статических методов.

Ведь это же overloading.


или jls как то по другому определяет override или ещё что-то я не понимаю - разъясните.

LS §8.4.8.3 (Java 8) says:

автор If a method declaration d1 with return type R1 overrides or hides the declaration of another method d2 with return type R2, then d1 must be return-type-substitutable (§8.4.5) for d2, or a compile-time error occurs.

Круто) компилятор по ходу работает абсолютно как jls)

а вот то, что в сообщение они забыли дописать слово hide - печально

Basil A. Sidorovquestionerhides?override (overload).



Хотите сказать, что jls не различаети override и overload?

Basil A. Sidorov,

Так, попробуем собрать всё воедино:


jlsTwo methods have the same signature if they have the same name and argument types

jls The signature of a method m1 is a subsignature of the signature of a method m2 if either:

m2 has the same signature as m1, or
the signature of m1 is the same as the erasure (§4.6) of the signature of m2.

Two method signatures m1 and m2 are override-equivalent iff either m1 is a subsignature of m2 or m2 is a subsignature of m1.

jlsIf two methods of a class (whether both declared in the same class, or both inherited by a class, or one declared and one inherited) have the same name but signatures that are not override-equivalent, then the method name is said to be overloaded.


вернемся к первому примеру:



у нас тут two methods of a class (whether both declared in the same class, or both inherited by a class, or one declared and one inherited) have the same name but signatures that are not override-equivalent , then the method name is said to be overloaded.[/quote]

are not override-equivalent - у нас явно override-equivalent !

Мне кажется придётся Вам всё-таки согласиться, что это не overloading)

Basil A. Sidorov,

Basil A. SidorovНежелательность такого сокрытия - остаётся в силе.

Да, конечно, в жизни нежелательно так делать)

Тут был вопрос на синтаксис

Basil A. Sidorov,

Basil A. SidorovА мне показалось, что придирка с сообщению компилятора

компилятор должен соответствовать jls) это тоже аксиома.

Basil A. Sidorov,Вывод: компилятор запрещает перегрузку
не вижу как этот демонстрируется в ващем примере.
автор но допускает сокрытие для статических.
Компилятор учитывает полную сигнатуру метода, включая возвращаемое значение.
да, допускает.


Если всё упростить и по русски, то у меня в голове сейчас следующее понимание.

перегрузка это когда у нас одинаковое имя у метода, но разный список параметров. Всё иное - не есть перегрузка.

hiding это по синтаксису то же самое, что и overriding только для статических методов.

Как мы знаем, что при overriding сигнатура(в терминах jls) должна сохраниться(как я понял из описания с учётом erasure, но это не наш случай, так что не будем об этом) возвращаемое значение должно быть ковариантно, throws <= чем у родителя и видимость >= чем у родителя.

Всё сходится.

Basil A. Sidorov,

я вас понял, интересный взгляд)


статичность здесь причем потому, что она позволяет создать такую ситуацию. Как я понимаю по-иному эту ситуацию и не получить. Поправьте если что

Basil A. Sidorovтип, который не совместим по присваиванию с типом скрываемого метода

Что скажете насчёт:




авторjava: m(java.lang.Number) in inheritanceTest.B cannot override m(java.lang.Number) in inheritanceTest.A
return type long is not compatible with int
-------------------------------------------------







авторjava: m(java.lang.Number) in inheritanceTest.B cannot override m(java.lang.Number) in inheritanceTest.A
return type long is not compatible with int


------------------------------





авторMain.java:20: error: m(Number) in B cannot override m(Number) in A
public static int m(Number n){System.out.println("Number B");return 1;};
^
return type int is not compatible with Integer

Basil A. Sidorov,

ну тогда напрашивается очевидный вопрос - что такое совместимость по присваиванию?


- ведь работает....

Basil A. Sidorov,

Basil A. Sidorovне "по присваиванию", а "по наследованию"
о том и речь.

а какая связь с примером то?

Компилируя в уме полагаю, что в случае НЕ статик.

трижды выведено class B

в случае статик

class A
class B
class A


вот слово ковариантность меня всегда пугала...когда-то я думал, что это аналог слова "приводимость" Но как оказалось нет и вообще по отношению к java не уверен, что стоит его понимать. Если оно только для override/hide методов используется

Basil A. Sidorov,
Basil A. SidorovС чего вдруг "нет"???

потому, что int приводим к long но не ковариантен ему!

Basil A. Sidorov,

приводимость бывает для объектов и для примитивов

---для объектов она называется ковариантность

---для примитов хрен знает как она называется

следовательно приводимость =! ковариантность

Basil A. Sidorov,

Basil A. SidorovВ (вашем) примере придирка к слову override - вы считаете, что должно быть hide.
Я считаю, что компилятор совершенно законно использует override, т.к. имеет место быть попытка перегрузки интерфейса класса. Попытка, нарушающая правила наследования

для override и hide даже правила вместе написаны. Так и называется раздел - правила для override and hide.

Ну я думаю, что тут уже наш спор себя исчерпал) хотелось бы услышать третью сторону

Basil A. Sidorov,

авторНу я думаю, что тут уже наш спор себя исчерпал

имеется ввиду по поводу overide/hide только

Basil A. Sidorov,

Basil A. SidorovТак что в контексте объектов "совместимость по присваиванию", она же "приводимость", она же "ковариантность" - эквивалентны.

только в контексте объектов!

для меня равенство это величина абсолютная во всех контекстах

то же самое сказать, что Object == String. String это Object, НО наоборот неверно.

Basil A. Sidorov,

вы сначала сами сказали, что
ВыТак что в контексте объектов "совместимость по присваиванию", она же "приводимость", она же "ковариантность" - эквивалентны.

потом я ответил:
автортолько в контексте объектов!

потом Вы:

Basil A. SidorovГде, пусть даже "только в контексте объектов" вы усмотрели "равенство" применительно к терминам "приводимость (по иерархии наследования)", "совместимость (по присваиванию)", "ковариантность (объектных типов)"???

как так то?


я лишь сказал, что
яприводимость =! ковариантность

ну то же самое если вас спросят List и LinkedList это одно и то же что вы ответите ?