• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

about specific method and compile time type error

 
Prasath Thirumoorthy
Ranch Hand
Posts: 65
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Friends,
Consider the following code below and execute it.It prints 3.I cant understand how and why plz help me
thank u
************************************
class Test {
public static void main(String[] args) {
Test t = new Test();
t.test(1.0, 2L, 3);
}
void test(double a, double b, short c) {
System.out.println("1");
}
void test(float a, byte b, byte c) {
System.out.println("2");
}
void test(double a, double b, double c) {
System.out.println("3");
}
void test(int a, long b, int c) {
System.out.println("4");
}
void test(long a, long b, long c) {
System.out.println("5");
}
void test(float a, long b, int c) {
System.out.println("6");
}
}
***************************************************
It prints Output as 3 plz help me friends in understanding
with regards
prasath
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24204
34
Chrome Eclipse IDE Mac OS X
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Java won't automatically convert a primitive type to another "smaller" type. So a double literal like 1.0 won't be automatically converted to a float, and a long literal won't be converted to an int, and an int literal won't be converted to a short. Java will, on the other hand, automatically convert primitives to "wider" types -- so all numeric types can be converted to double, for example. Of all the overloads you've defined, the only one that matches the three arguments you've given is the one that takes three doubles -- all the others would require an illegal conversion to a "smaller" type.
 
Fletcher Estes
Ranch Hand
Posts: 108
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Think about what the JVM has to do at run-time: find the closest fit for the parameters you provided. What were the parameters you provided? (double, long, int).

So, the JVM looks at the first parameter, which is a double. That eliminates all but the 1st and 3rd methods. Next it looks at the 2nd parameter, a long. Both the first and third methods can handle a long as their second parameter (with an automatic cast - both double and long are 64-bits wide). Finally, the JVM looks at the third parameter, an int. This eliminates the 1st method because a short cannot hold an int value without an explicit cast. Even though the number "3" easily fits inside a short, the JVM doesn't care. As far as the JVM is concerned, the compile-time constant "3" is an int.
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24204
34
Chrome Eclipse IDE Mac OS X
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Fletcher Estes:
Think about what the JVM has to do at run-time:


Fletcher's logic is perfect, except that overloaded methods are resolved by the compiler at compile-time, not by the JVM at runtime.
 
Prasath Thirumoorthy
Ranch Hand
Posts: 65
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi friends thank u for ur rplies
so the overloaded methods r resolved by compiler not by JVM is it
with regards
prasath
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic