This week's book giveaway is in the OCPJP forum.
We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line!
See this thread for details.
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Autoboxing with shortening/widening Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Autoboxing with shortening/widening" Watch "Autoboxing with shortening/widening" New topic
Author

Autoboxing with shortening/widening

Vadim Vararu
Ranch Hand

Joined: Jan 03, 2009
Posts: 147
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?


If you think you've done too much, usually it means you've done too few.
Vadim Vararu
Ranch Hand

Joined: Jan 03, 2009
Posts: 147
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
Sheriff

Joined: Sep 28, 2004
Posts: 18917
    
  40

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


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Vadim Vararu
Ranch Hand

Joined: Jan 03, 2009
Posts: 147
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).
 
jQuery in Action, 2nd edition
 
subject: Autoboxing with shortening/widening