Le Paris Jug organise mardi prochain (08/11) une soirée « Petites Librairies Java ». Comme d’habitude, les Duchess organisent l’AvantJUG, la rencontre précédant le ParisJUG, au Café Vavin (18, Rue Vavin, 75006 Paris) à partir de 18h30.
Nous vous attendons donc toutes et tous pour faire connaissance et discuter autour d’un verre.

Attention !
Pour des questions d’organisations, n’oubliez pas de nous prévenir de votre venue par mail à duchessfr(at)gmail(dot)com au plus tard le Mardi matin. Cela nous permettra de passer un bon moment en toute sérénité.

Le Paris Jug organise mardi prochain (13/09) une soirée rétrospective sur le Challenge USI 2011 dont le sujet était  « Et si vous codiez une application qui supporte 1 milliard d’utilisateurs ? ». Plusieurs équipes (dont les finalistes) viendront présenter leurs architectures.

Pas de changement, les Duchess organisent l’AvantJUG au Café Vavin (18, Rue Vavin, 75006 Paris) à partir de 18h30.
Nous vous rappelons que l’AvantJUG, comme tous les événements organisés par Duchess, n’est pas réservé uniquement aux filles. Nous vous attendons donc toutes et tous pour faire connaissance et discuter autour d’un verre.

Attention !
Pour des questions d’organisations évidentes, n’oubliez pas de nous prévenir de votre venue et si vous êtes accompagnés ou pas par mail à duchessfr(at)gmail(dot)com au plus tard le Mardi matin.

A bientôt !
Crew Duchess France

Le Paris Jug organise mardi prochain une soirée « La mode cloud, collections d’été ». Elle sera animée par Patrick Chanezon, français d’origine parti travailler chez Google USA. Il dirige l’équipe en charge de la promotion des services Google dans le nuage (App Engine, Storage, Prediction, BigQuery, Go) et des outils (GWT).

Comme d’habitude, les Duchess organisent l’AvantJUG, la rencontre précédant le ParisJUG, au Café Vavin (18, Rue Vavin, 75006 Paris) à partir de 18h30.
Nous vous rappelons que l’AvantJUG, comme tous les événements organisés par Duchess, n’est pas réservé uniquement aux filles. Nous vous attendons donc toutes et tous pour faire connaissance et discuter autour d’un verre.

Attention !
Pour des questions d’organisations, n’oubliez pas de nous prévenir de votre venue et si vous êtes accompagnés ou pas par mail à duchessfr(at)gmail(dot)com au plus tard le Mardi matin. Cela nous permettra de passer un bon moment en toute sérénité.

La prochaine soirée du ParisJUG aura lieu Mardi 14 juin à l’ISEP : Pete Muir (leader du développement de la spécification CDI 1.1) viendra nous présenter CDI (Contextual Dependency Injection) et les Managed Beans dans la plateform Java EE6. Peter nous montrera comment faire de l’injection de dépendance sans Spring en utilisant des annotations comme @Inject. Pour en savoir plus sur CDI n’hésitez pas à lire l’interview de Peter par les Duchess.

Comme les mois précédents, nous organisons l’AvantJUG, la rencontre précédant le ParisJUG, au Café Vavin (18, Rue Vavin, 75006 Paris) à partir de 18h30.

Nous vous rappelons que l’AvantJUG, comme tous les événements organisés par Duchess, n’est pas réservé uniquement aux filles. Nous vous attendons donc toutes et tous pour faire connaissance et discuter autour d’un verre.

Attention !
Pour des questions d’organisations, n’oubliez pas de nous prévenir de votre venue et si vous êtes accompagnés ou pas par mail à duchessfr(at)gmail(dot)com au plus tard le Mardi matin. Cela nous permettra de passer un bon moment en toute sérénité.

