new Blog( perso );

Qu'y aura t-il après Java ? Il ne s'agit pas de trouver ici le prochain langage de geek, mais celui qui accompagnera les millions de développeurs "collet bleu" qui ne vont pas aux conférences, ne bénéficient pas de formation avancées.

Partant de ce que 15 années de Java nous a appris, XX établit une liste de constats.

• les exceptions"checked" compliquent le code plus qu'elles nous aident
• le fait que les primitifs et les tableaux ne soient pas des objet complique le langage (mais améliorent les perfs), en particulier avec la surcharge des méthodes : foo( (short) 2) appel t-il  foo( Integer ), foo( int ) ou foo( Object ) ?
• les génériques de Java, avec leurs "super" et "extends" sont un nid de confusion

D'où quelques critères - le prochain "gros" langage de la JVM devra :

• avoir une syntaxe C-like pour s'apprendre facilement - considérant la base installée de développeurs
• être orienté-objet ET fonctionnel, non puriste d'un de ces deux paradigmes 
• typé statiquement, mais sans la rigueur excessive de Java, en particulier pour la réflexion. Invoquer dynamiquement une méthode devrait être trivial
• intégrer nativement les patterns que nous employons couramment et qui alourdissent le code : JavaBeans vs Propriétés, gestion du Null, Concurrence et Threads, Modules et visibilité, etc
• être adapté pour l'outillage, IDE, debuggers et profilers. L'IDE ne peut pas tout deviner tout seul, le langage peut l'aider dans son travail
• Etre raisonnablement ouvert aux extensions

Que donnent les langages alternatifs actuels au travers de ce prisme ?
Groovy est un assez bon candidat, mais son aspect dynamique le rend trop souple et mal adapté pour remplacer Java. Par contre il en est un excellent complément.
Scala est trop puriste du fonctionnel, trop strict, trop élitiste, trop différent de l'historique C/Java
Fantom a un bon potentiel, mais ne propose pas un modèle de typage suffisant. L'absence de génériques (en dehors des listes et maps) est un recul inacceptable.

Alors ? La solution pourrait être un Java ... sans compatibilité ascendante. On prend Java et on en retire tout ce qu'on sait aujourd'hui ne pas être un bon choix. L'outillage peut assurer la conversion du legacy si besoin. Peut être pour Java 9 ... à suivre sur twitter via #bijava !