Revue de Presse Xebia

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

Actualité éditeurs / SSII

SpringSource et Oracle ensemble pour l’OSGi d’entreprise

Le coin de la technique

Evènements de notre communauté en France et à l’étranger

Devoxx 2009 : le bilan

Actualité éditeurs / SSII

SpringSource et Oracle ensemble pour l’OSGi d’entreprise

Adrian Colyer, SpringSource, a annoncé la création d’un nouveau projet au sein de la fondation Eclipse : Gemini. Il s’agit d’un sous-projet d’Eclipse Runtime qui a pour but de réunir l’ensemble des implémentations de référence des spécifications OSGi liées au monde de l’entreprise. Il s’agit d’un effort commun de SpringSource et d’Oracle.

Deux composants fondamentaux sont apportés par SpringSource :

Gemini Web Container : il permet le fonctionnement d’un conteneur de Servlets dans un environnement OSGi. Cette implémentation est actuellement utilisée dans SpringSource dm Server et est donc prévue pour fonctionner sur Tomcat. Mike Keith, Oracle, assure que l’adaptation pour Jetty arrivera par la suite grâce à une collaboration avec l’équipe de ce projet.
Gemini Blueprint Service : il s’agit de Spring Dynamic Modules. Ce projet, qui a fortement inspiré la spécification du Blueprint Service intégré à OSGi 4.2, devient logiquement son implémentation de référence.

Il est important de noter qu’Adryan Colyer explique que SpringSource continuera désormais le développement de ces deux projets directement au sein de la fondation Eclipse et non plus en interne.

Oracle, pour sa part, apporte plusieurs implémentations de référence pour des RFC supplémentaires non intégrées à la spécification OSGi 4.2 : RFC 98 (transactions), RFC 122 (database access), RFC 139 (JMX integration), RFC 142 (JNDI integration), RFC 143 (JPA integration), RFC 146 (JCA integration).
Mike Keith indique qu’EclipseLink est à même de fonctionner correctement avec OSGi depuis longtemps, mais qu’il n’implémentait pas JPA lorsque cette intégration a été mise en œuvre au sein du projet. Par conséquent, une adaptation est nécessaire pour passer à la RFC 143, afin d’assurer une intégration JPA standard.

Alors que la spécification 4.2 a été finalisée il y a 2 mois, les implémentations de référence étaient toujours attendues. Cette réunification des implémentations liées a l’OSGi d’entreprise au sein d’un même projet Eclipse est une excellente nouvelle : elle met en avant la standardisation dont on pourra désormais bénéficier pour les développements intégrant OSGi dans les applications JEE. Mais cela suffira-t-il à démocratiser OSGi en entreprise ?!

Le coin de la technique

Lucene passe à Java 5

L’équipe du projet Lucene annonce la sortie de Lucene 3.0. Comme nous l’expliquions précedemment, cette version marque une évolution majeure puisqu’elle est la première a nécessiter Java 5.0 au minimum.

L’API bénéficie donc désormais de l’ensemble des améliorations du langage de Java 5.0 dont les generics, le varargs, les enums et l’autoboxing.

Tempérons cette annonce : l’API Lucene n’a pas été refondue, il ne s’agit que de quelques améliorations visant à la rendre type-safe. Citons par exemple :

Apparition d’enums BooleanClause.Occur, Field.Index, Field.Store et Field.TermVector ; ces concepts étaient jusqu’alors représentées sous forme de constantes type-safe.
La méthode getFields() de la classe Document retourne désormais une List<Fieldable> alors qu’elle retournait une simple List jusqu’alors.
La classe Term implémente désormais Comparable<Term> et non plus simplement Comparable.

Ces changements légers décevront peut-être certains utilisateurs lassés par l’API vieillissante de Lucene, mais on appréciera toutefois la facilité de migration, puisqu’il s’agira la plupart du temps de supprimer quelques casts (l’équipe Lucene cite quelques cas à surveiller lors de la migration).

Cette nouvelle version, qui apporte par ailleurs quelques modifications mineures, conclut donc un cycle d’évolutions importantes sur le projet Lucene.

Mark Reinhold justifie l’introduction des closures

C’était l’Annonce de cette édition de Devoxx, l’apparition des closures en Java 7. Mark Reinhold revient, sur son blog, sur les raisons à l’origine de cette petite bombe.
Il justifie cette évolution majeure du langage par la nécessité pour Java de tirer partie des nouvelles générations de processeurs, multi-cœurs.
Jusqu’ici, pour exploiter cette puissance, il fallait utiliser des Parallel Array et tout le code inutile nécessaire à leur fonctionnement. Les closures permettent de supprimer ce code, et il est temps de les introduire en Java.
Java doit se concentrer sur deux fonctionnalités clés : la syntaxe littérale, et les fonctions typées. L’arrivée des closures requiert deux autres évolutions de Java : les conversions, et l’extensibilité des méthodes.
Il est temps pour Mark Reinhold d’oublier les querelles. Sun spécifiera et implémentera un premier jet des closures pour le JDK 7. Cela permettra une expérimentation à grande échelle, et si tout se passe bien, cela conduira à une JSR de modification du langage, qui pourra être incluse dans Java SE 7.
La tâche est immense et Mark Reinhold appelle bien évidement toutes les bonnes volontés à contribuer.

