Mushfiq Mammadov wrote:1. On page 246, “Overriding a Method” section, the third sentence:
True! (But with duplicate "a method" you definitely know it's about methods and not fields

)
Mushfiq Mammadov wrote:2. On page 247, the output of example:
Maybe you laugh at me for this note
It doesn't actually matter but it is interesting. The outputs are 50.00 and 70.00 but we run this example the outputs would be 50.0 and 70.0. One zero is more than after dot.
Correct! And I would definitely not laugh about this one.
50.00 or
50.0 actually does matter: the 1st one has 4
significant figures, the latter one only 3.
Mushfiq Mammadov wrote:Maybe "name" is redundant in the above sentences. Because in the last sentence on page 246 is written that signature includes the name.
The method signature is indeed the combination of 2 components of the method declaration: the method's name and the parameter types. So the "name" part is indeed redundant, but it could also just be an additional aid to emphasize that the method name must be exactly the same (for those who have forgotten that method signature is name + parameters).
Mushfiq Mammadov wrote:Maybe "name" should be "return type" on page 265.
Here you are wrong! To have a valid override the return type must
not be the same. Since
Java 5
covariant return types are supported. Let's add a little code snippet to illustrate a covariant return type:
The above code compiles successfully! Although the return types do not match,
ReturnString.get() is a valid override of
ReturnValue.get().
ReturnString.get() has a covariant return type.
Hope it helps!
Kind regards,
Roel