|
|
|
|
|
|
by lomnakkus
4083 days ago
|
|
|
#1: The JIT can optimize this out in many cases. #2: No it doesn't. You can still specialize as appropriate when you know the types at compile time, see e.g. miniboxing for Scala. #3: This was added by the Java language designers for convenience. It would be possible to require explicit casting/specialization, but they deemed it too verbose. Of course then we ended up with advice like "explicitly unbox" as seen in Effective Java... The last bit is an appeal to authority. There are many people, esp. in the Scala community, who argue convincingly against reification. |
|
|
It can optimize some of the cases. Problem persists and is now even less predictable.
> No it doesn't. You can still specialize as appropriate when you know the types at compile time, see e.g. miniboxing for Scala.
Yes it does. The subject here is generics in Java, not scala kludges to compensate for the poor generics design.
> This was added by the Java language designers for convenience.
Strawman. You can point to any language feature and call it convenience, basically anything above a Turing Machine is convenience. The fact is that they realized that the type erased generics would appear severely hampered if they could not be used for the most used types at all. Hence, they swept the problem under the rug, by allowing implicit (automatic) conversions. The problem is still there, there's a big bulge on the rug and the linked FAQ is essentially a map to guide you around it so that you do not trip.
> The last bit is an appeal to authority. There are many people, esp. in the Scala community, who argue convincingly against reification
I'd be interested in hearing those arguments, specifically those that do not invoke interoperability with Java. Have source?
My source: http://gafter.blogspot.dk/2004/09/puzzling-through-erasure-a...