Le 14 juin prochain, le Paris JUG propose une soirée autour de CDI. Le speaker, Pete Muir, n’est autre que le leader du développement de la spécification CDI 1.1 (disponible sous GitHub, la classe!). Actuellement employé par Red Hat Inc. Pete travaille également sur Infinispan, un data grid open source écrit en Java. Auparavant, Pete gérait les projets JBoss Seam et Weld, il est également le fondateur du projet Arquillian. Pete a travaillé sur plusieurs spécifications dont JSF 2.0, AtInject (JSR 330) et CDI. Il est un speaker régulier des JUGs et conférences comme Devoxx, JAX, JSFDays et JBoss World.
Sa session au Paris JUG se déroulera en deux parties. La première sera dédiée à CDI (JSR 299) et aux Managed Beans, spécifications introduites dans Java EE 6 : quand et comment utiliser CDI et les EJBs dans le développement d’application? Pete abordera également la perspective de Java EE 7 et de CDI 1.1. La deuxième partie de sa session sera dédiée aux extensions CDI. Vous découvrirez ainsi comment il devient très facile d’écrire et d’ajouter des fonctionnalités s’exécutant dans n’importe quel conteneur supportant la JSR-299.

Cet interview a été préparé conjointement par Audrey NEVEU, Agnès CREPET et Antoine SABOT-DURAND

Audrey, Agnès & Antoine: CDI 1.0 est en grande partie la standardisation de Seam 2. Quand et comment avez vous décidé d’en faire une JSR et quel fut le travail nécessaire pour réaliser cette spécification ?
Pete: Pour moi CDI n’est pas “en grande partie la standardisation de Seam 2”. Je pense qu’il a reçu les influences de Seam 2 (contextes, événements) et de Guice (injections de dépendances type-safe, cycle de vie des événements) à parts égales, de même que d’autres frameworks comme Spring.
Nous avons décidé de déposer la JSR car à JBoss / RedHat nous croyons fermement au fait de retirer les verrous commerciaux et au fait de fournir la portabilité des applications . Cette influence se retrouve dans plusieurs domaines comme le prouve notre engagement dans le JCP (CDI, Bean Validation), OSGI et le cloud. Quand nous avons développé Seam, nous trouvions qu’il manquait à Java EE un modèle de programmation puissant, moderne, qui viendrait en complément des services fournis par les EJB et que cela réduisait la portabilité des applications, et nous avons décidé d’y remédier.
Nous sommes vraiment heureux du succès rencontré par CDI et enthousiastes de prendre part à la réalisation de Java EE 7. C’est agréable pour nous de voir que CDI est perçu comme puissant et moderne par la communauté.
La JSR a été déposée il y a 5 ans environ et c’est déjà beaucoup de travail investi dedans. Gavin King, spec lead pour CDI 1.0, a travaillé sur CDI environ 18 mois à temps complet. Red Hat a aussi produit une implémentation de référence (Weld) et un Technology Compatibility Kit sur lequel j’ai travaillé 18 mois environ avec une équipe à temps partiel qui de son côté, a aussi travaillé 18 mois en tout. Depuis que j’ai repris le rôle de spec lead pour CDI 1.1, Ales Justin a pris le lead sur Weld et sera responsable de son implémentation dans CDI 1.1.

Audrey, Agnès & Antoine: D’après vous, quels sont, s’il y en a, les obstacles majeurs à l’adoption de CDI ?
Pete: Je pense que, comme avec toutes les nouvelles technologies, l’une des premières difficultés pour l’adoption de CDI a été la documentation, les tutoriels et les guides. C’est pourquoi je suis heureux de voir l’apparition d’initiatives telles que CDISource. Une autre barrière a été la disponibilité de serveurs d’applications certifiés Java EE mais là encore, les obstacles ont été réduits depuis l’année dernière, avec par exemple la sortie de JBoss AS 6 à Noël. JBoss AS7 qui est annoncé pour le mois prochain sera particulièrement attractif pour les développeurs avec un temps de démarrage de 3s.

Audrey, Agnès & Antoine: Il y a plusieurs points d’entrée pour l’injection en CDI : champs, constructeur, setters. Avez vous des recommandations pour chacun d’entre eux ? L’introduction de logique métier est possible avec les constructeur et setters, mais pas avec l’injection par champs, est-ce la seule différence ?
Pete: Mon préféré est l’injection par construction car il permet de créer un objet immutable, ce qui est une des clés techniques pour la programmation concurentielle, qui est quelque chose qui devient de plus en plus important aujourd’hui.
L’injection par champs est préférée par certain car elle est un peu plus propre (pas besoin d’injecter manuellement le constructeur) et qu’elle produit elle aussi un objet immutable, du moins tant que le développeur est discipliné et qu’il ne modifie pas la valeur de l’attribut dans son code.
L’injection par setter peut être utile pour ajouter CDI à du code legacy où ce design pattern a déjà été utilisé, mais je le n’utiliserai en aucun cas dans un nouveau projet.
Enfin, comme vous le disiez, l’injection par constructeur et par setter offre également la possibilité d’insérer de la logique métier lors de l’injection.

