Revue de Presse Xebia

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• Sun, Java et le JCP
• RIA, SOA, Tim Bray tire dans le tas

SOA

• Red Hat JBoss choisit d’investir dans CXF

Le coin de la technique

• Enfin une roadmap détaillée pour le JDK7
• La création de bundles OSGi selon SpringSource
• Utiliser le nuage pour réduire les coûts d’intégration continue.
• Outils Glassfish pour Eclipse

Actualité éditeurs / SSII

Sun, Java et le JCP

Depuis quelques jours, une agitation se crée au sein de la communauté Java autour des agissements de Sun vis-à-vis de son projet OpenJDK 7. Plusieurs observations permettent en effet de penser que le JDK 7 pourrait bien ne pas être basé sur un standard du JCP comme c’est habituellement le cas :

• Neil Bartlett remarque que le projet Jigsaw, poussé par Sun pour être le système de modules utilisé par le JDK, n’est pas défini par une JSR. Ceci en fait donc une technologie propriétaire dont il doute de la légitimité face à OSGi, un standard bénéficiant de 10 années d’expérience.
• Stephen Colebourne constate que Sun ne fait plus mention de « Java 7 » depuis quelques temps, mais seulement de « JDK 7 » qui n’est qu’une implémentation, là où « Java 7 » qualifierait un standard.
• Anne Thomas Manes faisant des observations similaires, compare l’OpenJDK à la position de framework Open Source « rebelle », non standard, que tient Spring.
• Stephen Colebourne encore, visiblement très impliqué par ce débat, revient dans une série de billets sur les différents qui opposent Sun à la fondation Apache, rappelant l’historique, ainsi que sur la problématique de propriété intellectuelle au sein du JCP de manière générale.

Si le JDK 7 devait être finalisé sans qu’aucun standard ne le soutienne, cela constituerait un évènement majeur, puisque l’avenir deviendrait incertain pour les JVMs fournies par d’autres éditeurs tels qu’Oracle ou IBM.

RIA, SOA, Tim Bray tire dans le tas

C’est dans une interview pour InfoQ que Tim Bray co-auteur du XML nous donne son avis sur les technologies RIA. Selon lui, les RIA type Flex, Silverlight et JavaFx n’ont pour but que de fournir des applications toujours plus immersives et de moins en moins utiles. Il modère tout de même ses propos en s’appuyant sur des exemples de réussite comme Google et Yahoo! qui utilisent de manière élégante Ajax et consort. En bref, pour lui les avantages des interfaces web sont la simplicité et la rapidité, Tim ne croit donc pas en la longévité du RIA. Rien de mieux pour faire de l’applicatif lourd que de l’applicatif lourd.
Dans son interview, il explique rapidement que l’émergence des Web Services et des architectures de type SOA s’est faite en dépit du bon sens. Au début chacun y allait de son format XML privé et ça fonctionnait, mais on a voulu généraliser le problème et fournir une solution pour tous. Cette volonté de créer une pierre philosophale pour exposer ses services n’a apporté que des difficultés d’implémentation, d’intégration et surtout d’interopérabilité. Bref, Tim est assez pessimiste en ce qui concerne les ‘WS-*’, il soutient en revanche REST qui selon ses termes, n’est qu’une reformulation des bonnes pratiques des Web Oriented Architectures.
Enfin, il reste très discret sur Sun et sur le cloud computing en indiquant tout de même que pour le moment le département se cherche un peu. Faut-il fournir des solutions et des outils pour implémenter des nuages ou bien héberger directement des nuages et devenir fournisseur?

L’interview complète sur InfoQ
La réponse de Yakov Fain

SOA

Red Hat JBoss choisit d’investir dans CXF

Red Hat a annoncé la semaine dernière qu’elle devient un « key contributor » du projet Apache CXF.
A terme, comme l’explique Sacha Labourey sur son blog, cela signifie que JBossWS qui laisse aujourd’hui le choix de l’implémentation Web Service (ne fournissant qu’une couche d’abstraction) ne fournira plus que l’implémentation Apache CXF. C’est dommage, d’autant plus que les dernières releases de CXF ont été plutôt douloureuses et riches en bugs.
D’un autre côté, la participation active des équipes JBoss au projet ne peut qu’aider à rectifier le tir. Gageons donc que les futures releases d’Apache CXF seront de bien meilleures factures que celles de 2008.

Le coin de la technique

Enfin une roadmap détaillée pour le JDK7

Lors de la conférence Devoxx de décembre dernier, un keynote avait particulièrement retenu l’attention : Mark Reinhold présentait alors la liste des fonctionnalités qui seraient intégrées au futur JDK 7, ainsi qu’une date pour la version finale.

Mark Reinhold annonce maintenant la mise en ligne d’un calendrier détaillé des milestones prévus et des fonctionnalités associées.

L’analyse de ces informations aboutit à quelques remarques :

