overloaded methods

[Marlene Miller]

Just in case anyone has not seen this one:

class A {
   char m(char c) { System.out.println("char"); return c; }
}
class B extends A {
   float m(float f) { System.out.println("float"); return f; }
   public static void main(String[] args) {
      new B().m('x');
   }
}

(Added new B(). Thanks Lih.)
[ April 16, 2003: Message edited by: Marlene Miller ]

[Lih Chang]

Originally posted by Marlene Miller:
Just in case anyone has not seen this one:

class A {
   char m(char c) { System.out.println("char"); return c; }
}
class B extends A {
   float m(float f) { System.out.println("float"); return f; }
   public static void main(String[] args) {
      [B]new B().[/B]m('x');
   }
}

[ April 16, 2003: Message edited by: Marlene Miller ]

I added new B() in front of the method call. I'm not sure this was what you meant. What's intresting is that if I changed both methods to static, there is no compiler error and prints out 'char'. Don't know exactly why?

[Lih Chang]

Could this be the reason that static method does not participate polymorphism in the class hierarchy? But, why doesn't the compiler convert 'x' to int if both methods were declared as static?

[Thomas Paul]

Swap m(char c) and m(float f) and B compiles cleanly.
Move m(char c) out of A and put it in B and B compiles cleanly.
Make all the m()'s static and it compiles cleanly.
What do you think is happening in Marlene's little problem?

[Lih Chang]

Too many questions and too much confusion - that's why I'm still learning. Thomas, could you please tell me why? Thanks.

[Lih Chang]

I have tried several other combinations.

class A {
  //char m(char c) { System.out.println("char"); return c; }
  int m(int c) { System.out.println("int"); return c; }
  //float m(float f) { System.out.println("float 1"); return f; }
  //long m(long f) { System.out.println("long"); return f; }
}
class TestOverload1 extends A {
  //long m(long f) { System.out.println("long"); return f; }
  float m(float f) { System.out.println("float 2"); return f; }
  //int m(int c) { System.out.println("int"); return c; }
  //char m(char c) { System.out.println("char"); return c; }
  public static void main(String[] args) {
    new TestOverload1().m(10L);
  }
}

/*
  Base        Sub       param       compile     output
  ----------------------------------------------------
  float       long       'x'          OK        long
  long        float      'x'          error
  long        int        'x'          OK        int
  int         long       'x'          error
  int         float      'x'          error
  float       int        'x'          OK        int
  float       float      'x'          OK        float in Sub
  int         long       10           error
  long        int        10           OK        int
  int         float      10           error
  float       int        10           OK        int
  int         long       10L          OK        long
  long        int        10L          OK        long
  float       long       10L          OK        long
  float       int        10L          OK        float
  long        float      10L          error
  int         float      10L          OK        float
*/

Based on what I got, I guess that the compiler will choose the most compatible method and find the method from the bottom up in class hierarchy. Hope someone can shed some light on this.

[Marlene Miller]

Lih, you've been working hard on this one. This example helped me alot. I hope it helps you too.
Since the type of the argument in the m(�x�) is char, both m(float f) and m(char c) are *applicable* to the method invocation.
For the compiler to choose m(char c) instead of m(float f), (1) char has to be assignment compatible with float and (2) the class where m(char c) is declared has to be assignment compatible with the class where m(float f) is declared.
Unfortunately, a value of type A cannot be converted to B.
For the compiler to choose m(float f) instead of m(char c), (1) float has to be assignment compatible with char and (2) the class where m(float f) is declared has to be assignment compatible with the class where m(char c) is declared.
Unfortunately, a value of type float cannot be converted to char.
So the method invocation m(�c�) is ambiguous.

[Thomas Paul]

Well done, Marlene. Trying to figure that out from the JLS can be very painful and this little example helps to explain it easier.

[John Zoetebier]

Marlene says:

Since the type of the argument in the m(�x�) is char, both m(float f) and m(char c) are *applicable* to the method invocation.
For the compiler to choose m(char c) instead of m(float f), (1) char has to be assignment compatible with float and (2) the class where m(char c) is declared has to be assignment compatible with the class where m(float f) is declared.
Unfortunately, a value of type A cannot be converted to B.

The JLS says that if more than 1 method applies to the argument, the most restrictive method is chosen.
In this case method char m(char c) in base class A is more restrictive than method float m(float f) in subclass B.
Based on this rule I would expect the compiler to choose the method in base A.
But the compiler gives an error message, so something else is going on.
When both methods are static or in the same class, there is no problem.
If one method is inherited and an other method overloads the base method, the order does matter.
Why is this?

[Marlene Miller]

Hi John, I am glad you asked that question. This example helps to debug our assumptions.
The compiler chooses one method declaration m instead of other overloaded method declarations m� because
(1) all the types of the parameters of m can be converted to the types of the parameters of m�.
(2) the class where m is declared can be converted to the class where m� is declared.
Given
m(char c) declared in class A
m(float f) declared in class B
Can we convert char to float? Yes. Can we convert A to B? No.
Can we convert float to char? No. Can we convert B to A? Yes.
Here is the official description: JLS 15.12.2.2

