Coder's IO

Vert.x

je vais vous présenter le projet Vert.x. Je suis tombé dessus par hasard lors d’une veille technique quotidienne au détour d’un post sur un blog… (vous me suivez ? 😉 )

Qu’est ce que Vert.x?
C’est un framework qui peut se résumer par les termes suivants :

– moins d’effort
– polyglotte,
– scalable,
– simple,
– concurrence.

La première release 1.0 a vu le jour le 25 avril 2012 (aujourd'hui, la version courante est 1.2.3).
Ce projet est sponsorisé par VMware.
Lors de sa sortie en version béta, le projet est devenu le 32ieme projet Java suivi sur Github, juste derrière JBoss AS (ceci grâce à un article publié sur infoQ).

Pour se faire une idée rapide, c’est un outil très proche de Node.js dans l’état d’esprit. C’est à dire qu’au travers de quelques lignes de code, vous avez un serveur HTTP fonctionnel et très performant.

Pour être tout à fait honnête, je ne connais que les aspects théoriques de Node.js. Par conséquent, je ne vais pas pousser plus loin la comparaison et me focaliser sur Vert.x

Plus concrètement…
Vert.x est un framework d'application événementielle qui fonctionne sur la JVM.

Il est polyglotte : vous avez le choix du langage avec lequel vous souhaitez travailler :
– Javascript
– CoffeeScript
– Ruby
– Python
– Groovy,
– ….. et Java.

Vous avez aussi la possibilité de mixer les langages.

Il est simple : quelques lignes suffisent pour obtenir une application robuste et scalable :

import org.vertx.java.core.Handler;
import org.vertx.java.core.http.HttpServerRequest;
import org.vertx.java.deploy.Verticle;

public class Server extends Verticle {
public void start() {
vertx.createHttpServer().requestHandler(new Handler<HttpServerRequest>() {
public void handle(HttpServerRequest req) {
String file = req.path.equals("/") ? "index.html" : req.path;
req.response.sendFile("webroot/" + file);
}
}).listen(8080);
}
}

Il est scalable : il se base sur le modèle de programmation asynchrone avec des IO non-bloquantes.

La concurrence simplifiée : le framework offre la possibilité de coder comme dans un environnement mono-threadé.

Il est reparti : La communication entre les différents composants d’une application basée sur Vertx se fait via un bus d’évènement distribué. La communication se fait entre toutes les instances du serveur ainsi que la partie cliente. Cette gestion d’évènements est basée sur le modèle d’acteur.

Il supporte :
– websokets,
– SockJS
– communication HTTP/HTTPS
– TCP / SSL

Vert.x offre un système d’extension via les modules. Un repo public est disponible sur Github.

Autres fonctionnalités en vrac :
– Gestion de tâches planifiées,
– Fichier de conf rédigé en JSON,
– Module de définition de route,
– Manipulation du système de fichiers.
– etc…

Comment utiliser vert.x ?
Vert.x peut être utilisé comme une plateforme autonome ou alors embarqué dans une autre application.

La documentation est assez complète. La liste de discussion est très fréquentée et les questions trouvent rapidement des réponses.
Ce projet est encore jeune mais propose déjà des fonctionnalités avancées.

Je pense que c’est un projet sur lequel il faut garder un oeil et qu’il ne faut pas hésiter à tester.

#java #vertx #vmware #groovy #Javascript #CoffeeScript #Ruby #Python #Groovy ,

octobre 8, 2012 0

PowerMock

Les tests unitaires sont un point central dans un projet informatique; Ils garantissent (en partie) la stabilité du code couvert.
Ils doivent avertir le développeur d'un changement de comportement d’une portion de code. Dans certain cas ce changement est normal car une règle métier a changée;dans d'autre cas cela peut être dû à un impact collatéral sur composant, à priori, sans rapport avec l'évolution qui vient d'être faite.

Avoir une couverture de test unitaire la plus large possible sur l'ensemble du code de notre application permet de se prémunir des régression potentielle.

La famille des outils permettant d'écrire des tests unitaires est assez grande. On y trouve différents frameworks permettant d'adresser l'ensemble des contraintes que l'on peut rencontrer lorsque l'on écrit des tests unitaires.

Dans les applications que nous développons, nous travaillons généralement avec des APIs externes, du code legacy, etc.
Ce type de code, sur lequel nous n’avons pas forcément la main, peut poser des problèmes lors de l’écriture d’un test unitaire dépendant de ces composants.
Dans les bonnes pratiques d’écriture de test unitaire, il faut bouchonner (mocker) tout ce qui n’est pas directement lié au code à tester.

Pour cela, on utilise des frameworks de mock comme :
– EasyMock,
– Mockito,
– JMock.

Ce sont les plus connus. Avec ces outils on pourra bouchonner :

– Tous les composants fournissant une interface,
– Aussi les composants basés sur des classes non finale.

Sur ces bouchons on ajoutera des comportements permettant de positionner un contexte d’exécution au test unitaire cible. Les comportements seront du type :

Lorsque tu appelles telle méthode de ma classe, renvoies moi tel objet
Cette méthode ne jamais être appelée
Cette méthode doit être appelée au moins N fois

Bon c’est un tout petit rappel sur la mission attribuée à un framework de mock.

Malgré les possibilités offertes par ces frameworks, il existe des limitations :

– Mocker une classe déclarée finale,
– Mocker des méthodes déclarées privées,
– Mocker des méthodes statique,
– By-passer le constructeur d’une classe,
– Mocker partiellement une classe.

Toutes ces problématiques sont adressées par PowerMock et de manière très élégante.
En effet, à l’aide de deux annotations, toute la puissance de l’outil se retrouve dans vos tests unitaires et vous évite d’installer pas mal de plomberie pour pouvoir tester dans de bonnes conditions votre code.

PowerMock s’intégre parfaite (des extensions sont proposées) avec EasyMock, Mockito et aussi TestNG.

La dernière release du projet a été faite au mois de mai de cette année.
Le wiki fournit beaucoup de documentation et d’exemples, ce qui permet de prendre l’outil en main très rapidement.

Je pense qu’il apporte un vrai plus dans l’écriture de test unitaire. Il repousse les limites imposées par le langage et permet de rendre nos tests beaucoup plus robuste et exhaustif.

Mettez les bouchons doubles! 🙂

Il existe, dans le même registe, JDave : http://jdave.org/

#java #test #mockito #powermock #mock #test #unitaire

octobre 4, 2012 0

Chargeur de classes en Java

Le chargement des classes en Java est un mécanisme qui est souvent ignoré et laissé de coté par la plupart des développeurs.

Ce mécanisme est pourtant la base du langage et un de ses atouts par rapport au chargement dynamique des classes pendant l’exécution d’un programme. Par ce biais, Java ne charge en mémoire les modules que lorsque ceux ci sont nécessaires, etc.

Je vous propose aujourd’hui un article que j’ai trouvé particulièrement intéressant sur le sujet.
Bien que le sujet de l’article soit Le chargement de classe dans JBoss AS , toute une partie est consacrée à un rappel sur ce fameux mécanisme du chargement de classe : Le class loader.
Aussi, cet article à le mérite d’être rédigé en francais (ce qui est assez rare pour ce genre de sujet).
Enfin, malgré l’âge de cet article (28/11/2007), je pense que toute la théorie nécessaire à la bonne compréhension du système de chargement de classes reste d’actualité (à quelques détails près peut-être).

Globalement, l’article s’organise de la façon suivante; Tout d’abord, l’auteur fait un rappel détaillé sur comment se passe le chargement des classes au sein de la JVM. Notamment, en décrivant les 3 chargeurs fondamentaux de la JVM.
Ensuite, il fournit des explications précieuses sur les différents types d’exception pouvant être lancés pendant le chargement.

Après cette introduction, il se lance dans le coeur du sujet, en détaillant comment JBoss utilise ce mécanisme dans son context de serveur d’application.

L’article se termine sur des bonnes pratiques à mettre en oeuvre lors du développement de composants destinés à être déployés au sein d’un serveur d’application, en l'occurrence JBoss.

Au risque de me répéter, bien que l’article soit un peu ancien, il décrit des concepts et fournit des informations encore d’actualité aujourd’hui.
Il constitue une bonne base d’entrée en matière sur le sujet afin d’être mieux armé sur les problèmes que l’on pourrait rencontrés.

Voici, également, un pointeur sur un cours traitant du même sujet. il viendra compléter l’article.
http://deptinfo.unice.fr/~grin/messupports/java/chargeurs6.pdf

Bonne lecture!

#Java #classloader #JVM #classe #chargement.

octobre 1, 2012 0

Java au quotidien épisode 3

Aujourd’hui, je vais vous parler d’une méthode disponible dans l’API Guava que je trouve très pratique pour adresser des problématiques de partitionnement d’ensemble.
Je vois deux cas d’utilisations de cette méthode (tiré d’un cas réel) :

– gérer de la pagination,
– Spring batch ( en mode partitionnement).

Cette fameuse méthode fait partie de la classe Lists. Elle a la signature suivante :
public static <T> List<List<T>> partition(List<T> list,int size)

Elle permet à partir d’une liste typée et de la définition d’une taille, d’obtenir un ensemble de listes d’une taille correspondant à la taille définie en paramètre (sauf éventuellement pour la dernière ;-)). Chacune des listes contient un sous-ensemble de la liste passée en paramètre.

