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

Dur dur d’être un (Java)Rebel

RIA

Vidcast de Christophe Coenraets autour de Flex

Le coin de la technique

Actualité éditeurs / SSII

Dur dur d’être un (Java)Rebel

S’il n’est pas simple de faire connaître un outil, il est encore plus compliqué de le monétiser. ZeroTurnaround nous en fait la démonstration avec JavaRebel. C’est la fête à la licence : après les dons aux ceintures marrons de Java Black Belt, et aux membres de projets open-source, ZeroTurnaround offre cette fois ses licenses aux lecteurs de DZone (digg-like pour développeurs). Quelle sera la prochaine étape ? La gratuité pour les usages non commerciaux ?

JavaRebel est agent java permettant de recharger à la volée des modifications effectuées sur classes. A l’utilisation, le principe reste le même que celui du hotswap proposé out-of-the-box par la JVM Sun, offrant un rechargement plus complet.

RIA

Vidcast de Christophe Coenraets autour de Flex

A ceux qui ont raté James Ward au Paris JUG, InfoQ offre une seconde chance avec l’interview de Christophe Coenraets, lui aussi évangéliste Adobe, captée dans le cadre du QCon 2008 de Londres.
Dans cette vidéo, Christophe Coenraets aborde les points suivants :

Les technologies RIA Abode : Flex 3, Air et BlazeDs
L’environnement de développement d’abode, FlexBuilder 3
La stratégie open-source d’Adobe
L’introduction d’un front-end Flex dans un SI existant
L’avenir des RIA à travers leur intégration aux moteurs de recherche et aux navigateurs internet

Une bonne façon de se remettre rapidement à jour si vous avez raté les derniers développements de la percée d’Adobe sur le marché des clients riches.

Le coin de la technique

Failles de sécurité dans Spring MVC

La nouvelle est assez rare pour que tout le monde s’en empare (TSS, techtarget, net-security.org, xtremeopensource.org, linux mag, …), Ounce Labs annonce la découverte de problèmes dans Spring MVC pouvant causer des failles de sécurité dans les applications utilisant ce framework, en voici les descriptions :

Soumission de champs de formulaire non éditables. Si votre modèle contient plus de champs que votre formulaire HTML, il est possible d’envoyer une fausse requête contenant des données non éditables.
Injection Modèle/Vue. Ce problème arrive lorsque le rendering utilise un nom de vue provenant directement d’une requête. Si ces noms mappent certaines ressources protégées par le serveur d’applications, il est alors possible, dans certains cas, d’y accéder.

Ces deux vulnérabilités sont connues depuis longtemps par Spring Source, qui vient de publier une Spring MVC vulnerability FAQ à ce sujet. Il ne s’agit pas de véritables bugs, mais plus d’un mauvais usage du framework. Cela ressemble plus à une opération publicitaire de Ounce Labs qu’à une véritable alerte ; ce coup d’éclat a tout de même le mérite de nous rappeler la difficulté des développements web et le dilemme permanent des frameworks web qui sont écartelés entre l’ajout de fonctionnalités et la sécurité. Les approches actuelles zéro-confs sont à ce titre bien dangereuses.

Premier résultat SpecJVM2008, et alors ?

David Dagastine annonce dans First SPECjvm2008 Result Published! que Sun a publié le premier résultat de ce benchmark de JVM. Cependant, nous pouvons nous interroger sur le rôle qu’a aujourd’hui un tel benchmark dans le choix d’une JVM alors que les machines virtuelles d’IBM (J9), d’Oracle-BEA (Jrockit) et de Sun (Hotspot) qui ont aussi bonne presse sur ce sujet. Le critère de l’exploitabilité de la JVM, aujourd’hui très en vogue avec la médiatisation de VisualVM (Sun), ne semble pas plus pris en compte aujourd’hui alors que des écarts importants subsistent entre les éditeurs et qu’Oracle-BEA a de sérieux atouts différenciant avec son très mature JRockit Mission Control.

En fait, les JVM sont devenues des commodités et le critère de choix relève aujourd’hui plus de l’écosystème et particulièrement du serveur d’applications Java. Un utilisateur de Websphere devra utiliser J9 [1], un utilisateur de Weblogic aura le choix entre JRockit et Hotspot et les autres utilisateurs (Tomcat, JBoss, etc) se tournent le plus souvent vers le standard de facto : l’implémentation de Sun.

Nous noterons un point intéressant sur SpecJVM2008 : le benchmark se fait sans aucun tuning de la JVM. Cette règle illustre la tendance actuelle des éditeurs de JVM qui fournissent des machines virtuelles optimales en configuration par défaut grâce à des mécanismes de détection de la configuration de l’OS et d’optimisation automatique à l’exécution.

[1] sauf sur les plateformes sur lesquelles IBM n’a pas porté J9 et où il propose alors Hotspot (Solaris, HP UX)

