3 ms·

I'm pretty excited about that one, it's JEP-286, http://openjdk.java.net/jeps/286 http://openjdk.java.net/jeps/286. Valhalla is pretty big. Goetz described it

I'm pretty excited about that one, it's JEP-286, http://openjdk.java.net/jeps/286 http://openjdk.java.net/jeps/286. Valhalla is pretty big. Goetz described it as pulling on a very long string. It's going to touch everything in the JVM, including reifing generics, although as I understand it, erasure of Objects may be here to stay for the language.

whateveracct 10y ago
Erased generics will surely stay and are a good thing. If they were removed, Scala would be in trouble (or rather, scalac would have to perform erasure itself, which in turn would mean that interop from Java wouldn't be good anymore). What's broken in the JVM isn't erased generics but instead runtime reflection that is a lie due to erasure. Type erasure though is definitely an example of Java getting something very right for the wrong reasons.
- jdmichal 10y ago
  Are you attempting to separate the concepts of specialization vs reified generics? Java does neither right now, and both effects are due to type erasure -- the runtime simply doesn't have the necessary information. I'm not quite sure where you're trying to draw the line. Furthermore, runtime specialization (as opposed to compile-time) would seem to require reified types. So that further confuses things. But you can definitely have reified types without specialization, which I think is the point that you are trying to convey.
- int_19h 10y ago
  Aside from backwards compatibility, what's good about type erasure for generics?
  - jsmith0295 10y ago
    Doing it a better way is hard
    - int_19h 10y ago
      Is it, though? The most basic implementation, where things are still erased at runtime by the JIT, should be fairly simple, although it will not give the expected perf gains, of course. Either way, CLR and C# did it a long time ago, and in the same time period when Java acquired its type-erased generics.
      - jsmith0295 10y ago
        They care too much about backwards compatibility I think. .NET had done generics this way from the beginning.
  - dragonwriter 10y ago
    It permits languages on the platform with substantially-richer compile-time type systems than the primary language on the platform with good interior stories (this was, IIRC, a substantial problem with Scala.NET.)

whateveracct 10y ago

Erased generics will surely stay and are a good thing. If they were removed, Scala would be in trouble (or rather, scalac would have to perform erasure itself, which in turn would mean that interop from Java wouldn't be good anymore). What's broken in the JVM isn't erased generics but instead runtime reflection that is a lie due to erasure. Type erasure though is definitely an example of Java getting something very right for the wrong reasons.

jdmichal 10y ago
Are you attempting to separate the concepts of specialization vs reified generics? Java does neither right now, and both effects are due to type erasure -- the runtime simply doesn't have the necessary information. I'm not quite sure where you're trying to draw the line. Furthermore, runtime specialization (as opposed to compile-time) would seem to require reified types. So that further confuses things. But you can definitely have reified types without specialization, which I think is the point that you are trying to convey.
int_19h 10y ago
Aside from backwards compatibility, what's good about type erasure for generics?
- jsmith0295 10y ago
  Doing it a better way is hard
  - int_19h 10y ago
    Is it, though? The most basic implementation, where things are still erased at runtime by the JIT, should be fairly simple, although it will not give the expected perf gains, of course. Either way, CLR and C# did it a long time ago, and in the same time period when Java acquired its type-erased generics.
    - jsmith0295 10y ago
      They care too much about backwards compatibility I think. .NET had done generics this way from the beginning.
- dragonwriter 10y ago
  It permits languages on the platform with substantially-richer compile-time type systems than the primary language on the platform with good interior stories (this was, IIRC, a substantial problem with Scala.NET.)