Si l’on prend, par exemple, le premier cas de figure évoqué au début de l’article, sur la gestion d’une pagination, on peut se rendre compte de tout l’intérêt d’une telle méthode.
Dans certain cas, cette gestion est faite à la mano :

// En paramètre page courante, nombre d'élément par page

final List<MyElement> elementList = ElementProvider.getAllElement(/*some parameters*/);
totalRecords = elementList.size();
offset = rows * (page – 1);
// Let's avoid showing a blank page, back to first one.
if (totalRecords < offset) {
offset = 0;
page = 1;
}
int start = offset, end, size;
List<MyElement> selectedElements;
do {
size = rows > totalRecords – start ? totalRecords – start : rows;
end = start + size;
selectedElements = size > 0 ? elementList.subList(start, end) : new LinkedList<MyElement>();
doSomething(selectedElements);
start = end;
} while (selectedElements.size() < size && rows == size);

Sans vraiment regarder le détail du code ci-dessus (tiré de la vraie vie), on s’aperçoit que la complexité est là.
On pourrait remplacer ce code par le suivant :

final List<MyElement> elementList = ElementProvider.getAllElement(/*some parameters*/);

List<MyElement> currentElements = Lists.partition(elementList, nbElemeByPage).get(idxCurrentePage);

Remarque : certaines vérifications pour sécuriser le code seront tout de même nécessaires. Néanmoins celles-ci ne remettront pas en cause la simplicité du code