Envers : JBoss ajoute à JPA le versioning des données

Trois mois après l’annonce d’une preview, Adam Warski propose aujourd’hui la version 1.0 de JBoss Envers, une extension à JPA pour versioner les données, un sujet fréquent dans l’informatique de gestion des contrats. L’occasion pour JBoss de réaffirmer sa place de leader de l’innovation autour de JPA.

Les points clefs de JBoss Envers :

Versioning de propriétés simples (strings, integers, longs…) comme des composants embedded (eux même composés de propriétés simples)
Versioning de classes aux ids simples, composites ou _embedded_
Versioning des relations one-to-one et one-to-many
Listener de révision @RevisionEntity pour notamment ajouter des modifications spécifiques aux entités versionées
Historisation par numéro de version (@RevisionNumber) ou à date (@RevisionTimestamp)
Requête sur les données historiées avec un VersionsReader
Envers repose sur l’EntityManager JPA plutôt que la Session Hibernate, on peut y voir un signe supplémentaire pour migrer des API propriétaires d’Hibernate vers celles standard de JPA.

Exemple de classe versionnée avec Envers :

@Entity
@RevisionEntity(MyRevisionListener.class)
public class Person {
    @Id
    @GeneratedValue
    Integer id;

    @Versioned
    String name;

    @Versioned
    String surname;

    @Versioned
    @ManyToOne
    Address address;

    @RevisionTimestamp
    long revisionTimestamp;

   ...
}

Pour plus d’informations sur ce sujet, nous aimons Patterns for things that change with time de Martin Fowler.

JSR 203: More New I/O APIs for the Java Platform (« NIO.2 »)

Si NIO 1 mettait l’accent sur la scalabilité, JSR 203 – NIO 2 se focalisera sur l’utilisabilité des différents systèmes de fichiers comme Alan Bateman (Sun) et Carl Quinn (Google) l’ont expliqué à JavaOne dans « New I/O in JDK 7 ». Les points clefs de NIO 2 :

Nouvelle API d’abstraction de système de fichier (FileSystem, Path / FileRef et FileStore) et notamment l’amélioration de la navigation dans les arborescences.
Unification des API Channel et Socket avec une abstraction système de fichier sous-jacent.
Amélioration des I/O asynchrones.
Correction de bugs qui trainaient de longue date des les API I/O

Dans la continuité, Elliotte Rusty Harold détaille dans The Open Road: java.nio.file le fonctionnement de la nouvelle abstraction du système de fichier.

Pour plus d’informations sur les nouveautés de Java 7 :

L’avenir de la virtualisation et du cloud computing java selon Billy Newport

Billy Newport, Websphere eXtreme Scale, explique dans une interview à Floyd Marinescu, InfoQ sa vision de la virtualisation et du cloud computing en Java.

Nous retiendrons :

Pour les applications Java, la virtualisation de la couche physique (processeur, mémoire, etc) tend vers la gestion de grappes de petits serveurs virtuels à ressources fixes (e.g. 4 ways, 2 Go de RAM, 160 Go de disque) plutôt que vers des serveurs de grande capacité à ressources variables : il est très difficile d’optimiser les performances de gros serveurs (e.g. 32+ cores/ways, 10+ Go de RAM, etc) et les programmes ont le plus grand mal à se réadapter (e.g. pool de threads, taille de cache) quand les ressources allouées changent
Des serveurs à plusieurs dizaines de cores arriveront plus vite que nous le pensons et les éditeurs de JVM s’y préparent, mais les JVM et les APIs de concurrence ne sont aujourd’hui pas prêtes. Par exemple, les pattern multi-reader/mono-writer ne seront plus adaptés.
Les grilles de données n’ont pas besoin d’API spécifiques pour le moment : JPA et JMS suffisent aux besoins actuels. Par ailleurs, l’API JSR-107: JCache suscite des réticences de la part des grands éditeurs de grilles java et ne verra probablement jamais le jour.
La virtualisation des données se divise en deux grande familles :
- Network Attached Cache : le paradigme de programmation est le même qu’en l’absence de cache. Typiquement positionné en cache L2 d’un framework JPA, les données du cache sont rapatriées sur le serveur d’applications pour réaliser les traitements métiers, mais ce modèle atteint ses limites avec le coût de rapatriement des données.
- eXtreme Transaction Processing Grid : le paradigme de de programmation change complètement ; le traitement métier, au lieu d’être réalisé sur le serveur d’applications, est envoyé sur tous les noeuds de la grille, seule la consolidation est effectuée sur le serveur d’applications. Cette architecture scale jusqu’à plusieurs milliers de noeuds sur la grille.
Les SGBD, avec la co-localisation des données, ont atteint leur limite de scalabilité. IBM comme Oracle ou Microsoft investissent aujourd’hui dans les data grids pour lever cette limite (respectivement eXtreme Scale, Coherence et Velocity).