How to determine method signature

Question

Consider the following compilation unit in Java where ecran.afficher essentially is System.out.println. I do not understand why no error is detected at compile-time. According to me, at least the call d.m(d,c) is incorrect. There is an ambiguity between methods A.m(D, A) and D.m(A, A). But the compiler choses A.m(D, A). I cannot figure out why.
class A
void m(A x, A y){ ecran.afficher("A.m(A, A) -- stop") ; }
void m(D x, A y){ ecran.afficher("A.m(D, A)") ; m(y, x) ; }
class B extends A
          void m(A x, A y){ ecran.afficher("B.m(A, A)") ; y.m(x, x) ; }
          void m(B x, A y){ ecran.afficher("B.m(B, A)") ; y.m(x, x) ; }
          void m(A x, C y){ ecran.afficher("B.m(A, C)") ; y.m(x, x) ; }
class C extends B
void m(A x, A y){ ecran.afficher("C.m(A, A)") ; x.m(y, this) ; }
          void m(B x, A y){ ecran.afficher("C.m(B, A)") ; x.m(y, this) ; }
          void m(A x, C y){ ecran.afficher("C.m(A, C)") ; x.m(y, this) ; }
class D extends A
void m(A x, A y){ ecran.afficher("D.m(A, A) -- stop") ; }
class Q3
public static void main(String[] args){
A a = new A() ; B b = new B() ; C c = new C() ; D d = new D() ;
          A w = d ; A x = b ; B y = c ; A z = c ;
          d.m(d, c) ;
          d.m(x, y) ;
          z.m(a, b) ;
          c.m(d, x) ;
          y.m(z, a) ;
}

Answer 1

Thanks for giving me the pointer to the Specification
(third edition). Thus as far as I can
understand it, something fundamental has changed from
the second to the third edition. Now the class where
the method is declared is no longer taken into
account.
I suppose that this change is considered acceptable
by the Java designers since it increases the number
of accepted programs. My program is rejected by the
first two versions of the specification, not by the
third one.
I really feel it a bad idea to change such
fundamental aspects.I disagree.
As far as I can tell, the way the 2nd ed. is worded is a bug. I believe that the behavior you observe is what was intended all along, but that strict adherence to JLS 2nd ed. would lead to a compile time error due to ambiguity. A cannot be converted to D by method invocation conversion, so neither method matches both of the conditions.
I could be missing something though.
When the JLS has bugs--following it strictly leads to behavior that differs from the authors' intent--inconsistencies, or ambiguities, it must be revised. Naturally, the addition of new language features also requires revision of the spec.
At the same times, Java becomes so complex that I
really doubt that somebody is still able to write
correct programs in Java (i.e., a priori, not by
trial and error).I don't consider that a problem. Except for minimal, toy programs, I've never written a program that was perfect the first time. Nor do I need to. The compiler finds certain kinds of errors much more quickly and accurately than I ever could, and unit testing takes care of most of the rest.
Now, if you mean that nobody is able to write reasonably bug-free code with a reasonable amount of time and effort, I disagree. But that's entirely subjective anyway.
When I started to teach Java, I spent many days
reading the specification (first edition) carefully.
A few years later, I bought the second edition. But I
found the changes so complex (the new author is
credited as a "programming language theologist" !)
that I almost immediately decided to stick to the
first edition for ever.Then you have to live with the bugs and shortcomings of that editon. You also have to stick with using the corresponding version of the compiler (1.1 or whatever), or have a lang spec. that doesn't match the compiler that implements it.
Now, looking at the cryptic description of the third
edition, I just can say : "The world is getting
crazy". Who could possibly understand and use that ?I don't see the problem. It took me about ten minutes of fairly intesnse concentration to understand the relevant bits. It's not Dr. Seuss, but then, it's not intended to be. A general purpose computer language that has the kinds of features Java does is inherently complex. It requires a complex spec to define it precisely and accurately.
The problem is that I am teaching Java as a first
programming language in my University.That's reasonable. However, I don't think that Java's goals ever included being simple enough and unchanging enough to be easily grasped in its entirety by entry level university students.
I have to say
to my students : This language is changing all the
time. Yes. As are huge tracts of the technology landscape. It's the nature of the beast.
Also my demonstration programs are behaving
differently each year ! That sounds odd. Most of Java's changes as it moves forward have allowed programs written with earlier versions to compile and run unchanged with newer versions.
And I am forced to use the
latest version of the JDK, always bigger and bigger.Forced by whom? By you school's policy?
And I hate it !At the risk of sounding condescending, if you are that resistant to change, computer science may not be the ideal field for you.
Now what shall I do ? Since I will refuse trying to
read and understand the third editionNow it sounds like you're pouting. "My job is too hard. I won't do it. I won't I won't I won't."
(and the
fourth, the fifth...), I will probably teach an
hypothetical Java, invented by myself, and "directly
understandable". ("Tout ce qui n'est pas direct est
nul." (E.M. Cioran))That's your choice, I guess, but if you don't inform your students very clearly and emphatically that said language is something idealized for your convenience and doesn't reflect the real world, then you'll be doing them a great disservice (and possibly be violating Sun's license agreements or trademarks).