Un précédent article a exposé les grands principes de la sérialisation avec Thrift et Procotol Buffers. Ces deux frameworks promettent notamment une représentation des messages optimisée en termes de taille, ce qui est avéré dans le benchmark JVM Serializers : Thrift et Protocol Buffers y obtiennent une réduction de taille du message de 73% par rapport à la sérialisation native Java. Ce benchmark regroupe par ailleurs de nombreux autres frameworks de sérialisation du monde Java, mais se limite toutefois à l’utilisation d’un unique message de test.

Le présent article analyse l’influence de la structure (nombre et taille des objets, complexité de la grappe) sur la compacité du message sérialisé pour Thrift et Protocol Buffers. La comparaison est réalisée en Java, son protocole de sérialisation standard servant de référence.
(Lire la suite…)

Préambule

Les applications Web enrichies, utilisant JavaScript pour mettre à jour tout ou partie d’une page web, sont officiellement nées en 2005 avec l’apparition du terme Ajax, et sont aujourd’hui communes. De ce concept sont ensuite nées les applications JavaScript « Single Page Interface », modèle dans lequel rentre l’application typique GWT. Le framework propose aujourd’hui un modèle de programmation au juste milieu entre les paradigmes du développement RDA (pour Rich Desktop Application) et du développement Web. Après compilation, une application GWT devient une application JavaScript tout à fait standard du point du vue du browser.

Les applications Ajax n’introduisent pas de nouvelles failles de sécurité. Techniquement, les risques et les techniques d’exploitation sont les mêmes. Si certaines failles sont affaiblies par le modèle, d’autres ont vu leur terrain de jeu évoluer.

Le but de cet article et d’un autre à venir est de rappeler les failles de sécurité qui concernent tout particulièrement la portion JavaScript – et donc GWT – de nos applications Web, puis de présenter les réponses qu’il convient de mettre en œuvre dans une application GWT pour contrecarrer les éventuelles attaques.

(Lire la suite…)

La plus grand conférence de la communauté Java avec JavaOne a eu lieu à Anvers en Belgique au mois de Novembre. Cette année, les thèmes principaux de Devoxx étaient (sans ordre particulier):

• Le futur de Java
• Les langages alternatifs sur la JVM
• HTML5
• JavaFX
• Android
• Un peu de Cloud, de NoSQL et d’architecture haute performance

Nous avons aussi eu droit à une grande annonce pour une nouvelle conférence qui démarre en 2012 : Devoxx France!

Bien sûr, OCTO était sur place. Dans cet article, nous ne couvrirons pas toute la conférence en détail, de nombreux blogs l’ont déjà très bien fait. Nous allons néanmoins vous résumer les grandes tendances de cette édition et vous donner nos impressions à froid.

La suite de cet article en anglais, international oblige! Lire la suite…

