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.

Tu n’utiliseras pas null

La première règle est simple : ne jamais utiliser le mot clé null.

Globalement, il est utilisé dans deux cas :

• initialisation d’objets
• valeur vide

Par exemple, au lieu d’écrire :

String maVariable = null;

if(test == 0) {
  maVariable = "toto";
} else if(test > 0) {
  maVariable = "titi";
} else {
  maVariable = "tata";
}

maVariable.subString(….)

On peut tout simplement ne pas initialiser la variable maVariable. De cette façon, si on oublie un cas dans notre if, le compilateur va nous générer une erreur du type :

variable maVariable might not have been initialized

Pour les valeurs vides, le problème est plus complexe. Nous verrons donc par la suite comme remplacer un null qui fait office de valeur vide.

Tu utiliseras @NotNull, @Nullable

La JSR 308 nous apporte deux annotations @NotNull et @Nullable qui permettent une vérification statique par le compilateur des valeurs des paramètres et de retour des méthodes. Par exemple :

int maMethode(@NotNull String maChaine) {
  return maChaine.length();
}

maMethode(null);

Dans ce cas on aurait eu une NullPointerException au lancement, alors qu’avec cette annotation on aura un warning directement à la compilation.

Bien évidement, mon exemple est simpliste mais cela fonctionne aussi sur des cas plus complexes.

Cette JSR peut être intégrée à plusieurs outils (Maven, Eclipse, etc.), pour plus de détails c’est ici. Il faut noter qu’IntelliJ l’intègre nativement.

Tu utiliseras des objets vides

Une autre façon d’éviter le null est d’utiliser le Null Object Pattern. Le principe est très simple : créer des objets spécifiques qui représente le vide. Par exemple :

class Personne {
  public String getNom() { … }
  public void setNom(String nom) { … }
  public List<Personne> getEnfants() { … }
}

public final PersonneVide extends Personne {
  public String getNom() {
    return "";
  }
  public void setNom(String nom) {}
  public List<Personne> getEnfants() {
    return Collections.emptyList();
  }
}

Il suffit d’employer PersonneVide plutôt que d’utiliser null. Il y a plusieurs implémentations de cette solution. On peut aussi créer une interface Personne et l’implémenter en deux classe : PersonnePhysique (la vraie implémentation) et PersonneVide.

On peut aussi facilement étendre ce principe pour avoir d’autres objets plus spécifiques, comme le montre Martin Fowler.

Cette méthode a des nombreuses limitations. Il faut se contraindre à créer et surtout à utiliser ses objets vides. Ce qui rajoute du code et donc peut rajouter des bugs. À ma connaissance il n’existe pas de méthode automatique qui nous force à utiliser cette méthode.

Tu lanceras des exceptions

Une autre solution est d’utiliser des exceptions. Plutôt que de renvoyer une valeur null, on lance une exception. Cela à l’avantage d’avoir une validation statique faite par le compilateur. Pour plus de détail sur les bonnes pratiques sur la gestion des exceptions, c’est ici. Par exemple :

class ImpossibleDeGenererIDException extends Exception { … }

public class Personne {
  public Email genereID() throws ImpossibleDeGenererIDException {
    //On lance l'exception si on n'a pas pu générer d'ID
    //plutôt que de renvoyer null
  }
}

Il faut noter que lancer une exception est très coûteux en terme de calcul. Et comme le dis très bien l’article citer ci-dessus, utiliser une exception pour un contrôle de flux est un anti-pattern. À mon avis, cette solution n’est pas à utiliser.

Tu utiliseras le pattern Option/Maybe

Ce pattern nous vient des langages fonctionnels. Il consiste en un objet particulier Option qui encapsule un résultat. Cet objet peut avoir 2 valeurs possibles : une valeur non nulle (Some) ou None. Prenons un exemple de l’API de Java. La méthode get de MyMap renvoie null si l’objet demandé n’est pas présent dans celle-ci. Avec ce pattern, la méthode renverrait une instance d’Option. C’est donc l’utilisateur de la méthode est forcé par le compilateur de gérer le cas None. Une implémentation naïve serait donc :

interface Option<T> {
  public Boolean isNone();
}

class Some<T> implements Option<T> {
  public T get() { … }
  public Boolean isNone() { return false; }
}

class None<T> implements Option<T> {
  public Boolean isNone() { return true; }
}

class MyMap<K, V> {
  public Option<V> get(K key) { … }
}

MyMap<Integer, String> map = new MyMap<Integer, String>();
map.put(1, "un");

Option<String> result = map.get(2);
if(result.isNone()) {
  // Gestion du cas None
} else {
  String val = ((Some) result).get();
}

Cette méthode a le gros avantage d’avoir une validation statique par le compilateur. En effet, il est impossible d’utiliser directement la valeur de retour de la méthode get. Elle est du type Option<String> et donc complètement différent que celui attendu « classiquement » : String. On est donc forcé de faire le test du None. De plus, cela nous donne tout de suite l’information que la méthode peut renvoyer une valeur vide.

Cette implémentation est clairement bancale, la bibliothèque Functional Java en fournit une plus complète.

C’est à mon avis la méthode la plus sûre. Mais elle a été pensée pour les langages gérant le pattern matching comme Scala ou Haskell, où elle est intégrée nativement dans l’API.

Elle est donc un peu lourde à utiliser en Java. Et surtout, elle n’est pas intégrée à l’API. Il faut donc soit utiliser une autre API, ou faire des wrapper autour de l’API standard.

Conclusion

Ces méthodes sont adaptables à tous les langages orientés objets. Certains offrent d’autres méthodes. Par exemple en Groovy il y a l’Elvis Operator, en Ruby (avec Rails) le try.

Le problème reste lors de l’utilisation de bibliothèques externes. Même si un projet utilise ces solutions, il faudra toujours faire attention lors de l’utilisation de l’API Java ou autre (Hibernate pour ne citer que lui).

Il n’y a donc pas de méthode magique pour ne plus avoir de NullPointerException dans votre code Java (à part changer de langage ;)).

Suggestion d'articles :

1. Parallélisation, distribution partie 3 : comment tirer parti des processeurs multi-coeurs à travers l’API de concurrence de Java 7 ?
2. Les nouveautés du langage dans Java 7
3. Un DSL SQL pour Java

Groovy / Grails est une bouffée d’air frais pour le programmeur Java, vous permettant d’écrire du code plus expressif et plus lisible, sans les lourdeurs de Java ou de JEE. Groovy vous simplifie également la vie en vous épargnant les écueils classiques du programmeur débutant ou distrait (BigDecimal, equals(), etc…). Ce n’est pas pour autant suffisant pour s’assurer de la qualité du code délivré et il vous faudra là aussi un ensemble de pratiques pour garder un code maintenable malgré les ajouts et évolutions.

Une de ces pratiques est l’analyse statique de votre code source via des métriques et des règles, et la surveillance de leur évolution d’une version sur l’autre, ou de manière plus ciblée pour une version particulière. Dans ce domaine le programmeur Java est sans aucun doute l’un des mieux outillés, avec des outils comme PMD, FindBugs, CheckStyle, XDepend, Sonar etc… Qu’en est-il en Groovy / Grails ?

L’article complet, en anglais uniquement, aborde les points suivants :

• les outils disponibles en Groovy, à savoir GMetrics, CodeNarc, Sonar
• la pertinence des autres outils Java sur du code Groovy, par exemple PMD, FindBugs, CheckStyle ou XDepend
• la spécificité des langages dynamiques et l’importance des tests et d’une métrique comme la couverture de tests
• comment mettre en place la solution retenue sur votre projet Grails : Sonar, plus précisément le plugin Groovy pour Sonar
• une ouverture sur l’impact d’un IDE sur la qualité du code et les possibilités d’analyse d’IntelliJ via les « inspections »

En guise de teaser, voici un exemple de tableau de bord Sonar sur un projet Grails :

Suggestion d'articles :

1. Paris JUG : Groovy et Grails
2. Transactions et traitement métier en Grails
3. Retour sur le JUG de Lausanne sur l’analyse de la qualité du code Java

Guillaume Laforge, Responsable Développement Groovy, présentera Domain-Specific Languages par la pratique les 1er et 2 juillet prochains à l’Université du SI.

Voici 3 questions pour en savoir plus sur le contenu de sa session.

• Pourquoi participer à l’USI ?

Pour moi, il manquait clairement un événement IT de taille en France. L’USI vient combler ce vide, avec des speakers connus, du contenu de qualité, et plus encore.
C’est une conférence qui rassemble des gens aux profils variés (aussi bien techos que manager) pour parler ensemble de sujets centrés autour de nos SI, de notre métier d’informaticien, d’architecture, de technologie, de méthodos, d’évolution de l’informatique, etc.
L’USI, c’est vraiment là où il faut être si l’on veut rester au fait des tendances de notre métier.

