Re: This is javaaa

les abstractions qui ne font que compliquer la lecture, les interfaces n'ayant qu'une seule implémentation, les factory pour créer tout type d'objet
l'utilisation systématique de getters/setters publics, qui exposent l'implémentation d'un objet

Regarde ce que font les gens de Vertx, de spark (autant le framework web que celui de traitement big data), etc (ou même spring d'ailleurs). Ça n'est aucunement une fatalité.

Il faut souvent créer 2 ou 3 objets intermédiaires pour des opérations simples comme la lecture de fichier

Dans la bibliothèque standard c'est un objet. Par contre maintenant la lib standard te donne la possibilité de faire des traitement asynchrone des fichier, ce que tu ne retrouve pas dans tous les langages.

La distribution passe par la copie de .jar

Oui et ? Tu parle d'avoir les libs qui ne sont pas packagés dans le jar en question ? C'est un choix du développeur. Tu peux très bien avoir un jar exécutable qui se lance directement.

Le langage ne connaît que les pointeurs, qui peuvent toujours être nuls

C'est dommage en effet, mais pas insurmontable (et vu le nombre de langage qui ont le problème de nul ça n'est pas très discriminant ^^).

Il n'y a pas de concept de "const" ou de fonctions pures

Tu as final, mais il ne joue que sur la référence et n'est pas profond.
Perso j'ai pris l'habitude d'écrire des classes immutables. C'est plus simple et ça marche avec tous les langages statiques.

Pour les fonctions pure, de quoi tu veux parler ? Tu voudrait quoi ? Une annotation qui t'empêche de faire référence à ton contexte ?
Si tu parle d'optimisation de récursion terminale, tu ne l'a pas mais ce n'est pas très utilisé.

La gestion des ressources doit être faite manuellement (sauf la mémoire), et sans destructeurs

Faux depuis Java7 et les autoclosables. Tu as maintenant l'équivalent du with python avec le try-with-resource

Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)