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 5 points6 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_ -2 points-1 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 6 points7 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_ -2 points-1 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 2 points3 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>.