On voit que le code est beaucoup plus clair et concis.

L’autre cas concernant Spring Batch est clairement adapté.
Pour rappel, l’utilisation du partitionnement au sein de spring batch permet de répartir sur plusieurs agents le traitement d’un ensemble de données. En entrée de l’unité de traitement spring Batch, un ensemble. Cet ensemble est découpé en parts égales et distribuées à plusieurs agents (distants ou locaux) pour effectuer de manière cloisonnée et en parallèle un traitement à partir des données.

Dans ce cas, l’utilisation de la méthode de partitionnement est plus qu’évidente.

Voila j’espère que ce court article vous aura fait découvrir un outil qui vous sera utile dans votre quotidien…

A vos marques, prêt ? .. Partitionnez !

#Java #guava #partition #tools

septembre 26, 2012 0

JEP 162: préparation de la modularisation

Au mois de juillet dernier, Mark Reinhold annonçait le report du projet de modularisation qui devait faire partie de la prochaine version du JDK.

Malgré ce décalage, Alan Bateman propose au travers d’une JEP (JDK Enhancement Proposal) de préparer le terrain du projet de modularisation pour la prochaine release.
La JEP 162 décrit les évolutions proposées en vue de préparer l’intégration du projet Jigsaw.

Il est utile de préciser que l’objectif n’est pas de commencer à intégrer du code directement lié au projet de modularisation mais seulement de préparer le terrain.

