16
fév.
2009
fév.
2009
Des nouvelles de Java 7
Java / JEE ›
Liens externes
|
Tags :
java
Par Olivier Croisier
Suite à Devoxx'08 et en prévision de JavaOne'09, Alex Miller publie une synthèse des nouveautés de Java 7 : quelles API seront ou non intégrées, quelles modifications seront apportées au langage... Un tableau récapitulatif est également disponible.
L'absence la plus remarquée est celle des closures, autour desquelles le débat fait rage depuis plusieurs années. En revanche, on se réjouira de voir apparaître certaines fonctionnalités réclamées depuis longtemps, comme la possibilité d'utiliser des Strings dans les blocs switch.
Java7, évolution plus que révolution ?
Commentaires
Autres fonctionnalités qui semblent avoir eu l'heur d'être acceptées : le support amélioré du null, notamment avec un opérateur
?.
, et la gestion des exceptions avec le catch unique d'exceptions multiples (le "multi-catch"). Ces deux-là semblent être des modifications syntaxiques mineures, mais elles élimineront une sacrée quantité de code ! Et moins on a de lignes de code à maintenir, mieux on se porte... (traduire : moins les coûts de maintenance sont élevés)Le point amusant du multi-catch est qu'il a été introduit par Neal Gafter avec son POC de closures. Les closures ne sont pas retenues pour Java7, mais le multi-catch, si...
Toujours au sujet des closures, le débat fait effectivement rage depuis plusieurs années. Mais je constate, depuis deux ans que je suis le sujet avec attention, que le débat n'a pas avancé d'un pouce, malgré les efforts de ceux qui soutiennent leur intégration dans Java (formalisation des spécifications, développement d'un compilateur Java qui les supporte, rédaction de tutoriels, utilisations concrètes, ...). Souvent, les arguments des uns et des autres sont de l'ordre de l'irrationnel (un grand sage de mes professeurs m'avait pourtant dit un jour "Religion et programmation tu dissocieras"...).
Abandonnées pour Java7, certains n'hésitent pas à parler de leur intégration dans Java8. Mais avec Java7 annoncé pour, au mieux, début 2010 (mais sans doute plus probablement mi-2010), il ne faut pas attendre Java8 avant 2012 ou 2013. Si les closures sont effectivement intégrées dans Java8, on ne les verra pas généralisées dans l'industrie avant 2015-2016... (Voyez le temps qu'il a fallu à l'industrie pour absorber les génériques : certaines sociétés refusent encore de les utiliser, 4 ans et demi après la sortie du JDK 1.5 !) Bref, de l'eau va couler sous les ponts d'ici-là. Et tout cela à condition que le débat avance d'ici 2011 (12 à 18 mois avant que Java8 ne sorte effectivement), ce qui n'est pas gagné (que permettront les 3 prochaines années, que les 2 dernières n'ont pas permis de faire ? Pour l'instant on ne voit rien poindre à l'horizon).
Ce que je regrette pour ma part, c'est tout ce que ce refus des closures empêche d'ajouter dans les bibliothèques accompagnant la JVM, notamment en matière de programmation concurrente. Ainsi la JSR166 est-elle amputée de l'API ParallelArray, qui est l'un des outils les plus simples de manipulation parallèle de données tout en garantissant une sécurité de programmation optimale. A un moment où l'optimisation des logiciels passe de plus en plus par une parallélisation des traitements, c'est très dommage, et cette limitation sera retenu au débit de Java.
En fait, Java est en train de mourir à petit feu. Il ne parviens pas à suivre les évolutions souhaitables et souhaitées tout en conservant sa cohérence. Les closures devrait faire partie de java.lang mais plus de 10 ans après la création du langage, on en est encore à polémiquer pendant des années, c'est dire !
Les applet sont arrivée trop tôt, Swing n'à pas suivi le mouvement et FX arrive trop tard.
L'intégration des langages de scripts arrivent trop tard et via une API, c'est trop pauvre !
Et les EJB, mort de rire, après plus de 5 ans ils ont enfin abandonné la persistance foiareuse pour adopter juste à temps JPA qui est vraiment bien mais n'est pas issu de SUN, merci Hibernate.
Il faut faire comme Microsoft avec CLR ou un truc dans le genre : garder la JVM mais faire table rase du langage Java et du coup on peut mélanger l'ancien et le nouveau.
Je choix de Java, quant à moi, reste un choix par dépit aucun autre langages ayant des avantages décifis sans des inconvénients encore pire... Je rève des fonctionnalités de LISP pour Java ...
Je ne serais pas aussi catégorique que toi, ano. De ce que j'en ressens, au sein des DSI, Java reste le seul langage considéré comme industriel parmi tous ceux qui reposent sur la JVM : les autres langages y sont vus comme des joujoux (alors même qu'ils sont compilés au même titre que Java !).
Concernant la persistance des EJB, ce n'est pas tant Sun que le marché (avec toutes ses imperfections) qui a dicté sa loi : sinon, on aurait abandonné les bases de données relationnelles depuis près de 10 ans pour passer aux bases de données objet, tellement plus confortables et performantes quand on programme objet (et je pourrais en parler des heures tellement je connais le sujet de près...).
Quant au langage dont tu rêves... il ressemble furieusement à OCaml ! Car pour autant que je le connaisse ce langage, il possède les six points que tu mentionnes, plus un septième qui n'est pas le plus anodin : OCaml produit des exécutables parmi les plus rapides qui soient.