Netapsys Blog - java

Groovy : retour sur la présentation du Paris JUG

Can Atac — Wed, 10 Sep 2008 08:17:00 +0200

Le JUG de Paris présentait le 9 septembre le langage Groovy et le framework associé Grails. Près de 200 personnes y assistaient dont, au moins, trois représentantes de la gente féminine !

Piètre programmeur java et amoureux de musique 'soul', je dois avouer que ma curiosité a d'abord porté sur le caractère "funky groove" du nom du langage et de son logo.
Cela dit, quand un vieux bonhomme de 37 balais comme moi discute de Groovy avec une jeune recrue et sort :
"Oh là là, encore un nouveau langage à apprendre" et que ce dernier répond
"Oui, mais c'est comme du java",
la crise naissante de la quarantaine m'a motivé à titiller mes neurones en comprenant mieux l'intérêt porté par les développeurs et ainsi, objectif ultime, de rester "hype" ;)

La présentation de Groovy m'a rassuré en tout point :

D'abord, vu le monde, c'est vraiment tendance ensuite c'est gratuit et open source !
C'est un langage de script où le typage est dynamique (et donc un peu plus gourmand en ressources)
C'est vrai, ça ressemble beaucoup à du java
Je peux continuer à utiliser Eclipse avec un plugin adapté (à ce propos, le présentateur a une préférence pour IntelliJ)
Je peux allier java et groovy dans une même application : une classe groovy peut étendre une classe java, et vice-versa (c'est ce qu'on appelle la "protection de son investissement"), et je peux mettre des petits bouts de code groovy dans mon code java (version 6 avec l'API javax.script)
Groovy est en avance sur Java : il y a des "closures" (des fonctions définies dans des fonctions...je crois) dans la version actuelle (1.5 depuis nov. 2007), j'avoue que j'ai eu un peu de mal à saisir leur intérêt, j'attends que quelqu'un m'éclaire...
Des grands comptes ont des applications en groovy : 50000 lignes de code pour une mutuelle américaine (la moitié représentant des tests...ouch !...)

Côté productivité : Des petits exemples sur la manipulation de listes et de Datasets avec moins de lignes de code montrent qu'effectivement, le programmeur va plus vite.

Quelle conclusion pour un débutant qui connaît java :

Facile à installer, à utiliser
Une programmation plus rapide
Pour ma part, une étape initiatique avant d'aller vers Ruby

Quelle conclusion pour un décideur :

La prise de connaissance ne coûte pas chère !
Un gain de productivité (qui reste néanmoins à mesurer)
Il protège son investissement

Bon c'est vrai, j'ai toujours un peu de mal à trouver des arguments chocs pour convaincre une Direction Financière de changer de techno...je vais travailler cela...

Netapsys sur le JDN Développeurs - Intéropérabilité entre Java et .NET : rêve ou réalité ?

Sébastien Hébert — Mon, 01 Sep 2008 11:39:00 +0200

Netapsys publie un nouvel article sur le Journal du Net dressant une synthèse sur l'interopérabilité entre Java et .NET via les Services Web.

Si le sujet n'est pas nouveau en soi, quelques progrès sont à noter à savoir une meilleure prise en charge de la sécurité (authentification par certificat, etc.) et de la gestion transactionnelle. Les outils/technos dont il est question sont WCF 3.0 (Windows Communication Foundation apparu avec .NET 3.0) et Metro (piles de services Web) disponible dans Glassfish et utilisable sous Tomcat (implémentation à base de servlet disponible uniquement).

PS : Un grand merci à Yoann, Jérémy et Jean-Baptiste pour leurs retours.

Première rencontre du Nantes JUG

Sébastien Roul — Sat, 09 Aug 2008 09:24:00 +0200

Au menu, Intégration Continue.

Nantes JUG annonce sa première rencontre : le jeudi 11 septembre !

La rencontre sera l'occasion de voir :

Quels outils peuvent être utilisés: Maven, Hudson, CruiseControl, Sonar
Quelles sont les étapes importantes de la mise en oeuvre : L'infrastructure
Comment ça fontionne au quotidien : Mylyn, Jira, TRAC, les tests, un métier d'ingénieur qui change !
Quel est le retour d'expérience : Retour sur un an d'utilisation

L'Ecole des Mines de Nantes nous accueillera dans ses locaux pour ce premier évènement.

Inscrivez-vous vite : ICI

NANTES JUG : Communauté des utilisateurs JAVA de NANTES.

Un JUG printanier

Darko Stankovski — Wed, 11 Jun 2008 00:43:00 +0200

Pour le dernier JUG Parisien de printemps, le thème était le framework Spring. La mouture 2.5 est en effet sortie il y a environ 2 mois, accompagnée de son lot de nouveautés.

Retour sur cette soirée riche en enseignements.

Une des évolutions, qui concernera le plus grand monde, est l'utilisation plus importante des annotations qui permet de décharger de manière très importante les fichiers de configuration. En effet, l'une des grandes critiques que l'on pouvait faire à propos de Spring, est le volume de fichier de configuration XML. Avec cette mouture 2.5, la configuration XML devrait elle aussi être réduite puisqu'elle ne devrait concerner que la partie initiale du projet. Au développeur par la suite de tirer profit des annotations que Spring met à disposition pour alléger le code technique. Ceci a été illustré par le développement d'une fonctionnalité de Blog par la méthode des TDD (Test Driven Developement, Développement Dirigé par les Tests) par Christian Blavier au micro et Jean-François Hélie au clavier. Cette démonstration a pu mettre en avant l'avantage de cette méthode qui tire pleinement avantage de ce qu'offre Spring 2.5, ainsi que des outils associés tel que Unitils qui permet de tirer profit de DBUnit et EasyMock pour les tests (plus ou moins) unitaires.

La présence de Julien Dubois et Michaël Isvy, de SpringSource, a permis d'approfondir les nouveautés de Spring 2.5. Parmi celles-ci, Spring Security, évolution d'Acegi Security, est l'une des plus marquante. Acegi Security, bien que très bon outil de sécurité, avait comme gros défaut d'être très complexe à manipuler. Spring Security 2.0 équilibre la donne en réduisant la complexité, notamment au niveau du fichier de configuration, tout en permettant une gestion fine de la sécurité. Il est ainsi possible de laisser Spring Security gérer les cookies d'authentification, de bloquer 2 authentifications simultanées, et par les méthodes d'interception, de gérer les autorisations d'appel de toute méthode des objets gérés par Spring. Tout cela peut faire l'objet d'un prochain billet...

Pour le reste des nouveautés, il faut citer Spring Dynamic Modules For OSGi(tm) Service Platforms qui a pour objectif de proposer des modules Java (et non pas juste des archives). Je vous laisse découvrir ce sujet sur la présentation disponible sous peu sur le site de Paris Jug. On citera donc aussi Spring Batch, Spring Web Flow, Spring WebServices... Tant de projets qui apportent de manière souple des facilités pour le développement de nos applications Java.

Nouvelle version de Sonar

Jean-Baptiste Defard — Mon, 09 Jun 2008 14:22:00 +0200

La version 1.3RC1 est sortie la semaine dernière. J'ai retardé la mise en production car dans l'infrastructure test la migration depuis la version 1.2.1 supprimait des mesures. Renseignement pris (merci Simon), il semblerait qu'il faille relancer une collecte pour que les mesures réapparaissent. Je suis vraiment très content de l'évolution du logiciel. Il s'améliore à chaque nouvelle version.

Les nouveautés :

Possibilité de déployer sous Tomcat
Détails des mesures par paquetage (très pratique :-))
Nouveaux ratios pour les commentaires et le code dupliqué
Amélioration des performances de l'ensemble

