Le weblogue de SeB

Même si je ne suis pas un habitué des podcasts, je vous avais déjà présenté Les Cast Codeurs. Comme le titre de ce billet le laisse deviner, aujourd’hui je souhaite pour informer qu’un podcast dédié à Android ainsi qu’à sa communauté francophone existe depuis quelques mois. Ce petit nouveau se nomme l’Android Devcast.

C’est encore très très jeune mais on ne peut que saluer l’initiative et leur souhaiter une longue existence !

Mardi dernier, j’ai assisté lors de la session du NormandyJUG à la présentation d’Olivier Croisier sur les annotations. Autant le dire tout de suite : je ne suis pas fan des annotations. J’ai beaucoup de mal avec cette mode de mettre des éléments de configuration dans du code source. On nous rabâche depuis des années que le code source doit être réutilisable et donc générique. Or que depuis l’apparition des annotations, je vois beaucoup de code contenant du paramétrage. On se retrouve donc avec des binaires liés à un environnement.

Néanmoins, c’est sans apriori que je me suis rendu à cette session. Espérant, apprendre quelque chose et peut-être changer d’avis.

Introduction

En regardant en arrière, on se rend compte qu’XDoclet est l’ancêtre des annotations. Ce système utilisait déjà une méthode de paramétrage et/ou injection/génération de code à partir d’”@” dans la JavaDoc. Cette implémentation avait deux défauts :

• tout n’est pas documentable dans le langage Java
• la documentation disparait à la compilation

Voilà pourquoi la création des annotation était nécessaire.

Afin d’assurer une compatibilité du byte code avec le Java <=4, l’implémentation des annotations réutilise les concepts existants dans la langage d’une façon parfois déroutante…

Annotations personnalisées

Pourquoi ?

• remplacer les fichiers de configuration
• simplifier le code avec la meta-programmation
• ajouter des règles de compilation

Caractéristiques

• un champ d’action
• une durée de vie (source, compilation, exécution)

La compilation

Les annotations permettent de réaliser un plugin pour le compilateur (Java >=6) via les Pluggable Annotation Processor. Ceci permet entre autre de casser le build. Ce qui peut de révéler très pratique pour faire respecter des best pratices de développement.

Pourquoi ?

• La génération de ressources
• La configuration
• Les classes
• La documentation
• L’amélioration du compilateur
• Norme de codage
• Message d’erreur

A ce stade de la présentation, Olivier met en garde l’utilisation de certain framework tel de Lombok qui a quelques contraintes tel que la dépendance de la compilation. En effet, votre compilateur doit être supporté par le projet. Comme toujours, c’est à vous d’estimer le ratio entre risques et avantages.

Comment ?

Ces annotations sont implémentées via AbstractProcessor. Une API permet de faire de l’introspection et découvrir dynamiquement les annotations. Nous avons le droit à une petite démo avec le  SerializableClassesProcessor.

Le runtime

Pourquoi ?

• Le mapping
• Les POJO
• La configuration et/ou les frameworks

Notre intervenant nous illustre cela avec un CSVReader.

Aller plus loin…

Pour nous montrer ce qu’il est possible de faire avec les annotations, notre invité nous présente alors son proof of concept d’injection d’annotations : AnnotationInjector. Il nous avoue que c’est un framework assez sympa à réaliser mais qu’il n’a pas encore trouvé son utilité !

La conclusion

Une session très enrichissante qui ma réconcilié avec les annotations ! J’éviterai toujours les éléments de configuration dans le code (surtout s’il est lié à un environnement tel que développement, recette ou production). Néanmoins, j’ai déjà testé les Annotations Processor. Et les sembles prometteuses.

La session se termine par une présentation de seren. Cet outil, réalisé par Olivier Crosier, a pour objectif d’optimiser les temps de traitement de la sérialisation et de désérialisation.

Si ce compte-rendu vous a donné envie de vous mettre aux annotations, sachez que la présentation et le code source est disponible sur GitHub.

Après plus d’un an et demi de pause forcée, j’ai pu enfin retourner au NormandyJUG !