Audrey, Agnès & Antoine: Pouvez vous nous expliquer comment vous avez amélioré Weld, l’implémentation de référence pour CDI, au sujet de l’usage de la mémoire, du temps de démarrage et des performances au runtime ?
Pete: Nous avons apporté d’importantes améliorations à Weld et nous constatons maintenant que les performances au runtime sont aussi bonnes que celles d’autres implémentations de CDI ou que d’autres frameworks d’injection de dépendances. Pour ce qui est de l’usage de la mémoire et de l’optimisation du temps de démarrage, nous y avons également consacré du temps mais nous n’avons pas fini pour le moment : nous pensons pouvoir réduire encore l’usage de la mémoire par dix.

Audrey, Agnès & Antoine: Comment avez vous prévu de travailler avec les autres implémentations de CDI : Candi et Open Webbeans ?
Pete: Nous sommes assez proches des membres de ces équipes : les deux participent activement au groupe d’experts de CDI 1.1. Comme nous venons tous du monde de l’opensource, nous sommes habitués à partager notre travail et à nous engager dans la communauté. En pratique, trois équipes d’implémentation collaborent pour améliorer le Technicology Compatibility Kit et discutent au sujet de la spécification. Nous collaborons aussi pour promouvoir CDI de temps en temps : nous avons d’ailleurs proposé quelques sessions en commun à JavaOne cette année.

Audrey, Agnès & Antoine: Vous êtes le leader de la spécification CDI 1.1 qui semble résoudre certains des problèmes rencontrés par CDI 1.0 et standardiser quelques unes des extensions les plus populaires de CDI amenées par la communauté. Pouvez vous nous donner des exemples de ceux-ci ?
Pete: Nous avons identifié trois types de problèmes : des bugs dans la spécification (des erreurs de conception), des besoins de clarification nécessaires (des contradictions dans la spécification ou des implémentations qui ont pris différents chemins) et des nouvelles fonctionnalités, qui sont le plus gros du travail, la majeure partie des bugs et des clarifications ayant déjà été traités. Quelques uns des plus gros problèmes que l’on nous remonte est de revoir l’activation et l’ordre des interceptors, decorators et alternatives, qui contrôlent quelles classes sont scannées.
Nous sommes également en train de nous intéresser à la standardisation de quelques extensions inspirées par les projets de la communauté tels que Seam Solder et MyFaces CODI comme handlers de service.

Audrey, Agnès & Antoine: Le JCP a annoncé à la fin d’avril que la spécification de CDI 1.1 avait reçue une approbation quasi unanime : tout le monde ayant voté oui, excepté VMWare qui n’a pas voté. Quelles sont vos relations de travail avec les gens de VMWare ? Quelle est votre analyse sur le long commentaire fait par IBM sur ce vote ?
Pete: Je ne peux pas vraiment m’exprimer sur l’inactivité de VMWare dans le JCP, nous essayons plutôt de travailler avec IBM sur CDI, car ils nous avaient déjà apporté leur aide sur la version 1.0. Ils avaient quant à eux déclaré que la proposition pour CDI 1.1 inclue un nombre d’améliorations qui sont souhaitables mais dont certaines nécessiteraient un traitement externe à CDI. Les intercepteurs par exemple ne sont pas spécifiques à CDI, ils devraient être considérés comme un problème relatif à la plateforme dans son ensemble ou bien comme une mise à jour à rajouter à leur propre spécification. Pour IBM, faire fonctionner des fonctionnalités déjà implémentées est plus important qu’en ajouter de nouvelles et c’est pourquoi ils auraient été contraints de voter non si ces remarques n’avaient pas été prises en compte.
Red Hat a approuvé cette déclaration et inclu ces éléments dans la proposition pour CDI 1.1 sous un avertissement des spec lead Java EE précisant que nous devrions relever les problèmes qui concernent également d’autres technologies Java EE. Nous pourrons ainsi les affecter correctement au fur à et mesure des progrès de la spécifications de Java EE 7. Nous sommes également d’accord avec IBM que l’alignement avec d’autres JSR est important (la proposition inclue un certain nombre d’éléments avec lesquels s’aligner) et attendonc avec impatience de travailler avec IBM à résoudre les problèmes qu’ils pourraient nous faire remonter.