Pour les notes de releases c'est par ici. Un site de démonstration a été ouvert en même temps que la release de la 1.3RC1.

La prochaine version (1.3) devrait sortir au début du mois de juin et semble bien avancée.

Polymorphisme des listes génériques

Michael Courcy — Tue, 27 May 2008 13:19:00 +0200

Avec Java 5 les développeurs ont vu pour leur plus grand bonheur arriver dans le langage les types génériques. On allait enfin pouvoir manipuler les List, Set et Map avec un typage fort.

Par exemple avec Java 4, lorsque l'on créait une list, on pouvait y mettre n'importe quel objet :

List menagerie = new ArrayList();
menagerie.put(new Animal());
menagerie.put(new Cat());
menagerie.put(new Dog());
//arg faut pas que je fasse ça
//mais le compilateur ne dit rien 
menagerie.put(new HumanBeing());

Bien sur les risques d'erreurs étaient très élevés car le développeur était le seul garant qu'on ne mettait pas n'importe quoi dans la liste. Sans parler du code de cast que l'on devait écrire pour récupérer les type adhoc :

Iterator it = menagerie.iterator();
//cast obligatoire même si je sais que ma 
//list ne contient que des animaux
Animal animal = (Animal) it.next();

Mais en Java 5 tous ces problèmes sont "résolus" avec les types génériques (je dis résolu entre guillemet vous allez bientôt voir pourquoi).

