2 ms·

That sounds as ex post facto justification. IIRC the designers hit the issue once they started implementing generics and the gravity of the situation became app

by bitL 7y ago

That sounds as ex post facto justification. IIRC the designers hit the issue once they started implementing generics and the gravity of the situation became apparent just at that time. Then another set of hackers figured out a way to utilize it for language interoperability. I am not saying CLR's final implementation is great either, but it addresses some points JVM missed as they had time to learn from SUN's mistakes, while making their own errors in the process as well. Language/platform design is notoriously difficult and unpredictable.

pron 7y ago
The original issue was compatibility and interop between two languages with different variance strategies. It's just that those two languages were two versions of the Java language. Calling it a "justification" is also misplaced: baking a variance strategy into the runtime makes the runtime very over-fitted to a particular language; AFAIK this is only done by .NET. So if it's a "justification" it is a very reasonable one. I don't think either of the approaches is a black-and-white mistake, but I personally very much prefer Java's. The loss is a very minor inconvenience (mostly the inability to overload methods with different generic arguments, e.g. foo(List<String> x) and foo(List<Integer> x)), and the gain is that the Java platform is a great compilation target for many different languages. Whether or not those who made this decision had other languages in mind is irrelevant; it's a very good decision, even though some would prefer the opposite one. It's certainly not a mistake and not a hack. It's not a hack because it is a well-known, well-understood, common compilation technique; it's not a mistake because there is no alternative that's clearly better, and many (myself included) think it's significantly better than the alternative chosen by .NET.
paulddraper 7y ago
> That sounds as ex post facto justification. The initial reason was indeed backwards compatibility. As it turns out, compatibility with Java 1 unintentionally yielded compatibility with future languages too. Because of this flexibility (ex post facto notwithstanding), the JVM became the most popular VM target ever. Note that GraalVM -- which from day 1 intended to be a multilingual VM -- also uses type erasure. --- Know that there is more than conceptualization of a type system, and in particular a parameterized type system. C vs C++ vs Java vs Haskell. The more of this is baked into the runtime, the more reflection can be done at runtime, but the less interop can be done with other type systems. (There is a reason why C not C++ is the de facto FFI standard and its not just age.)

by bitL 7y ago

pron 7y ago

The original issue was compatibility and interop between two languages with different variance strategies. It's just that those two languages were two versions of the Java language. Calling it a "justification" is also misplaced: baking a variance strategy into the runtime makes the runtime very over-fitted to a particular language; AFAIK this is only done by .NET. So if it's a "justification" it is a very reasonable one. I don't think either of the approaches is a black-and-white mistake, but I personally very much prefer Java's. The loss is a very minor inconvenience (mostly the inability to overload methods with different generic arguments, e.g. foo(List<String> x) and foo(List<Integer> x)), and the gain is that the Java platform is a great compilation target for many different languages. Whether or not those who made this decision had other languages in mind is irrelevant; it's a very good decision, even though some would prefer the opposite one. It's certainly not a mistake and not a hack. It's not a hack because it is a well-known, well-understood, common compilation technique; it's not a mistake because there is no alternative that's clearly better, and many (myself included) think it's significantly better than the alternative chosen by .NET.

paulddraper 7y ago

> That sounds as ex post facto justification. The initial reason was indeed backwards compatibility. As it turns out, compatibility with Java 1 unintentionally yielded compatibility with future languages too. Because of this flexibility (ex post facto notwithstanding), the JVM became the most popular VM target ever. Note that GraalVM -- which from day 1 intended to be a multilingual VM -- also uses type erasure. --- Know that there is more than conceptualization of a type system, and in particular a parameterized type system. C vs C++ vs Java vs Haskell. The more of this is baked into the runtime, the more reflection can be done at runtime, but the less interop can be done with other type systems. (There is a reason why C not C++ is the de facto FFI standard and its not just age.)