new Blog( perso );

Pour cette keynote, Joshua Bloch, Mark Reinhold, Stephen Colebourne, Antonio Goncalves, Juergen Hoeller et Bill Venners débattent des orientations de la plateforme Java face aux questions de la communauté.

Java doit-il rester backward compatible ou devons nous avoir le courage de casser les choses ?

La question ne fait pas l'unanimité. Rien que dans le JRE, les méthodes deprecated ne disparaissent souvent pas au cours des versions suivantes. Joshua aimerait pourtant (par exemple) que la notation "32l" pour définir un long 32 (et pas l'entier trois-cent-vingt-et-un !) ne soit pas acceptée, et remplacée par "32L" moins ambigu. Evolution simple mais déjà pas si simple d'obtenir le consensus.

Quel impact d'Oracle sur la communauté Java ?

De l'avis général, tout n'a pas été positif, mais personne n'ose explicitement mettre les pieds dans le plat. Antonio prend finalement la parole pour résumer le BOF Jug d'hier qui a été positif et les opportunités qu'Oracle nous propose.

Comment gérer le problème de licence du TCK Java ?

(rappel : Apache Harmony ne peut pas être validé "Java" pour cette raison). Mark Reinhold ne veut pas se dérober à cette question (ce qui l'obligerait à porter un chapeau ridicule en alu, c'est la règle), cependant il ne peut pas répondre officiellement... mais ne voit pas Apache obtenir une licence TCK ni à court ni à long terme.

Android peut-il être la plateforme Java mobile de facto ?

Antonio élargit le problème à la gestion des communautés Groovy, Scala, et donc Android, qui font partie de l'écosystème Java sans rentrer dans le moule. Juergen ajoute Google App Engine et défend que ces initiatives permettent de défricher l'avenir de Java et doivent avoir leur place, en tout cas être "autorisées" dans la communauté. En résumé, avoir ajouté un aspect légal sur le débat est la pire chose qu'il y avait à faire.

Qu'est ce que .Net (plateforme/communauté) pourrait nous apprendre pour améliorer Java ?

Techniquement, .Net a bénéficié de Java pour ne pas faire les mêmes erreurs. Les puzzlers de Joshua, traduits en .Net, ne produisent plus de problème par exemple. Cela nous ramène à la première question ...

Va t-on voir la fin de la gue-guerre JigSaw/OSGi ?

Oracle vend en effet des produits basés sur OSGi, alors ? OSGi est utilisé sur de gros frameworks, serveurs d'application, middlewares, etc, mais est peut être un peu compliqué pour un usage plus standard. Java 8 vise plus une unification pragmatique, pour résoudre les problèmes simples dans la JVM, ce pour lequel OSGi est sur-dimensionné.

Comment gérer les JVM legacy que nous héritons du parc installé (i.e. Websphere) ?

Le passage en Java5 n'est pas encore une généralité... alors Java 7 ! Un problème dérivé est le temps entre la finalisation d'une JSR et son implémentation. Un an après JavaEE 6 les grosses implémentations ne sont pas encore là. Peut être revoir la logique du JSR pour être plus incrémental...

Java permettra t-il d'accéder aux noms des paramètres de méthodes ?

oui ! c'est possible, reste à savoir comment ... car cela va poser un problème de compatibilité (retour à la question 1 encore une fois).

L'approche fonctionnelle est-elle si pertinente qu'elle devrait être formellement intégré à Java ?

Scala, Clojure montrent la voie, doit on avoir un langage officiel pour cela ? Retour en arrière pour rappeler l'engouement pour XML et sa désaffection (relative). L'associer très officiellement à Java aurait-il eu un intérêt ? Si l'approche fonctionnelle apporte une vision intéressante, trop de choses dans le langage risquent de le scléroser. Par contre, des facilités dans le JDK pour mieux supporter les langages fonctionnels sont une option à considérer ...

Comment Oracle espère t-il faire revivre JavaME fàce à la concurrence sans Android ?

Modular Java permettrait de faire entrer Java sur des mobiles, cependant cela reste hypothétique. La question renvoie à l'organisation du JCP, et ses nombreux représentants issus du monde mobile.

Comment corriger le JCP ?

Idéalement : construire une structure indépendante, sur le modèle de la fondation Eclipse. Mais quel intérêt pour Oracle de lâcher sa main-mise sur Java ? Antonio modère le sujet en précisant que la participation au JCP reste ouverte et que certaines JSR sont pilotées par des indépendants. Toujours plus de transparence reste cependant une priorité.
Le lien avec la position dure prise par Doug Lea sur le JCP est porté par la question suivante, mais baser Java 7 sur le seul OpenJDK ne peut être la solution. Comment savoir ce qui fait foi, comment savoir si le code d'une JVM alternative est  respecte la norme ou est juste compatible ? Des petites phares fusent, elles ne manqueront pas d'être reprises sur twitter :P

Jusqu'à quand l'historique desktop de Java va t-il encombrer le JRE ?

C'est l'une des raisons d'être de Java modularisation ! Sur le besoin de modularité, l'unanimité est faite.

La plateforme correspond elle à l'utilisateur "standard" de Java aujourd'hui ?

Joshua est partisan d'une simplification de la syntaxe et de l'élimination de nombreux tweaks qui font de Java un outil pas 100% satisfaisant pour la grande majorité de développeurs qui programment pour payer leur facture. Les geeks qui vont aux JUGs et à Devoxx sont une toute petite minorité. Qui par exemple a défini ses propres annotation ? Qui utilise les generics pour autre chose que des List ? Il manque peut être un niveau de langage dédié aux développeurs de librairies et un autre pour le développeur lamba...