Voici la liste (non exhaustive) des propositions :

– Amélioration du mécanisme de chargement des classes, ainsi que la correction de certains problèmes identifiés.
– Standardisation de l’utilisation de java.util.ServiceLoader.
– Fourniture d’un outil d’analyse des dépendances statiques.
– Déprécier l’ensemble des APIs Java SE pouvant être une contrainte ou un obstacle pour le projet Jigsaw
-etc..

Malgré le report du projet, on peut constater que l’effort est maintenu par cette anticipation dans le contenu de la prochaine release.
Vous pourrez trouver plus de détails dans l’article attaché à ce post.

#java #jigsaw #JEP #162 #JDK8 #JDK9

septembre 24, 2012 0

Exception et errors

Je suis tombé sur ce blog ‘original’. Tout est dans le titre… L’auteur,
+Ganesh bhuddhan bu a commencé à recenser les exceptions et les erreurs (Error) en fournissant une description assez détaillée sur les raisons de leur apparition.

Pour chaque cas, on trouve un commentaire plus un bout de code mettant en évidence la source de l’erreur.
Le blog existe vraisemblablement depuis le mois de mai de cette année. Je trouve l’initiative intéressante.
Si pour des développeurs expérimentés cela peut paraitre évident, je pense que pour des personnes d’un niveau plus junior, cela peut constituer une mine d’or d’information 🙂

Bonne lecture!

#java #exception #error

septembre 12, 2012 0

DumdSter : Email testing

Toutes les applications sur lesquelles nous travaillons ont toujours le besoin d’émettre des mails.
En règle générale, ces mails servent à notifier ou informer des utilisateurs.
Bien souvent, le contenu du mail est dynamique, ainsi que les paramètres d’envoi tels que l’émetteur, le destinataire, le sujet, etc…
Bien entendu, la gestion des mails est assurée par un composant générique, développé par nos soins ou dans 95% des cas, fourni par un framework tiers (ex: Spring).

Associé à ce coté dynamique, on a des règles métier. Je pense que vous voyez où je veux en venir.
Afin de garantir la cohérence par rapport à ces règles et surtout détecter les régressions en cas d’évolution, il est impératif d’écrire les tests unitaires et d’intégration qui vont bien.

Tester un envoi de mail, n’est pas toujours évident dans le sens où le résultat produit est un mail qu’il faut réussir à intercepter une fois qu’il a été construit et envoyé.

Dumbster est un outil permettant d’adresser ce besoin de manière efficace et très simple.
L‘objectif est de permettre au sein d’un test unitaire/test d’intégration de démarrer un serveur SMTP afin d’intercepter les mails envoyés.
Le fait d’avoir un serveur de ce type à disposition facilite grandement les choses.

La mise en place sur un projet est d’une simplicité déconcertante. Elle se résume aux étapes suivantes :
– ajouter la dépendance dans votre pom (ou dans le classpath pour un projet non mavenisé)
– démarrer le serveur smtp au début du test (1 ligne)
– envoyer vos mails
– récupérer vos mails (1 ligne)
– traiter le résultats avec vos assertions
– arrêter le serveur smtp (1 ligne).

Sans exagération, ce n’est pas plus compliqué que cela. Il n’y a aucune configuration à faire.
Plus concrètement, voici un exemple de code mettant en œuvre l’outil.

SimpleSmtpServer server = SimpleSmtpServer.start();

// envoi des mails

// récupération du nombre de messages reçus par le serveur
int receivedEmailSize = server.getReceivedEmailSize();

// récupération des emails de manière effective
Iterator emails = server.getReceivedEmail();

//traitement des mails reçus

SimpleSmtpServer.stop();

Cela ne nécessite pas plus de travail que cela.

Ce projet va bientôt avoir 10 ans d'existence, la dernière release a été faite en novembre 2005. Il ne semble plus y avoir beaucoup d’activité sur le projet, cependant le service rendu par cet outil est précis et fonctionne bien.

Étant donné l'âge de l’outil, bon nombre d’entre vous connaissent probablement déjà l’outil ; dans ce cas n’hésitez pas à donner vos impressions sur l’outil.

