Type conversion not specified by JLS

[Ruben Soto]

Hi,

It is common knowledge that widening and boxing is not allowed, but there must be some explanation for the following legal code:

Short s = (byte) 4; // OK. Widen byte to short, then box short into Short

I can't find provisions for widening followed by boxing in the JLS, but I must obviously be missing someting (either that, or the JLS needs to be revised, which I would find very surprising.)

I would appreciate some help with this.

Thanks,

Ruben

[armando fonseca]

Correct me if I'm wrong ruben , but I don't see widening, I see a narrowing and then boxing:
Short <- short <- byte <- int

is my assumption correct?

[Ruben Soto]

armando fonseca wrote:Correct me if I'm wrong ruben , but I don't see widening, I see a narrowing and then boxing:
Short <- Object <- Byte <- byte <- int

is my assumption correct?

Armando,

The issue with your chain of conversions is that you can't have an implicit reference narrowing conversion (in your case that would be from Object to Short.) This is what is commonly called reference downcasting, and it requires an explicit use of the casting operator.

This is an interesting problem. Either I can't find something in the JLS, the JLS is missing something, or javac is not doing what it should. I'm leaning towards the first option, because otherwise my unshakable faith in the Java gods will be disturbed for ever (just kidding.)

[Rashmi Jaik]

I don't know if looking at the bytecode helps

here's your code:

 
class Test{

        static public void main( String[] args ){

                Short s1 = 4;

                Short s = (byte) 4;



        }

}

Compiled to create .class file

javac Test.java

The output of this gives
javap -classpath . -c Test

Compiled from "Test.java"
class Test extends java.lang.Object{
Test();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   return

public static void main(java.lang.String[]);
  Code:
   0:   iconst_4
   1:   invokestatic    #2; //Method java/lang/Short.valueOf:(S)Ljava/lang/Short;
   4:   astore_1
   5:   iconst_4
   6:   invokestatic    #2; //Method java/lang/Short.valueOf:(S)Ljava/lang/Short;
   9:   astore_2
   10:  return

}

On both 1: and 6: above the bytecode looks identical

but I wish we could see more details in the bytecode, like primitive type conversions

[Ruben Soto]

That's very interesting, thanks Rashmi.

I'm mostly curious from the theoretical point of view (by theoretical I mean the official language specification,) because I do not think that anywhere in the JLS there is an explanation for what is taking place.

[Rashmi Jaik]

Yup, there doesn't seem to be a mention of the boxing conversion in 2 levels as discussed above

All I see is this:

http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#25214
byte to short, int, long, float, or double , so I guess byte primitive is directly converted to short primitive and then
public static Short valueOf(short s) , is called to convert the short primitive to Short object

this is what armando explained above

I'll try to see how this could be manually done prior to Boxing and Unboxing by compiling it with a previous version of Java

[Rashmi Jaik]

javac -source 1.4 -target 1.4 Test.java

Compiled this to pre-boxing version of Java

class Test{

        static public void main( String[] args ){

                //Short s1 = 4;

                //Short s = (byte) 4;

                byte a = (byte) 4;

                short b = a;

                Short c = Short.valueOf(b);

//-----------------------------------------------------------------

                byte x = (byte) 4;

                //Short y = Byte.valueOf(x); //#2

                Short z = Short.valueOf(x); //#1



        }

}

From #1 above , it looks like Short.valueOf() can take both short and byte primitive arguments, byte is widened to short primitive and then the valueOf , converts the short to Short.


But at #2 above, it fails to compile - because as you mentioned Byte and Short don't have any inheritance relationship between them.

This deduction is based on logic, and looking at the bytecode - not from the JLS

[Ruben Soto]

Thank you Rashmi. All this makes sense. I don't see anything unexpected there. But it doesn't explain why the type conversion is taking place. You can always use explicit casting operations, but the JLS is very explicit about what implicit type conversions are allowed, and byte to Short is not one of them.