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.

  • Vipsu@lemmy.world
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 year ago

    Yeah, this quote pretty much sums it up

    C# made the opposite choice – to update their VM, and invalidate their existing libraries and all the user code that dependend on it. They could do this at the time because there was comparatively little C# code in the world; Java didn’t have this option at the time.

    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.