• De quoi va parler ta session USI ?

Je vais vous parler de langages métier et de comment concrètement en créer avec Groovy (http://groovy.codehaus.org)
Je gère depuis plusieurs années le projet Groovy, qui est un langage dynamique pour la machine virtuelle Java.
Groovy permet de créer ses propres langages dérivés pour exprimer des règles métier.
Et je profite de l’USI pour m’adresser aussi bien aux geeks qu’aux boss, pour leur montrer ce que peuvent apporter les Domain-Specific Languages en Groovy dans leurs applications.

• Sinon, quoi de neuf dans la sphère Groovy ?

Depuis le rachat de ma société G2One par SpringSource , on n’a pas chaumé, et on a sorti deux versions majeures de Groovy et Grails : respectivement Groovy 1.6 et Grails 1.1. Plus de performance, plus de fonctionnalités pour simplifier la vie des développeurs Java. J’organise également une conférence, GR8Conf au Danemark, en mai, et ce sera l’occasion d’approfondir toutes les technologies apparentées à Groovy, comme Grails et Griffon.
J’espère vous y voir nombreux !

Video de présentation de la session

Cliquez ici pour suivre l’actualité USI 2009

Suggestion d'articles :

1. Paris JUG : Groovy et Grails
2. Retours sur le JavaCampParis II
3. OCTO à la conférence Grails eXchange 2007

Dans un article précédent, Yannick prônait l’innovation durable illustrée dans le secteur des Télécom, auquel un commentateur zélé répondait qu’icelle « n’est pas une question de technologie, ni d’architecture de SI », invoquant même le directeur marketing de Coca-Cola (lire).

Je suis assez tenté de rejoindre votre position, cher commentateur. D’autant plus que, chez OCTO, l’innovation que je vais vous présenter a démarré bien loin de l’IT.

OCTO, nombre de lecteurs l’auront évidemment compris, est fervent partisan de l’intégration des méthodes Lean dans le SI. Le kaizen (amélioration continue), issu des pratiques industrielles de Toyota, reste un maître mot dans l’accompagnement de nos clients.

Pour tordre le cou au droit proverbial des cordonniers à être mal chaussés, j’avais décidé de mettre en place cette pratique en interne. L’innovation proposée devait amener de la valeur à un public ciblé, sans bousculer les habitudes de travail, avec un investissement initial restreint.

Le sujet était tout trouvé : améliorer la communication commerciale essentielle vers les consultant(e)s. En effet, tous étaient et sont toujours susceptibles d’être intéressés par les propositions commerciales en cours, celles (brillamment !) gagnées et celles (étonnamment !) perdues et ce, au fil de l’eau.

Allais-je lancer une expression des besoins puis une recette auprès de key users habilement sélectionnés ? Allais-je me ruer tête baissée vers une extraction journalière des données de notre ERP pour une diffusion par mail aux abonnés ?  Allais-je tout simplement me lancer dans la technologie pour innover ? Le suspense est insoutenable, vous le sentez aussi.

Pour tester et démontrer la valeur de mon innovation, j’ai plutôt choisi de prototyper éco : économique et écologique.

• Un tableau en liège grand format installé dans la cafét’ (en face du baby-foot)

• Des post-it de couleurs variées (les couleurs illustreront les secteurs de nos clients sur lesquels est structurée notre organisation)

• Des punaises de qualité irréprochable

• Et… c’est malheureusement tout : je sais, c’est cruel pour les technophiles technocentriques

Le tableau est divisé en trois sections : en cours, gagnées, perdues. Sur les posts-it, le nom du client et l’intitulé de la mission gribouillés au marqueur. La purge est mensuelle.

Mon objectif : susciter l’adhésion des  gestionnaires commerciaux (écrire un post-it à la pause café ne coûte pas), obtenir un feedback de TOUS les utilisateurs sans les assaillir (pendant qu’on discute autour d’un café, on peut commenter les missions affichées) et initier le changement sans rupture (l’information pertinente est accessible sans efforts).

Le projet a été plébiscité, et depuis plus de six mois désormais, le tableau est régulièrement mis à jour et a subi quelques modifications suggérées par les utilisateurs.

Passer à la technologie était l’étape complémentaire : quelques modifications de code dans notre ERP maison, l’ajout d’un feed RSS sur les missions et le tour était joué. Modifier le code était relativement aisé puisque notre logiciel (basé sur le framework Grails) était balisé par un harnais de tests automatisés (*). Implémenter un flux RSS était redoutablement facile, mais vous devez achever la lecture de ce billet pour comprendre pourquoi : c’est visiblement l’article de tous les suspenses.

Alors, innover sans technologie c’est non seulement possible mais c’est indispensable lorsque le contexte s’y prête :

• Les utilisateurs ne sont pas bousculés, au contraire ils sont tacitement incités à participer à l’élaboration du projet par des suggestions immédiates ou du fait de la facilité à modifier soi-même (changer la disposition ou la couleur des posts-it),
• L’investissement initial est marginal (chez OCTO, on peut encore se servir de posts-it sans remplir cinq formulaires) et autorise l’échec,
• Toutes les castes sont impliquées et valorisées d’emblée : les directeurs, les commerciaux, les consultants, les stagiaires : tous transitent une fois par jour au moins à la salle café (au moins trois fois par jour pour les stagiaires) et constatent l’épanouissement du business de notre société.

La partie technique

Les articles informatiques, c’est comme les bons yaourts aux fruits : c’est toujours meilleur avec des morceaux dedans.

La plateforme Grails qu’on ne présente plus possède un plug-in spécifique : Feeds. Grâce à l’expressivité intrinsèque de Groovy et à l’implémentation masquée des mécaniques de flux (RSS/ATOM), ce plug-in a permis de développer la version technologique du tableau de la salle café en deux heures à peine, tests inclus évidemment.

L’innovation avec Grails est un sujet passionnant, qui sera de nouveau abordé dans une session de l’Université du SI les 1 et 2 juillet prochain. Décidément, le suspense se poursuit…

Extrait du code de génération du flux RSS à partir du plug-in Grails « Feeds ».

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

render(feedType:'rss', feedVersion:'2.0') {
title = "Les propositions commerciales OCTO"
description = "La mise à jour régulière propositions commerciales d’OCTO"
link = url + "/wS/feedMissions"
 
// méthode du Core Domain pour récupérer les dernières modifications
// sur les missions. La variable period fournie par l’utilisateur permet de
// remonter les modifications chaque jour (défaut) ou chaque semaine.
def l = Project.listRecent(period, new Date())
 
l.each { pr ->
  // On filtre sur les projets facturés
  if (pr.isBilledProject()) {
    def client = "client non renseigné"
    def sector = "secteur inconnu"
 
    if (pr.client) {
      client = pr.client.name
      sector = pr.client.sector.name
    }
 
    // projectStatus.name renseigne sur l’état de la mission :
    // avant-vente, signée, annulée, perdue…
    def title = pr.projectStatus.name.toUpperCase() + " : " + client + " (" + sector + ")"
    def ref = pr.getReferenceAndName()
    def am = pr.accountManager ? pr.accountManager.trigram : "N/A"
    def invoice = pr.invoicingType.description
    def amount = pr.totalAmount() ? String.format('% 6.2f', pr.totalAmount()) + " euros"
                                  : 'N/A'
 
    // Définition d’une entrée RSS
    entry(title) {
      publishedDate = new Date()
      link = url + "/project/edit/" + pr.id
 
      // cette méthode met en forme les informations
      // sous forme linéaire ou tabulaire, selon le choix utilisateur
      renderFeed([ref, invoice, amount, am, pr.comment], format)
    }
  }
}

(*) Hmm… Ce n’est pas entièrement vrai, à croire que l’adage sur les cordonniers a la nuque raide

Suggestion d'articles :

1. La productivité des développements… n’est pas qu’une affaire de technologie !
2. Scrum sans itérations ?

Une société dans le monde des médias :

« Deux mois, seulement deux mois pour sortir ces nouvelles fonctionnalités, sinon nous sommes morts ! ». Pour se différencier, il faut innover. Mais l’innovation métier seule ne suffit pas, il faut innover avec une longueur d’avance, être le premier. Le décor est planté.

Pour adresser l’innovation dans un contexte temporel borné, on aura tendance à privilégier des méthodes agiles plutôt que de se lancer dans des longues phases de spécifications fonctionnelles générales, détaillées, qui ne feront qu’ajouter du risque … Passons le peu de temps que l’on a à produire plutôt qu’à tout spécifier en détail.

Les méthodologies agiles permettent d’une part de répondre à ces contraintes de planning très fortes où les dérapages sont impossibles et d’autre part d’avancer sur un périmètre fonctionnel et/ou technique non encore défini ou changeant.

Concrètement, on adoptera une approche itérative et incrémentale

• Itératif : Les phases de développements sont cycliques, régulières et de durée fixe. On parle d’itération. Le périmètre fonctionnel d’une itération est figé.
• Incrémental : Chaque itération délivre une nouvelle version fonctionnelle du logiciel.

Du coté des développements, l’équipe se doit d’être réactive aux orientations de la MOA, c’est-à-dire faire en sorte que le logiciel puisse être facilement adaptable aux évolutions futures ou autre changements de spécification. De cette hypothèse, on va privilégier une conception et une architecture légère : la technique ne doit plus être une contrainte pour faire évoluer le logiciel. C’est là que GRAILS et les tests entrent en jeu…

GRAILS, kesako ?

GRAILS, bien plus qu’un framework est une plateforme JEE complète ayant comme objectif la productivité et la simplification des développements. S’appuyant massivement sur le paradigme  » Convention Over Configuration « , cette approche permet de libérer le développeur de toutes les  » siouxeries  » techniques de configuration, de manipulation des multiples APIs, etc… Précisons que GRAILS n’est pas un autre framework issue du bien connu syndrome  » NIH  » (Not Invented Here), mais une abstraction des frameworks les plus éprouvés du monde JEE à savoir Spring, Spring MVV, Hibernate, Sitemesh, EhCache, Log4j, etc… ce qui garantit bien évidemment un certain standard.

Cette solution dite  » packagée « , permet d’être très rapidement opérationnel, puisqu’elle vient avec tout ce dont le développeur à besoin pour coder, lancer et tester son application : une base de données embarquée (HSQLDB), un serveur web light (Jetty), des scripts Maven /Ant…
Bref, en quelques minutes les développeurs sont opérationnels et peuvent commencer à travailler sur les premières fonctionnalités.

Récemment racheté et intégré au portefeuille des produits de Spring Source (éditeur de Spring/Spring DM, etc…), les récents téléchargements de la dernière version montrent clairement un engouement prononcé de la communauté… (30 000 téléchargements en février 08. 72 000 téléchargements pour le mois de novembre, soit plus du double).

GRAILS, un bon candidat pour adresser l’innovation métier

La convention apportée par GRAILS alliée à l’expressivité du langage GROOVY permet de se focaliser sur le besoin métier, c’est-à-dire sur les règles de gestion que le développeur devra coder.

• Expressivité: Le code est proche du langage naturel et les termes techniques sont minimisés (dans le cas de groovy, ils se résument à de la simple ponctuation)
• Convention : En respectant l’architecture proposée, les règles de nommage des variables, méthodes, pages jsps, controllers, services, etc … le framework se charge de la technique que nous aurions dû normalement coder. Par exemple : les accès en base, les requetes sql/hql, la configuration des mapping url/controllers et controllers/vues, etc…

Ainsi, pas besoin d’être un expert Hibernate, Spring, etc… pour réaliser les opérations CRUD d’un objet, mais une convention à respecter. Cette approche permet de réduire le temps de développement et ainsi maximiser l’apport de valeur métier. Les démonstrations à la MOA sont plus fréquentes, on obtient un feedback au plus tôt et l’on peut soit valider le besoin soit réajuster le tir si besoin ;-). Ceci est particulièrement appréciable en contexte d’innovation.

Un bémol tout de même; à ce jour (décembre 08), l’intégration dans les IDEs n’est pas aussi étendue qu’avec Java. Ce manque devrait être comblé grâce aux travaux actuels des développeurs de Spring Source.

Des fonctionnalités décrites sous la forme de tests de recette

Pas de cahier des charges, mais une approche TDR (Test Driven Requirements) c’est-à-dire une spécification où les règles de gestion sont écrites sous la forme de tests de recette automatisés. Dans un contexte où le temps est compté, cette approche est particulièrement bien adaptée puisqu’elle présente les avantages suivants :

• La spécification est compréhensible : la règle de gestion est illustrée via un test représenté sous forme tabulaire, comme dans Excel.
• La validation de la spécification est automatique : Le test de recette est automatiquement exécuté sur le code de l’application
• La validation est univoque : Le résultat d’un test est binaire : OK ou KO, pas de discussions possibles

J’ai l’habitude d’utiliser l’outil FitNesse sur mes projets. Gratuit, léger et autonome (il ne requiert aucun système externe), il répond bien dans un premier temps à mes attentes : installation et prise en main rapide.

FitNesse, un outil collaboratif

FitNesse est un wiki, il donne une véritable visibilité au projet. Les spécifications (ou tests ;-) sont accessibles à l’aide d’un navigateur web, ce qui facilite son adoption et rassemble autour de lui les équipes MOA et MOE.

Pour plus d’information sur FitNesse, je vous invite à consulter le site officiel http://fitnesse.org/

Un exemple concret

Une fois le contexte posé, voyons à partir d’un exemple concret comment cela se passe dans la réalité.

Mise en situation. Notre client nous demande d’implémenter la fonctionnalité suivante :

• Réduction sur la vente des albums musicaux à partir de codes promotionnels.

La suite dans le prochain billet, ce qui nous donnera l’occasion de voir l’écriture du test de recette et l’intégration de FitNesse avec GRAILS.

A suivre donc…

Suggestion d'articles :

1. Transactions et traitement métier en Grails
2. Grails Maven Plugin 0.3
3. Paris JUG : Groovy et Grails

Merci à vous !

Bonjour, Merci aux participants d’avoir rendu cet évènement si sympathique ! Merci d’avoir simplement été présents avec votre passion et votre enthousiasme :)

