Re: Inférence de types

Suffit de passer ce "var" magique à une API qui a des méthodes de même nom mais avec des arguments de types différents pour être sûr d'avoir du code Java du niveau d'un code javascript...

Je ne suis pas sûr de comprendre ce que tu as voulu dire par là. Mais juste pour être certains qu'on parle de la même chose : le mot-clef var fait de l'inférence de type pas du Duck Typing. La variable a un type bien défini, nommé, et en général identique à celui de la valeur de l'expression affectée à la variable. La variable n'est pas du tout un argument valide pour une méthode qui attendrait un type différent mais avec des méthodes/propriétés de même nom.

Pour des exemples d'usage, personnellement je m'en sers quasiment partout dans mes déclarations de variables initialisées dans des méthodes :

Je trouve que :

var myMap = new HashMap<String, String>();

est plus lisible que :

HashMap<String, String> myMap = new HashMap<String, String>();

Ça évite de se répéter et il n'y a aucune perte d'information disponible visuellement dans cette situation.

Ensuite pour les retours de fonctions, le type n'est pas forcément l'information la plus importante. Des fois c'est la sémantique qui est importante, pas l'implémentation.
Dans l'exemple que tu donnes plus bas où on fait des calculs sur des entiers avec risque de dépassement, clairement le type est important et tu as intérêt à le rendre visible. On est dans un cas où l'implémentation est importante.
Par contre, si tu écris du code métier avec beaucoup d'abstraction, très rapidement tu te moques du type, le point important pour le lecteur est qu'est-ce qu'on veut faire, pas comment on le fait.

var myContacts = GetContacts();
for (var contact : myContacts){
 Display(contact.Name);
}

L'exemple ci-dessus est parfaitement compréhensible, peu importe le type de myContacts. Rajouter le type permettrait d'expliciter le comment on gère ça sous le capot. Mais si le lecteur est intéressé par le comportement de la méthode et non par son implémentation, c'est juste de la pollution visuelle. Contrairement à ce que tu insinues dans un de tes commentaires, ça n'a rien à voir avec le fait de se contenter d'un code qui compile, c'est simplement une question de qu'est-ce qu'on veut mettre en valeur dans son code.