List menagerie<Animal> = new ArrayList<Animal>();
menagerie.put(new Animal());
menagerie.put(new Cat());
menagerie.put(new Dog());
 
//compile pas ....
menagerie.put(new HumanBeing());

Enfin plus de cast necessaires lorsqu' on parcourt la liste :

Iterator<Animal> it = menagerie.iterator();
//pas obligé de caster
Animal animal =  it.next();

Mais quid du polymorphisme des types génériques ?

C'est ici que les développeurs ne comprennent plus, et c'est compréhensible.

Supposons que je développe une methode

public void nourrit(List<Animal> menagerie);

J'aimerais pouvoir l'invoquer en lui passant une liste de chats par exemple

List<Cat> cats = new ArrayList<Cat>();
//compile pas ....
nourrit(cats);

Ce code ne compile pas, la méthode nourrit attend une liste d'animaux pas une liste de chats, même si le chat est un animal ... Difficile de comprendre pourquoi, le chat hérite de animal, donc tout ce que cette méthode fait avec des animaux elle doit pouvoir le faire avec des chats. Logique et pourtant non le compilateur refuse.

Deux questions viennent alors :

Pourquoi ?
Il y a-t-il une solution à ce problème ?

Répondons à la première : Pourquoi ?

Cette situation est d'autant plus troublante que le polymorphisme avec les tableaux est quant à lui possible :

//j'ai développé cette méthodes
public void nourrit(Animal[] menagerie);
 
//compile sans problème car Cat hérite de Animal
Cat[] cats = new Cat[15];
nourrit(cats);

Seulement vous pouvez aussi faire de grosses bêtises : Supposons que je développe cette méthode qui met un chat en tête du tableau d'animaux qu'on lui passe

public void metUnChatAuDebut(Animal[] animals){
   animals[0] = new Cat();
}

Je peux tout à fait invoquer cette méthode de la façon suivante :

Dog[] dogs = {new Dog(), new Dog(), new Dog()};
//ça compile parfaitement
metUnChatAuDebut(dogs);
//aïe !!! J'ai mis un chat dans un tableau de chiens, pauvre minou !

Si vous exécutez ce code, vous déclencherez une ArrayStoreException. C'est le chat qui souffle : jamais il n'aurait pensé que l'ArrayStoreException lui serait un jour salutaire.

En clair à l'exécution la machine virtuelle sait que le tableau qui lui est passé est un tableau de Dog et qu'on ne peut y mettre que des Dog ou des classes héritant de Dog et si vous avez pu échapper à la vigilance du compilateur vous n'échapperez pas à celle de la machine virtuelle.

Mais pour les listes typées, il en va tout autrement. En effet, pour pouvoir maintenir le code qui a été écrit à l'époque où les listes n'étaient pas génériques, Sun a choisi de ne faire de la généricité qu'une affaire de compilation. En fait au niveau bytecode ce sont toujours des Objects qui sont manipulés, ajoutés, retirés.

