WidenBoxing Confusion

[yusuf Kaplan]

Hi there,

in the K&B book there is an example regarding widening and boxing. It looks like this:

class WidenAndBox{
  static void go(Long x){System.out.print("Long");}

  public static void main (String [] args){
     byte b = 5;
     go(b);
  }
}

This does not compile due to line 6: WidenAndBox cannot be applied.
1. Why cant the compiler widen the argument from byte to long and then box to Long?
2. Why is WidenAndBoxing applied here?
3. How to know whether WidenAndBox or BoxAndWiden is applied??

Regards,
Yusuf

[Asad Zubair]

1. I believe it is more of a compiler rule / limitation that anything else. You could perform the widening manually by replacing line 06 with go((long) b) and the compiler will then perform the autoboxing. However WidenAndBox is too much for the compiler to handle.
2. WidenAndBox is being applied here to show you an example of where you would get a compiler error.
3. The order in which the compiler tries to compile is widening then boxing then varags. So it would WidenAndBox first if it could. But as we have said above this is not possible so it would try to BoxAndWiden.

Hope this helps.

[yusuf Kaplan]

Hmm I don't understand honestly. The key point is: Why cant the compiler widen from byte to long and then Box??
byte fits into any long reference variable, so I don't know why it fails here.

[Shaikh Ali]

I think it might be helpful to take autoboxing and method selection as a two-step process. Step 1 concerns autoboxing rules, and the 2nd concerns method selection.

First of all remmember that widening is always preferred over autoboxing when there is a choice.

For primitives:

Step 1p: A primitive can only box to its own wrapper type if needed e.g. byte to Byte. If boxing has been done, rules in step 2w will apply.

Step 2p: A primitive type will always widen to the smallest primitive container available to it e.g. if a byte has a choice between widening to short and int, it will choose short because it is the smallest container available to byte.

For wrappers:

Step 1w: A wrapper can only unbox to its own primitive type if needed e.g. Integer to int. If unboxing has been done, rules in step 2p will apply.

Step 2w: A wrapper cannot 'widen' to another wrapper because there is no inheritance relationship between any wrapper classes, but it can widen using the rules of polymorphism to the closest ancestor available e.g. an Integer will widen to Number, if Number and Object are both available.

I hope it's not too confusing

[yusuf Kaplan]

Faraz, thank you for your great answer. This summarizes many key features to remember for the exam, I guess
But Im still not convinced: In the code example above why didnt the compiler perform step 2p (byte -> long) and then w1 (long -> Long) ???

[Andreas Svenkson]

yusuf Kaplan wrote:Faraz, thank you for your great answer. This summarizes many key features to remember for the exam, I guess
But Im still not convinced: In the code example above why didnt the compiler perform step 2p (byte -> long) and then w1 (long -> Long) ???

It has to do with the rules of boxing and widening in general, I recommend checking out this post: https://coderanch.com/t/417622/java-programmer-SCJP/certification/Golden-Rules-widening-boxing-varargs

Bear in mind, it's not entirely complete. Can't remember exactly now, but there was something about rule #4 that I believe I found slightly "incomplete" in its description.

// Andreas

[Ikpefua Jacob-Obinyan]

Hello All, Andreas I copied the contents of the link as follows:

5 Golden Rules of widening, boxing & varargs

1. Primitive Widening > Boxing > Varargs.
2. Widening and Boxing (WB) not allowed.
3. Boxing and Widening (BW) allowed.
4. While overloading, Widening + vararg and Boxing + vararg can only be used
in a mutually exclusive manner i.e. not together.
5. Widening between wrapper classes not allowed

Now Let me illustrate each of them with instances :
view plaincopy to clipboardprint?

1.
2. Overloaded methods Invoked by saying Called method
3. doX(Integer i) & doX(long l) doX(5) long (by Rule 1)
4. doX(int...i) & doX(Integer i) doX(5) Integer (by Rule 1)
5. doX(Long l) & doX(int...i) doX(5) int...i (Rule 2 & 1)
6. doX(Long l) & doX(Integer...i) doX(5) Integer...i(R. 2 & 1)
7. doX(Object o) & doX(Long l) doX(5) Object o (Rule 3 & 2)
8. doX(Object o) & doX(int...i) doX(5) Object o (Rule 3 & 1)
9. doX(Object o) & doX(long l) doX(5) long l (Rule 3 & 1)
10. doX(long...l) & doX(Integer...i) doX(5) ambiguous (Rule 4)
11. doX(long...l) & doX(Integer i) doX(5) Integer (Rule 1)
12. doX(Long l) Integer i; error (Rule 5)
13. doX(i)
14. doX(Long l) & doX(long...l) Integer i; long...l(Rule 5 & 1)
15. doX(i)
_________________________________________________________________________________________________________________

