• Post Reply Bookmark Topic Watch Topic
  • New Topic

Overloading and method matching question  RSS feed

 
Vonique Leary
Ranch Hand
Posts: 107
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is from the Bates and Sierra book.

"When a class has overloaded methods, one of the compiler's jobs is to determine
which method to use whenever it finds an invocation for the overloaded method.
Let's look at an example that doesn't use any new Java 5 features:"



"Which produces the output:
int int long double"

I totally get why this works this way but what I don't get is the following statement from the book:

"In every case, when an exact match isn't found, the JVM uses the method with the smallest argument that is wider than the parameter. "

Question:

If the smallest argument is wider than the parameter then how could that argument "fit" into that parameter? It makes me think of trying to fit a int into a byte. I know I'm missing something because I get the concept of widening, but I just don't get the above statement. What do they mean by the argument being wider than the parameter? The argument is the thing that gets passed to the method, correct?

Thanks,
Vonique

 
Hunter McMillen
Ranch Hand
Posts: 492
Firefox Browser Linux VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Like you said:

"In every case, when an exact match isn't found, the JVM uses the method with the smallest argument that is wider than the parameter. "

So if the parameter was a byte(there is no static void go(byte b)), the JVM would choose the method with the next biggest argument past a byte, which would be an int. (byte = 8 bits, int = 32 bits).

Hope this helps.

Hunter
 
Vonique Leary
Ranch Hand
Posts: 107
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It does help. I think the wording in the book could have been clearer. Instead of referring to the "argument wider than the parameter", they could have said the JVM would choose the method with the argument corresponding to the next largest parameter. Oh well, I get it. I think I get too hung up on semantics sometimes.


Thanks!
 
himanshu.harish agrawal
Ranch Hand
Posts: 47
Java Linux Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Vonique,

Two rules (nothing to do with java .. )
1. Don't move a single step ahead till you have got the funda.
2. Never underestimate the power of words in any book.

Now, for our question:
If you were reading J2SE 1.4 you would have not got that statement ("In every case, when an exact match isn't found, the JVM uses the method with the smallest argument that is wider than the parameter. ")

Because this is to do with Varargs (The varargs, or variable arguments, feature allows a developer to declare that a method can take a variable number of parameters for a given argument.) which is available from J2SE 1.5 onwards.

Refer below code:



Output: from simple int

Rationale: Both the overloaded methods are eligible for receiving the call but the one with simple int received the call because JVM will always look for the method with the smallest argument that is wider than the parameter.
Now as the method go(int... x) can receive 'n' number of int values and go(int x, int y) can receive only two int values, so go(int x, int y) will become the method with the smallest argument that is wider than the parameter and hence is called by JVM.

Please feel free if you have any doubts.

Thanks.
 
Vonique Leary
Ranch Hand
Posts: 107
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The parameter meaning the byte Because that is the only thing that would make sense.
 
Martin Vajsar
Sheriff
Posts: 3752
62
Chrome Netbeans IDE Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
himanshu,

I agree with your conclusions, but not with your interpretation of the JLS wording.

JLS actually describers varargs methods as variable arity methods. Furthermore, varargs argument is passed as an array, and Java specification consistently refers to the "size" of an array as length. Therefore the JLS statement that speaks about width of arguments/parameters has nothing to do with varargs. Width of a parameter/variable/argument is a term defined for a very long time, corresponding to the "size" of the variable in bits. Wider variable has more bits, therefore int is wider than short (32 bits versus 16 bits).

JLS does specify that non-vararg methods take precedence over vararg methods if the number of parameters matches number of arguments and arguments are convertible to parameters. The link is here (variable arity methods are considered last). The following modified example illustrates it even more clearly:

An int, int version is called, though the varargs short... matches the actual type of the parameter better.
 
himanshu.harish agrawal
Ranch Hand
Posts: 47
Java Linux Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Martin Vajsar wrote:

JLS does specify that non-vararg methods take precedence over vararg methods if the number of parameters matches number of arguments and arguments are convertible to parameters.



Hello Martin,

Got your point but just little dubious about the quoted statement.
Because i think JPL do specify below rules:
1. Widening conversion (non-vararg methods) will win over varargs.
2. Widening conversion (non-vararg methods) will win over boxing.
3. Boxing will win over varargs.

So, your statement "variable arity methods are considered last" is precisely correct but the output of your code is because of the first point, which questions the quoted statement.

Thanks.
 
Martin Vajsar
Sheriff
Posts: 3752
62
Chrome Netbeans IDE Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello himanshu,

I'd say that the statement "Widening conversion (non-vararg methods) will win over varargs" is logically equivalent to "Varargs methods are considered last" for the purpose of our discussion, there is no disagreement here.

I mainly wanted to clarify that "parameter width" refers to the size (in bits) of the parameters, and is not related to varargs/non-varargs problematics.
 
Alex Hurtt
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
himanshu.harish agrawal wrote:Hello Vonique,

Two rules (nothing to do with java .. )
1. Don't move a single step ahead till you have got the funda.
2. Never underestimate the power of words in any book.

Now, for our question:
If you were reading J2SE 1.4 you would have not got that statement ("In every case, when an exact match isn't found, the JVM uses the method with the smallest argument that is wider than the parameter. ")

Because this is to do with Varargs (The varargs, or variable arguments, feature allows a developer to declare that a method can take a variable number of parameters for a given argument.) which is available from J2SE 1.5 onwards.

Refer below code:



Output: from simple int

Rationale: Both the overloaded methods are eligible for receiving the call but the one with simple int received the call because JVM will always look for the method with the smallest argument that is wider than the parameter.
Now as the method go(int... x) can receive 'n' number of int values and go(int x, int y) can receive only two int values, so go(int x, int y) will become the method with the smallest argument that is wider than the parameter and hence is called by JVM.

Please feel free if you have any doubts.

Thanks.


By your logic here, what if you call just go(b) ? It's going to pick the varargs version for reasons that should be pretty obvious. But not for the same reason you specified. Varargs methods are only used when no better match is found by rules that existed pre-varargs in order to maintain backward compatibility with Java 1.4 and backward code. When the book talks about 'width' of parameters it is talking about 8bit vs 16bit vs 32bit etc...
 
Steven Kissh
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It seems to me the OA is right to be confused. The quoted statement is wrong and should say, "In every case, when an exact match isn't found, the JVM uses the method with the smallest PARAMETER that is wider than the ARGUMENT. " Parameters are found in the method signature and define the method. Arguments are found in the method call. The argument is what Java is trying to accommodate by matching it with a method that can handle it. It just makes sense that Java would match the argument with the method that has a parameter that is just large enough(smallest) and no larger.
 
Liutauras Vilda
Sheriff
Posts: 4927
334
BSD
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch, Steven.

User might cleared his doubts already as this thread is 6 years old. But if you think you can add some extra to it - feel free.

Steven Kissh wrote:It seems to me the OA is right to be confused.

Anyway, what is the OA?
 
Steven Kissh
Greenhorn
Posts: 4
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry, I meant OP (Original Poster). I realize this is an old thread but I found it when looking for info on the same topic. I thought I could shed some light for others who might also be led here by a their search.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!