[Marlene Miller]

Thank you Thomas. Painful is right. I learned this example from the SUN forums. I watched people puzzle over this for pages and pages.
I wish I had such revealing examples for every single item in the JLS. I even suggested a SUN forum called the "anotated JLS" where people could post examples and insights.

[Lih Chang]

Marlene, thank you so much for sharing your thought. I think I need to spend more time reading JLS before posting anymore. Thanks again. Here I wrote three more examples with some explanation just to make sure I understood the concept. I used the word "see" in my comment, not sure it is right though. If I was wrong again or missed any critical concept, please correct me. Thanks in advance.

/*
class A {
  float m(float f) { System.out.println("float"); return f; }
}
class TestOverload1 extends A {
  char m(char c) { System.out.println("char"); return c; }
  public static void main(String[] args) {
    //this compile cleanly and output "char"
    //a has a reference type of TestOverload1
    //at compile time, it "sees" both m(float) and m(char)
    //and 'x' can be converted to either float or char, so, both methods are applicable
    //which one is more specific for the compiler to choose
    //float -> char (no), A -> TestOverload1 (no)
    //char  -> float (yes), TestOverload1 -> A (yes)
    //therefore, m(char) is selected for method invocation
    //this has the same effect as new TestOverload1().m('x');
    TestOverload1 a = new TestOverload1();
    a.m('x');
  }
}
*/
/*
class A {
  byte m(byte b) { System.out.println("byte"); return b; }
}
class TestOverload1 extends A {
  char m(char c) { System.out.println("char"); return c; }
  public static void main(String[] args) {
    //this will give compiler error
    //because the reference type of a is A
    //at compile time, only m(byte) is "seen" by a
    //and 'x' can not be converted to type byte
    //if A is changed to TestOverload1, output is "char"
    A a = new TestOverload1();
    a.m('x');
  }
}
*/

class A {
  float m(float f) { System.out.println("float"); return f; }
}
class TestOverload1 extends A {
  char m(char c) { System.out.println("char"); return c; }
  public static void main(String[] args) {
    //this compile cleanly and ouput "float"
    //Again, a is type of A
    //therefore, it "sees" m(float) at compile time
    //and 'x' can be converted to float
    A a = new TestOverload1();
    a.m('x');
  }
}

[ April 17, 2003: Message edited by: Lih Wang ]

[Thomas Paul]

Originally posted by Marlene Miller:
I even suggested a SUN forum called the "anotated JLS" where people could post examples and insights.

Have you read the book, "Java Rules"?

[Kathy Sierra]

Originally posted by Marlene Miller:
I wish I had such revealing examples for every single item in the JLS. I even suggested a SUN forum called the "anotated JLS" where people could post examples and insights.

Howdy
I just want to be REALLY clear that this level of understanding and clarity about the spec is FAR beyond what is required for the exam. I'm by no means trying to disuade you from the attempt, Marlene (and others), because the more we all know the better -- and because I think that your original quote about "the more I understand..." couldn't be more right.
My concern is that a lot of the discussions on this cert forum lately have been way WAY beyond the scope of the exam, and I think that this might be intimidating to folks who aren't -- or don't want to be -- that intimate with the spec
And at Sun we believe that you don't *need* to be that intimate, in order to pass the exam, and in order to be a really good Java programmer.
In fact, we think most folks could learn exactly what they need to learn *without* referring to the spec, although it certainly doesn't hurt. We believe folks will be better off if they spend their time learning patterns, idioms, and key APIs in general, but we can't test for that in SCJP because there was not a standard agreement on exactly WHICH of those should be required for ALL Java programmers. In the early days, for example, I/O and AWT were considered essential for any Java programmer. But the surge in server-side development eventually drove us to finally drop those two objectives for the 1.4, as more and more developers were doing back-end work (no GUI), where the application servers handle the I/O.
So my comment to everyone out there prepping is to "pick your battles" for the purposes of the exam.
By all means, continue to do whatever other research and discovery and experimenting and learning that you can and want to do, but understand that you may be going way beyond what is required knowledge, understanding, and memorization for the exam. But please know, that with only limited brain resources, going too far beyond what's needed for the exam could hurt -- or at least delay -- your ability to adequately prepare for the exam.
Cheers,
Kathy (who herself has extremely limited brain resources
p.s. although I realize that there is much debate on whether it is appropriate for someone to pass the exam without having practical Java knowledge; that's not what I'm talking about here. On a Venn diagram, practical knowledge and spec knowledge overlap in only *some* areas. As I suggested, intense spec-knowledge sure could not hurt, but it definitely is not a requirement for either the exam OR becoming a good, practical Java programmer. We consider it a matter of personal preference. Some folks like to read and study and understand specs, and some don't. And the JLS is *not* a reader-friendly spec. An important document, sure, and the one you want to rely on when there is a dispute, but by no means is it a document we believe all Java programmers must read.
On the other hand, some of the other Java specs *are* useful and readable. The EJB spec, for example, is inherently usable, and absolutely crucial for an EJB developer. But that's a different kind of spec...