Audrey, Agnès & Antoine: Avez vous ressenti des changements dans le JCP depuis qu’Oracle a racheté Sun ?
Pete: Pas pour le moment, mais je ne suis pas impliqué dans les activités du Comité Executif du JCP.

Audrey, Agnès & Antoine: Y a t’il quelque chose de prévu pour fédérer tous les contributeurs de l’écosystème autour de CDI (Seam 3, Codi, CDI Source par ex.) afin d’assurer l’intéropérabilité et éviter le développement en double d’extension ?
Pete: Nous n’avons pas de projet de la sorte et nous sommes persuadés que la compétition dans l’écosystéme reste une bonne chose pour amener de l’innovation. Cependant, nous voulons garantir l’intéropérabilité et la meilleure façon de le faire, c’est de s’assurer que CDI offre les facilités nécessaires pour développer des extensions qui intéragissent au dessus de lui et pas à travers ses propres interfaces. Nous encourageons d’ailleurs toute personne qui rencontre des problèmes de la sorte à les faire remonter, de façon à ce que nous puissions les prendre en compte pour CDI 1.1.
Il y a aussi des rumeurs à propos de JSRs qui auraient été proposées pour standardiser des fonctionnalités qui viendraient au dessus de CDI (pour la sécurité par exemple).

Audrey, Agnès & Antoine: Est il prévu d’intégrer des modules CDI (Seam Solder ou Seam configuration par ex.) dans la spécification, et si oui, lesquels ?
Pete: Nous réfléchissons à standardiser certaines fonctionnalités développées dans Solder, cependant de manière générale nous pensons que si une extension peut être développée facilement, il n’y a pas de réel besoin pour la spécification de se s’en mêler car cela risquerait d’étouffer l’innovation.
Il faut se souvenir que le but premier pour la standardisation de CDI était de produire des applications portables, et les extensions n’empêchent pas ça !

Audrey, Agnès & Antoine: L’instantiation de Bean étant déjà possible au runtime, pensez vous qu’il soit possible que CDI évolue de façon à permettre aussi l’enregistrement de Bean au runtime ? Avec cette possibilité, nous serions capable par exemple de créer un bean avec Groovy, comme nous le faisions avec Seam 2.x.
Pete: Les langages dynamiques deviennent de plus en plus populaires et il est important que CDI soit compatible avec eux. Seam 2 offrait la possibilité de “redémarrer partiellement” le container pour les classes Java et Groovy, une partie seulement des beans étaient redéployés. CDI a une validation du graphe de dépendances beaucoup plus stricte, ce qui autoriserait une solution plus complète : CDI pourrait ainsi voir quels beans sont affectés par des changements et ne redéployer que ceux là. L’expérience montre que les gens ont tendance à construire des modèles fortement interconnectés (il est très difficile de parvenir à construire des modèles efficaces et utiles sans qu’ils aient de nombreuses interconnexions) ce qui ferait qu’un tel redémarrage causerait le redéploiement de la quasi totalité de l’application. Bien sûr vous pouvez continuer à utiliser des classes Groovy avec CDI, vous ne pourrez juste pas changer les classes au déploiement.
Nous n’avons pas prévu d’ajouter quoi que ce soit là dessus à la spécification pour le moment et je pense personnellement qu’il est préférable de le laisser pour l’instant comme une implémentation à rajouter. Nous avons prévu d’expérimenter une fonctionnalité comme celle ci dans Weld (notez au passage que c’est un outil orienté SPI (Service Provider Interface), et non un utilisateur orienté SPI !) Il y a aussi quelques alternatives : l’excellente équipe de Serli travaille avec nous et les équipes d’experts OSGi de JBoss pour tenter de définir comment CDI et les services OSGi pourraient interagir, ces derniers permettant le redémarrage partiel de votre application. JRebel travaille déjà avec Weld et si nous fournissons une API de redémarrage partiel, il n’y a qu’eux que ça pourrait aider. JBoss AS 7 quant à lui a un temps de démarrage vraiment minime (2.3s) ce qui réduit le besoin de redémarrage partiel.
En conclusion, il est important de signaler que TorqueBox, le projet de JBoss, qui propose Ruby on Rails avec la puissance de JBoss AS, supporte CDI, ce qui offre la possibilité d’injecter vos services CDI écrit en Java dans Ruby, pour ceux qui veulent tester ce langage.

