Generics over values. It is persistent irritant that generics do not work over primitive types today. With value types, this irritation will increase dramatically; not being able to describe List<Point> would be even worse. Still worse would be having it mean “today’s list, containing boxed points”. Supporting generics over primitives and values, through specialization, is the topic of a separate investigation.
The need for boxing/unboxing is for me one of the most common sources of facepalm in Java. I guess it's difficult to fix without breaking existing code (I guess that a new implementation of generics may not break java code, but it would break existing bytecode), but it's really annoying.
Note that specialization ("templates") are not a JVM issue but a language issue. If the JVM offers value types, then any JVM language can choose to provide specialization -- or not. In fact, this might be a better idea than baking specialization into the JVM (as done in .Net), as doing so might enforce a specific implementation of generic types, and might prevent other JVM languages from providing their own, novel type systems.
Java needs feature opt-in, import future.sane.Generics; and so on. (Scala has these.)
Python learned it the hard way. The value of backward compatibility got a bit underestimated there, with Java it's going the other way (the value of progressing, giving better tools to developers is overlooked). The JVM is a big bag of crazy code already (HotSpot with C1 and C2 JIT compilers, the many garbage collector algorithms/implementations and the other stuff that is currently deemed the JVM's responsibility), so there's plenty of space for new opt-in features.
Feature opt-in sounds good. The C++ people did it. Look what happened. Qt, boost, gtkmm, mscf are all (more or less) good. But you can't (shouldn't) mix them.
Basically. If you want to implement generics you basically have the choice of 1) boxing (Java approach), 2) instantiating a different type for each generic parameter (C++ approach), and 3) doing something in the runtime to enable a relatively transparent hybrid (C# approach). They each have their own tradeoffs in terms of flexibility, memory consumption, runtime complexity, and compilation / linking time.
This functionality is old and because it tends to generate many class files, there's also a newer project that fixes that and that should replace the @specialized annotation soon: http://scala-miniboxing.org/
"The Java Hotspot Server Compiler implements the flow-insensitive escape analysis algorithm."
This is actually a big problem. The key word is "flow-insensitive". Because current JVM escape analysis is flow-insensitive, it misses lots of opportunities.
Thankfully, this is changing. Oracle recently published "Partial Escape Analysis" paper http://dl.acm.org/citation.cfm?id=2544157 and I hope it will be integrated in future versions of JVM.
Generics over values. It is persistent irritant that generics do not work over primitive types today. With value types, this irritation will increase dramatically; not being able to describe List<Point> would be even worse. Still worse would be having it mean “today’s list, containing boxed points”. Supporting generics over primitives and values, through specialization, is the topic of a separate investigation.
The need for boxing/unboxing is for me one of the most common sources of facepalm in Java. I guess it's difficult to fix without breaking existing code (I guess that a new implementation of generics may not break java code, but it would break existing bytecode), but it's really annoying.