• La période annoncée en décembre dernier pour l’arrivée d’une version finale, à savoir « début 2010 », est légèrement décalée puisqu’un final milestone est prévu pour le 18/02/2010 suivi d’une phase de release candidate d’un à deux mois. Ceci porterait donc l’arrivée d’une version finale à avril ou mai 2010.
• La liste des nouveautés reste globalement inchangée à une exception près : il n’est plus question de MVM (Multiple Virtual Machines) qui devait permettre d’exécuter plusieurs applications au sein d’une même VM. Cette fonctionnalité, particulièrement intéressante dans le contexte du regain d’intérêt pour les Applets Java et autres applications JavaFX embarquées dans le browser, était annotée d’un « maybe » il y a deux mois et était visiblement trop ambitieuse pour résister à la pression du calendrier.
• La JSR-310 (Date and Time API) n’avait pas été citée en décembre et ne l’est toujours pas. L’appel à l’aide du spec lead Stephen Colebourne aura donc été vain. En effet, comme il le faisait alors remarquer, dans le cas d’une inclusion au JDK, JDBC et NIO2 seraient impactés afin de prendre en compte la nouvelle API. Compte-tenu de cet impact, il était essentiel que cette JSR puisse être finalisée rapidement. Or son statut, toujours annoncé comme « inactive » par le site du JCP, tend à nous faire penser que la classe java.util.Date a encore de « beaux » jours devant elle.

La création de bundles OSGi selon SpringSource

SpringSource annonce l’arrivée de Bundlor, son outil de création de bundles OSGi, actuellement en version 1.0M2.

Dans un projet OSGi il est en effet nécessaire que l’ensemble des modules de l’application et des librairies tierces soient fournis sous forme de bundles. La création de bundles pour les modules dont on a le contrôle n’est pas un problème en soit, pour les librairies tierces, il en est tout autrement.

Deux possibilités s’offrent alors au développeur : obtenir la librairie qu’il recherche packagée sous forme d’un bundle OSGi sur un repository dédié (celui de SpringSource par exemple) ou créer ce bundle par lui-même. Dans ce dernier cas, il faudra analyser l’ensemble des dépendances de la librairie pour créer un manifest adapté. C’est là que les outils de création automatisée de bundles interviennent. Bnd était le seul disponible jusqu’alors, crée par Peter Kriens, Technical Director d’OSGi. SpringSource amène donc désormais son propre outil.

Bundlor est justifié par SpringSource par quelques fonctionnalités non présentes dans Bnd telles que la création incrémentale de manifests et l’intégration à Eclipse via un plugin dédié.

Malgré l’apparente efficacité de ce type d’outil, il est indispensable de ne l’appliquer qu’à des librairies tierces. En effet un des intérêts d’OSGi réside dans sa capacité à n’exposer qu’une partie soigneusement sélectionnée des interfaces d’un module, ce que seule une intervention humaine sera à même d’effectuer correctement.

Utiliser le nuage pour réduire les coûts d’intégration continue.

Il est de notoriété publique que plus la fin d’un sprint approche, plus les ressources du serveur d’intégration sont sollicitées. En outre, c’est dans ces périodes que les développeurs ont besoin des feedbacks les plus rapides. Alors, que faire ? S’offrir une machine surpuissante, dédiée à l’intégration continue, mais qui ne sera que rarement utilisée à pleine capacité ?
Atlassian, l’éditeur du serveur d’intégration continue Bamboo, propose de résoudre ce problème dans la version 2.2 de son produit, en offrant la possibilité d’utiliser « Elastic Bamboo », un agent distant s’exécutant sur le nuage Amazon EC2. Ainsi, la disponibilité et la puissance sont maximales lorsque l’équipe en a besoin, tout en limitant les coûts.
Et comme Atlassian utilise Bamboo en interne, certains plâtres sont déjà essuyés :

• Les builds doivent réellement être indépendants de l’environnement (à vous de construire vos builds en étant conscients de ce problème).
• Dans le cas standard, les dépendances doivent être téléchargées à chaque build (l’instance de build disparaissant du nuage lorsqu’elle se termine). Une solution peut être d’utiliser une image disque sauvegardée sur le nuage.

Toutes les astuces de Edwin Wong pour paramétrer votre serveur d’intégration continue sur le nuage se trouvent sur le blog d’Atlassian.

Outils Glassfish pour Eclipse

Sun vient de sortir la version 0.9 (la version 1.0 arrive bientôt) de son bundle.
Celui-ci intègre:

• Eclipse 3.4.1
• Serveurs Glassfish v 2.1 et v3 Prélude
• JDK 1.6 Update 12 (optionnel)
• Une série de plugins permettant de configurer votre serveur J2EE, ainsi que vos WebServices (Soap ou Rest) depuis l’IDE. (Plus de détails sur les plugins, ici).

Ce bundle offre l’avantage de fournir un paquet tout-en-un. Il est destiné aux développeurs et aux organisations qui n’utilisent pas NetBeans, mais Eclipse. Celui-ci étant l’IDE le plus répandu. Sun élargit ainsi son public et se rapproche de la grande communauté d’Eclipse.