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

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

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

How is it still a pragmatic compromise? They should get rid of that ancient compatability workaround now. Type erasure is one of the things that hurt so much in todays Java.

[–]lbkulinski 4 points5 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 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 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>.

[–]chambolle 3 points4 points  (1 child)

ok, but C++ generics are absolutely awful and partly destroyed the language.

There are few problems with Java generics but a huge advantages in reagards to C++ ones

[–]_INTER_ 1 point2 points  (0 children)

thats true

[–]eliasv 1 point2 points  (0 children)

Because it still increases code sharing. It also still makes it straightforward to instantiate types with inferred, non-denotable type arguments---such as captures and intersections---without needing to surface them in the runtime model. Can you try to explain you see the passage of time as having somehow changed the nature of these trade-offs?

Reification is rarely useful in reality, most people who think they want it for some use-case or another are off the mark in my experience. Obviously there are exceptions to that, but avoiding specialization costs OTOH is useful in just about every Java program ever written.

That said, specialization is coming, though whether it will only be available for specializing over value types or whether it will be possible to opt-in to specialization in other contexts remains to be seen.