public class TestVarargs {

   public static void main(String[] args){
	
	
	  new TestVarargs().go(5); 
   }
   void go(long... l){
	   System.out.println("long");
   }
   void go(Integer... i){
	   System.out.println("Integer");
   }
   void go(Number n){
	   System.out.println("Number");
   }
}

The above code could possibly be the additional information we need to know about rule 4.
The output is Number.

Take Note that without the method whose argument is of TYPE Number, the code provokes
a compile-time error.

[Henry Wong]

Andreas Svenkson wrote:

yusuf Kaplan wrote:Faraz, thank you for your great answer. This summarizes many key features to remember for the exam, I guess
But Im still not convinced: In the code example above why didnt the compiler perform step 2p (byte -> long) and then w1 (long -> Long) ???

It has to do with the rules of boxing and widening in general, I recommend checking out this post: https://coderanch.com/t/417622/java-programmer-SCJP/certification/Golden-Rules-widening-boxing-varargs

Bear in mind, it's not entirely complete. Can't remember exactly now, but there was something about rule #4 that I believe I found slightly "incomplete" in its description.

Or you can go directly to the Java Language Specification. The specification lists a fix set of options for assignment conversions -- and states that you can only choose "the use of one of the" options.

Java Language Specification wrote:5.2 Assignment Conversion
Assignment conversion occurs when the value of an expression is assigned (§15.26) to a variable: the type of the expression must be converted to the type of the variable. Assignment contexts allow the use of one of the following:

an identity conversion (§5.1.1)

a widening primitive conversion (§5.1.2)

a widening reference conversion (§5.1.5)

a boxing conversion (§5.1.7) optionally followed by a widening reference conversion

an unboxing conversion (§5.1.8) optionally followed by a widening primitive conversion.

If, after the conversions listed above have been applied, the resulting type is a raw type (§4.8), unchecked conversion (§5.1.9) may then be applied. It is a compile time error if the chain of conversions contains two parameterized types that are not not in the subtype relation.

Henry

[Lalit Mehra]

you need to know just one thing when it comes to autoboxing and widening

a primitive can only be boxed to it's own WRAPPER type ... i.e. an "int" can only be boxed as an "INTEGER"

and widening widens a primitive only to the smallest container that can take that primitive ... it's just like using a 200ml container for 100ml of water rather than using the 400ml one when the water still will remain 200ml and the size of the container only takes up more space on the table where the container is placed with no effect on the actual amount of water ...


I am feeling thirsty now

you cannot widen and then box because a WRAPPER boxes a value of it's own type only

[Henry Wong]

Lalit Mehra wrote:
you cannot widen and then box because a WRAPPER boxes a value of it's own type only

Actually, you can. This...

public class WideningAndBoxing {
	public static void main(String[] args) {
		final byte b = 10;
		Short i = b;
		
		System.out.println(i);
	}
}

compiles. The JLS has special rules related to compile time constants which allow this.

Henry

[Lalit Mehra]

Thanks Henry for making this clear ...



I never thought of testing this thing ... using a final variable for widening and then boxing ...

[Lalit Mehra]

amusingly there's a gotcha over here ...

This works fine ...

final byte b = 10;
Short s = b;

This doesn't ...

final byte b = 128;
Short s = b;

when the literal value goes beyond the actual limit of the type, "byte" here, the second statement complains the same thing ... required short, found byte

[yusuf Kaplan]

Lalit Mehra wrote:

final byte b = 128;
Short s = b;

when the literal value goes beyond the actual limit of the type, "byte" here, the second statement complains the same thing ... required short, found byte

Are you sure? I think, the compiler just complaints about the the first line?!?

[Lalit Mehra]

yusuf Kaplan wrote:

Are you sure? I think, the compiler just the first line?!?

check it out ... YES I AM SURE

and i cannot understand what you mean

[dennis deems]

Compiling this generates two errors:

possible loss of precision
found : int
required: byte
final byte b = 128;
^
incompatible types
found : byte
required: java.lang.Short
Short s = b;
^