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.
Does anyone have any good examples where type erasure is actually a problem?
Yeah, this is an example I talked about in another comment here but I can be more concrete. This and code like it is why I usually wondered why erasure happens at all. In the Jackson framework to convert JSON to a class you pass in the type like
MyClass.classbut because you can’t pass in parameters you’d have to doList.class. Jackson has this method to handle such situations. It uses theTypeReferenceclass which takes advantage of Java storing type parameters for anonymous classes. The Javadoc for that class mentions this blog which is sort of the de facto source for getting around this limitation. Essentially the code you write is like this,readValue(someJson, new TypeReference<List<Integer>> {});You make a new, anonymous implementation of
TypeReference<T>andTis known at runtime.I haven’t looked into why Jackson has to do it that way but my best guess is the proper way would be inconvenient.
Ah, that makes sense!
I guess I haven’t really run into many examples like this. The times I’ve run into code where the former developers clearly struggled with handling types correctly has nearly always been their own fault (bad interface, bad organization of data, etc)
Yeah, agreed. My first project as a junior dev was on Java 6 using something written before Java 5 that they sort of slapped generics all over for no apparent reason. So many warnings lol.