Нашёл пример  немного изменил получилось:
Интересный, скажу я вам, получается результат.
Кто то может (не запуская!) сказать, что произойдёт после запуска этого приложения!? И объяснить свою версию...
Меня результат вогнал в ступор.




Это сообщение отредактировал(а) v2v - 4.9.2007, 17:09

Instrument1 play

так как flute =  new Instrument1();

соответственно и метод мы вызвали с класса Instrument1

Добавлено через 2 минуты и 38 секунд
ну и еще  static void tune(Instrument i) статический, значит метод play класса Instrument он принципиально вызвать не может

а как же преобразование к базовому типу?

Добавлено через 2 минуты и 19 секунд

на самом деле может, но как такое происходит что при приведении типов, данные из дочернего типа остаются?

вообще да может.. ступил малек )
в общем то оценил всю ситуацию.. терь сам не понимаю ))

А как же полиморфизм?

А где вы нашли приведение типов? Я нашел только переопределение метода play, который и вызвался у Instrument1...

static void tune(Instrument i)

Добавлено через 3 минуты и 49 секунд

а при чём тут он?

Народ вы чего? Создали экземпляр Instrument1. От того что его откастили к базовому классу значение ссылки на объект не поменялось, новый объект никто не создавал, работаем все с тем же экземпляром Instrument1. В котором метод переопределен.

Притом, что вызов метода зависит не от типа ссылки, а от типа объекта, на который эта ссылка указывает. Это как бы и есть полиморфизм.

значит upcasting это всего лишь изменение некоторого скрытого поля className и никакого удаления лишних меотодов, объектов из класса ...

Добавлено через 1 минуту и 14 секунд
всё. понял. спасибо за помощь

Все довольно логично, имхо. Создается инстанс flute, затем вызывается статический метод от класса-родителя. Статический метод вызывает метод инстанса play, который был переопределен.... тов.powerOn прав, полиморфизм, господа ;)


Вдогонку:

Если изменить код таким образом, то что же должно произойти? ;))

Добавлено через 58 секунд
ну, в общем, все уже сказали )) сорри за флуд 

AxNe0, ну да, твой кусок кода показывает тоже самое только более явно.

Это не баг, это фича. Выбор функций и полей виртуальной машиной определяется во время runtime. Поначалу не очень логично, просто надо привыкнуть. 
Логика такая: Пусть мы в какой нибудь ArrayList кладем много всяких Instrument, которые все звучат по разному, потому что play() is overridden. Предстваим что jvm запускает метод play() класса Instrument, и получится что все инструменты звучат одинаково, хотя мы и старались переепределить play(). Нет уж, once you've overridden the method of a class, you forget thinking about it. 

йоу, не заметил : тема помечена как решённая , я разобрался в чём фишка и как оно называется ?!;)