Voici le Cr de la session sur Grails/Groovy :

Langages dynamiques : pourquoi des langages dynamiques comme Ruby, Python et Groovy ont du succès bien que ces langages s’inspirent largement de Smalltalk qui ne trouve pas sa place dans le monde des entreprises. Groovy : Deux propriétés assez attirantes : 1/ le concept de closure, et 2/ la lisibilité du code (langage fonctionnel proche du domaine métier – DSL). Le problème est qu’il n’y a pas, pour le moment, assez d’outillage ce qui rend difficile toute refactorisation. Rails : bien adapté si on souhaite des accès CRUD. Pas assez outillé. Pas de retour sur le « Scaffolding » dans des cas réels. L’exécution et le débogage est souvent fait en mode console. Il n’y a pas eu retour sur le plugin eclipse (non utilisé). Typage faible, fort et dynamique : les concepts différent d’une personne à une autre.. il n’y a pas de support pour refactoriser le code des langages à faible typage comme Ruby par ex. Finalement il y a eu une discussion sur les raisons pour lesquelles une équipe adopte une nouvelle technologie.

Merci à Houssam Fakih pour les notes sur la session Groovy, et merci aux blogueurs pour les retours :

http://www.insideit.fr/post/2008/12/17/JavaCamp-2-compte-rendu

http://www.touilleur-express.fr/2008/12/17/java-barcamp-2-merci-octo/

http://thecodersbreakfast.net/index.php?post/2008/12/17/Java-BarCamp-2-%3A-compte-rendu

http://thecodersbreakfast.net/index.php?post/2008/12/19/Java-BarCamp-2-%3A-compte-rendu-(2/2)

http://boissinot.blogspot.com/2008/12/retour-sur-le-barcamp-2.html

http://www.itaware.eu/2008/12/20/javacamp-ii-db-et-esb/

A bientôt pour la 3 eme édition !

Luc

Suggestion d'articles :

1. Retour sur le BarCamp Java du Mardi 30 Septembre
2. Paris JUG : Groovy et Grails
3. BarCamp Java à Paris le Mardi 16 Décembre

« Devoxx is over! ». Directement depuis le train du retour…

Il est traditionnel que la journée du vendredi (la matinée en fait) ne regroupe jamais les sessions les plus attendues. Cette matinée nous a tout de même amené du contenu fort intéressant.

DM Server : from WAR to Web Module

SpringSource a profité de la matinée pour réaliser une présentation d’une heure sur leur nouvellle plateforme DMServer. DMServer a pour objectifs:

• offrir de la modularité. SpringSource considère les war comme quelque chose de monolitique (notamment car l’ensemble des librairies disponibles sont potentiellement en plusieurs exemplaires dans le répertoire WEB-INF/lib) et souhaite pouvoir partager des services communs à plusieurs applications web entre ces applications web.
• faciliter l’intégration des beans Spring dans OSGI avec notamment la « service registry », l’annuaire de services
• faciliter la gestion des librairies avec le « Bundle Repository », le référentiel de Bundle OSGI. A noter que lorsqu’une application utilise un Bundle OSGI, ce dernier est chargé uniquement « on demand » afin bien entendu de limiter l’empreinte mémoire.

