Il s’agit d’une traduction de l’article de Gavin Clarke publié  sur le site The Register « Java won’t curl up and die like Cobol, insists Oracle ».

Cette article revient sur l’intervention de Simon Ritter, Product Manager Java qui est intervenu lors du QCon 2012 à Londres pour présenter les évolutions de Java

QCon 2012

Avec une version 8 de Java prévue courant 2013 et la préparation déjà en cours des futures versions Java 9 et 10, Oracle réfute toute « cobolisation » de son language.

Les nouvelles versions 9 et 10 aborderont encore davantage l’interopérabilité, le cloud, et la mobilité et sortiront respectivement en 2015 et 2017, a annoncé Oracle ce mercredi.

Simon Ritter, un ancien de Sun, actuellement Product Manager Java chez Oracle et conférencier à la conférence QCon 2012 à Londres ce mercredi a annoncé que Java allait revenir sur un rythme d’une version majeure toutes les 2 ans.

A l’époque de Sun, et jusqu’en 2006, une version majeure sortait tous les 2 ans, mais suite à un manque de décisions stratégiques, Java 7 n’est finalement sorti qu’en 2011.

Concernant Java 9 et 10, rien n’est inscrit dans le marbre, Ritter a confirmé la volonté d’Oracle (par ailleurs gros consommateur de Java) de vouloir poursuivre l’évolution de la plateforme, à destination des entreprises, mais aussi et surtout vers les clients et les périphériques. Oracle veut ainsi inciter les développeurs Java à faire le grand saut.

Ritter refuse de considérer Java comme étant un langage ennuyeux en mode « maintenance » sans grandes nouveautés et dont la communauté se délassent au profit d’autres langages plus excitant. « Java n’est pas le nouveau Cobol », a dit Ritter. (Réponse à l’article « Java devient le nouveau Cobol »  en Anglais)

Oracle travaille donc à rendre Java pertinent pour le développement d’applications mobiles, connectées et massivement scalable.

Pour le JDK 10 et après, une discussion est en cours sur la possibilité de revoir le modèle orienté objet de Java. Cela pourrait aboutir par exemple à la suppression des types primitifs pour les remplacer par leurs équivalents objets. Il s’agit de pistes évoquées par le groupe de travail constitué d’Oracle et IBM (OpenJdk Project) dont l’objectif est de tendre vers un vrai langage orienté Object.

Une évolution du JDK 9 est prévue pour améliorer la supervision des machines virtuelles Java et ainsi améliorer les performances, tandis que le JDK 10 pourrait évoluer pour proposer un adressage des tableaux en 64 bits pour constituer des ensembles de données plus grand.

Bien avant cela, l’arrivé du JDK 8 l’année prochaine devrait voir apparaitre de gros changements autour de la programmation web et mobile. Java 8 sera un concentré de performance Javascript avec le remplacement du moteur JavaScript Rhino par un nouveau moteur qui utilisera les librairies de JVM (Projet Nashorn)

Avec JDK 8, l’édition standard (Java SE), conçu pour une utilisation bureau, sera mis à jour pour fonctionner sur davantage de supports mobiles. Ces supports ne sont compatibles qu’avec l’édition mobile actuellement. Oracle considère que les multi-cœurs et la mémoire vive actuellement disponibles sur les derniers smartphones vendues permettent désormais de faire tourner des applications Java comme sur un bureau.

Pour répondre à cela, Oracle a donc annoncé que Java 8 sera modulable et reposera sur le fonctionnement du projet Jigsaw. L’idée est de simplifier le packaging des applications Java en supprimant le classpath pour rendre la programmation plus simple et plus clair. La plateforme Java ne sera plus intégralement nécessaire pour faire fonctionner un programme, seuls les composants nécessaires à une application seront installés.

C’est une démarche intéressante, étant donné qu’Oracle est engagé dans une bataille juridique contre Google autour d’Android qui implémente une partie du projet Harmony. Open JDK est une implémentation de Java SE. (Note w3blog : Je ne vois pas trop le rapport de ce paragraphe avec le précédent)

A l’origine de Java il y 15 ans, 200 classes avait été déclarées. Aujourd’hui, Java compte près de 4000 classes et si on regarde les méthodes obsolètes, certaines classes ont une plus forte proportion de méthodes obsolètes que de méthodes non-obsolètes. Ritter juge nécessaire de devoir en supprimer quelques unes pour éviter que Java ne devienne trop gros.

« Pourquoi avoir Corba dans la bibliothèque Java alors que plus personne ne l’utilise ? Pourquoi JDBC est inclus nativement alors que certaines applications ne nécessitent aucun accès à une base de données ? Nous souhaitons diviser Java en module pour faciliter le déploiement d’application mais également faciliter l’intégration de Java SE sur les supports mobiles »

Une percé dans la modularité a déjà été faites avec OSGi. Ritter dit qu’Oracle est actuellement en train de regarder pour assurer une compatibilité avec ce système. L’objectif à terme serait de pouvoir charger un bundle OSGi en tant que module Java.

« Java SE 8 est assez bien défini et borné», a déclaré Ritter: « Concernant, SE 9 et SE 10, rien n’est gravé dans le marbre. ». Les groupes de travail réfléchissent pour les versions 9 et 10 à ce que nous pouvons faire en Java, à ce qu’on pourra faire en Java, mais aussi à ce que nous n’avons pas besoin de faire en Java ». Ritter ajoute qu’ils ne veulent pas non plus faire de changements radicaux dans Java et risquer de rendre la programmation plus difficile ou d’apporter encore plus d’erreurs.