Hacker News new | comments | show | ask | jobs | submit login

Those are not breaking changes. Existing byte code will continue to work.

My understanding of generic type erasure is that it is more of a language issue than a VM issue. Nothing in the VM prevents reified generics, but when generics were introduced in Java 5 they decided to use type erasure in order to avoid having to produce a whole new collections standard library or break compatibility with existing code.




I meant breaking in that the Java 10 compiler would be targeting a newer version of the JVM and could dispense with having to be backwards compatible, which was one of the reasons I remember reading for generics.

They could have simply left the old library, deprecated it, and added in their genericed one as a a new package. It had to be modified anyway.


Right, it breaks forward compatibility: bytecode for a newer VM won’t work on an older VM. IMO backward compatibility is much more important for a programming language, though.


Or they could have done erasure in the runtime when they detected non-generic usage of a generic class. Instead of forcing it on everyone.


Yup, and Microsoft did exactly that, meaning C# has been able to express List<int> for ten years now.


Nah this is a VM issue.

Type assertions have no ability to recurse. RN you assert both classes are a UTF8 value in the constant pool. Or really 1 class is a UTF8 value, which the compiler know the first one is.

But with Generics, you may not know what it holds at runtime so this doesn't work. You'd have to constantly rebuild the constant pool (Slow) each time a new _kind_ of generic is used.

So either a new type+byte code would have to be introduced, or the type assertion instruction would have to become recursive. The later is a breaking change.

Also interfaces break this b/c those are class specific. So a Lorg/my/company/myClass$5; and Lorg/your/company/yourClass$0 might both implement the same interface. But that interface information isn't in the collection class, but those to class's class files. So really it just needs new byte code.


If you look at the .NET (IL) implementation of generics [1] it relies quite heavily on the VM/Bytecode. Implementing a new collections library (like C#/.NET did) is probably not the cost, afaik the Java team choose type erased generics to prevent breaking binary compatibility between Java 4 and 5 at the VM/bytecode level.

[1]: https://stackoverflow.com/a/5342424/572635


Java could have done the same by implementing erasure as a VM-level construct that's only invoked when a generic class is used in a non-generic manner. That is, using List is equivalent to using List<Object>, which I think even retains semantic equivalence. Bonus points for gating the feature behind pre-5 class versions.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: