4 ms·

I agree with your points, but would like to add another one: runtime generic type erasure needs to go. Whether it is through reification or some other means, I

I agree with your points, but would like to add another one: runtime generic type erasure needs to go. Whether it is through reification or some other means, I don't care, but it feels like every single time I sit down to write some solid core-of-the-program basic code, I run up against erasure. It's probably not every time, but you get the point. That said, I think that Java 8 is in a good state, and I really liked its improvements. For Java 9, the new modularization system seems interesting, and I'll be happy to ditch classpaths!

pjmlp 10y ago
> runtime generic type erasure needs to go. Is is part of the value type related changes. http://www.oracle.com/technetwork/java/javase/community/jlssessions-2016-3114175.html http://www.oracle.com/technetwork/java/javase/community/jlss... How it will actually look like is still WIP.
- aardvark179 10y ago
  I think you should be very careful with statements like that. The Valhalla work adds a mechanism by which generic types can be reified, but reference types in Java are not proposed to be reified as that would cause big interoperability problems with existing code. However the mechanism introduced for reifying value generics could be used by other JVM languages to provide reified reference generic types. So HashMap<MyRefClass> will always remain the same class as HashMap<Object> when created in Java code, but might not be the same in another JVM language, and HashMap<MyValueType> will never be the same class as HashMap<Object>.
  - pjmlp 10y ago
    True, but nothing prevents them to have an ImprovedHashMap<any MyRefClass>.
jburwell 10y ago
I couldn't agree more with you. Erasure was one of the top boneheaded decisions made in the history of Java development. The irony was that it was done in the name of backwards compatibility that, in practice, was unnecessary. The runtime and API changes introduced Java5 we so large that byte-compatibility was no useful during the transition.

pjmlp 10y ago

> runtime generic type erasure needs to go. Is is part of the value type related changes. http://www.oracle.com/technetwork/java/javase/community/jlssessions-2016-3114175.html http://www.oracle.com/technetwork/java/javase/community/jlss... How it will actually look like is still WIP.

aardvark179 10y ago
I think you should be very careful with statements like that. The Valhalla work adds a mechanism by which generic types can be reified, but reference types in Java are not proposed to be reified as that would cause big interoperability problems with existing code. However the mechanism introduced for reifying value generics could be used by other JVM languages to provide reified reference generic types. So HashMap<MyRefClass> will always remain the same class as HashMap<Object> when created in Java code, but might not be the same in another JVM language, and HashMap<MyValueType> will never be the same class as HashMap<Object>.
- pjmlp 10y ago
  True, but nothing prevents them to have an ImprovedHashMap<any MyRefClass>.

jburwell 10y ago

I couldn't agree more with you. Erasure was one of the top boneheaded decisions made in the history of Java development. The irony was that it was done in the name of backwards compatibility that, in practice, was unnecessary. The runtime and API changes introduced Java5 we so large that byte-compatibility was no useful during the transition.