• Post Reply Bookmark Topic Watch Topic
  • New Topic

Question about Overloaded Methods  RSS feed

 
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have been reading Mala Gupta's book and in Chapter 3, she did something that really confused me. She gives the following example which MAKES SENSE.


Mala says that the above fails to compile b/c the JVM can't figure out which method to use because int basically fits inside double and the "2, 3" could fit in either. This makes sense! I understand that just fine. What DOESN'T make sense is her answer to a sample question as follows:



Her answer says:
"Using method arguments with data types for which one can be automatically
converted to the other (int and long) is also acceptable.
When the code executes course.enroll(c), char can be passed to two overloaded
enroll methods that accept int and long. The char gets expanded to its nearest
type—int—so course.enroll(c) calls the overloaded method that accepts int,
printing int."

Why doesn't JVM freak out here? How does it know to use int instead of long? Would the original one that made sense have worked if there was an int, int method in addition to the int, double and the double, int methods?
 
Marshal
Posts: 56608
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In future please indent the code; it makes it much easier to read.

When you implicitly cast a char to a wider type, you encounter an int before you get to a long. The full details are in the Java® Language Specification, but that is often difficult to read. You probably want the section about most specific method. An int is narrower than a long, so it counts as more specific.
 
Campbell Ritchie
Marshal
Posts: 56608
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Richard Newman wrote: . . .
Why doesn't JVM freak out here? . . .
Because the JVM doesn't choose between overloaded methods. It only chooses overridden methods. The choice between overloaded methods is made and fixed at compile‑time. Look in the bytecode, which you can see by compiling the class and then using the javap tool
javap -c EJavaGuru
 
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:The full details are in the Java® Language Specification, but that is often difficult to read. You probably want the section about most specific method. An int is narrower than a long, so it counts as more specific.


To fully elaborate, an int can be implicitly used for a method that takes a long, but a long can't be implicitly used for a method that takes an int. This makes the int parameter method more specific... which explains the second part of the question.

For the first part of the questions ... the most-specific method rule can be applied to more than one parameter too. An "int, long" parameter pair can't be implicitly used for a method that takes a "long,int" parameter pair. Likewise, A "long, int" parameter pair also can't be implicitly used for a method that takes an "int,long" parameter pair. This means that neither method is more specific than the other -- and hence, it is ambiguous on which one the compiler should choose, and hence, compile time error.

Henry


 
Richard Newman
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry Wong wrote:
Campbell Ritchie wrote:The full details are in the Java® Language Specification, but that is often difficult to read. You probably want the section about most specific method. An int is narrower than a long, so it counts as more specific.


To fully elaborate, an int can be implicitly used for a method that takes a long, but a long can't be implicitly used for a method that takes an int. This makes the int parameter method more specific... which explains the second part of the question.

For the first part of the questions ... the most-specific method rule can be applied to more than one parameter too. An "int, long" parameter pair can't be implicitly used for a method that takes a "long,int" parameter pair. Likewise, A "long, int" parameter pair also can't be implicitly used for a method that takes an "int,long" parameter pair. This means that neither method is more specific than the other -- and hence, it is ambiguous on which one the compiler should choose, and hence, compile time error.

Henry




Okay, so how then does Java know to use the "int" version instead of the "long" version in the bottom-most part of my opening post? Since the "int" could very easily fit into a "long", I'm still not seeing how Java can figure that out?
 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Richard Newman wrote:
Okay, so how then does Java know to use the "int" version instead of the "long" version in the bottom-most part of my opening post? Since the "int" could very easily fit into a "long", I'm still not seeing how Java can figure that out?


I already answered this question ... in fact, Campbell answered it too.

Henry Wong wrote:
To fully elaborate, an int can be implicitly used for a method that takes a long, but a long can't be implicitly used for a method that takes an int. This makes the int parameter method more specific... which explains the second part of the question.


Henry
 
Richard Newman
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry Wong wrote:
Richard Newman wrote:
Okay, so how then does Java know to use the "int" version instead of the "long" version in the bottom-most part of my opening post? Since the "int" could very easily fit into a "long", I'm still not seeing how Java can figure that out?


I already answered this question ... in fact, Campbell answered it too.

Henry Wong wrote:
To fully elaborate, an int can be implicitly used for a method that takes a long, but a long can't be implicitly used for a method that takes an int. This makes the int parameter method more specific... which explains the second part of the question.


Henry


I apologize. I read that, but I didn't really understand it too well. I'm still a "beginner" at this. Is what you're saying something to the effect of Java will find the nearest match for the type and use that? Which is why it used "int" instead of getting confused on whether it should use "int" or "long"? I have only read a handful of books (most of which came out of the last question I asked on the forum like Heads Up Java). So again, I apologize if I don't get it right away.
 
Campbell Ritchie
Marshal
Posts: 56608
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, and no.
Because the number of bits in an int is closer to a char than the char is to a long, that counts as nearer. But the correct answer to why it is more specific is what Henry told you.
 
Bartender
Posts: 1840
10
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My suggestion: play around with a test class and find out what you can and can't do.

You actually raised a good question right at the start:
>Would the original one that made sense have worked if there was an int, int method in addition to the int, double and the double, int methods?
Did you try that out? What was the result?


My understanding of it is
- If there is a method signature that matches without having to do any expansion, use that one.
- Otherwise choose the method signature that requires the least number of expansions

The first example fails to compile because both matched methods require one expansion to be matched - and how should it choose which one to use as a result?

The second example doesn't have the same issue because it only has one parameter to worry about .
 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Richard Newman wrote:
I apologize. I read that, but I didn't really understand it too well. I'm still a "beginner" at this....


No need to apologize. This section of the JLS is actually one of the more complex parts of the document. It gets really complex once autoboxing gets added, in choosing the most specific method ... and ... once varargs gets added, I am totally confused too ...

Henry
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!