Ce qui signifie que par rapport à l'exemple précédent, on pourrait aller un cran plus loin dans l'exécution et effectivement mettre un chat dans une liste de chiens, car pour la JVM on met finalement un Object dans une liste d'Objects et ça pour le chat ça risque d'être un moment très pénible.

C'est parce que cette sécurité supplémentaire n'existe pas que Sun a décidé d'interdire une utilisation aussi directe du polymorphisme :

public void ajouteUnChat(List<Animal> animals){
   animals.add(new Cat());
} 
 
List<Dog> dogs = new ArrayList<Dog>(); 
dogs.add(new Dog()); 
dogs.add(new Dog()); 
dogs.add(new Dog());
//ça ne compilera pas !!!
//et c'est peut être pas plus mal ...
ajouteUnChat(dogs);

Et ceci nous amène à la deuxième question.

Y a-t-il une solution à ce problème ?

Oui, mais à deux conditions :

si vous promettez de ne faire que des opérations de lecture sur la liste alors vous pourrez passer une liste de Dog à une méthode attendant une liste d'Animal
En respectant la syntaxe wildcard

public int compteLesAnimaux(List<? extends Animal> animals){
   //fait une opération qui n'ajoute pas d'élément à la liste 
   //ou ne réassigne pas un élément de la liste 
   //par exemple
   return animals.size() 
} 
 
List<Dog> dogs = new ArrayList<Dog>(); 
dogs.add(new Dog()); 
dogs.add(new Dog()); 
dogs.add(new Dog());
//ça compile !!
compteLesAnimaux(dogs);

Mais ce code ne compilera pas :

public void ajouteUnChat(List<? extends Animal> animals){
   //erreur de compilation 
   animals.add(new Cat());
} 
 
//ce qui suit ne présente pas beaucoup 
//d'intérêt puisque ce qui précède ne 
//compile pas
List<Dog> dogs = new ArrayList<Dog>(); 
dogs.add(new Dog()); 
dogs.add(new Dog()); 
dogs.add(new Dog());
ajouteUnChat(dogs);

Si la généricité avait été proposée dès le départ, Sun aurait certainement eu d'autres options. On peut dire que les choix qui ont été faits sont ceux du moindre mal, mais dès lors ils deviennent un peu difficile à appréhender.

Vous trouverez en pièce jointe un micro projet eclipse illustrant mes propos.

Maven au ParisJUG

Jean-Baptiste Defard — Sun, 18 May 2008 12:19:00 +0200

J'ai assisté mardi soir dernier à la présentation, par Arnaud Heritier, de Maven au Paris JUG . C'était une présentation vraiment intéressante. Arnaud a répondu avec beaucoup d'intelligence et de gentillesse à un certain nombre de questions concernant la communauté, l'organisation des repositories, les plugins et l'avenir du projet. Il a présenté les principales nouveautés de la version 2.0.9 et l'actualité de la communauté.

Concernant les bonnes pratiques, des confirmations de ce que nous faisons déjà :

Utiliser Maven 2.0.9 sur lequel un gros travail d'amélioration a été réalisé, notamment en ce qui concerne la gestion des dépendances.
Eviter les mises à jour automatiques des plugins en déclarant les versions des plugins utilisés dans le POM.
Déclarer les versions des dépendances dans le POM parent et référencement dans les POM dérivés.
Même si Maven 2.0.9 améliore les choses, ne pas faire (trop ) confiance à la résolution des dépendances transitives.
Limiter l'utilisation des profils au strict minimum indispensable pour les configurations multi-environnements.

Pour la configuration des plugins de rapport, il faut placer la configuration par défaut dans la section <report> et éventuellement modifier cette configuration par défaut dans la section <build> d'un POM dérivé. Autre information intéressante, configurer les plugins de rapport dans la section <pluginManagement> ne sert à rien, car cette configuration est ignorée.

L'intégration à Eclipse devrait s'améliorer notablement d'ici à la fin de l'année. Eclipse prévoit d'intégrer dans ses distributions soit le plugin Q4e, soit le plugin m2Eclipse. Ces deux plugins sont actuellement en compétition pour l'intégration à Eclipse. Netbeans a, semble-t-il, un meilleur support de Maven 2.