Bien au-delà de la manipulation du multi-threading, les closures pourraient permettre une simplification des APIs courantes. Cette perspective semble essentielle à Mark Reinhold qui ne pouvait attendre le JDK 8 pour une nouvelle tentative, dans 3 à 4 ans…

Patterns NoSQL

Nous vous parlions récemment dans une revue de presse et un article du mouvement NoSQL, qui se caractérise par « une absence de requête et par un relâchement des caractéristiques ACID propres aux RDBMS ». Ricky Ho, architecte chez Adobe, revient sur son blog sur les caractéristiques communes de plusieurs technologies permettant de « faire du NoSQL », et extrait quelques patterns récurrents. Ne vous arrêtez pas à la mise en page étriquée de l’article, car la description est très complète. Ricky Ho y explore successivement:

Les types de noeud possibles (physiques et virtuels) ainsi que leur fonctionnement.
Le partitionnement des données.
La réplication de ces données, ainsi que le maintien de leur consistance.
La gestion des pannes.

On notera quand même que l’une des solutions retenue pour le stockage des données reste… une base de donnée relationnelle ! ;) Humour mis à part, une telle formalisation de patterns est vraiment bienvenue dans un environnement aussi émergeant.

Evènements de notre communauté en France et à l’étranger

Devoxx 2009 : le bilan

Nous concluons aujourd’hui notre série de billets sur Devoxx 2009. Ces 5 jours passés à Anvers furent riches en informations et en rencontres et nous souhaitions vous les faire partager.

A l’heure du bilan, voici ce que nous retiendrons de cette édition :

Les annonces concernant JDK 7, JEE 6 et Maven 3.0.
Le succès de JEE 6 : toutes les sessions sur le sujet ont fait salle comble.
La place réservée à la nouvelle plateforme Flash d’Adobe, présente au keynote et dans de nombreuses sessions ; il est intéressant de noter que cette place correspond exactement à celle occupée par JavaFX lors de la précédente édition.
L’omniprésence de Scala ; au-delà des sessions qui lui étaient consacrées, il était cité dans beaucoup d’autres présentations lorsqu’il était question de DSL par exemple.
L’intérêt persistant de la communauté pour le Cloud Computing. Ce nouveau concept a rencontré un large succès à Devoxx.

Pour rentrer plus en détails dans les enseignements de cette conférence, vous pouvez désormais retrouver l’intégralité de nos billets Devoxx :

Commentaire

3 réponses pour " Revue de Presse Xebia "

Published by Hervé A. , Il y a 14 ans

‘Omniprésence de Scala »… « Jazoon – Jour 1 – Groovy »… que faut-il faire, Scala ou Groovy, ou autre ? Existe-t-il une tendance dans ces salons ?
Published by Francois Marot , Il y a 14 ans

@Herve bonne question ! ;)
Mais les 2 ne sont pas identiques. Pour ma part j’ai testé Groovy et quasiment pas Scala. Ce que j’apprécie dans Groovy c’est qu’on peut s’y mettre tout doucement. Du Groovy, c’est (presque) du Java: on peut se contenter d’apprendre petit à petit, c’est assez sécurisant, tout en restant tres puissant. Et je pense que pour des équipes de dev déjà formées à Java, Groovy est une évolution logique. Scala par contre change beaucoup de choses. C’est un autre paradigme, sans doutes tout aussi puissant, tres intéressant aussi, mais tres different ! Donc à mon avis, il sera plus dur pour des équipes entiere de « faire du Scala » convenablement avant un bon bout de temps: il faudra que les équipes de dev’ réapprennent toutes les bonnes pratiques (avec les erreurs de débutant qui en découlent).
Published by Dominique De Vito , Il y a 14 ans

Perso, ce que j’aimerais, c’est un auto-boxing des méthodes en objets implémentant une interface, comme je l’indique ici : http://www.jroller.com/dmdevito/entry/next_jdk_wishlist_3_a

Cela couterait pas cher et cela permettrait d’améliorer un peu les choses.

En gros, si j’ai une méthode :

Object myProcessing(Object e) {
…
}

Méthode dont la signature est compatible avec l’interface :

public interface UnaryOperator {
Object eval(Object arg);
}

avec, par ex, l’utilisation suivante de cette interface :

public class AbstractList … {

public void map(UnaryOperator op) {
…
}
}

Alors j’aimerais pouvoir simplement écrire :

mylist.map(myProcessing);

Avec auto-boxing automatique de « myProcessing » en un objet implémentant l’interface UnaryOperator.

Ce serait un plus, et une avancée qui pourrait obtenir un consensus plus facilement que les différentes propositions des closures.