Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

The official Java tutorial on generics explains type erasure and why it was added to the compiler:

When a generic type is instantiated, the compiler translates those types by a technique called type erasure — a process where the compiler removes all information related to type parameters and type arguments within a class or method. Type erasure enables Java applications that use generics to maintain binary compatibility with Java libraries and applications that were created before generics.

This most likely was a pragmatic approach, or perhaps the least painful one. However, now that generics is widely supported across the industry, what can be done in order for us to not need type erasure? Is it feasible with out needing to break backwards compatibility, or if it is feasible, is it practical?

Has the last statement in the quote above become self referential? That is: "type erasure enables Java applications that use generics to maintain binary compatibility with Java libraries and applications that were created with Java versions that perform type erasure."

share|improve this question
1  
The Sun 1.4 was EOL'ed. IBM still supports 1.4 on their platforms. –  user1249 Jun 5 '12 at 12:47
    
@ThorbjørnRavnAndersen: And at least for the platform that sits in my dad's basement, there is no 1.5. –  Jörg W Mittag Jun 5 '12 at 15:39
    
@ThorbjørnRavnAndersen Not only that but one can purchase extended support for much earlier versions of the JVM as well. Last I heard though it is quite expensive. –  maple_shaft Jun 6 '12 at 19:13
1  
None of us here possess a crystal ball, thus, it is not answerable. Perhaps it can be reopened if you rephrase the question from a "Will there ever be..." question to a "What needs to be accomplished for Type Erasure to be performed in a future version of Java" –  maple_shaft Jun 6 '12 at 19:14
    
@JörgWMittag would that be a platform actually used for production in 2012? –  user1249 Jun 6 '12 at 19:56
show 3 more comments

1 Answer

up vote 5 down vote accepted

The end-of-life applies to the Java Development Toolkit and Java Runtime Environment. And only the Oracle (Sun) versions. But it does not apply to applications written by third parties. The intention is to never break code that has ever run on the JVM, thus it's unlikely Java will ever stop doing type erasure.

Of course C# also introduced generics in later version in backward-compatible manner without doing type erasure, but it basically meant duplicating all the collection classes. Which I suppose is what Java designers don't want to do and thus why they chose type erasure in the first place. Without value types the advantage of non-type-erased generics is not that big.

share|improve this answer
5  
The OpenJDK team has discussed looking at reified Generics again, timeframe? Most likely to be looked at seriously during Java 9's timeframe and if it's technically feasible, delivered in Java 10's timeframe. But this is serious soothsaying on my part. –  Martijn Verburg Jun 5 '12 at 12:59
    
Type erasure is done by the compiler, not the JVM. Introducing reified generics would require a new compiler and new JVM, but presumably they would still work with old code. –  Gabe Jun 7 '12 at 3:20
    
@Gabe: Obviously they would be introduced in new release, so there would be new compiler and new JVM. But it also requires duplicating significant part of the standard library, because it would than need generic versions for new code and non-generic versions for backward compatibility. .NET did just that in version 2.0, Java avoided it with erasure. .NET has value types (struct) and first class support for them precludes type erasure. Java does not, so the pressure for reified generics is much smaller. –  Jan Hudec Jun 7 '12 at 7:38
    
Jan: I was just commenting on the fact that reifying generics doesn't automatically mean all old code is broken. I would also add that a List<int> would probably make certainly workloads much more efficient than the current List<Integer>. –  Gabe Jun 7 '12 at 11:22
    
@Gabe: We don't disagree in that. I just wanted to note the main drawback. –  Jan Hudec Jun 7 '12 at 11:43
show 3 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.