Audrey, Agnès & Antoine: Avec tous les progrès de CDI 1.1, est il plausible d’imaginer que de nombreuses personnes vont délaisser le container d’ejb dans le futur ?
Pete:EJB offre un set de “entreprise services” essentiels tels que la déclaration des transactions donc je ne vois pas le besoin de s’en débarrasser. Cependant ce que je vois, c’est un mouvement vers cette idée que les services EJB peuvent être appliqués à chaque bean managé, et pas seulement les EJB; les EJB et CDI seront ainsi dans la continuité l’un de l’autre. Red Hat encouragera certainement cette décision et je suis impatient de voir cela avoir lieu pendant le développement de Java EE7.

Merci Pete!

Les inscriptions seront ouvertes à partir du jeudi 9 juin 7H00! Rendez-vous sur le site du Paris JUG

La prochaine soirée du ParisJUG aura lieu Mardi 10 Mai à l’ISEP : Charles Moulliard viendra nous parler d’Apache Camel, projet sur lequel il est committer.

Comme les mois précédents, nous organisons l’AvantJUG, la rencontre précédant le ParisJUG. Cette pré-soirée aura lieu comme toujours au Café Vavin (18, Rue Vavin, 75006 Paris) à partir de 18h30. Vous souhaitez rencontrer les habitué(e)s de l’AvantJUG ? convaincre un ou une de vos collègues de vous accompagner au ParisJUG ? ou tout simplement discuter autour d’un verre ? alors n’hésitez pas ! venez nous rejoindre !

Vous vous êtes inscrit(e) au ParisJug et vous souhaitez participer à l’AvantJUG ?
Alors prévenez-nous de votre participation à l’AvantJUG en envoyant un mail à l’adresse suivante : duchessfr(at)gmail(dot)com

Vous êtes accompagné(e) par des collègues (H/F) ?
Dites leur de venir, nous serons heureuses de les accueillir.

Attention !
Suite au nombre de participants plus importants nous réservons des tables au Vavin alors pensez à nous prévenir au plus tard le Mardi matin de votre venue et si vous viendrez accompagné(e) ou non. Cela nous permettra de passer un bon moment en toute sérénité.

Important : Suite à une flemmingite aiguë de l’auteure de ce post, il est décidé qu’aujourd’hui en grammaire française, tout s’accorde au féminin. Mais bien sûr messieurs, votre venue est indispensable !

Chère lectrice,

toi qui est une networkeuse avertie, je ne t’apprends rien en te disant que la semaine prochaine, deux évènements majeurs se profilent à Paris et que les deux sont organisés par Duchess France … Mais certaines d’entre toi auront peut être eu la tête ailleurs ces derniers temps et c’est pourquoi il est de mon devoir de te rappeler ces deux dates à rajouter illico dans ton google agenda, pour rester une geekette dans le vent !

Mardi 12 : l’Avant Jug

L’Avant Jug c’est bien sûr le rendez vous qui permets aux dukes et aux duchesses de faire connaissance autour d’un verre au Café Vavin et de parler geek. Ou Git, au choix la semaine prochaine puisque c’est le thème de la soirée présentée par Sebastien Douche. Eh oui, comme on est sympa chez Duchess, on ira rendre visite à une bande de copains juste après : ils ont monté une petite assoc’ le ParisJug (ou je ne sais plus quel autre truc en UG) et on leur file un petit coup de main en parlant d’eux, c’est bien normal Alors que tu souhaites nous rencontrer ou faire découvrir Duchess à un ou une collègue, inscris toi en envoyant un mail à duchessfr(at)gmail(dot)com et soit la bienvenue parmi nous à partir de 18h30 au 18 rue Vavin, dans le 6ème !