#java #smtp #test #fake #integration

septembre 10, 2012 0

Java EE 7 gardera les pieds sur terre

Courant juillet 2012, Oracle annoncait le report du projet Jigsaw de la version 8 à la version 9 du JDK. Ce décalage de release était du à un problème de temps et des soucis techniques rencontrés. Nous en avions parlé lors d’un post sur cette page : https://plus.google.com/112440333946538821016/posts/MrYT1eBkTnV

Aujourd’hui, c’est au tour de la plateforme Java EE d’annoncer un changement dans sa roadmap initialement prévue au quatrième trimestre 2012.

C’est sur le blog d’Oracle que la nouvelle est tombée le 30 août 2012 annoncant que toute la partie Cloud ( Paas et la mutualisation) est reportée sur JavaEE 8.
Les raisons données, par la responsable de la spécification JavaEE 7, Linda DeMichiel, sont liées à une avancée lente sur toute cette partie par rapport aux planifications.

D’après les explications données par Linda, ces ralentissements sur l’agenda sont du principalement :
– au manque de maturité des technologies du cloud (mutualisation, déploiement d’application, etc)
– ainsi qu’à la volonté, des équipes d’Oracle, de vouloir faire les choses correctement, compte tenu de l'expérience limitée de l'industrie dans le domaine de nuages lorsque le travail a été entamé.

En gardant la cible initiale JavaEE 7 pour ces fonctionnalités, cela aurait eu pour conséquence de décaler la release au printemps 2014, soit un décalage de 2ans.
Le report des fonctionnalités liées au Cloud présente les avantages suivants :
– Cela permettra aux revendeurs des platformes JavaEE de gagner en expérience sur leur implémentations dans ce domaine.
– La communauté n’aura pas à supporter le prix des fonctionnalités nécessitant plus de temps à mettre en place.
– parce que dans Java EE 7, une partie des bases nécessaires à l’infrastructure du Cloud ont déjà été posées (définition des métadatas, amélioration de la configuration de la couche de sécurité,etc). Ces bases permettront d’accélérer la livraison de JavaEE 8 (estimée au printemps 2015).

Au delà des avantages présentés ci-dessus, cette modification de planning permettra au équipes de :
– garder un focus sur l’amélioration de la simplification et de la convivialité de la platforme
– livrer dans les temps les fonctionnalités largement plébiscitées par les développeurs (Websocket, JSON-P, la simplification de l’api JMS 2.0, etc).

On comprend que la réduction du scope des fonctionnalités est un choix plutôt raisonnable. En effet, l’entreprise préfère tenir son planning en terme de date et fournir des fonctionnalités très attendues par la communauté ; au détriment du Cloud qui aurait imposé un décalage de livraison important.
Comme on dit : “mieux vaut tenir que courir”. En espérant qu’il n’y ait pas de nouveaux rebondissements, rendez-vous au quatrième trimestre 2012…

#java #javaEE7 #javaEE8 #annonce #report

septembre 5, 2012 0

C’est la rentrée !

& +Fabien Baligand

Les parasols sont rangés, les bouées dégonflées, les souvenirs photographiés…
La rentrée s’annonce pour tout le monde, c’est avec plaisir et toujours plus de motivation que nous reprenons les publications sur cette page.

Nous gardons le rythme d’un article par jour du lundi au jeudi sur Java & son écosystème : news, présentation de librairies sympa, articles techniques, annonces de releases, annonces de conférences, …

Pour suivre les publications de la page, vous pouvez intégrer le flux google+ dans votre reader RSS favori via l’url suivante :
http://gplus-to-rss.appspot.com/rss/112440333946538821016

Les statistiques de la page sont toujours disponible ici :
http://gplusstats.fsznajderman.fr

Enfin si vous souhaitez faire connaître cette page, voici une url plus facile à retenir que l’id de la page Google+ :
http://gplus.to/javafr

Nous espérons vous retrouver nombreux sur la page, n’hésitez pas à partager vos impressions sur les publications à venir.

#java #reprise

septembre 3, 2012 0