Generic type casting

[Cristian Senchiu]

nagaraju uppala wrote:Thanks cristian
now my doubt is cleared. you mean at runtime also the generics will replaced with object type.am i right?

1.If are talking about the types:
The types will be erased to their bounds.
No bounds => erased to Object. If it would have been, for example, T extends BoxyTwisted1 => T would be erased to BoxyTwisted1.
2.If you are talking about the usage:
Yes and no... It is more complex, depending on what the compiler has to guarantee us ... As you can see when you read my previous post (right above your last post).
But this whole discussion is way beyond exam's objectives .... I presume.

[Ruben Soto]

This was some great discussion. Cristian, I think you are right. What Ankit and I were thinking is that maybe the compiler preparsed the code first (expanding the string concatenation into the StringBuilder append chain) and then analyzing the code to chose the most specific method. Even if that's not the case, the compiler must know that a toString() call is possible on the reference (unless the reference is null.) And while it's true that toString is defined in Object, and thus an invocation of toString() can be left to the polymorphic overriding resolution mechanism, that's not what happens when you explicitly invoke toString() on the reference. But maybe that's too much to ask of the compiler.

And I also think this is beyond the bounds of the exam (at least K&B mention that we are not required to know any technical stuff about type erasure.)

[Cristian Senchiu]

Yes Ruben and Ankit, it was!
P.S.: I just reread my post and saw that I didn't write about the special case "String", which is now easily explained through the efforts compiler makes to find the most specialized code.

[Ruben Soto]

Cristian Senchiu wrote:Yes Ruben and Ankit, it was!
P.S.: I just reread my post and saw that I didn't write about the special case "String", which is now easily explained through the efforts compiler makes to find the most specialized code.

Cristian, I am afraid I don't follow. How is String explained, when String and StringBuffer (for example) behave differently in the first case?

Good work, by the way!

[Cristian Senchiu]

Ruben Soto wrote:

Cristian Senchiu wrote:Yes Ruben and Ankit, it was!
P.S.: I just reread my post and saw that I didn't write about the special case "String", which is now easily explained through the efforts compiler makes to find the most specialized code.

Cristian, I am afraid I don't follow. How is String explained, when String and StringBuffer (for example) behave differently in the first case?

Good work, by the way!

Thanks Ruben.
The String case is that one case that throws already at lineX, where no other type of object throws. Remember? Was in our discussion at the very beginning.

BoxTwisted<BoxyTwisted1,String> box = new BoxTwisted<BoxyTwisted1,String>();
...
System.out.println("1) " + box.u);     // lineX (no other type of objects throws here, only String does)
...

That's explainable now because there's the specific concatenation for case String+String (so for compiler the String+<reference> is not the best choice anymore as it would be in case of any object, including StringBuffer for example).

[Ruben Soto]

Cristian Senchiu wrote:
Thanks Ruben.
The String case is that one case that throws already at lineX, where no other type of object throws. Remember? Was in our discussion at the very beginning.

BoxTwisted<BoxyTwisted1,String> box = new BoxTwisted<BoxyTwisted1,String>();
...
System.out.println("1) " + box.u);     // lineX (no other type of objects throws here, only String does)
...

That's explainable now because there's the specific concatenation for case String+String (so for compiler the String+&lt;reference&gt; is not the best choice anymore as it would be in case of any object, including StringBuffer for example).

I remember String being a special case, Cristian. I just don't see how this is explained. I think the main thing is that I don't see how there is a specific concatenation for String + String. I looked in the JLS (15.8.1) and I don't see a mention of a special case when both operands are Strings vs (for example) a String and a StringBuffer. Where did you find in the JLS this information?

[Cristian Senchiu]

Ruben Soto wrote:I think the main thing is that I don't see how there is a specific concatenation for String + String. I looked in the JLS (15.8.1) and I don't see a mention of a special case when both operands are Strings vs (for example) a String and a StringBuffer. Where did you find in the JLS this information?

Sorry for my late response. A movie was in the way.
Yes Ruben, my explanation was not the best I could give, and I think I understood which part was misleading:

... there's the specific concatenation for case String+String (so for compiler the String+<reference> is not the best choice anymore as it would be in case of any object, including StringBuffer for example).

So, JLS says

If only one operand expression is of type String, then string conversion is performed on the other operand to produce a string at run time.

That is:
- there's the case when one operand is not String. All objects are here (beside String objects) plus all primitives (as JLS says primitives are converted through their wrappers). So I have here always the case String+<reference> (unhappy naming of the case?)
- and there's the "specific" (unhappy usage of word specific?) case String+String
So in our case with String, the compiler goes in the case (generates instructions for) String+String and avoids String+<reference> case (for which would generate instruction if we would have another object, StringBuffer for example).

[Ruben Soto]

You are absolutely right, Cristian. I missed the part that says "If only one of the operands is a String." So things make absolute sense now, thanks.

I hope you enjoyed your movie. I also saw a movie. It starred javac and had a lot of exciting exceptions. In the end everything compiled right.

[Cristian Senchiu]

Ruben Soto wrote:You are absolutely right, Cristian. I missed the part that says "If only one of the operands is a String." So things make absolute sense now, thanks.

I hope you enjoyed your movie. I also saw a movie. It starred javac and had a lot of exciting exceptions. In the end everything compiled right.

Yes I did, thanks! I'm glad that yours had also a happy end.