Jeudi 14 : Happy Birthday Duchess !

Bien sûr, en lectrice assidue de Geek & Chic Magazine, tu sais déjà que the place to be cette année, c’est au premier anniversaire de Duchess France ! Mais peut être as tu peur de te lancer seule ou de n’être point à ta place ? Eh bien n’aies crainte, l’anniversaire de Duchess France c’est avant tout une soirée pour se rencontrer et s’amuser ! Tout d’abord sache que l’anniversaire de Duchess France c’est la première soirée geek en France avec 33% de vraies filles dedans ! Autant te dire que l’on va faire des envieux Ensuite tu trouveras au programme des jeux pour petits et grands : Invité protocolaire, Padawan ou Jedi chacun pourra participer, apporter sa petite pierre à l’édifice de la bonne humeur avec notre grand Trivial Pursuit Spécial Java. Et pour finir, nous avons préparé avec nos gentils sponsors plein de surprises super sympas et un buffet pour discuter avec toi, ce serait quand même dommage de louper ça …

Peu de monde à l’avant Jug et pas la foule des grands jours pour ce Paris Jug post 3ème anniversaire et c’est bien dommage pour ceux qui ne sont pas venus car Stephen Colebourne nous avait préparé une soirée passionnante autour de Java.

Once upon a time

Pour commencer, petit retour sur l’histoire de Java de sa naissance à aujourd’hui, en passant par la présentation des divers acteurs de cette épopée : Sun, Apache, Oracle mais également Google. Aux travers d’événements plus récents (le désengagement d’Apache du JCP et les retentissantes attaques d’Oracle contre Google) Stephen nous a livré ses réflexions sur l’avenir de Java en général et du JCP en particulier, avenir qui n’est pas des plus rayonnants selon lui car notre speaker conçoit mal un JCP sans Apache.

Joda Money

Stephen nous a ensuite présenté sa librairie Joda Money. Moins connue que Joda Time, elle est pourtant là pour combler elle aussi une lacune historique du langage : la gestion des montants en Java.

Pour cela, deux classes sont à notre disposition : Money qui a un nombre de décimales fixe et Big Money, qui propose un nombre illimité de décimales sans perte de précision. La classe Money fournit notamment de nombreuses méthodes pour effectuer les opérations basiques (y compris le formattage) sur un montant en gérant les devises, le tout de manière thread safe.

La librairie est assez petite ce qui fait que vous la maîtriserez rapidement, mais contient toutes les fonctions indispensables, ce qui en fait deux bonnes raisons pour supprimer sur le champs vos BigDecimal du code et les remplacer par des instantiations JodaMoney bien plus efficaces

Joda Time et la JSR-310

Stephen a ensuite enchaîné avec la plus célèbre et toujours aussi utile Joda Time , une librairie incontournable pour tout développeur Java. Sous ses aspects triviaux, la gestion des dates est un problème bien plus complexe que l’on ne se l’imagine de prime abord. De nombreuses problématiques sont à prendre en compte : les différentes échelles de temps, les notions de moment de la journée (minuit n’est pas une notion universelle), les divers calendriers existants de part le monde, sans compter les décisions politiques qui viennent parfois bouleverser les timezone.

En développant cette librairie, Stephe avait pour objectif de fournir une API :

• immutable (contrairement à l’API Date qui n’est pas Thread Safe)
• extensible
• facile d’utilisation : les objets et les méthodes sont simples et décrivent bien leur fonction
• avec une documentation explicite : tous les exemples de la javadoc sont concis et concrets

Pour ne citer qu’un exemple, prenez la classe LocalDate et parcourez ses méthodes : vous pouvez facilement retrouver le jour de la semaine ou encore rajouter 3 mois à votre date courante. Et lorsqu’il s’agit de déterminer un délai de facturation à 3 mois, fin de mois + 10 jours (si, si, ça existe) on est bien content d’avoir JodaTime sous la main ! Il y aurait peu d’intérêt à énumérer les possibilités vraiment nombreuses de cette librairie, on ne saurait que trop vous encourager à aller voir par vous même