OSGI introduit la notion de Bundle, un jar définissant un MANIFEST qui définit quels packages sont visibles de l’extérieur du Bundle. La limite aux bundles dans le cadre d’une application Web reste le déploiement et l’unité de déploiement (classiquement un WAR ou un EAR). pour répondre à cela, SpringSource définit une nouvelle unité de déploiement : le PAR qu’il faut voir comme un jar définissant un MANIFEST qui contient des headers de type Application-* et qui définit quels sont les Bundle OSGI qu’il peut utiliser…Au delà de la pure problématique de déploiement, le PAR doit aussi permettre de gérer le scope des Beans à l’application…Reste que DMServer accepte de déployer de bon vieux WARs.

Il faut avouer que la session était très « par la pratique » et a consisté à transformer un WAR en PAR/WebModule. Donc du code, de l’IDE…

Step 1: d’un WAR aux librairies partagées

Prenez une application web classique regroupant dans son WEB-INF/lib quelques jars. La première étape consiste à rajouter dans le WAR un MANIFEST OSGI qui spécifie les Bundles que l’application va utiliser ainsi que leurs versions. Par exemple

1
2

Import-Package:javax.servlet:version="2.5"
Import-Library:org.springframework.spring,version"[2.5.0,3.0.0)"

Résultat des courses, le WEB-INF/lib disparait. Vous me direz qu’on savait déjà mettre des jars dans le classpath du serveur. Ce n’est pas faux mais cela ne permet de gérer qu’une seule version des jars.

Step 2: vers des services partagés entre WAR

L’idée est de pouvoir partager des « services » – concrètement des Beans Spring » – qui seraient communs entre différents WAR. Dans ce cas, l’application se repose sur le Service Registry mis à disposition par DMServer.

Pour faire cela, on extrait du war les classes en question (typiquement les classes des packages « services ») puis il faut exposer certains packages au niveau des Bundles réutilisables puis les référencer depuis l’application Web. L’exposition de services/beans est assez simple et ce fait grâce au manifest, à un fichier de configuration spring et un fichier OSGI (et oui, cela se complexifie un peu…).

concernant le manifest donc:

Export-Package:com.octo
Import-Package:org.myossproject

La première ligne de cet extrait de manifest offre la possibilité d’exporter les classes présentes dans le package com.octo. La seconde indique que le Bundle utilise le package org.myossproject. Ce fichier manifest doit (ou peut?) être complété par :

• un fichier META-INF/spring/module-context.xml, un classique fichier Spring qui définit le Bean, son nom logique…
• un fichier META-INF/spring/osgi-context.xml qui précise le bean Spring à exposer – via son nom logique -.

1

<service ref="myService" interface="com.octo.IMyService"/>

Côté WAR et application web, il est nécessaire de modifier le fichier application-context.xml pour référencer le service OSGI

précédemment exposé (vous être toujours là? ;o) ). Le fichier devient donc :

1

<reference id="myService" interface="com.octo.IMyService" />

Personnellement, à ce moment là je tape les limites suivantes:

• trop de configuration XML avec la nécessité de répéter certaines informations comme l’interface. Il y a certainement une bonne raison mais je dois avouer que je ne l’ai pas saisie.
• les projets se démultiplie. Quelques années auparavant, on créait des artifacts (pour Maven notamment et pour gérer les dépendances de compilation) et donc des projets différents. Personnellement, cela ne me dérange pas mais force est de constater que beaucoup trouve cela trop complexe. Donc, la mode est de tout ramener simplement dans un WAR avec des packages « propres ». Et bien là, roll back, le nombre de projet augmente à nouveau.

La session continue avec cet exemple et démontre que l’on peut charger et décharger les bundles de la JVM sans aucun problème. La subtilité vient au moment où on décharge le bundle qui est référencé, utilisé par l’application Web. Tant que cette dernière ne réalise pas d’appels vers les services exposées par ce bundle, tout va bien. Lorsque l’on souhaite utiliser un de ces services, l’application attend jusqu’au timeout…

Là encore je tape une limite. Franchement c’est génial et la démonstration est impressionante mais (ben oui il y a un mais…)

• comment vont faire les équipes d’exploitation pour gérer les bundles utilisés, déployés, non utilisés…certes la console d’administration fournit la liste des bundle et leur version déployées dans le serveur mais est-ce suffisant pour s’assurer qu’après 6 mois d’exploitation, ne seront pas utilisé que 3 des 20 bundles déployés
• peut-on vraiment en production déployer de nouvelles versions des bundles en remplacement des anciennes? Les équipes ont intérêt à être hyper mûres sur les aspects testabilité et non regression de leurs APIs. Enfin il me semble.
• le déploiement des Bundles est ordonné. En effet, si le Bundle B dépend (Import-Package) du Bundle A, il faut que ce dernier soit déployé avant…

Step 3 : La création du Web Module et du PAR

le Web Module est un jar qui contient un répertoire particulier MODULE-INF. Ce répertoire MODULE-INF reprend l’intégralité du répertoire WebContent, c’est à dire les jsp, le WEB-INF…Ce module contient également un manifest

1
2

Module-Type:web
Web-ContextPath:myAppContextRoot

Enfin le PAR qui est un artefact d’agrégation. Ce PAR proser un fichier META-INF/MANIFEST qui reprend la liste des Bundles nécessaires à l’application Web. Le bon ordre de chargement des bundles est alors garanti par DMServer.

Bref, j’ai été plutôt prolixe sur cette session qui reste pour moi géniale. J’ai néanmoins cette (première) impression qui est que sur ce coup, les choses sont encore un peu complexes. Après, il s’agit de la première version.

Developing beyond locahost

Lors de cette session, un autre aspect de la productivité à été présenté : comme vérifier rapidement que son code marche correctement sur des OS et des configurations différentes ?

La réponse proposée est d’utiliser des machines virtuelles sur son poste et ainsi pouvoir tester directement les effets d’une modification et son comportement sur les différentes configuration. La démo s’est basée sur l’outil VirtualBox déployé sur OpenSolaris :

• On code notre application
• On switch très rapidement entre les VMs ce qui rend les tests (manuels) très rapides
• La machine utilsée (laptop) n’a pas souffert de lenteurs malgré les 3 VMs

Un outil assez intéressant (désolé le nom m’échappe…) permet d’effectuer des sauvegardes incrémentales (et donc d’en faire une multitude sans prendre trop d’espace). Ces sauvegardes nous permettent de revenir à un état initiale, pour ne plus avoir des cookies ou de cache par exemple, ou encore pour vérifier l’installation ou la montée de version d’une application JavaWebStart.

Devoxx is Over!

Devoxx en général et l’édition 2008 reste un bon moyen de sentir ce qu’il se passe sur les thématiques d’architectures, de développement et même un peu de méthodologie (car on a noté quelques 2 ou 3 sessions taggées « Méthodologie » autour de Java).

• La Modularité. Toujours et partout. Au niveau des serveurs d’applications, au niveau des applications, au niveau du JDK…bref, c’est le régime pour Java et la possibilité du « juste adapté ».
• Java et sa JVM comme plateforme d’exécution de « tous » les langages. Force est de constater la poussée toujours plus forte des langages dynamiques (Groovy, Ruby,Python etc…). La retro-compatibilité du lagange et de la plateforme, mise en avant depuis des années, a commencé à être attaqué dans le but de faire tomber les barrières qui limitent l’évolution du langage, l’intégration d’autres langages…La plateforme Java est-elle vouée à devenir une plateforme offrant des services techniques à des applications écrire en N langages, une espèce de machine virtuelle universelle?
• Java s’ouvre à la communauté et cherche à fournir une plateforme plus productive. Les modèles de programmation Spring et JEE se rapprochent et tendent vers du plus simple. Le langage évolue en ce sens également.
• La confirmation de l’avantage des IHMs « vectorielles » (à base de plugin comme par exemple Flex) et des architectures IHM « client-side ». Au delà des purs aspects graphiques, ces solutions laissent envisager de nouvelles manières d’interagir avec des machines, bref de nouveaux patterns d’usabilité.
• Le rapprochement Designer/Développeur. Des solutions apparaissent et visent à faciliter voire à rendre transparent ce round trip entre le designer et le développeur, l’objectif étant de s’assurer qu’il n’y a pas de pertes lors des développement.

By Benoit Lafontaine, Olivier Mallassi, Fabrice Robini

Suggestion d'articles :

1. Another day @ Devoxx
2. One day @ Devoxx
3. Les grandes tendances de Devoxx 2011