Cette soirée était consacrée à un seul et unique thème :  l’accès aux données face à la montée en charge. La session était animée par Julien Dubois qui est entre autre l’auteur de Spring par la pratique. Le sujet ou l’intervenant devaient intéresser puisque nous étions une 50aine.

En partant du principe que la scalabilité d’une application Java est limitée par la base de données, la présentation consistait à évaluer les solutions disponibles. En effet, avec le Cloud Computing, il est “facile” d’ajouter des machines pour assurer la montée en charge d’une application mais le point de contention reste le serveur de base de données. Avant d’aller plus loin, il faut rappeler le théorème de CAP qui indique qu’il est impossible de répondre à ces trois contraintes en même temps :

• Cohérent (Consistent)
• Disponible (Available)
• Tolérant aux pannes réseaux (Partition tolerant)

Le serveur de base de données

Hibernate et le cache

NoSQL

Il existe de nombreuses solutions NoSQL mais ici nous avons vu Cassandra qui serait le plus performant en écriture. En gros, c’est un cluster de données sans maître où chaque données est répliquée sur au moins 3 noeuds. Lorsque l’on interroge un noeud, il répond tout de suite avec les informations dont il dispose. Puis va chercher à se mettre à jour (d’où le à terme sera cohérent). En écriture, la gestion des conflits se fait via une date cliente. C’est donc le dernier arrivé qui l’emporte !

Parfois, le Java peut nous rendre quelque peu perplexe. Prenons par exemple le code suivant :

String s[] = {"1","2","3","4"};
List<String> l = Arrays.asList(s);
l.remove("1");

Ces lignes de code Java semblent correctes. Pourtant, à l’exécution, elles vont lever l’exception suivante :

java.lang.UnsupportedOperationException
java.util.AbstractList.remove(Unknown Source)
java.util.AbstractList$Itr.remove(Unknown Source)
java.util.AbstractCollection.remove(Unknown Source)

Mais pourquoi la classe List propose une méthode remove() qui n’est pas supportée ? Rappelons que List est une interface. En fait, la faute revient à la méthode Arrays.asList() qui retourne une liste liée à un tableau et donc non modifiable. Si vous voulez modifier une liste créée à partir de cette méthode, il faut utiliser le code suivant :

List<String> l = new ArrayList<String>(Arrays.asList(s));

La liste obtenue est modifiable. Vous pouvez y ajouter ou y enlever des éléments sans risquer une exception.

JAXB permet de générer des classes Java à partir de XSD pour manipuler du XML plus facilement. En clair, il permet de générer un parseur et un générateur de flux XML en Java. Ce qui fait gagner énormément de temps en développement.

En revanche, par défaut, le parseur JAXB n’ignore pas les espaces inutiles (appelés whitespaces). Pas de panique, l’API JAXB permet de le faire assez simplement. Il faut seulement créer un filtre et l’appliquer lors de la lecture du flux XML.

Le code du filtre ressemble à ceci :

public class WhitespaceFilter implements EventFilter {
	public boolean accept(XMLEvent event) {
		return !(event.isCharacters() && ((Characters)event).isWhiteSpace());
	}
}

Ensuite, pour l’appliquer il suffit d’instancier votre parseur de cette façon :

	JAXBContext jc = JAXBContext.newInstance("mon.package");

	// instancie le parseur XML pour ignorer les espaces inutiles
	XMLInputFactory inputFactory = XMLInputFactory.newInstance();
	XMLEventReader eventReader = inputFactory.createXMLEventReader(new FileInputStream("/monrepertoire/monfichier.xml"));
	eventReader = inputFactory.createFilteredReader(eventReader, new WhitespaceFilter());

	// parse le fichier XML
	Unmarshaller u = jc.createUnmarshaller();
	grid = (PCCADGRID)u.unmarshal(eventReader);

Cet exemple supprimer les espaces inutiles entre les balises XML. En revanche, les espaces inutiles sont toujours présents dans les valeurs. Pour supprimer ces derniers, il faut mettre en place un adaptateur. Voici son code :

public class NormalizedStringAdapter extends XmlAdapter {
	public String marshal(String text) {
		return text.trim();
	}

	public String unmarshal(String v) throws Exception {
		return v.trim();
	}
}

Il y a trois méthodes pour l’appliquer. Soit lors de l’initialisation du parseur :

