Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Autoboxing with shortening/widening

 
Vadim Vararu
Ranch Hand
Posts: 147
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello everybody,

I can't get the logic here.

This compiles ok:


and this does not compile ok:


Why it doesn't use the same logic/algorithm for the method parameters. So it shortens and autoboxes it well at the variable declaration and cann't do it at the method invocation. Is here a logic or we just have to take it as a rule?
 
Vadim Vararu
Ranch Hand
Posts: 147
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ah, i've understood the logic. At the variable declaration, the compiler can check if the value will fit into the smaller variable, while at the method parameters it can not because the value will come at runtime. VoilĂ !
 
Henry Wong
author
Marshal
Pie
Posts: 21409
84
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Vadim Vararu wrote:
I can't get the logic here.

This compiles ok:


and this does not compile ok:


Why it doesn't use the same logic/algorithm for the method parameters. So it shortens and autoboxes it well at the variable declaration and cann't do it at the method invocation. Is here a logic or we just have to take it as a rule?



The first case is defined in section 5.2 of the JLS (assignment conversion). The second case is defined in section 5.3 of the JLS (method invocation conversion). If you look, you will notice that there is a section regarding compile time constants, in section 5.2. The equivalent to this is not present in section 5.3. This is why the first works and the second does not.

It kinda makes sense, for method parameters, the compiler must actually pass a parameter. It is not possible for a method parameter to be a compile time constant.

Henry
 
Vadim Vararu
Ranch Hand
Posts: 147
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry Wong wrote:
Vadim Vararu wrote:
I can't get the logic here.

This compiles ok:


and this does not compile ok:


Why it doesn't use the same logic/algorithm for the method parameters. So it shortens and autoboxes it well at the variable declaration and cann't do it at the method invocation. Is here a logic or we just have to take it as a rule?



The first case is defined in section 5.2 of the JLS (assignment conversion). The second case is defined in section 5.3 of the JLS (method invocation conversion). If you look, you will notice that there is a section regarding compile time constants, in section 5.2. The equivalent to this is not present in section 5.3. This is why the first works and the second does not.

It kinda makes sense, for method parameters, the compiler must actually pass a parameter. It is not possible for a method parameter to be a compile time constant.

Henry


Actually, it's a little bit wrong. There is no problem to invoke methods passing them literals (compile time constants). The problems is that we cant pass a numeral literal (because they all are integers) as a argument to a method that requires a smaller Wrapper (Short, Byte). That's because compiler will autobox any integer literal to Integer (which is not a variant for an Short or Byte parameter).
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic