3 ms·

"So had history been a little different, either with Sun deciding to throw out backwards compatibility after adding generics, or with Sun adding generics into t

"So had history been a little different, either with Sun deciding to throw out backwards compatibility after adding generics, or with Sun adding generics into the JVM, or with Java first being released with generics, then this exception would not be thrown" It returns a ClassCastException because underneath it all, in the Java bytecode the Java compiler stores generics as casts. Therefore it will complain because it can't cast. If they had baked generics in at the beginning of Java then it wouldn't have compiled. It would be the equivalent of writing String one = 1;

djsumdog 10y ago
There are a lot of young developers that have never seen the <1.4 Java code and understand what's happening underneath with type erasures until this bites them. I hope professors today teach the 1.4 vs 1.5+ equivalents and explain what happens in the underlying type system. A lot of these problems with the JVM are exacerbated in the Scala world. With such a heavy dependence on type matching in Scala, things like a match { case List[MyCustomType] =>{}; case List[SomeOtherType] => ... become impossible since the underlying types are removed at compile time.
- philipkglass 10y ago
  And you may not discover the type erasure problems until runtime. I once found an "impossible" bug in production that came of someone accidentally swapping two values passed to a database function. We had separate DocumentId and UserId types for the values -- how could the bad line of code even compile?! Oh, type erasure; they were both Longs "underneath". (This weakness also mandates more basic testing for Scala code than you might expect for a language whose flagship company was called Typesafe.) Yes, the Scala docs do explain that type aliases are not really distinct types, so this sort of bug could have been expected in advance. I came to Scala with no prior Java experience so I got to discover the ways the JVM leaks through on the job. I thought that I could reuse my previous knowledge about types in program design in obvious ways and just get the obviously (to me, anyway) desired behavior. Mea culpa!
  - deleted 10y ago
    [deleted]
  - kod 10y ago
    That has nothing to do with type erasure. Type aliases are not distinct from the underlying type, even at compile time. You needed value classes, not aliases. example: object Example { type IdA = Long type IdB = Long def usesA(i: IdA) = "it's an A" case class IdC(i: Long) extends AnyVal case class IdD(i: Long) extends AnyVal def usesC(i: IdC) = "it's a C" val a: IdA = 1L val b: IdB = 2L val c = IdC(3L) val d = IdD(4L) usesA(a) usesA(b) usesC(c) // these won't compile // usesC(d) // usesC(a) }
    - philipkglass 10y ago
      How embarrassing! Thanks for correcting my mistake. I inherited someone else's code base and I thought that the type aliases were there to enforce correctness.
chrisseaton 10y ago
> It returns a ClassCastException because underneath it all, in the Java bytecode the Java compiler stores generics as casts. Right - the article already says that doesn't it? > If they had baked generics in at the beginning of Java then it wouldn't have compiled Why wouldn't it have compiled if the JVM had generics? It's an error in the design of the type system of the language isn't it? The type system is the same if we have reified generics or erased generics isn't it? And that's where the failure is - not at the JVM level.
- _old_dude_ 10y ago
  I agree with Chris, it would be a lot worse if generics were reified in Java because instead of having some spurious ClassCastExceptions, you will get memory corruptions instead.

djsumdog 10y ago

There are a lot of young developers that have never seen the <1.4 Java code and understand what's happening underneath with type erasures until this bites them. I hope professors today teach the 1.4 vs 1.5+ equivalents and explain what happens in the underlying type system. A lot of these problems with the JVM are exacerbated in the Scala world. With such a heavy dependence on type matching in Scala, things like a match { case List[MyCustomType] =>{}; case List[SomeOtherType] => ... become impossible since the underlying types are removed at compile time.

philipkglass 10y ago
And you may not discover the type erasure problems until runtime. I once found an "impossible" bug in production that came of someone accidentally swapping two values passed to a database function. We had separate DocumentId and UserId types for the values -- how could the bad line of code even compile?! Oh, type erasure; they were both Longs "underneath". (This weakness also mandates more basic testing for Scala code than you might expect for a language whose flagship company was called Typesafe.) Yes, the Scala docs do explain that type aliases are not really distinct types, so this sort of bug could have been expected in advance. I came to Scala with no prior Java experience so I got to discover the ways the JVM leaks through on the job. I thought that I could reuse my previous knowledge about types in program design in obvious ways and just get the obviously (to me, anyway) desired behavior. Mea culpa!
- deleted 10y ago
  [deleted]
- kod 10y ago
  That has nothing to do with type erasure. Type aliases are not distinct from the underlying type, even at compile time. You needed value classes, not aliases. example: object Example { type IdA = Long type IdB = Long def usesA(i: IdA) = "it's an A" case class IdC(i: Long) extends AnyVal case class IdD(i: Long) extends AnyVal def usesC(i: IdC) = "it's a C" val a: IdA = 1L val b: IdB = 2L val c = IdC(3L) val d = IdD(4L) usesA(a) usesA(b) usesC(c) // these won't compile // usesC(d) // usesC(a) }
  - philipkglass 10y ago
    How embarrassing! Thanks for correcting my mistake. I inherited someone else's code base and I thought that the type aliases were there to enforce correctness.

chrisseaton 10y ago

> It returns a ClassCastException because underneath it all, in the Java bytecode the Java compiler stores generics as casts. Right - the article already says that doesn't it? > If they had baked generics in at the beginning of Java then it wouldn't have compiled Why wouldn't it have compiled if the JVM had generics? It's an error in the design of the type system of the language isn't it? The type system is the same if we have reified generics or erased generics isn't it? And that's where the failure is - not at the JVM level.

_old_dude_ 10y ago
I agree with Chris, it would be a lot worse if generics were reified in Java because instead of having some spurious ClassCastExceptions, you will get memory corruptions instead.