Le framework CXF est aujourd’hui probablement le meilleur framework pour implémenter des web services selon la spécification JAX-WS en Java. Ayant réalisé un projet d’envergure autour de CXF, cet article n’a pas pour but d’être une initiation à ce framework car les tutoriaux de base de la documentation sont très bien faits ( http://cxf.apache.org/docs/index.html). Nous allons plutôt, dans une série d’articles, tenter de vous présenter quelques « tips avancés » sur CXF.

Une grande qualité de CXF est d’être un framework très modulaire de par sa conception autour d’un bus et d’une chaîne d’intercepteurs.

Lorsqu’on met en place un ensemble de WebServices, on peut être amené à effectuer un traitement commun à tous ces web services. Par exemple, rattraper les exceptions et maîtriser la soap:foault qui sera renvoyée au client. Ce type de traitement peut être réalisé de diverses façons, mais une bonne pratique est d’utiliser des intercepteurs.

La documentation officielle explique très bien les bases de la mise en place d’intercepteurs.
CXF découpe en phases le cycle de vie d’un message depuis son arrivée en passant par son traitement jusqu’à la réponse à celui-ci. C’est sur ces phases que l’on « branche » les intercepteurs afin qu’ils puissent traiter un message en fonction de son étape de cycle de vie.
On peut aussi spécifier explicitement que l’on branche un intercepteur avant ou après un autre intercepteur sur la même phase.

(Lire la suite…)

La JSR 303 (Java Specification Request) a été lancée en 2006. Elle a pour objet d’éviter la duplication de la validation des données dans les diverses couches de l’application en la localisant dans la définition des Beans Java. Ceci, dans le but de gagner en productivité et d’éviter les bugs liés à la redondance de la validation. 5 ans après son lancement, nous sommes tentés d’en savoir plus sur le chemin parcouru par cette JSR et surtout de savoir si oui ou non elle a atteint ses objectifs !

Avant toute chose cependant, il est primordial de se poser quelques questions basiques qui nous permettront de comprendre cette JSR. En effet, quels sont les principes de cette JSR ? Quelles sont les différentes implémentations qui en ont été faites ? Sont-elles au même degré de maturité ? Cette JSR s’intègre-t-elle avec les frameworks existants ? Ou se situe-t-elle par rapport aux autres outils de validation ?

(Lire la suite…)

NullPointerException : l’erreur la plus courante dans un programme Java. On est tous à un moment ou à un autre tombé sur cette exception. Malheureusement, ce n’est qu’en production à 4h du matin qu’elle arrive. On corrige donc le bug suivant :

MonObjet monObjet = null;
…
monObjet.maMethode(); // => NullPointerException

Par un rapide :

if(monObjet != null) {
  monObjet.maMethode();
}

Ce correctif est tout à fait honorable, mais pourquoi ne pas essayer de ne plus avoir aucune exception de ce type ?

Il existe plusieurs méthodes validées par le compilateur pour l’éviter, et donc avant la mise en production. Aucune n’est nouvelle, certaines controversés, mais elles sont toutes étudiées dans la suite de cet article.

(Lire la suite…)

Le sujet du packaging des applications Java EE a suscité récemment des échanges riches sur notre mailing-list interne. C’est pourquoi nous avons trouvé intéressant d’en publier une synthèse. Nous remercions Dominique Jocal pour avoir réalisé cette synthèse, ainsi que les participants à ce débat : Benoît Lafontaine, Mikael Robert, Bertrand Paquet, Marc Bojoly – et nous vous souhaitons une bonne lecture !

Un projet de montée en version ou de changement de serveur d’application Java et de JVM est l’occasion pour une direction technique de se pencher à nouveau sur la stratégie d’empaquetage des applications : doivent-elles embarquer leur socle technique, ou s’appuyer sur celui présent dans le serveur d’application ?
(Lire la suite…)

A l’heure où les nouvelles technologies de stockage de données regroupées sous les termes NoSQL et Distributed Data Grid deviennent populaires, il est intéressant de suivre l’évolution de cet écosystème et notamment des librairies d’intégration avec ces outils.
Des librairies apportant un certain niveau d’abstraction émergent, avec l’espoir de voir apparaître des solutions de haut niveau comparables aux ORM que nous utilisons pour les bases relationnelles. Nous allons nous intéresser aujourd’hui au projet Spring Data, qui propose une certaine unification pour les accès aux bases de données dites NoSQL. (Lire la suite…)

Lorsqu’on écrit une application avec des données persistantes, il est souvent nécessaire de pouvoir réaliser de l’audit sur les modifications. Aujourd’hui, l’état de l’art pour la persistance des données se base sur des outils de type ORM à travers l’interface JPA en Java. Etre capable d’ajouter à chaque table la date de création et de dernière mise à jour est souvent la première demande en terme d’audit. Borémi et moi avons du répondre à cette question en mission. Nous avons regroupé et étudié différentes implémentations, notamment mises en oeuvre par d’autres Octos. De façon à vous aider à choisir le meilleur outil dans ce genre de situation, je vais vous présenter dans cet article (en anglais) les différentes solutions que nous avons comparées.
(Lire la suite…)