Heureusement pour nous, le JDK 1.8 verra le remplacement de l’API Calendar actuelle par la spécification proposée par Stephen, mais cela représente une énorme somme de travail et c’est pourquoi notre speaker vous invite à se joindre à lui Alors si vous aussi vous voulez devenir un super spécialiste en UTC, TAI et calendriers exotiques, n’hésitez pas, c’est ici que ça se passe : jsr-310.

The next big language for the JVM

Après le buffet, Stephen s’est penché sur ce que pourrait être le prochain langage pour la JVM. Au cours de son évolution, Java a connu pas mal d’ajouts de fonctionnalités, dont certaines parfois obscures ou complexes comme les Generics. Pour illustrer son propos, notre speaker nous présente plusieurs exemples de code pour le moins ardus à déchiffrer et encore plus à expliquer.

Et c’est bien là le coeur du problème selon Stephen : un langage performant doit être aisément compréhensible par un développeur moyen, et ce sans aide extérieure. Si un développeur “middle-level” ne peut parvenir à avoir au moins une idée de ce que fait la fonction rien qu’en lisant le code de celle ci, c’est que quelque chose ne va pas. Pour reprendre le cas des Generics, une centaine de personnes d’un niveau d’expertise avancé ont participé à leur élaboration, mais aucune ne s’est demandé si c’était compréhensible par l’utilisateur.

L’évolution de Java est freinée depuis plusieurs années déjà par son héritage lourd et parfois encombrant (le type null, les types primitifs, …) et cela s’illustre parfaitement avec la dernière version sortie qui ne comportait que quelques nouvelles classes et pas de grandes révolutions, comme ont pu en apporter les versions précédentes. Certaines implémentations qui étaient de vraies solutions techniques à la naissance du langage ressemblent plus aujourd’hui à d’embarrassantes tares dont l’on aimerait bien se débarrasser, ce qui est devenu impossible bien entendu pour des raisons de rétro-compatibilité.

Faut il pour autant abandonner Java et créer un autre langage ? Et ce langage à quoi ressemblerait il d’ailleurs ?

Après avoir comparé plusieurs langages (Scala et Fantom entre autre), Stephen nous a présenté quelques pistes de réflexion, au travers notamment d’une déclaration de Bean classique, qui s’allégeait au fur et à mesure que l’on envisageait l’intégration de fonctionnalités telles que la gestion “directe” des propriétés, qui nous permettrait par exemple de supprimer les classiques accesseurs qui prennent tant de places dans nos classes.

En revenant sur les langages historiques que sont C, C++ et Java, Stephen a également relevé un autre point intéressant : leur naissance vient souvent apporter le support de Design Patterns qui sont devenus indispensables (le C++ pour faire de l’objet, Java et la JVM pour la gestion de la mémoire, etc …), un Design Pattern n’étant rien d’autre que la réponse à un problème récurrent que le langage ne permets pas de traiter nativement.

Le prochain langage devra donc corriger les “défauts” de java, supporter nativement certains aspects devenus indispensables comme les closures, intégrer les design pattern qui sont devenus incontournables et tout cela en restant simple dans sa syntaxe.

Notre speaker n’a pas encore trouvé le langage idéal, celui qui pourrait prendre la relève et remplir tous ces critères, mais rien ne vous empêche de commencer à y réfléchir de votre côté et si vous l’inventez, n’oubliez pas de nous prévenir, nous vous réserverons un article dans Duchess

Le Lundi 28 février le Paris JUG soufflera sa 3ème bougie. A date exceptionnelle, soirée exceptionnelle.

Le lieu. Cette soirée aura lieu à la Cité Internationale Universitaire, dans un grand auditorium  de 500 places. Pour une fois vous n’aurez pas à courir pour vous inscrire, il y aura de la place pour tout le monde.

L’horaire. La soirée sera plus longue que d’habitude, Elle commencera à 18h pour se terminer à 22h30. L’équipe du Paris JUG vous accueillera à partir de 17h30. Extinction des feux à 22h30, tout le monde dehors … pour continuer la fête !

Le contenu. Le thème cette année sera Siffler en travaillant ou, dit autrement, montrez nous que c’est sympa de bosser :

