4 ms·

Mistake maybe but I disagree on the ‘biggest’ part. For me type erasure is a bigger issue. I get that it was done for backwards compatibility but the drawbacks

by jarym 6y ago

Mistake maybe but I disagree on the ‘biggest’ part. For me type erasure is a bigger issue. I get that it was done for backwards compatibility but the drawbacks imposed by that decision seem to only grow as more time passes and more new compromises have to be made.

mac01021 6y ago
What, in your opinion, is the biggest drawback of type erasure?
- Deadron 6y ago
  Type erasure makes deserialization a pain. This has lead to multiple incompatible implementations of ways to indicate what a generic type contains on top of the existing type system. In practice it means using generic types on DTOs is a pita.
- nikeee 6y ago
  Some things that came to my mind: - List<T> doesn't "just work" with non-reference types. It needs boxing that increases memory usage and introduces stuff like ints being null. - We need special functional interfaces for non-reference types for that reason (e.g. IntConsumer). - This also affects Stream<T>, so we need IntStream etc. - A method must have a parameter of that generic type (or it has to belong to a class that has this generic type). It otherwise becomes indistinguishable during rumtime. For example, a method like ImmutableList.CreateBuilder<T>() is not possible in Java (that example is from C#'s collection types). Type erasure moslty comes into play when looking at non-reference types. For reference types, it seems to work pretty good (although it's weird that Map<String, String> will have the same runtime type as Map<Object, Object>). The last point I mentioned is not good, but no deal breaker. If generics would be like in .NET, we wouldn't have any of these restrictions. With type erasure, we ironically have to write more java code while not being able to express stuff in an abstract manner (Stream<T> is incompatible with IntStream).
  - sedatk 6y ago
    Thankfully, C# team made the right call and used reification.
hinkley 6y ago
It could have been handled in the class loader. By the time the spec had gone anywhere Java was already transitioning rapidly to servers. The memory usage argument was always bullshit. The JIT internals could have done some many to one type metadata to share function bodies between concrete instances of a particular generic. I’m sure a bunch of material would have been written describing how to avoid runtime code duplication by tweaking your class hierarchies.

by jarym 6y ago

mac01021 6y ago

What, in your opinion, is the biggest drawback of type erasure?

Deadron 6y ago
Type erasure makes deserialization a pain. This has lead to multiple incompatible implementations of ways to indicate what a generic type contains on top of the existing type system. In practice it means using generic types on DTOs is a pita.
nikeee 6y ago
Some things that came to my mind: - List<T> doesn't "just work" with non-reference types. It needs boxing that increases memory usage and introduces stuff like ints being null. - We need special functional interfaces for non-reference types for that reason (e.g. IntConsumer). - This also affects Stream<T>, so we need IntStream etc. - A method must have a parameter of that generic type (or it has to belong to a class that has this generic type). It otherwise becomes indistinguishable during rumtime. For example, a method like ImmutableList.CreateBuilder<T>() is not possible in Java (that example is from C#'s collection types). Type erasure moslty comes into play when looking at non-reference types. For reference types, it seems to work pretty good (although it's weird that Map<String, String> will have the same runtime type as Map<Object, Object>). The last point I mentioned is not good, but no deal breaker. If generics would be like in .NET, we wouldn't have any of these restrictions. With type erasure, we ironically have to write more java code while not being able to express stuff in an abstract manner (Stream<T> is incompatible with IntStream).
- sedatk 6y ago
  Thankfully, C# team made the right call and used reification.

hinkley 6y ago

It could have been handled in the class loader. By the time the spec had gone anywhere Java was already transitioning rapidly to servers. The memory usage argument was always bullshit. The JIT internals could have done some many to one type metadata to share function bodies between concrete instances of a particular generic. I’m sure a bunch of material would have been written describing how to avoid runtime code duplication by tweaking your class hierarchies.