Unmarshaller u = jc.createUnmarshaller();
u.setAdapter(new NormalizedStringAdapter());

Soit avec une annotation sur les champs concernés :

@XmlElement(required=true)
@XmlJavaTypeAdapter(NormalizedStringAdapter.class)
String name;

Soit avec une annotation dans les classes package-info pour l’appliquer à tous les champs du type chaine de caractère :

@javax.xml.bind.annotation.adapters.XmlJavaTypeAdapter(value=NormalizedStringAdapter.class,type=String.class)
package mon.package;

Une fois cet adaptateur mis en place, les données XML que vous chargerez ne seront plus polluées par des espaces, retours à la ligne, tabulations, etc…

Notez qu’il existe également un adapteur qui permet de compacter les espaces. Comme ci-dessus, il supprime les espaces en début et fin de chaine mais réduit les multiples occurrences d’espace à un seul espace. Si vous le cherchez, c’est : javax.xml.bind.annotation.adapters.CollapsedStringAdapter.

Ma bonne résolution du précédent compte-rendu du JUG n’a pas tenu longtemps puisque j’ai attendu un mois pour faire le compte-rendu du JUG.

J’ai titré un “air de déjà vu” car ça faisait longtemps qu’une réunion n’avait pas autant débordée dans le temps. Ça doit remonter à la première réunion.

Lors de cette soirée, un seul et unique thème a été présenté par Dimitri Baeli et Nicolas Giard. Ils nous ont présenté Scrum, une méthode agile pour la gestion de projet. Au début de la présentation, quatre cobayes sont choisis pour réaliser une mise en pratique.

L’esprit agile

La méthode Scrum est venue d’un constat : il y a trop d’échec en développement.  De plus, le besoin évolue sur un projet d’un an ou plus. Afin de contrer ces effets, quatre valeurs ont été définies :

• Interaction avec les personnes != process, outils
• Produit opérationnel != documentations
• Collaboration avec le client != négociation de contrat
• Réactivité face au changement != suivi d’un plan

Scrum en cinq minutes (ou plus)

• Une méthode agile
• Un logiciel qui fonctionne à chaque sprint
• Le métier défini les priorités : l’équipe s’organise elle-même
• A la fin d’un sprint, tout le monde regarde le produit et dit s’il faut réitérer

Les rôles

• Product owner : représentant du client
• Scrum master : représentant le management du projet (un facilitateur)
• L’équipe : cinq à dix personnes ayant tous les rôles qui ne change pas pendant un sprint

Meetings

• Planification de sprint
• Scrum quotidien
• Revue de sprint
• Rétrospective

Artefacts

• Product backlog
• Sprint backlog
• Burndown chart

Cette méthode est intéressante. Elle met l’accent sur le besoin client. En revanche, la notion de planning ou de budget est complétement occultée. Ma remarque est peut-être provocatrice mais pas totalement sans fondement car cette approche doit être difficile à faire accepter au management ou au client :

• Comment donner une vision sur l’occupation des charges quand il n’y a pas de planning ?
• Comment le client peut-il savoir si son budget correspond à son besoin et s’il sera maitrisé ?

Il a y énormément de chose à dire sur le sujet. J’espère au moins avoir titillé votre curiosité.

lire la suite…

Cette fois ci je m’y suis pris assez tôt pour vous faire un compte-rendu de la réunion du mois de janvier du NormandyJUG.

Le changement d’année s’est accompagné d’un changement de décors puisque cette réunion a eu lieu à l’UFR Sciences et Techniques du Madrillet. Cette soirée avait de quoi plaire avec le thème Java EE 6 et Glassfish. Initialement, la réunion devait s’organiser ainsi :

• Les nouveautés de Java EE 6 par Antonio Goncalves
• Glassfish v3 première implémentation Java EE 6 par Alexis Moussine-Pouchkine

Au final, il s’est avéré que les deux présentations ont fusionnées et nos deux intervenants ont alterné les présentations des nouveautés de Java EE 6 au travers d’une quinzaine de démonstrations qui tournaient sur Glassfish.
Pour ceux qui ont raté l’événement, Java EE 6 est sorti le 10 décembre 2009 et regroupe actuellement 28 spécifications. Cette nouvelle version apporte sont lot de nouveautés qui raviront de nombreux développeurs parmi les suivantes :

