but double writing for type-paramters sucks

If you use Eclipse then you never need to type the type-parameters more than once; Eclipse’s code completion fills them in for you. I would image (or hope) that other IDEs can do the same.

At the moment I’m doing a bit of C# which supports duck typing using the var keyword. I don’t like it much because if the variable is being returned by a method you can’t readily see the type.

E.g.
var x = getClients();

What type is x? Also the IDE can no longer go to the definition of the type because var is a keyword.

In Java I use Eclipse to do the work for me; quick fix can create a variable to hold the return value of a method and guess a name based on the method name e.g. the quick fix ‘Assign statement to new local variable’ on getClients() will result in a variable called clients of the type returned by the method.

So I think the answer is to use the right tools. No language changes are required .

Further, nobody will argue against that:
final Map map = new HashMap();
is a better coding style than:
final HashMap map = new HashMap();

Well, I just did argue against it. See entry just above yours.
Here some more reasons: you also don’t write:

Number n1 = 3;
Number n2 = 3.7;
CharSequence s = “hi”;

If you don’t care about the precise type then use a scripting language, but not Java.

Besides, that ‘new’ is a reserved keyword, one could also do that by hand and the type-paramters would be inferred whenever possible. Luckily this makes ‘new’ an ideal candidate for a language addition

The statement that the local declaration List list = new ArrayList(); allows to use any kind of list is wrong:

you have to change the code exactly there where it is used:List list = new LinkedList();
just look into the JDK collection API documentation how often Sun changes the semantic of overwritten methods. Example: Collection.add(Object) adds element anywhere while List.add(Object) specifies it to append the element. Not to mention that in both cases add(Object) is an optional method, which your code then should not use if it should be able to deal with any List implementation.
even if the semantic remains the same when switching to a java.util.LinkedList, you will not want to write e.g. for( int i = 0; i but use an iterator instead, because indexing in linked lists is horrible slow.

And as shown in the above list in most cases it is even important to know whether some code is dealing with an ArrayList or with a LinkedList. And not only at the location where the variable was initialized.

Personally, the feature I’d like to see added is Design-by-Contract similar to how Eiffel does it. I think it would be in line with the core principles of Java and greatly improve readability / robustness of code. Being able to define a contract in the interface and know that every implementor abides by it is simply strengthening current practices. And if it did cause enough of a performance problem (not likely, especially when RoR is the rage and is dog slow) it can be turned off for production but help detect errors early in QA cycles.

All the features that Java-5 added I use every day, but I rarely find myself wanting any of the ones proposed for Java-7. When I read the blogs of those who propose the additions (like Gafter’s and Colebourne’s) its obvious they’re lost over-designing than dealing with real-world scenarios. I’d rather see Colebourne focus on cleaning up Joda Time for the JDK than screw around with another ugly closure implementation.

It would be ironic if C++ gets closures while Java doesn’t …

Map m = new HashMap();

we know the underlying object in m is a HashMap anyway. By not making any kind of explicit type declaration at all for m, the best practice of always making the reference the least specific possible becomes moot.

Even venerable old C++ is adding features, including type inference. In this article from over a year ago, Bjarne Stroustrup outlines the new features (they’ll use the keyword “auto” for type inference):

http://www.artima.com/cppsource/cpp0x.html

And this is Stroustrup’s proposal for lambda expressions and closures in C++:

http://public.research.att.com/%7Ebs/N1968-lambda-expressions.pdf

this is understood by the compiler as HashMap. What’s the problem with that. Why do you want

Map map = new HashMap();

Probably you want to be able to change that to TreeMap later on.
But you could do that, even with the above one. When you want it to be assigned to a Map reference you could always do that.For example you could return it as a Map.
Want to change it to TreeMap? No problem change it. That’s ok. And if it is not compatible, compiler detects it.
For eg.
public Map foo() {
final map = new TreeMap();
…
return map;
}

Am I missing something?

I can’t understand. For me, the compiler always will understand

final map = new HashMap();

as

HashMap map = new HashMap();

If you want Map or another interface, you must explicit it:

Map map = new HashMap();

As I mentioned, it has no reason whatsoever to work that way, using the context of this code (the way you’re using map) allows the compiler to infer the most possibly abstract types (in this case, there’s no reason why it couldn’t infer that map is of type Map). Moreover, since type inference requires an extremely extensive static type analysis (and the less formalized the type system, the more extensive the analysis requirements) the compiler would be able to warn you in case of inference to concrete datatypes (what ZdenÄ›k Machač gave an example of, in his own example it’s impossible for the compiler to infer to an ADTs because the code only works on a specific, concrete datatype).

final map = new HashMap();

as

HashMap map = new HashMap();

If you want Map or another interface, you must explicit it:

Map map = new HashMap();

Clear enough, ah?