Hi Jan,
I think the author means
virtual in the sense that the method that will be doing the actual work is not
known during compilation.
But, since the
signature (i.e. the name of the method and the number, order and types of formal parameters)
is known, the compiler does know which
overloaded version of the method will be chosen.
Ultimately, at runtime, it is possible to know which actual, as opposed to virtual, method will be chosen,
because only then the real class is known.
Your code snippet shows only part of what is needed to explain this, because it is easier to understand
when there is some inheritance/sub-classing involved...
Suppose a class
Zoo that implements interface
Habitat and let's say in
Habitat you defined
two methods that look like the ones you show.
Given...
During compile you don't know which class instance will actually be returned by
Zoo.getZoo(), because
Zoo might itself be extended by other classes which might
override Zoo's methods.
What you and the compiler do know is that, whatever the 'extending' class will be, it will be a method having
the signature
lala(Object a, Animal b) that will do the actual work...because of the choice made on the
last line of the snippet...
...I hope it is a bit clearer
Gian