• Le prunning indique qu’une spécification peut disparaitre dans une prochaine version de Java EE.
• Les profiles définissent des sous-ensembles ou sur-ensembles de JEE (un peu comme le fait JME). Aujourd’hui, il existe le profile Web Profile.
• Les EJB Lite.
• La normalisation du nommage JNDI.
• Tout est Managed Bean. Avec Managed Bean 1.0 n’importe quel objet est une sorte de POJO EE qui autorise des concepts fondamentaux : cycle de vie, injection et intercepteurs.
• La mise à jour majeure de JPA 2.0 apporte des améliorations essentielles :
  • Mapping de liste de type simple
  • Embeddable récursif
  • Amélioration de la gestion des Maps
  • Enrichissement du JPQL
  • Normalisation du persistence.xml
  • Lock pessimiste
  • Une criteria API (enfin !)
  • Cache
  • Etc…
• Servlet 3.0 n’apporte pas grand chose de nouveau :
  • Annotations
  • Extensions via des fragments ou une API
  • API de configuration
  • FileUpload
  • Support de la sécurité
• Quelques nouveautés intéressantes dans EJB 3.1 :
  • Intercepteurs configurable comme ça se fait en AOP
  • Interface optionnelle pour les EJBs locaux
  • EJBs asynchrones
  • Paquetage dans un WAR possible pour EJB Lite
  • Un nouveau Timer Service qui reprend les bonnes idées de cron
  • EJB Singleton
  • Une container API pour disposer d’un conteneur embarqué
• JSF 2.0 :
  • Utilisation des facelets
  • Pas de dépendance avec Servlet 3.0
  • Les fichiers de configurations deviennent optionnels
  • Composants et composants composites
  • Amélioration des traces d’erreur
  • Standardisation de l’Ajax via le JavaScript et les tags
  • Bean Validation
  • Template
• Bean Validation 1.0 permet d’écrire des règles métier une seule fois et de les utilise partout (couche JPA et JSF aujourd’hui). Des règles simples sont pré-définies mais il est possible de créer ses propres règles personnalisées.
• REST n’a pas été oublié avec JAX-RS 1.1. Tout se fait simplement avec des annotations (comme les web services) : support des mimes types, paramètres, EJB, …
• Le CDI/DI permet de réaliser un couplage lâche avec un typage fort. Cette spécification définie également la notion de porté en introduisant une nouvelle : la conversation. Cette dernière permet de résoudre la problématique de scénario concurrent sur une interface web (ie pour une utilisation multi-fenêtre ou multi-onglet).

Même si je ne suis pas un très grand fan des annotations, je dois avouer que cette nouvelle version de Java EE est très séduisante et donne envie de passer le plus rapidement possible sur un serveur d’application implémentant Java EE 6.

J’ai essayé d’être le plus concis possible mais il y a tellement de chose qui ont été présentées… J’espère vous avoir donné également envie d’utiliser Java EE 6. Je tiens enfin à saluer Antonio et Alexis pour leur bonne humeur et la qualité de leur prestation !

lire la suite…

Je vais arrêter de m’excuser pour le retard… Je souhaite juste vous faire un retour rapide sur la réunion du mois de décembre du NormandyJUG.

Cette réunion a eu lieu comme lors de la précédente réunion à l’eXia/CESI. C’était une soirée assez variée puisque trois thèmes bien différents ont été abordés :

• Découverte d’Android par Nicolas Giard
• GWT 2.0 par Youen Chéné
• JSF par Gontran Tombette

La présentation d’Android était faite pour les personnes qui ne connaissaient pas la plate-forme Android. Un état de l’art des différents smartphones a été fait. Puis l’environnement de développement a été décrit dans ses grandes lignes.

