I watched the Oracle OTN Virtual Event: Java SE and JavaFX 2.0 (28 Feb 2012) and while talking about the new diamond operator (that Map<String, List<String>> myMap = new HashMap<>(); thing) the speaker mentioned that it was not as simpleto implement than one might think, as it is not a simple token replacement.
My question is why? Why can't be this implemented as simply taking the string from the variable's declaration and put it into the diamond operator?
I didn't implement it either, so I can only guess.
But usually the reason these things are more complex than they seem is that first inspection only looks at the most common (or most publicized) use case. In this case it's the one you mentioned. In theory that should be easy to specify exactly and it should be rather easy to implement in a compiler.
However, the diamond operator (which is not technically a operator, by the way) can be used in different ways as well:
someMethodWithGenericArguments(new HashMap<>());
new SomeGenericClass(new HashMap<>());
T foo = new SomethingRelatedToT<>(); // where T is a generic type parameter
In those cases a simple token replacement obviously no longer works, you need actual type inference involving real type analysis (i.e. it's on an entirely different abstraction level as a simple token replacement would be).
Something which Java doesn't do (which many languages have) is implied types based on usage. i.e. Java doesn't imply a require type based on how it is used.
e.g.
Type a = b;
The type of a and the type of b are independent and no assumptions are made about b based on the type of a.
MethodHandles are showing signs of supporting this. The return type use can be based on context, but this is a runtime feature.
In conclusion, my assumption is; It was hard to implement in Java because the language didn't support any like it. If the language used feature like this all the time, the approach to take would be understood (in term of defining a spec of how it should work) and supported by the tools in the compiler.
