Why does compiler only look at public methods of superclasses of...?

[Wildemar Wildenburger]

I have never read a Java book by him, but I am envisioning it
something like "In java each class is in its own file". And all
the Java gurus will point out that it is not correct. And if the
same Java gurus wrote a book it would be "In java each top level
public class is in its own file" and the readers will close the
book after reading that and learn Python instead.

You make that sound like it's a bad thing.


/W

 

[failure_to]

Could you please tell us the title, author, and publisher of this
terrible book so we can (a) avoid it, (b) recommend against it, and (c)
complain to the publisher?


I find it even stranger that the technical reviewers of the book didn't
pick all this nonsense up. Are you sure you're quoting it accurately?

Well book is called Core Java 2, Volume 1, but as I don't actually
study from this book, it may very well be that author pointed out
( few pages earlier ) the fact that he is simplifying things. I don't
want a guy to loose a million cause of little me.

Anyways, I'm gonna quote the first two steps from the book, since
they appear to cause the most controversy:


"It is important to understand what happens when a method call is
applied to an object. Here are the details:

1) the compiler looks at the declared type of an object and the method
name. Let's say we call x.f(param), and the implicit parameter x is
declared to be an object of class C. Note that there may be multiple
methods, all with the same name, f, but with different parameter
types. For example, there may be a method f(int) and a method
f(String). The compiler enumerates all methods called f in the class C
and all methods called f in the superclasses of C
Now the compiler knows all possible candidates for the method to be
called

2) Next, the compiler determines the types of parameters that are
supplied in the parameter call. If among all the methods called f
there is a unique method whose parameter types are best match for the
supplied parameters, then that method is choosen to be called. This
process is called overloading resolution. The situation can get
complex because of type conversions ( int to Double and so on ). If
compiler cannot find any method with matching parameter types or if
multiple methods all match after applying conversions, then compiler
eports an error.
Now the compiler knows the name and parameter types of the method that
needs to be called"

cheers

 

[Ben Phillips]

Sure you can. Specifically from the JLS:
If the overridden or hidden method is protected, then the overriding or
hiding method must be protected or public; otherwise, a compile-time
error occurs.

Hrm. This suggests that adding a private method to a class might break a
subclass if that subclass defines a nonprivate method with the same
name. I would hope that this isn't the case! What does the JLS say about
it? I don't have a copy handy.

 

[Lew]

Hrm. This suggests that adding a private method to a class might break a
subclass if that subclass defines a nonprivate method with the same
name. I would hope that this isn't the case! What does the JLS say about
it? I don't have a copy handy.

<http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html>

There's no breakage because the subclass cannot see the superclass's private
method. It is free to declare its own private, package-private, protected or
public methods of the same name with compatible or incompatible signatures.

<http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.4.8>

 

[Eric Sosman]

Sure you can. Specifically from the JLS:
If the overridden or hidden method is protected, then the overriding
or hiding method must be protected or public; otherwise, a
compile-time error occurs.

Hrm. This suggests that adding a private method to a class might break a
subclass if that subclass defines a nonprivate method with the same
name. I would hope that this isn't the case! [...]

Other way 'round, I think: Adding a non-private method to a
superclass might break an existing subclass that defines a private
method with the same name and signature. Or in general, adding a
more-accessible method to the superclass can break a subclass whose
less-restrictive method suddenly becomes an override instead of a
free-standing "voluntary" method.

In an ideal world this wouldn't happen, and even in the real
world it doesn't happen often after the first few flailings at
an initial design. Adding a non-private method to a superclass
is a change in that class' "contract" with its clients; when a
contract is rewritten you have to expect some negotiations among
all the parties. It's a step not taken lightly -- but it is
occasionally taken, as when Vector was retrofitted with the
List interface.

 

[Eric Sosman]

[...] Or in general, adding a
more-accessible method to the superclass can break a subclass whose
less-restrictive method suddenly becomes an override [...]

"Less-accessible," of course. >sigh<

 

[EJP]

Anyways, I'm gonna quote the first two steps from the book, since
they appear to cause the most controversy:

Thanks. The word 'public' does not appear in the text you've quoted. So
there's nothing wrong with the *book*. You just made it up.