confusing stuff in wrapper classes

[Ash Gill]

Hi everyone, there is some very confusing stuff going on in the initial chapters

float f = 22.0; // compiler error, fine this is as expected but
Float ff = new Float(22.0)   // this is also allowed
Float fff = new Float(22.0d); // allowed 
Float ffff = 22.0;    // while the above two are allowed, this gives compiler error

byte b = 44;  //allowed, implicit narrowing of int literal to byte AND
Byte bb = 44; //allowed, implicit narrowing and boxing BUT           ###1
Byte bbb = new Byte(44)   //compiler error, 44 is not implicitly narrowed to a byte

if we have a method that takes Byte argument:

void TakeByte (Byte b)

then while ###1 is allowed, BUT

int i = 44;
TakeByte(i) // compiler error, here the int literal is not implicitly narrowed to a byte and then boxed; unlike ###1 

there are few more in wrappers, please suggest are we required to remember all this?? its to confusing, no fixed logic.

[Henry Wong]

Ash Gill wrote:

float f = 22.0; // compiler error, fine this is as expected but
Float ff = new Float(22.0)   // this is also allowed
Float fff = new Float(22.0d); // allowed 
Float ffff = 22.0;    // while the above two are allowed, this gives compiler error

The first and last don't have to be explained -- as you mentioned that it is as expected. The second and third is happening because the Float class provides a constructor that takes a double primitive variable.

Henry

[Henry Wong]

Ash Gill wrote:

byte b = 44;  //allowed, implicit narrowing of int literal to byte AND
Byte bb = 44; //allowed, implicit narrowing and boxing BUT           ###1
Byte bbb = new Byte(44)   //compiler error, 44 is not implicitly narrowed to a byte

The first and second is happening due to a rule in the Java language specification regarding compile time constants. It is related to assignment conversions (section 5.2) and it applies to byte, short, char, and int. Interesting, this rule doesn't apply to long, float, or double, so doesn't work for your previous set of questions.

As for the third, the Byte class doesn't have a constructor that takes an int parameter.

Henry

[Henry Wong]

Ash Gill wrote:
if we have a method that takes Byte argument:

void TakeByte (Byte b)

then while ###1 is allowed, BUT

int i = 44;
TakeByte(i) // compiler error, here the int literal is not implicitly narrowed to a byte and then boxed; unlike ###1 

The rule regarding compile time constants (which I mentioned previously) related to assignment conversions (section 5.2) does not have an equivalent rule related to method invocation conversions (section 5.3).

Henry

[Mahmoud Abdulmoniem]

Hi Ash,

the most important rule to remember is that floating-point literals are double by default.

float f = 22.0; // compiler error, fine this is as expected but
Float ff = new Float(22.0)   // this is also allowed
Float fff = new Float(22.0d); // allowed 
Float ffff = 22.0;    // while the above two are allowed, this gives compiler error

so @ line 1 : 22.0 is double and can't be assigned to float variable.
@ line 2 : if you checked the Float() constructor in API you'll find that it has one version that accepts float value and another overloaded version that accepts double value

@ line 4 : the value (22.0) is double by default , and double can't be implicitly narrowed to float.

it'll work if there is explicit casting :

Float ffff = (float)22.0;

as for the method that takes byte or Byte argument
as mentioned in java language specifications :

method invocation doesn't include implicit narrowing of integer constants; so you can't call a method that takes a byte/Byte argument using integer literal.

i hope this clears your confusion

[Ash Gill]

thanks a lot henry and mahmoud. the logic is clear, i will just have to practice and remember now

[Prashanth Patha]

Doubt :
Here , in the following :

Float f = 22.0;

its ok that 22.0 is double by default. But, when it gets compiled, anyhow,any one of the constuctors of Float( one with float argument or other with double argument) should be called to create a wrapper object, doesn't it? Since, 22.0 is double , it should be matched with the Float(double) . Then why is it not getting compiled? Actually what happens when this type of line is compiled?

for the following line also , compiler is giving error... why ?

Float g=2;

[Henry Wong]

Prashanth Patha wrote:its ok that 22.0 is double by default. But, when it gets compiled, anyhow,any one of the constuctors of Float( one with float argument or other with double argument) should be called to create a wrapper object, doesn't it? Since, 22.0 is double , it should be matched with the Float(double) . Then why is it not getting compiled? Actually what happens when this type of line is compiled?

The Java compiler doesn't use "any one of the constructors of Float". It follows very specific rules for autoboxing -- which is defined by the Java language specification. Specifically, this line....

Float f = 22.0;  

Gets converted to this (via boxing)....

Float f = Double.valueOf(22.0);  

Henry

[Henry Wong]

Prashanth Patha wrote:for the following line also , compiler is giving error... why ?

Float g=2;

This second case gets converted to ....

Float g=Integer.valueOf(2);

Henry

[Prashanth Patha]

Thank you Henry Wong ,
one more Doubt:

There are only two constructors in Java API for Double wrapper class :

1) Double(double value)
2) Double(String s)

Then, when we write something like this :

Double d=new Double(3.3f);

here, we are passing float literal to Double constructor. But their is no constructor for matching with that.Then , how is it getting executed ? Actually , for assignment statements, float literals will be implicitly widened to double... is their anything same for this constructors ?

[Henry Wong]

Prashanth Patha wrote:
here, we are passing float literal to Double constructor. But their is no constructor for matching with that.Then , how is it getting executed ? Actually , for assignment statements, float literals will be implicitly widened to double... is their anything same for this constructors ?

Yes. See section 5.3 (Method Invocation Conversion) of the Java Language Specification.

[Prashanth Patha]

Thank you Henry Wong........