« Et ça continue, encore et encore…. ». ne me demandez pas pourquoi j’ai cet air dans la tête. ce n’est franchement pas mon style de musique…

Effective Java by James Bloch

Du code, du code, du code…malgré des neurones pas encore complètement « up ». Une session au format Tips & Tricks sur certains aspects de la version 5 langage Java. Des subtilités autour des enum (« do not use ordinal() »), des mécanismes de lazy initialization, des generics.

On peut s’étonner du fait qu’on ne parle que de Java5 mais force est de constater qu’encore peu de personnes ont définitivement quitté la version antérieure de Java et que cela reste la version amenant le plus de modification du langage depuis un bout de temps.

La Modularité : décidément un sujet à la mode…

…mais ce matin, la keynote s’est concentrée sur la modularité du JDK, la compatibilité et les nouveautés de Java7. Le JDK se doit d’être modulaire pour faciliter les downloads, les temps de démarrage etc….une mouvance que l’on a déjà constaté au niveau des serveurs d’applications (par exemple Glassfish).

« La compatibilité ne sera pas forcément assurée tout le temps » est une synthèse du message de Mark Reinhold sur le sujet de la compatibilité ascendante entre versions du JSE. C’est surprenant, effrayant et en même temps, cela garanti ou facilite la survie du langage Java : certaines fonctionnalités, évolutions du langage se doivent d’être intégrées et la compatibilité est un frein à une réelle intégration…Affaire à suivre.

Les nouveautés du Java 7. On note un mouvement de fond de Sun qui est l’ouverture sur la communauté utilisateur comme si Sun avait compris qu’il était important de faire évoluer le langage pour répondre aux demandes du terrain et donc aux communautés de développeurs. J’aime cette idée. Java 7 intègre donc des évolutions souhaitées par Sun et des évolutions souhaitées par d’autres acteurs:

• la JSR 277 (ou JAM) disparait au profit de la JSR 294. Là ou la JSR 277 travaillait sur le déploiement, la JSR 294 se limite au langage, aux mécanismes de super-package ou comment jouer sur la visibilité de certaines classes ou package. on se rapproche d’OSGI
• OSGI justement. Mark Reinhold officialise le rapprochement. Dans les faits, cela c’était déjà concrétisé avec la modularité OSGI de Glassfish.
• la machine virtuel veut supporter des langages dynamiques. Son petit nom de code est simplement JSR 292 mais le mouvement était déjà lancé depuis quelque temps
• de nouvelles APIS de I/O. Certes les NIO mais surtout de nouvelles APIs d’accès au système de fichier (depuis le temps… ;-) )
• une gestion des exceptions facilitée grâce à deux points.
  • Le « safe rethrow » qui permet par exemple de « catcher Throwable » et de « relancer » strictement l’exception alors que la signature de méthode ne prévoit que deux cas d’erreur fortement typé. en bref, le compilateur gère pour nous.

1
2
3
4
5

