Ce matin je me suis amusé à participer au concours du Tweet le plus fun pour Devoxx 2011. Et j’ai rebalancé les URLs des vidéos de l’an dernier tournées avec le Paris JUG, montées dans la nuit, et balancées au petit matin par votre serviceur. Or lors de la Keynote de Mark Reinhold, qui n’est autre que le Mr Java d’Oracle, je me souviens qu’Oracle avait annoncé la sortie de Java SE 7 pour le 28 juillet 2011. Et bien bonne nouvelle : ça semble bien parti !
Les 3 JSR autour du langage avaient été annoncées lors de Devoxx 2010. La JSR 336 liste explicitement le contenu de la future version de Java 7. Le JCP a approuvé non sans mal, et je vais y revenir, la JSR le 6 juin dernier. Google a voté NON comme la fondation Apache dans le passé, toujours en raison des problèmes du TCK. J’entends encore Marc Reinhold dire en novembre 2010 : « The TCK License issue is over », puis quelques semaines plus tard, le départ de la fondation Apache du JCP.
Ce qu’il faut retenir, c’est qu’il y a 2 JUG désormais au sein du JCP : le SouJUG (Brésil) et le LondonJUG (Londres/Angleterre). Comme IBM, Red Hat, Goldman Sachs ou Fujitsu, ils ont voté OUI pour la validation technique, tout en se joignant à la vague de protestation des entreprises citées. Le principal reproche fait à cette JSR, est que la liste de diffusion n’est pas publique. Bref la communauté Java ne peut pas suivre (et commenter) les discussions entre les acteurs principaux de l’industrie Java. Sur un marché qui pèse aujourd’hui plusieurs millions de dollar, c’est un peu dommage. Mais c’est stratégique.
Oracle a clairement annoncé qu’il reprenait les choses en main afin de faire avancer le développement de Java. Depuis 2006 il ne se passe plus grand chose, notre langage ne répond plus aux demandes des développeurs dès lors qu’il s’agit de sortir de la zone de confort de la plateforme. L’essor d’alternatives sur la JVM comme Groovy, Scala, JRuby ou Clojure, montre qu’il est important d’être polyglotte. Mais en même temps, on commençait à regretter quelques aspects de Java. La bonne nouvelle donc, est que les choses bougent en avant d’un point de vue technique. Et merci à Oracle pour cela.
D’un point de vue politique maintenant, est-ce que le JCP a toujours lieu d’être ? Oui, très certainement. Un peu comme un pacte pendant la Guerre Froide, le JCP a permis de souder les acteurs du marché, et de les faire avancer ensemble. Finalement, lorsque l’on regarde les standards dans l’industrie électronique, comme le Blueray, c’est un peu près la même démarche, dans notre industrie. Or ce type d’investissement ne peut pas être philanthropique. Il faut que des acteurs de l’industrie s’accordent et financent des structures pour normaliser le langage et les librairies, ce que fait le JCP.
Sun Microsystems n’est pas tout blanc dans l’histoire du TCK, par rapport à la fondation Apache. Il est explicitement marqué que le TCK ne peut pas être utilisé pour discriminer ou restreindre une implémentation compatible de Java. SUN n’en n’a pas tenu compte pour la plateforme mobile, en s’opposant à ce que la fondation Apache, avec le projet Harmony, sorte une version pour la plateforme mobile de Java. SUN voulait garder le marché du portable. Résultat : Apple utilise iOS et le langage Objective-C, Google a lancé sa virtual machine, Dalvik, qui utilise la syntaxe Java, mais qui transforme des .class en .dex. Joli pied de nez à SUN, ce qui a d’ailleurs entrainé une plainte d’Oracle après le rachat, à l’encontre de Google. Tout cela pour des histoires de dollar, nous sommes au pays de l’Oncle Sam (et des avocats).
Pour résumer la situation, SUN souhaitait protéger d’hypothétiques revenus de la plateforme Java ME en 2006. Aujourd’hui, Oracle souhaite se protéger et gagner les poursuites judiciaires à l’encontre de Google. Ce qu’explique très bien Steven Colebourne dans son dernier article.
Pour terminer sur une note plus positive, Oracle a annoncé le 17 mai dernier une nouvelle version du Java Community Process, appelé JCP.next (JSR 348). Plus étonnant, on retrouve un bon nombre des personnes de la communauté Java Francophone comme nouveaux membres du JCP : Nicolas Leroux (Play! Framework contributor), Julien Dubois (Ippon Technologies, ancien de SpringSource), Antoine Sabot-Durand (Ippon Technologies), Stéphane Epardaud (Rivieria JUG), et Mathieu Ancelin (SERLI, contributeur GlassFish) pour ceux que je connais personnellement.
Java SE 7 sera donc là avant l’été, nous aurons le temps d’en reparler sur le Touilleur Express.
Je vous laisse avec les commentaires du JCP lors du vote de la JSR-336, c’est du caviar.
0 no likeOn 2011-05-31 Oracle voted Yes with no comment.
——————————————————————————
On 2011-06-02 Google Inc. voted No with the following comment:
While Google supports the technical content of this JSR, we are voting no because of its licensing terms. As per the JCP resolutions of 9/25/2007 and 4/7/2009, « TCK licenses must not be used to discriminate against or restrict compatible implementations of Java specifications by including field-of-use restrictions on the tested implementations. Licenses containing such limitations do not meet the requirements of the JSPA, and violate the expectations of the Java community that JCP specs can be openly implemented. »The proposed license clearly violates this requirement (see Exhibit A, Section II). Oracle was duly reminded of this when JSR-336 was first proposed, but has done nothing to address the issue. It would be wrong to condone the inclusion of field-of-use restrictions in a TCK license, as this clearly violates the JSPA, by Oracle’s own admission. Google does not want to slow the progress of this release, but we do believe it is critical that this issued be addressed, in order to comply with the JSPA and to preserve the openness of the Java platform.
——————————————————————————
On 2011-06-06 SouJava voted Yes with the following comment:
SouJava votes yes on this JSR based on its technical merits. Our members are satisfied with the evolution of the technology, but are unhappy with how the licensing terms in this proposal discriminates against open source implementations, and how this can negatively affect or influence other JSRs. We also have concerns about the lack of transparency of some of the JSRs involved in JSR 336, and how it has negatively impacted the Public Review process. We urge the Spec Lead to rectify this immediately, long before the Final Draft is presented.
——————————————————————————
On 2011-06-01 Eclipse Foundation, Inc voted Yes with no comment.
——————————————————————————
On 2011-06-06 Hewlett-Packard voted Yes with no comment.
——————————————————————————
On 2011-06-05 Keil, Werner voted Abstain with the following comment:
While I wish new and improved versions of Java to be released as soon as possible, given multiple delays in the past, the lack of transparency both in this Umbrella JSR and relevant components (especially Project Coin) fuel my decision to abstain here.Not only have other EC members expressed their discomfort with this situation and confirmed some of these developments behind closed doors they demanded being opened, haven’t been. The Spec Lead has also publicly admitted he wished, more of the SE-related activities were open and transparent than they were so far.
Given the efforts for more transparency by JSR 348 were just accepted by a larger majority than even this JSR or most others in SE/EE, I hope some more existing JSRs respect this and become more open especially if related projects even use names like « Open… »
——————————————————————————
On 2011-05-31 VMWare voted Yes with no comment.
——————————————————————————
On 2011-06-01 Intel Corp. voted Yes with no comment.
——————————————————————————
On 2011-06-02 IBM voted Yes with the following comment:
IBM’s vote is based on the technical merits of this JSR and is not a vote on the licensing terms. IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage. We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM’s preferred licensing model.
——————————————————————————
On 2011-06-02 RedHat voted Yes with the following comment:
Red Hat’s vote is based on the technical merits of this JSR and is not a vote on the licensing terms. Red Hat would prefer a licensing model that creates an open arena for everyone, including those not members of the JCP and removes any ability for one individual or vendor to exert undue control over a standard. We are an open source company and hence would like to see such a licensing model for JCP contributions. Note however, that this comment is not necessarily directed at the license terms for this JSR, but is a statement of Red Hat’s preferred licensing model.
——————————————————————————
On 2011-06-02 SAP AG voted Yes with no comment.
——————————————————————————
On 2011-06-05 London Java Community voted Yes with the following comment:
The LJC votes Yes to the JSR for SE 7 based on its technical merit and our very strong desire to get Java moving again.We note that the archives for some of the Expert Groups that comprise this JSR have not yet been made public, despite a promise from Oracle to do so. We do not feel that this is appropriate for a public and open standards body. In particular, Oracle’s silence as to why the archives have not been made public is harmful to community participation, i.e. the community has no access to historical technical discussions, which are vital for participating in future Java language initiatives.
Going forward, we are unlikely to support any JSRs that do not meet minimum standards of transparency.
——————————————————————————
On 2011-06-06 Goldman Sachs & Co. voted Yes with the following comment:
Goldman Sachs votes Yes on JSR 336 based on its overall technical merit and our support for moving the platform forwardThis umbrella JSR suffers from an overall lack of transparency compounded through inclusion of other JSR’s as components which in turn are opaque. We clearly need to improve the transparency of the constituent parts and ensuing that the community has a clear understanding of what is coming. We are hopeful that JSR 348 (JCP.Next) starts to address these issues
——————————————————————————
On 2011-06-06 Ericsson AB voted Yes with no comment.
——————————————————————————
On 2011-06-06 Fujitsu Limited voted Yes with the following comment:
Fujitsu’s vote is based on the technical merits of this JSR, but not based on the licensing terms.——————————————————————————
Roh le vieux copier / coller entre Red Hat & IBM !
Qui a copié sur qui pour son commentaire ? 🙂
Pour ceux d’entre vous qui se considèrent comme des « ninjas du JDK », vous pouvez dès à présent tester les builds expérimentaux dans votre distribution Linux préférée :
– Debian : http://packages.debian.org/experimental/openjdk-7-jdk
– Ubuntu : https://launchpad.net/ubuntu/+source/openjdk-7
N’hésitez pas à me faire un retour.
A+
Précision : les commentaires sur le blog le Touilleur Express ne sont pas modérés. S’ils n’apparaissent pas immédiatement, c’est qu’il y a 2 raisons :
1) j’utilise WP-SuperCache qui réduit la charge sur la base, et qui ne regénere pas tjrs la page
2) si vous mettez des URLs dans vos emails, alors le systeme anti-spam bloque vos commentaires. Je dois alors manuellement les accepter.
Merci
Il s’agit de SouJAVA et de LJC (London Java Community)
bien vu!