• une keynote d’ouverture de 45 minutes sur le télétravail par Nicole Turbé-Suetens
• des quickies de 15 mn sur des thèmes plus ou moins techniques
• quartier libre de 19h30 à 20h45, vous pourrez vous désaltérer au buffet, aller voir les stands de nos sponsors, acheter des livres informatiques et vous faire masser (et oui, on ne change pas une recette qui gagne)

Toutes les informations sotn sur le site du Paris JUG.

La 3e mi-temps. Un Paris JUG ne serait pas un Paris JUG sans la fameuse 3e mi-temps. Le restaurant Le Vavin ne peut accueillir que 80 personnes. Pour cette soirée exceptionnelle, il faudra réserver sa 3ième mi-temps sur le site du ParisJUG. Et la 3ième mi-temps commencera par une surprise !

4e mi-temps. Pour les plus courageux direction le Falstaff à partir de 3h du matin … jusqu’à … et bien jusqu’à ce qu’on décide qu’on a assez fait la fête.

Cet article a été rédigé par Audrey Neveu et Claude Falguière.

Vous voulez prouver à tout le monde que non content d’être là mardi vous avez écouté David  avec toute la discipline de padawan requise et que vous n’étiez pas en train de chercher la fève gagnante parmi les galettes du buffet ?

Alors faites le test et frimez devant vos collègues en réalisant un 100% parfait !

A – Mon build prend trop de temps mais c’est pas grave, vu la rapidité de Maven, personne ne s’en rendra compte
B – C’est trop long, je le supprime et j’arrête les tests
C – Cool, je peux rester à jour de ma timeline Twitter tout en jouant sur Facebook !
D – J’ai toujours un test en train de tourner, c’est parfait car je travaille en NTD (Neverending Test Development)

A – Se maquille outrageusement et met des platform boots
B – Fait beaucoup de bruit
C – Applique le principe KISS (Keep It Simple, Stupid)
D – Viens nous voir

A – Avec une solution d’intégration continue multi-agent avec Hudson parallélisée sur un cloud
B – Si je change pour un quadri-coeur
C – En utilisant l’option “-T4” de Maven3 dans la commande “mvn clean install”
D – Si chaque test est plus performant
E – Si on enlève ceux qui ne servent à rien

A – En retournant jouer dans mon bac à sable
B – En cassant tous mes gros tests en petits morceaux
C – En me laissant pousser la barbe et en me teignant en roux dans l’espoir de ressembler à David Gageot
D – En délaissant Sélénium pour tester le code de l’IHM au profit d’un vrai test unitaire en Javascript
E – En améliorant mon code

A – Ils servent à accueillir les nouveaux tests
B – Ils permettent de vérifier que l’application fonctionne de bout en bout
C – Ils testent les spécifications du domaine
D – Ils sont nécessaires pour tester l’IHM

A – A dupliquer tous les tests unitaires pour les passer 2 fois au cas où
B – A montrer qu’Eclipse c’est quand même vachement mieux qu’IntelliJ IDEA vu que ça n’existe pas pour d’autres IDE
C – A fournir des tas de fonctionnalités super sympa aux courageux développeurs qui testent envers et contre tout et peuvent alors siffler en testant
D – A lancer le test depuis la classe sous test unitaire

A – A ne jamais terminer chaque test pour faire du NTD (Neverending Test Development)
B – A rejouer les tests impactés de manière transitive par la modification d’une classe
C – A embêter les gens qui utilisent TestNG pour qu’il reviennent à JUnit
D – A visualiser rapidement quel test est mis en échec par les modifications qui viennent d’être apportées dans le code

A – Un truc plus tendance que Hamcrest
B – Un outil qui extrait les règles à vérifier du code pour éliminer la maintenance
C – Une librairie qui permet d’écrire les assertions de manière plus naturelle
D – Un site pour s’assurer qu’il y a toujours un festival dans le coin

A – @Rule
B – @AfterTestWhenAllIsFine
C – @Theory
D – @Categories et @SuiteClasses

Les réponses sont dans un post secret protégé par mot de passe, mais comme on sait que vous allez répondre à tout en 5 mn et ne pas pouvoir patienter plus longtemps pour prouver à vos collègues que vous êtes maintenant incollable sur les tests unitaires, le voici : testsrocks

Les photos sont de José Paumard du Paris JUG.