void doIt() throws X1, X2{
 
try{}
 
catch(Throwable e){throw e}

• • Le « multicatch » qui permet d’avoir un seul catch(X1, x2…) et donc un seul traitement pour les exceptions X1 et X2.

1
2
3

try{...}
 
catch(X1, X2){

• peut etre de nouvelles annotations sur plus de type. L’exemple pris est celui d »une annotation @NonNull sur un paramètre de méthode. Cette annotation permet de préciser que le paramètre doit etre non null et facilite la vérification de NullPointerException et autres bugs. C’est intéressant car cela nous rapproche des classiques outils de qualimétrie mais on peut regretter la forte adhérence et intrusion au code.

Event Driven Architecture & Complex Event Processing

Les architectures orientées évènements fonctionnent sur la base d’évènements échangés entre un « publisher » et un « subscriber ». L’utilisateur a alors la responsabilité de s’abonner aux évènements qui l’intéressent; le système s’auto organise (enfin…).

Le Complex Event Processing est une évolution des architectures orientées évènements ou Event Driven Architecture qui vise à agréger beaucoup plus finement qu’un simple Publish/Subscribe des informations, des évènements provenant de différentes sources. Il est possible de requêter le contenu des messages; par exemple, les ordres d’achat qui dépasse tel ou tel montant ou bien les évènements de crédit et débit qui ont en commun un numéro de compte…

Les cas d’utilisation sont autour des systèmes de trading, de détection de fraudes ou bien un système de monitoring de système…

La session est l’occasion de présenter un produit nommé Esper qui implémente et facilite (normalement bien entendu car rappelez vous qu’il s’agit d’une présentation…) le développement de systèmes basées sur cette architecture. Esper propose donc une API permettant de réagir aux évènements, d’en créer de nouveaux, de requêter le contenu des message avec une syntaxe proche de SQL.

La modularité Java

Je crois que je n’aurai jamais autant entendu ce terme: modularité. Cette présentation se concentre sur la JSR-294 ou comment gérer la modularité de JDK mais également des applications afin d’améliorer quelques limitations sur l’existant:

• le « jar hell » et les problématiques de classpath. Apparemment, l’idée de supprimer le classpath et sa nécessaire configuration au profit de quelque chose – que j’avoue ne pas avoir trés bien saisi…
• les temps de download
• les « memory footprint »

Bref, cette JSR veut faire évoluer le langage et la VM pour être plus simple et flexible. Alors voilà dans les grandes lignes ce qui nous attend (au risque de ne pas être exhaustif). En premier lieu, le concept de module. le package est hiérarchique. le module, lui, permettra de regrouper des classes de différents packages dans un composant « logique ». Ainsi le code suivant pourra être écrit

1

module com.octopackage com.octo.core public class DoIt

puis dans une autre classe

1

module com.octo package com.octo.ext module class DoItDifferently

la classe DoItDifferently utilise le mot-clé module qui lui donne simplement la visibilité – et donc la possibilité d’être utilisée – au sein du module, indépendamment de son package.

Mais le module introduit également la gestion des dépendances. Ainsi il peut référencer d’autres modules qu’ils utilisent et que la JVM aura à charge de récupérer (comment? ca non plus je n’ai pas compris…ben oui désolé.)

1

module com.octo{ require com.octo.core require ceQueVousVoulez }

Bien entendu, il faut rajouter les notions de versionning; là encore, c’est le développeur qui gère cela.

1

module com.octo @ 1.2{ require com.octo.core @ 1.2 require ceQueVousVoulez @ 2.2 }

Il reste à voir comment la JVM va gérer ces dépendances de modules. Reste qu’à ce jour, ces évolutions du langage me semblent plutôt destinée aux éditeurs mais cela risque d’impacter nos processus de build car aujourd’hui des outils comme Maven gère pour nous et au build ces histoires de dépendances et de version de binaires.
Peut être que la JSR 294 aura le même destin que sa quasi homonyme JSR- 277; Java Module. Peut-être pas.

JEE 6 : Coming Soon, March 2009

Là encore, le keyword est « modularité ». JEE continu à grossir par rapport à sa version précédente mais introduit la notion de profile. L’idée dérrière les profiles est de regrouper des technologies « cohérentes » entre elles. Le premier de ces profiles est le « Web Profile » ou quelles sont les APIs nécessaires et utiles pour réaliser une application Web complète.
Ainsi, le Web Profile va réunir Servlet 3.0, JSP 2.1, JSF 2.0, EJB Lite 3.1, JTA 1.1, JPA 2.0..Un beau programme mais la limite ou la difficulté auquel Sun devra faire face avec les profils, c’est de créer le consensus sur ce quelles APIs seront présentes ou non dans le profile…Au regard des réactions du public, la tâche me parait complexe.

« Faute avouée est à moitié pardonnée » disait ma mère (et en fait j’imagine toutes les mères…). Sun appelle le « pruning » ou comment déprécier des pans complet de JEE; les éditeurs auront le choix d’implémenter ou non ces parties. On y trouve des APIs comme JAX-RPC…

JEE 6 s’ouvrira également sur la communauté au proposant les « Extensibility »; un mécanisme permettant à des solutions open source, des framework comme Spring, de bundler leur configuration (typiquement les servlet-filter…) pour que cette dernière soit simplement et de façon transparente, pour le développeur, prise en compte par le container.

Pour aller un peu plus dans le détail. Servlet 3.0 propose :

• un mode de développement à base d’annotations (@WebServlet, @ServletFilter)
• une modularité du fichier web.xml. Cela rejoint les « extensibility » mais il est possible d’embarquer un fichier META-INF/web-fragment.xml dans un jar, un framework et ce dernier sera mergé avec la configuration de l’application réalisée par annotation.
• l’intégration de Comet. Encore une configuration à base d’annotations @WebServlet(asyncSupported=true)…Les choses bougent vraiment trop vite…

Concernant EJB 3.1, on note:

• l’appartion d’un nouveau type de Bean. Annoté @Singleton, ce dernier est un Bean qui joue le rôle de singleton. Semble idéal pour les classiques problématiques de « Startup class », attention à ce que ce dernier ne deviennent pas le bottleneck de l’applicatif. L’API rajoute un gestionnaire d’accès concurrent (@ConcurrencyManager), un gestion des lock (@Lock)…
• le support de méthodes asynchrone sur un EJB Session. L’ajout de l’annotation @Asynchronous rend l’exécution asynchrone et laisse le container définir le moment opportun pour son exécution.
• les EJB 3.1 Lite…Modularité quand tu nous tiens! Bref, un sous ensemble d’EJB 3.1 qui propose Session Beans, gestion des transactions, de la sécurité, les intercepteurs et un mode EJB Container embedable. Cet embeddable Container peut être facilement démarrer via des APIs. Il permet donc d’utiliser des EJBs avec un JSE, de faire de tests unitaires. Enfin, ces EJBs peuvent être directement intégrables dans une application web; il n’est donc plus nécessaire de passer par un jar tiers.

Un outil a essayer : Javarebel

Commencons par le but du produit : supprimer le turnover; ie le temps entre une modification du code et la visualisation du changement dans une application déployée sur un serveur.

La présentation commence par poser le problème : en tant que développeurs Java d’application web, on passe 10% du temps à attendre que notre application se redéploie et a peu pès autant à retrouver ce qu’on était en train de faire vu que pendant notre temps d’attente, notre cerveau à perdu le fil. Bref, chaque seconde compte.

Des solutions plus ou moins bonnes existent déjà.

• Les serveurs d’applications savent recharger une application en changeant de classloader, le problème est qu’il faut alors réinitialiser et recharger le contexte, avec des applications spring cela peut prendre relativement longtemps.
• OSGI va plus loin et permet de ne plus recharger toute l’application, mais seulement un module (et les modules qui en dépendent). On réduit, mais ce n’est pas encore ça.
• Les frameworks comme tapestry ou RIFE permettent de recharger un composant uniquement. On approche… mais il reste des problèmes (tout ce qui est hors composant par exemple, et il faut toujours recharger le contexte)
• Hotswap, c’est un peu ce qu’on vise, car avec hotswap, on ne recharge plus de contexte, c’est le code de l’objet qui est directement changer. Cette (très bonne) solution reste limitée : on ne peut peut changer que le code interne à une méthode et on est obligé d’être dans un debuggeur.

Javarebel est assez similaire a hotswap : il change directement le code des objets (donc pas de rechargement de contexte), mais il supporte lui plus de fonctionnalités comme l’ajout de méthodes, de
variables d’instances, de classes etc… Les limitations sont repoussées aux changement d’héritage (l’objet n’étant plus X mais Y par exemple).

Une partie de certains frameworks comme Spring ou Struts sont aussi gérés (tant que la configuration est gérée par annotation dans la classe) : par exemple, on peut rajouter à chaud une méthode d’un controlleur spring avec l’annotation qui va bien pour qu’elle soit bindé sur l’URL correspondante, ou encore on peut rajouter un bean « autowired », le bean sera mis à jour automatiquement.

Des plugins sont prévus pour intégrer ce produit aux outils comme Maven ou Eclipse.

Conclusion du speaker : « chaque secondes comptent. Il y a plein de solutions efficaces, gratuites et qu’il faut utiliser, si vous voulez aller encore plus loin, il y a une solution payante (mais pas chere) » .
A noter, que vous pouvez payer en bières si vous voulez (4 pour la version individuelle et une dizaine pour la version entreprise)

La société développe aussi un serveur d’application basé sur la même technologie qui vous permet de réaliser une montée de version de votre application avec zéro interruption de service.

Hibernate Performance Tuning

Session très intéressante qui énumère toutes les optimisations possibles et leur contexte d’application. Toute la chaîne participant à la persistance est passée en revue, on commence par parler des paramétrages au niveau de l’OS (et oui, à la fin nos données son bien sauvegardées sur de vulgaires fichiers ;-), les accès disques (compression, cryptage, fragmentation), communication réseau, etc… Puis on remonte d’un niveau pour aborder la base de données et les configurations permettant là encore de gagner en performance: la taille du cache (the bigger, the better ;-), les indexs, la taille des buffers, les table space… là on se dit, tiens je vais aller payer un café à mon DBA préféré ;-) Puis on remonte doucement vers Hibernate (en abordant le choix judicieux du driver JDBC); petite piqure de rappel sur les différents caches Hibernate (1er et 2ème niveaux). On entre ans le vif du sujet avec les optimisations au niveau code et design d’implémentation: on prendra bien soin de ne pas avoir une hiérarchie d’héritage trop importante, de bien choisir le type de la colonne discriminante (on préférera utiliser un char(1), certes moins explicite mais bien plus performant.

Idée reçu: le DDL automatiquement généré par hibernate n’est pas optimisé pour la production ! Volker insiste bien sur le fait de se rapprocher le plus possible du DBA pour qu’il puisse « tuner » les scripts de génération et poser correctement les bons indexs (sans doute l’optimisation qui fournit le meilleur retour sur investissement). La session se termine par l’optimisation des requêtes HQL: toujours utiliser les « parametrized queries », maximiser les bulks/batch invocation pour optimiser les allers-retours vers la base de données, préférer le eager-loading pour les cas d’utilisation de navigation dans les grappes d’objet…

L’optimisation des performances s’effectue à de très nombreux niveaux depuis les fichiers jusque dans le code de l’application. Pour que ce chantier soit utile et concluant, Il ne faut jamais oublier de se fixer un objectif… et là, le test de monté en charge nous aidera pour fixer cet objectif à atteindre grâce aux métriques que nous pourront alors suivre.

Efficient Enterprise Build

Les nouveautés de Maven 3 :

• Une gestion des plages de versions qui fonctionne : les plages de fonctions par exemple : version=[1.1,) étaient présentent dans les dernières versions de Maven2, mais il restait pas mal de problèmes dans leur implémentation.
• Plexus (le framework d’IOC de maven) va être remplacé par un autre framework, probablement XBean ou Guice Maven devient encore plus modulaire (encore…). Cette modularité ouvre de nombreuses possibilités de réutilisation ou d’ouverture notamment :
  • La partie embedder permet une meilleure intégration aux outils comme Eclipse, Netbean ou Hudson
  • Le « Plugin manager » est réutilisée dans Nexus
  • Le project builder peut-être changer pour intégrer des projets Visual Studio ou pour permettre de construire son POM avec un script ruby ou groovy à la place du fichier XML.
• Une amélioration de la partie « code coverage » qui ne se limitera plus aux tests unitaires, mais permettra de visualiser la couverture de code par les tests unitaires, les tests d’intégration et les tests
  d’acceptance sous le même rapport.

L’équipe travaille avec Hudson pour offrir une meilleure intégration de Maven, notamment grâce à l’embedder. Une intégration de workflow (via drools) permettra de définir un workflow pour une release par exemple : « build – envoi de mails – vote des intéressés – release ».

Au final, un gros accent sur la modularité et l’intégration aux outils du développeur, Jason van Zyl nous à fait une bonne démo de m2eclipse et l’objectif est clairement que le développeur reste dans son IDE et que celui-ci lui apporte tout ce qu’il a besoin : documentation pour construire son projet, autocomplétion, vue sur les repositories centraux, etc…

By Benoit Lafontaine, Fabrice Robini, Olivier Mallassi

Suggestion d'articles :

1. Last day @Devoxx
2. One day @ Devoxx
3. Les grandes tendances de Devoxx 2011

Cet article en 3 volets présente comment intégrer la construction et le test de parsers ANTLR avec Maven. La première partie est consacrée à une présentation rapide d’ANTLR.

Lorsque vous avez besoin de développer un langage maison pour votre projet Java, avec une grammaire capable de le reconnaître, une valeur sûre est ANTLR (ANother Tool for Language Recognition, http://antlr.org), de même que le couple lex + yacc (ou la version GNU flex + bison) est la référence pour le langage C. Pour citer deux exemples, le parser HQL de Hibernate et celui de Groovy sont écrits avec ANTLR. On notera au passage que l’auteur d’ANTLR, en photo sur la page d’accueil du site, a conservé la métaphore animale en passant du monde des bovidés (Bos grunniens et Bison bison) à celui des cervidés (Cervus elaphus) !^[1]

Après une première partie de présentation d’ANTLR, cet article vous proposera de mettre en œuvre l’exécution automatique et fiable d’ANTLR au sein d’un build Maven. Une troisième partie montrera comment on peut écrire et lancer, par le même biais, des tests unitaires sur une grammaire.

A propos d’ANTLR

Malgré des différences importantes dans l’implémentation des langages, ANTLR, comme lex + yacc, est un préprocesseur qui prend en entrée un fichier descriptif de votre grammaire (appelons-le Demo.g) et pond du code source : en l’occurrence deux classes, une pour le lexer (DemoLexer) et une pour le parser (DemoParser). Le code source est par défaut émis en Java, mais ANTLR est aussi capable de générer du C#, du C++, du Ruby, du Brainfuck, … Dans cet article nous ciblons une plate-forme Java.

Le lexer (le terme exact est analyseur lexical) découpe le flux de caractères en entrée en tokens, ou éléments syntaxiques de base : une constante numérique, un caractère de ponctuation, un identifiant de variable, …

Quant au parser, il consomme ce flux de tokens pour reconnaître les constructions syntaxiques du langage (ex. une déclaration de méthode) et agir en conséquence. Ses actions peuvent être l’interprétation immédiate du texte fourni en entrée (ex. exécution de commandes), ou bien la construction d’un arbre syntaxique abstrait (AST) en mémoire^[2].

Voici un schéma récapitulatif qui illustrerait un fragment de grammaire pour le langage Java :

Une première exécution

Téléchargez la dernière version d’ANTLR sur le site : http://antlr.org/download/antlr-3.1.1.jar, et placez le JAR dans un répertoire de votre disque.

Ensuite copiez-coller le code suivant dans un fichier texte que vous nommerez Demo.g, dans le même répertoire :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

grammar Demo;
 
// Les mots-clefs de notre langage
tokens {
    PRINT = 'print';
}
 
// Code Java ajouté en tête du fichier source du lexer
@lexer::header
{
    package com.octo.testantlr;
}
 
 
// Code Java ajouté en tête du fichier source du parser
@parser::header
{
    package com.octo.testantlr;
}
 
// Règles du parser (les noms commencent par une minuscule)
program
    :    statement*
    ;
 
statement
    :     PRINT INTEGER ';'          // Ex. : print 123;
    |     PRINT VARIABLE ';'         // Ex. : print toto;
    |     VARIABLE '=' INTEGER ';'   // Ex. : toto = 123;
    ;
 
// Règles du lexer (les noms commencent par une majuscule ; la convention est de tout mettre en majuscules)
 
// Nom de variable
VARIABLE
    :     LETTER (LETTER | DIGIT)*
    ;
 
// Constante entière
INTEGER
    :     DIGIT+
    ;
 
// Commentaire -> ignoré
COMMENT
    :     '//' (~ NL)* NL? { skip(); }
    ;
 
// Sauts de ligne (ignorés via la règle WS)
NL
    :     'n' | 'r'
    ;
 
// Espaces -> ignorés
WS
    :     (' ' | 't' | NL) { skip(); }
    ;
 
fragment LETTER
    :     'A'..'Z' | 'a'..'z' | '_'
    ;
 
fragment DIGIT
    :	'0'..'9'
    ;

Puis, pour générer le lexer et le parser en ligne de commande, depuis le répertoire où est stocké Demo.g :

1

java -cp antlr-3.1.1.jar org.antlr.Tool -o . Demo.g

Vous aurez alors, dans le répertoire courant (du fait de l’option « -o .« ), deux fichiers DemoLexer.java et DemoParser.java — qui ne sont pas destinés à être lisibles par un être humain ! Il y a même un troisième fichier, Demo.tokens, qui contient la liste et les valeurs de tous les tokens, explicites et implicites, définis par la grammaire. Ce fichier est utilisé lorsqu’on veut partager des tokens entre plusieurs grammaires ; nous n’en avons pas besoin ici.

Une fois un lexer et un parser instanciés dans un projet (opérations non détaillées ici), la méthode DemoParser.program(), dont le nom est celui de la règle « point d’entrée » du parser, reconnaîtra notre mini-langage (aucune action n’étant associée aux règles du parser, en l’état celui-ci ne fait que valider la syntaxe du langage sans effets de bord).

Intégration au build Maven d’un vrai projet

Ce sera l’objet de la partie suivante. Pour l’instant, il faudra vous contenter de copier les fichiers générés dans le répertoire de votre projet, en faisant attention au nom du package (cf. sections @parser::header et @lexer::header de Demo.g), et de les regénérer à la main à chaque fois que vous modifierez la grammaire.

N’hésitez pas aussi à jeter un œil à l’IDE dédié à ANTLR, ANTLRWorks : http://antlr.org/works/index.html. Il vous permet de tester les règles individuelles en mode interactif, d’obtenir une représentation graphique de l’automate du parser, etc. Un plugin Eclipse est aussi disponible ici : http://antlrv3ide.sourceforge.net/, mais je ne l’ai pas encore essayé !

Suggestion d'articles :

1. Construire ses parsers ANTLR avec Maven – Partie 2/3 – Avec Maven
2. Construire ses parsers ANTLR avec Maven – Partie 3/3 – Testez vos grammaires
3. Maven deploy avec 2 profiles

La nouvelle version de Java 7 est en cours de préparation. Malgré le retard et les incertitudes sur le contenu, nous considérons que Java 7 constitue une opportunité intéressante pour le langage. Après un premier article consacré aux nouvelles librairies proposées pour Java 7, ce second article introductif vous propose de découvrir les nouvelles fonctionnalités du langage et de la JVM. Là encore, en cas de doute sur le contenu de la version finale, nous préciserons les réserves concernant une librairie ou une syntaxe en indiquant si l’exemple de code proposé compilait avec la version de prévisualisation 1.7.0-ea-b37.

Support des propriétés JavaBean

En Java, il est nécessaire d’implémenter des accesseurs (getter et setter) pour lire et modifier les attributs d’un objet. En effet, rendre public un attribut est une (très) mauvaise pratique puisque lorsque le besoin d’ajouter un comportement lors de la lecture ou de la modification de cet attribut apparaitra, tous les accès à cet attribut devront être remplacés par des appels aux accesseurs (qui implémentent ce nouveau comportement). La notion de propriété est proche de celle d’un attribut à ceci près qu’un getter et un setter peuvent lui être associés sans que l’appelant ne soit impacté.

Ainsi une propriété peut-être déclarée public :

1
2
3
4

class Product {
  public property String name; 
} ... 
product->name = "Java";

Dans cet exemple, la propriété name se comporte comme un attribut public (notez cependant la nouvelle syntaxe d’accès à la propriété, ->, qui n’est pas sûr d’être celle retenue dans la version finale). Lorsque le besoin d’implémenter un getter et/ou un setter se fait sentir :

1
2
3
4
5
6

class Product {  
  private String _name;  
  public property String name   
  get {    // do something    ...;    return _name;   }   
  set(String newName) {     // do something     ...;     _name = newName;   } 
}

Après cette évolution, le code appelant n’a pas besoin d’être modifié, les nouveaux getter et setter seront appelés. Les propriétés permettent donc de s’affranchir d’écrire des getter et setter qui ne font rien de plus que lire et modifier un attribut (même si nos IDE le font pour nous aujourd’hui) mais aussi d’alléger le code des classes de type JavaBean.

Le compilateur de la prévisualisation ne supporte pas encore cette fonctionnalité.

Support des opérateurs numérique pour le type BigDecimal

Lorsqu’il s’agit d’effectuer des calculs avec la classe BigDecimal de Java, cela devient vite illisible :

1

bd1.multiply(bd2).divide(bd3.add(bd4))

En ajoutant le support des opérateurs numériques à cette classe, on obtiendrait alors un code plus clair :

1

bd1 * bd2 / (bd3 + bd4)

Le compilateur de la prévisualisation ne supporte pas encore cette fonctionnalité.

Comparaison pour les énumérations

Cette proposition permet de donner un ordre aux valeurs d’une énumération et ainsi de pouvoir comparer leur ordre.

1
2

enum LevelEnum { level1, level2, level3, level4, level5 }; 
if (currentLevel > LevelEnum.level3) ...

Le compilateur de la prévisualisation ne supporte pas encore cette fonctionnalité.

Invocation chainée

L’invocation chainée de méthodes d’un même objet consiste à renvoyer l’objet en question pour ses méthodes qui ont déclarées void comme type de retour. De cette façon, il est alors possible d’appeler une seconde méthode de cet objet après l’appel d’une méthode qui ne renvoie rien.

1

new JFrame()  .setBounds(0, 0, 100, 100)  .setName("MainFrame")  .setLocation(200, 200);

L’intérêt est d’alléger le code répétitif et de pouvoir pousser un peu plus la création d’API dites fluides (ou « fluent API »). Le compilateur de la prévisualisation ne supporte pas encore cette fonctionnalité.

Méthodes d’extension

Les méthodes d’extension sont des méthodes statiques qui peuvent être utilisées comme s’il s’agissait de méthodes de la classe de leur premier argument.

1
2
3

Class Collections {   
  public static T max(Collection collection) { ... } 
}

import static java.util.Collections.max;
Collection list = new ArrayList();
list.max();

La méthode max est appliquée sur l’objet list comme s’il s’agissait d’une méthode de la classe Collection. Avec les méthodes d’extension, ceci est possible car list est du type du premier argument de la méthode statique max. La dernière ligne revient à écrire :

1

Collections.max(list);

Le compilateur de la prévisualisation ne supporte pas encore cette fonctionnalité.

Clause catch améliorée

La clause catch améliorée permet de traiter plusieurs exceptions dans le même bloc en utilisant l’opérateur ‘|‘ :

1
2
3

try {  ... } 
catch (IOException | RuntimeException exception) 
{  ... // le même traitement est appliqué pour les 2 types d'exceptions }

De plus, la possibilité de renvoyer une exception même si la classe déclarée dans la clause catch est parente de la classe réelle de l’exception sans avoir à l’encapsuler dans une nouvelle exception d’un type déclaré par la méthode (comme c’est nécessaire de faire actuellement).

1
2
3
4
5
6
7
8
9
10
11

public void throwAnException() throws IOException, RuntimeException {  
try {    ...  } 
catch (Exception exception) {    
  // Code actuel:    
  // throw new IOException(exception);    
  // ou    
  // throw new RuntimeException(exception);   
  // Code avec la clause catch améliorée    
  throw exception;  
 } 
}

Le compilateur de la prévisualisation ne supporte pas encore cette fonctionnalité.

Instruction invokedynamic et langages dynamiques

invokedynamic est une nouvelle instruction du bytecode de la JVM qui permet de simplifier l’implémentation de langages dynamiques (tels que JRuby, JPython ou encore Groovy). En effet, pour ces langages, les types des objets sur lesquels sont invoquées les méthodes ne sont pas connus à la compilation mais à l’exécution. De plus, il n’est pas possible de savoir si une méthode existe ou non pour une classe puisqu’elles peuvent être ajoutées ou supprimées à l’exécution. Les instructions actuelles (invokeinterface et invokevirtual) du bytecode Java nécessitent un type bien définit pour exécuter une méthode. Les implémentations actuelles de ces langages dynamiques sur la JVM doivent donc générer ces types à l’exécution. invokedynamic supprime cette limitation et améliore alors les performances de ces langages.

Support natif XML

Le support d’une classe XML avec une syntaxe native au langage Java est une des propositions d’inclusion pour la version 7. En effet, au même titre que la classe String qui possède une syntaxe particulière (les guillemets) pour construire une nouvelle chaine de caractère, une syntaxe particulière pour construire des documents XML permettrait de réduire grandement la verbosité du code Java nécessaire pour créer de telles structures avec les API existantes. Parmi les syntaxes proposées, on trouve :

1
2
3
4
5
6
7

public XML createProduct(String name, String version) {  
  XML product = <product>
                          <name>{name}</name>
                          <version>{version}</version>
                       </product>;  
         return product; 
}

Cette syntaxe a l’avantage d’être du XML mais utilise les éléments syntaxiques des génériques. Une autre syntaxe pourrait être : public XML createProduct(String name, String version) {

1
2
3
4
5

XML product = #product { 
                        #name { name },               
                        #version { version }       
       }; 
    return product; }

Les expressions entre accolades sont des expressions Java. À cette proposition s’ajoute la notion de DataCoder qui permettrait d’encoder et décoder un objet Java en chaine de caractères (pour être placé comme contenu d’une balise XML par exemple) et inversement. Pour ce qui est du streaming XML, les objets XMLSource pour lire (hasNext(), match(String xpath) et match()) et XMLSink pour écrire permettraient de simplifier la lecture et l’écriture au fil de l’eau de flux XML.

Le compilateur de la prévisualisation ne supporte pas encore cette fonctionnalité.

Comparaisons de chaines de caractères dans la clause switch

Une des propositions d’évolution pour Java 7 est la possibilité d’utiliser des chaines de caractères dans les clauses case d’un switch :

1
2
3
4
5
6

switch (str) {    
  case "true":        
    return true;    
  case "false":        
    return false; 
}

Le compilateur de la prévisualisation ne supporte pas encore cette fonctionnalité.

Tiered Compilation

En plus du mode client et du mode serveur actuels, un nouveau mode de compilation JIT appelé Tiered Compilation permettra à la JVM de profiter à la fois d’un démarrage rapide proposé par le mode client et d’optimisations plus agressives qu’offre le mode serveur actuel. En fait, il améliorera le mode client actuel en supprimant certaines compilations inutiles car réalisées trop top dans le démarrage de la JVM. Par exemple, certaines méthodes sont compilées et inlinées car au démarrage il n’y a qu’une possibilité d’appel (une seule implémentation de la classe sous-jacente) alors que d’autres classes sont ensuite chargées et rendent obsolète cette optimisation car elles implémentent cette même méthode. En effet, le choix de la méthode à appeler dépendra alors de la classe réelle de l’objet sur lequel la méthode sera appelée. Après le démarrage, les optimisations sont plus agressives (que le mode client actuel) comme pour le mode serveur. Ce type de compilation permet ainsi de profiter du meilleur des deux modes.

Garbage collector G1

Pour la JVM de Sun, une nouvelle évolution du Garbage Collector sera introduite dans la version 7 (voir peut-être même dans une version précédente) portant de le doux nom de G1 (ou Garbage First). Sans entrer dans trop de détails, le principe est de diviser l’espace mémoire en zones de taille fixe qui seront taggées avec leur génération (jeune ou ancienne, G1 reste donc un collecteur générationel au même titre que l’actuel CMS (Concurrent Mark-Sweep)). Après une phase de marquage globale des objets pour déterminer ceux qui sont encore en vie, le collecteur pourra vider (en copiant les objets d’une zone à une autre) les zones avec peu d’objets vivants afin de les regrouper. Ceci aura pour gain de faire gagner de l’espace dans la heap et supprimer la fragmentation dont souffrait CMS. En libérant plus d’espace mémoire, le passage d’un nettoyage complet (et coûteux en resources CPU) s’effectuera moins souvent.

Types et génériques

Un certain nombre d’évolutions concernent les types Java :

• l’inférence de types,
• les annotations sur les types,
• les types littéraux
• la réification par des génériques

Afin de décrire plus en profondeur chacune de ces évolutions et des notions qu’elles traitent, un article à part entière abordera ces sujets.

Closures et blocs de gestion automatique des ressources

Les closures, fonctionnalité qui revient sur le devant de la scène avec les langages dynamiques, sont proposées pour être incluses dans Java 7. Nous verrons dans un prochain article ce qu’elles sont et ce qu’elles peuvent apporter au langage Java.

Au cours de ces deux articles nous avons largement détaillé les nouveautés de Java 7. Les points que nous n’avons pas abordés tels la modularité, la gestion de la concurrence et du parallélisme, les évolutions des génériques et le closures seront étudiés dans de futur articles.

Il reste vrai que de nombreuses incertitudes entourent encore cette version de java tant sur sa date de sortie que sur son contenu. Mais au final, nous trouvons que les fonctionnalités pressenties apportent de la valeur à cette plate-forme. Pour notre part, nous retiendrons plus particulièrement :

• La prise en compte de la modularité et du packaging
• Des librairies qui facilitent le code de tous les jours avec API Date & Time, Unit & Quantites ou JMX 2.0. Elles sont largement basées sur l’expérience de framework réel, ce qui est un gage de qualité et d’intérêt des concepts importés.
• Des outils pour faciliter l’utilisation de swing comme Beans Binding et Beans Validation
• Des améliorations pour rendre le langage plus expressif comme la nouvelle syntaxe pour les propriétés, les méthodes d’extension, ou le support natif du XML. Cela contribue à rendre Java plus léger et moins verbeux pour rester compétitif par rapport à des langages plus jeunes qui ont simplifié leur syntaxe comme JRuby ou C#.
• Des améliorations techniques par exemple au niveau du garbadge collector ou de l’instruction invokedynamic

Toutes ces modifications même très techniques restent importantes car elles constituent la base de l’innovation pour tous les développements du monde java.

Par David Rousselie et Marc Bojoly

Suggestion d'articles :

1. Socle technique des applications Java EE : dans le WAR ou dans le serveur ?
2. Les nouvelles librairies dans Java 7
3. Thrift et Protocol Buffers : compacité du message sérialisé dans le monde Java