En passant, j'ai bien apprécié la nouvelle fonctionnalité de Maven 2.0.9 permettant de modifier les dépendances d'un plugin. Vraiment pratique, par exemple pour utiliser AspectJ 1.6.0 avec le plugin maven.

En résumé, une bonne soirée au JUG et plein d'informations utiles pour améliorer les builds.

Nantes JUG : c'est parti !

Sébastien Roul — Fri, 09 May 2008 17:08:00 +0200

Le JUG (Java User Group) de Nantes est lancé !

Un JUG pour quoi faire ?

Le but est de réunir les acteurs nantais du langage (professionnels, communautés open source, institutions, étudiants, enseignants...) afin d'échanger des idées et de discuter "Java".

Un JUG pour qui ?

Tous les passionnés de JAVA qui souhaitent échanger dans un autre cadre que l'école ou le boulot.

Un JUG pour quand ?

Nous lançons les bases du projet dès la semaine prochaine, l'idée est d'être opérationnel en Septembre.

Y a t'il des personnes motivées pour participer à l'aventure ? N'hésitez pas à nous contacter : team@nantesjug.org

JUG2B : le ParisJUG étend son périmètre d'action

Yoann Hébert — Wed, 30 Apr 2008 21:56:00 +0200

Par définition, un JUG (Java User Group), concentre naturellement les adeptes les plus ferrus de Java : du développeur au chef de projet technique en passant par l'architecte. Mais c'est bien connu, la consanguinité peut rapidement générer quelques problèmes... ! ;-)
L'équipe du ParisJUG l'a bien compris et a décidé, à peine 4 mois après le lancement du JUG, de l'ouvrir à une population plus large : c'est le cadre du JUG2B (JUG to Business). Son objectif est d'associer les dirigeants (informatiques, ressources humaines, ...) à la démarche et de rassembler l'ensemble des acteurs tous les trimestres, autour de thèmes plus larges que lors des réunions mensuelles. Rassurez-vous, il y est toujours question d'informatique !

La première session du JUG2B, prévue le 12 juin, abordera deux thèmes intitulés "Meilleurs développeurs" et "Comment attirer et garder les développeurs".

Plus d'infos sur le site du JUG.

Java events : à vos agendas !

Yoann Hébert — Tue, 15 Apr 2008 11:38:00 +0200

Le retour du printemps et l'arrivée des beaux jours (si, si, ils finiront bien par arriver un jour), s'accompagnent traditionnellement de conférences et de rencontres en tout genre. Deux d'entre elles intéresseront particulièrement les développeurs et architectes Java, TheServerSide Java Symposium et Jazoon08.

TheServerSide Java Symposium

La version européenne de cette manifestation aura lieu à Prague du 18 au 20 juin 2008. Sa version américaine avait eu lieu à Las Vegas du 26 au 28 mars 2008.

Au programme de cette manifestation, de nombreuses présentations qui se veulent suffisament pragmatiques pour permettre aux développeurs et aux architectes java d'en tirer rapidement profit. Elles traiteront par exemple de sujets intitulés "Spring Dynamic Modules", "Integrating JPA and Hibernate with RIA", ou bien encore "JRuby on Rails: Web Development Evolved".

Comptez environ US $ 1 800 pour l'inscription (une réduction de US $ 200 est accordée aux Juggers).
Inscription et renseignements : http://javasymposium.techtarget.com/europe/index.html

Jazoon08 - "The international conference on java technology"

Cette manifestation aura lieu du 23 au 26 juin 2008 à Zurich. Ces 4 jours seront ponctués de différents types de session : "Tutorials", "Technical sessions", "Exhibition", ... ainsi que, pour les passionnés de Java ET de foot, une "After hours" un peu spéciale consacrée à la demi finale de l'euro 2008 !

Comptez 1 045 € pour l'inscription (tarif ramené à 785 € pour les membres d'un JUG).
Inscription et renseignements : http://jazoon.com