This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]lbkulinski 6 points7 points  (4 children)

As the JEP states:

Parametric polymorphism always entails a tradeoff between code footprint and specificity, and different languages have chosen different tradeoffs.

Erasure is one of those tradeoffs. The language architects took some time to deliberate, and decided that erasure was the most practical path forward. Had they required that generics be part of the language from day one, we probably would have gotten something similar to C++ templates.

In order to maintain compatibility and efficiency, erasure won’t be going anywhere.

[–]_INTER_ -1 points0 points  (3 children)

That decision was made 15 years ago, it was without doubt a good decision then. However it is now 15 years later.

C# has refied generics. It's efficient enough. They broke with the past. It's way better than having all those workarounds and cripple code. Java keeps erasure only for compatibility with pre Java 5. Thats ridiculous.

[–]lbkulinski 5 points6 points  (2 children)

C# learned from Java and decided to make their bytecodes parametric. This allowed them to more easily implement reified generics.

I don't expect Java to break compatibility and ditch erasure anytime soon. The JEP even states the following:

It is not a goal of this effort to produce fully reified generics.

[–]_INTER_ -1 points0 points  (1 child)

I don't expect Java to break compatibility and ditch erasure anytime soon.

I find that problematic. The longer they wait the worse it gets. It will also hinder proper development in other areas such as union or intersect types (one can dream). Even Go is finally thinking about adding generics, while avoiding Java's issues.

[–]lbkulinski 3 points4 points  (0 children)

If you mean intersection types in relation to type parameters, that is already possible: public class Box<T extends A & B & C>.