A great read for folks wondering why Java uses type erasure instead of “reified” generics. For the unaware, that means that a List<Integer> is a List<Object> at runtime. I had always wondered about it and why they didn’t take the alternative route. For context, C# does have reified types so the actual type parameter is available at runtime.
I personally love reading in depth discussions about counter intuitive engineering decisions like this.
This is an interesting read, but it doesn’t really live up to the title. I can see how erasure was the best compromise at the time, but it’s still a compromise.
Yeah, this quote pretty much sums it up
Which tells me that it was mostly about maintaing backwards compatibility with legacy code. Having used C# and Java for years the effect of type erasure seems to be bunch of silly
@SuppressWarnings("unchecked")annotations in code and classes that mostly just exist to encapsulate a list of objects. With C# I create my own generics all the time but with Java I tend to avoid doing that like a plague.I do however have to admit that I skimmed through most of the article because it’s just too difficult to read with its complex vocabulary (full of words like pragmatic, ubiquitous, fictions, heterogeneous, etc) combined with a lot of technical jargon about lower level languages. Guess reading and actually really understanding the article would be easier and less time consuming if I was native english speaker but at its current form the article is far from being accessible or succesful explaining why one should love type-erasure.