La seconde partie avait pour titre : “GWT avancé“. Malgré qu’il était mal en point, Youen a tenu à présenter la nouvelle version de GWT. Je vous passe le nouveau Development mode et l’UiBinder pour vous expliquer un peu la raison d’être de GWT 2.0 : l’optimisation des temps de chargement. En effet, une application GWT devient très vite très grosse. Or, toute l’application est chargée dès la première page. Ce qui peut alors prendre un certain temps. La communauté a demandé de trouver une solution à ce problème. Et Google a proposé une solution : le code splitting. Afin de pouvoir découper le code d’une application en plusieurs morceaux, il faut procéder à un découplage du code. C’est pourquoi l’Event Bus a été ajouté est recommandé dans GWT 2. Alors que nous avons l’habitude d’utiliser le modèle de conception MVC, l’Event Bus permet de mettre en place le modèle de conception : le MPV. Ce modèle donne les bonnes pratiques pour réaliser un couplage faible et donc de réduire les dépendances entre les composants.

Enfin, la dernière partie était une très bonne présentation de ce qu’est et permet de faire JSF. Je peux même dire que cette présentation de JSF 2.0 m’a presque réconcilié avec JSF. Je m’étais arrêté à la version 1.2 assez rapidement par déception. Je pense tout de même que ce framework reste à destination d’applications de type back-office.

Cette nouvelle réunion du NormandyJUG est passée à deux doigts de se transformer en réunion Google… Heureusement que JSF était là pour rattraper le coup !

lire la suite…

Je viens d’installer Eclipse 3.5, plus connu sous le nom de Galileo, et le plugin m2eclipse permettant de gérer des projets Maven. Lors de la création d’un nouveau projet Maven, il m’était impossible de sélectionner un archétype car la liste “Nexus Indexer” était vide.

Heureusement, il existe une solution à ce problème. Allez dans le menu “Window” et cliquez sur “Show view > Other…”. Ensuite sélectionnez “Maven > Maven Indexes” et cliquez sur “OK”. Une nouvelle vue “Maven Indexes” s’affiche. Elle doit alors contenir deux dépôts : workspace et local. Faites un click-droit sur cette vue et cliquez sur “Add Index”. Mettez la valeur http://repo1.maven.org/maven2/ pour le champ “Repository URL” et central pour “Display name (optional)”. Enfin, cliquez sur “OK”. Eclipse va alors lancer le traitement “Updating indexes”. Une fois ce traitement terminé, vous pourrez créer un nouveau projet Maven et sélectionner un archétype puisque la liste “Nexus Indexer” ne sera plus vide.

Vous pouvez continuer à vous amuser avec Maven sur Eclipse !

C’est avec un énorme retard que je voulais vous présenter la troisième réunion du NormandyJUG qui a eu lieu au mois d’octobre. :-/

Cette réunion a eu lieu dans un nouvel endroit. En effet, l’eXia/CESI nous a accueilli au sein de leurs locaux. Cette soirée proposait un unique programme : les outils de construction. Trois outils étaient présentés lors de cette session :

• Maven par Arnaud Héritier
• Ivy par Xavier Hanin (initialement mais il s’est excusé)
• Easy Ant par Jean Louis Boudart
• Gradle par Grégory Boissinot

Que faut-il retenir de ce comparatif ?

“Le produit du code source (ici il faut entendre les binaires) est tout aussi important que le code source lui-même !”

Maven reste sûrement l’outil le plus mature et le plus complet. Le projet a su tirer partie des erreurs faites lors de sa première version. De plus, la communauté des utilisateurs étant plutôt conséquente, le retour d’expérience est non négligeable.

Easy Ant propose une solution entre Ant et Maven. Il permet de faire à peu près la même chose que Maven mais avec la souplesse de Ant. Effectivement, Maven imposse un cadre qui peut parfois être frustrant. Cependant, c’est aussi sa force. Je pense que Easy Ant est plus à destination des tous petits projets car plus rapide et moins lourd à mettre en place.

Quant à Gradle, il est a réserver pour le moment pour les expérimentations. En effet, il n’est pas encore mature. Il a pour objectif de réunir les bonnes pratiques de construction à la Maven et la gestion de dépendance à la Ivy. L’un de ses avantages est de pouvoir être utilisé en tant qu’application autonome (contrairement à Maven).

Tout ça pour dire que c’est à vous de faire votre marché parmi ces outils. Je pense que Maven est un cran au dessus à partir du moment où l’on est près à accepter ses contraintes et l’investissement pour sa mise en place.