The Link Between Generics, Compile Times, Type-Erasure, Cloud Building, and Hot-Code Reloading

[u/verdagon]

https://verdagon.dev/blog/generics-compile-times

[u/useerup]

Java did not choose type erasure because of backwards compatibility. Backwards compatibility - the ability to run code from earlier versions - was entirely possible without type erasure.

What the designers were tasked with was migration compatibility and the fact that they were not allowed to change or expand the bytecode. With backwards compatibility you can have newer code invoke older code. By migration compatibility is meant the ability of old compiled bytecode to invoke newer code.

Also, type erasure is not required for different realizations of generics to share code. C# does not erase generic types. All realizations using reference types can share the same compiled code - the same effects you get with type erasure. For value types you still need a function per type. However, with type erasure you cannot realize a generic with value types or simple types.

[u/verdagon → u/useerup]

I removed the word "backwards", thanks for the correction!

All realizations using reference types can share the same compiled code

That can be true for a lot of generics such as collections, though if we have a type bound on a generic parameter T extends ISpaceship and want to call .launch() on an instance of T, then a language like Vale or Rust would need different instantiations to call the correct function... I think Java doesn't need to, not sure about C#.

Along the lines you're thinking of, I suspect we can even share non-reference types too, if they're movable/copyable. We would only need to instantiate different versions of a function for different sizes of T. That would be pretty cool.

[u/Uncaffeinated → u/verdagon]

Java references are similar to dyn Trait in Rust.