17 novembre 2010

Next Big Java Language

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 !

4 commentaires:

Dominique De Vito a dit…

Perso, je suis en faveur d'inclure de nouvelles fonctionnalités disruptives dans les prochaines versions de Java et de soutenir la compatibilité ascendante uniquement avec des options spécifiques du compilateur et/ou de la JVM. Cela permettrait de ménager la chèvre et le chou, tout en faisant avancer Java...

Ex:
Next JDK wishlist-4: using a compiler option in order to not use @deprecated methods
ou
Next JDK wishlist-5: make variables 'final' by default

Romain a dit…
Ce commentaire a été supprimé par l'auteur.
codingly.com a dit…

Loin de moi l'idée de vouloir troller, mais la description du "Next Big Java Language" ressemble à quelque chose qui pourrait se situer entre C# 3.0 et C# 4.0. (Les features de la version 5.0 commencent à être annoncées.)

nicolas deloof a dit…

C'est clair qu'il y a aussi des idées à prendre du côté de C#. Qui se lance d'ailleurs sur un compilo C# pour la JVM Java (donc sans les API .Net) ?