insideIT.fr : le blog des architectes IT de SFEIR

Aller au contenu | Aller au menu | Aller à la recherche

Java

Fil des billets - Fil des commentaires

jeudi 12 mars 2009

JBoss TattleTale, un outil de vérification de dépendances

Par Mohamed Abdennebi le jeudi 12 mars 2009, 13:45

Actuellement, j'effectue la migration vers Maven de quelques applications historiques. La difficulté de cette tâche réside dans le dépouillement et l'inventaire des fichiers JAR desquels dépend une application. En effet, on se retrouve face à un amas de fichiers JAR parmi lesquels se trouvent des doublons (mais avec un nom différent ou une version différente), des fichiers appartenant au serveur d'applications (par exemple, servlet.jar ou connector.jar), d’autres qui ne sont plus utilisés par l'application, et parfois même des fichiers de bibliothèques de tests unitaires (par exemple junit.jar). Le travail consiste alors à ne garder que les JAR qui sont réellement utilisés, et d'éliminer avec la plus grande précaution tous les autres. Il va sans dire qu’attaquer un tel problème à « mains nues » n'est pas une mince affaire.

C'est en cherchant un outil de vérification de dépendances que je suis tombé sur l'utilitaire « JBoss Tattletale » qui, à ma grande chance, vient de sortir - en version bêta - des laboratoires de JBoss (voir l'annonce sur le Blog de JBoss).

Cet outil permet de vérifier les dépendances entre les fichiers JAR présents dans un même répertoire considéré comme un classpath. Ses fonctionnalités les plus remarquables sont :
  • Identifier les dépendances entre les fichiers JAR (par exemple, hibernate-3.1.3.jar dépendant de antlr-2.7.6rc1.jar)
  • Lister les classes dont dépend un fichier JAR et lister celles qu'il expose.
  • Lister les classes dont dépend un JAR, mais qui sont absentes du classpath.
  • Lister les classes présentes dans le classepath et les fichiers JAR dans lesquels elles se trouvent
  • Alerter si une classe est présente dans plusieurs fichiers JAR.

L'outil s'utilise en ligne de commande et sa prise en main est rapide. Il génère un rapport au format HTML dans lequel on peut naviguer aisément (voir la capture d'écran ci-contre).

Cet outil m'a vraiment aidé à effectuer la vérification des dépendances lors de la phase préliminaire de migration vers Maven. Malheureusement, il ne dispose pas (pour l'instant?) de plugin Maven permettant l'automatisation de cette tâche (de son coté, ANT dispose déjà d'une tâche tattletale).

Enfin, si vous vous demandez ce que veut dire «tattletale» sa définition se trouve ici. En résumé, «tattletale» est une personne commère qui révèle les secrets. On voit bien que e nom n'a pas été choisi par hasard !
L'outil, qui me semble très prometteur, en est tout juste à ces débuts. Souhaitons-lui un bel avenir!

Liens utiles :

Téléchargement : http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=311046&release_id=665534 (800ko environ)

JIRA : https://jira.jboss.org/jira/browse/TTALE

lundi 9 mars 2009

Android et son SDK

Par Arnaud Weber le lundi 9 mars 2009, 13:09

Vous en avez surement entendu parler, Google a sorti dernièrement son système d'exploitation pour mobile : Android. Parallèlement, Google a sorti un kit de développement afin que tout le monde puisse développer des applications et les partager au monde entier. Cet article va vous présenter ce kit de développement et vous présenter les bases à connaitre pour développer une application Android.

Lire la suite...

jeudi 19 février 2009

Intégration de Guice avec les RemoteServiceServlet de GWT

Par Florent le jeudi 19 février 2009, 14:29

La dernière version snapshot de Guice intégre des fonctionnalités intéressantes pour les Servlets, notamment de nouveaux Builders qui viennent du projet warp-servlet et qui permettent de configurer des mappings de Servlet ou de Filter directement dans un module. Vous pouvez obtenir les sources de l’exemple décrit dans cet article ici.

Au lieu de définir nos RemoteServiceServlet dans le web.xml (ce qui est désormais le cas avec GWT 1.6), nous allons déclarer un GuiceServletContextListener et un GuiceFilter :


 1 <?xmlversion="1.0"encoding="UTF-8"?>
 2 <web-app>
 3 

 4 <!-- Default page to serve -->
 5 <welcome-file-list>
 6  <welcome-filecda.html</welcome-file>
 7 </welcome-file-list>
 8 

 9 <listener>
10  <listener-classcom.sfeir.server.CdaGuiceServletConfig
11  </listener-class>
12 </listener>
13 

14 <filter>
15  <filter-nameguiceFilter</filter-name>
16   <filter-classcom.google.inject.servlet.GuiceFilter
17  </filter-class>
18 </filter>
19 

20 <filter-mapping>
21  <filter-nameguiceFilter</filter-name>
22  <url-pattern/*</url-pattern>
23 </filter-mapping>
24 

25 </web-app

GuiceServletContextListener crée une instance d’Injector avec la méthode getInjector(), nous pouvons alors définir notre module en redéfinissant cette méthode :


 1 public class CdaGuiceServletConfig extends GuiceServletContextListener
 2 {
 3     @Override
 4     protected Injector getInjector()
 5     {
 6         return Guice.createInjector(new ServletModule()
 7         {
 8             @Override
 9             protectedvoid configureServlets()
10             {
11                 serve("/cda/echo").with(EchoServiceImpl.class);
12                 serve("/cda/spreadsheet").with(SpreadSheetServiceImpl.class);
13 ...

Nous utilisons pour cela une classe anonyme qui hérite de ServletModule : les méthodes «serve» et «filter» de cette dernière nous permettent de faire l’équivalent de huit lignes de XML pour déclarer une Servlet ou un Filter en une seule ligne de Java.

«serve» fonctionne directement avec les RemoteServiceServlet de GWT (il faut néanmoins ajouter y l’annotation Singleton), par contre les scopes Session et Request de la classe ServletScopes ne peuvent pas être utilisés : nous allons devoir hériter de la classe RemoteServiceServlet pour y ajouter notre propre Scope Session et par la même occasion ajouter un champ «injector» qui contiendra l’objet Injector créé par notre classe CdaGuiceServletConfig.

Dans notre ServletModule, nous rajoutons un appel à «bind» qui associe l’interface SpreadsheetManager à une implémentation :


 1                 bind(SpreadsheetManager.class).
 2                         to(SpreadsheetManagerImpl.class);

Ainsi l’appel de getInstance de l’object Injector avec SpreadsheetManager.class en paramètre renverra une instance de SpreadsheetManagerImpl.


 1 @Singleton
 2 public class SpreadSheetServiceImpl extends GuiceRPCServlet implements SpreadSheetService
 3 {
 4 

 5     @Override
 6     public List<String> fetchSpreadsheetList()
 7     {
 8         SpreadsheetManager manager = injector.getInstance(SpreadsheetManager.class);
 9         ...

Par défaut, l’Injector de Guice renvoie toujours une nouvelle instance. Nous pouvons également utiliser l’annotation Singleton ou dans le cas présent notre propre annotation GwtSessionScoped afin qu’une même instance soit réutilisée, par exemple le temps d’une session.


 1                 bindScope(GwtSessionScoped.class,
 2                         GuiceRPCServlet.SESSION);
 3                 bind(GoogleService.class).toProvider(
 4                         SpreadsheetServiceProvider.class).
 5                         in(GwtSessionScoped.class);

Ainsi les champs injectés de type GoogleService seront créés une première fois puis récupérés dans la session en cours. Ce mécanisme fonctionne quand l’Injector de Guice est appelé, il est donc exclu de l’utiliser sur des champs d’une RemoteServiceServlet.


 1 public class SpreadsheetManagerImpl implements SpreadsheetManager
 2 {
 3     @Inject
 4     private GoogleService service;
 5 

 6     @Inject
 7     @Named("user")
 8     private String username;
 9     @Inject
10     @Named("pass")
11     private String password;
12 

13     @Override
14     public void authenticate()
15     {
16         try
17         {
18             service.setUserCredentials(username,password);
19         } ...

L’annotation Named est utile pour injecter objets de même type sans avoir à créer de nouvelle annotation. La méthode statique «named» crée cette annotation pour l’utiliser dans les instructions de binding.


 1                 bindConstant().annotatedWith(named("user")).
 2                         to("cappelle.florent@gmail.com");
 3                 bindConstant().annotatedWith(named("pass")).
 4                         to("*************");

Finalement, Guice permet aussi d’ajouter des fonctions transverses à nos services en «bindant» un intercepteur sur un ensemble de méthodes :


 1                 bindInterceptor(subclassesOf(SpreadsheetManager.class),
 2                         returns(subclassesOf(List.class)),
 3                         new LoggingInterceptor());

Ici, LoggingInterceptor est appliqué aux classes qui héritent de SpreadsheetManager et plus particulièrement aux méthodes de ces classes dont le retour est de type List. Les classes d’interception doivent implémenter MethodInterceptor de l’API aopalliance.

Vous aurez sans doute deviné que LoggingInterceptor fait un log des appels de méthode, la sécurité et les transactions étant les autres exemples typiques d’utilisation des MethodInterceptor.

En conclusion, Google Guice constitue une alternative intéressante à Spring pour l’injection de dépendance. Dans certains cas, on pourra également utiliser les méthodes de la classe SpringIntegration afin de réutiliser une configuration XML existante.

Liens :

mercredi 11 février 2009

Le Paris JUG a 1 an

Par Pierre Mage le mercredi 11 février 2009, 01:16

Paris JUG

Ce soir le Paris JUG fêtait son premier anniversaire dans une ambiance chaleureuse.

Quelques chiffres sur l'année passée :

  • Un public composé majoritairement de développeurs seniors et d'architectes ;
  • Le site Web compte 15000 visites pour les 7 derniers mois (majoritairement d'île de France).

A suivi un quicky d'un quart d'heure sur Wicket par Tarik Filali Ansary.
Wicket m'a semblé être un framework recherchant des objectifs similaires à GWT : simplifier la vie des développeurs Java pour la création d'application Web.
Rien n'est plus explicite que quelques exemples.
De plus Wicket semble jouir d'une communauté très active : Wicket Stuff, Wicket Library.

Par la suite, nous avons pu nous rendre compte combien les JUG florissent en France. En effet, cette session avait pour invités d'honneur des représentants de tous les JUG français : Christophe Jollivet (Tours JUG), Xavier Hanin (Bordeaux JUG), Nicolas Leroux et Stephane Epardaud (Riviera JUG), Nicolas de Loof (BreizhJug), Sebastien Roul (Nantes JUG), Christophe Meyer, JM Doudoux et Xavier Roy (Lorraine JUG), Gaël Blondelle (Toulouse JUG), Julien Ripault et Cédric Exbrayat (Lyon JUG).

Puis Christian Frei a présenté Jazoon09 de manière très dynamique.

Ce fut ensuite le tour de Stephan Janssen avec pour sujet Parleys.
J'avais déjà assisté à la présentation de la version Flex de Parleys durant JavaPolis07 mais je ne pense pas me tromper en disant que Stephan a eu beaucoup d'effet sur l'assemblée de Juggers en présentant les versions prototype JavaFX et surtout GWT !
Pour la partie moins fun, Parleys proposera bientôt des espaces professionnels pour poster des présentations. Ces espaces seront gratuits pour les JUGs.
Pour finir, Stephan a continué d'envoyer la purée en présentant l'outil de post-processing vidéo qu'il a développé (avec Adobe AIR) pour traiter les enregistrements des conférences Devoxx.

Pour la présentation de Java SE 7 Dolphin, ... et bien, j'étais en train de me faire masser donc je n'ai pas pu prendre de notes ! D'ailleurs merci aux masseurs et aux organisateurs du Paris JUG, c'était un très bonne idée, et toutes mes excuses à Thomas Chamas.
Par contre je me souviens en avoir entendu parler durant une keynote de Devoxx08

Le dernier quicky traitait de l'état de l'art et de l'utilisation de Java dans les jeux vidéo (avec Java Binding for Open GL) par Julien Gouesse.
J'avoue qu'il m'a bluffé. Je ne savais pas que des jeux développés en Java étaient commercialisés même s'ils se comptent sur les doigts.
Pour les personnes intéressées par ce genre de développement, le code source du doom-like TUER développé par Julien est dispo ici.
Par ailleurs, la fluidité de la démonstration du jeu TUER a également bluffé l'ensemble des spectateurs : voir un jeu 3D développé en java aussi fluide, j'avoue que je ne m'y attendais pas.

lundi 2 février 2009

JavaFX : Widgets pour applications professionnelles

Par David MARTIN le lundi 2 février 2009, 14:05

Le petit dernier des candidats aux applications RIA, JavaFX, est sorti dépourvu des composants graphiques utiles et nécessaires au développement d'applications à destination des professionnels. Comme Sun semble occupé à mettre le paquet sur une prochaine release en début d'année, incorporant la partie "Mobile", il est peu probable d'en voir arriver tout de suite par le canal officiel.

Alors, quels sont les choix ? Et bien, on se retrouve un peu comme aux débuts de GWT : nous avons un socle technique, il ne reste qu'à retrousser ses manches. Oui mais voilà, tout le monde ne souhaite pas réinventer la roue.

Alors inspirons nous de ce qui a été largement fait pour GWT (par exemple) : le wrapping. Avec GWT il est relativement aisé de wrapper les librairies JavaScript (Ext, SmartClient...) pour pouvoir utiliser les composants existants et souvent de qualité. Avec JavaFX, il est permis de wrapper n'importe quel composant Swing étendant javax.swing.JComponent, autrement dit un nombre assez conséquent :-)

Certes la tâche peut paraitre conséquente - et elle l'est d'ailleurs - mais si une communauté prend autour de JavaFX, des librairies de ce type peuvent rapidement apparaître. Voici un tutorial illustrant comment wrapper la célèbre librairie JFreeChart, tant utilisée par ailleurs !

Lire la suite...

lundi 19 janvier 2009

Compte-rendu de la soirée Java EE 6 et GlassFish V3 au Paris JUG

Par Tanguy Bayard le lundi 19 janvier 2009, 21:38

La semaine dernière s'est tenu la première réunion du Paris JUG de l'année !

Au menu, présentation de la future spécification Java EE 6 par Antonio Goncalves (également co-organisateur du Paris JUG), et présentation du serveur d'applications de Sun - Glassfish - par Alexis Moussine Pouchkine.

La soirée commence avec quelques annonces :

  • La prochaine réunion sera spéciale, le Paris JUG fêtera sa première année (déjà !). Pour l'occasion, les organisateurs des JUG français ainsi que l'organisateur de Devoxx seront présents, et on aura le droit à une série de Quickies sur différents sujets. Tarik Filali Ansary, chef de projet technique chez Sfeir, viendra nous présenter Wicket.
  • Le Paris JUG, attirant de plus en plus de monde, commence à être victime de son succès. Trop de monde, pas assez de budget pour investir dans une autre salle -> inscription obligatoire pour les prochaines réunions.
  • Après XP France, un nouveau groupe d'agilistes est en cours de création, le French Scrum User Group. Lancement prévu le 19 mars, avec Jeff Sutherland himself, rédacteur du manifeste agile et fondateur de Scrum.

Ces annonces faites, Antonio a commencé à nous présenter Java EE 6. Pour info, Antonio est JCP Expert Member de Java EE 6, JPA 2.0, et EJB 3.1. 

Java EE 6

Java EE 6, c'est 28 JSRs, environ 500 pages par spec. Le travail est encore en cours, peu de JSRs ont atteint le statut de public draft, et la sortie est prévue pour mai 2009.
... et présenté par Antonio, c'est façon Daft Punk : richer, easier, lighter !

Richer et en même temps lighter ?

Oui, c'est possible grâce à l'apparition :

  • des EJB Lite. La spécification EJB-lite est un sous-ensemble de la spécification EJB qui supprime notamment le support de RMI, EJB 2.x, Message Driven Bean.
  • des profiles. Le profile "web" permet de supporter la base de "Java EE", et même plus puisque cela inclut les EJB-Lite. Cela permettra à des serveurs d'applications légers d'être certifié sur un sous-ensemble de Java EE 6.
  • du pruning. Plus fort que le deprecated, le pruning doit permettre de se séparer des vieux morceaux obligatoirement présents en raison de compatibilité ascendante. A noter que Entity CMP, JAX-RPC et JAX-R seront "prunées" dans Java EE 6. Cela signifie que ces APIs seront tout simplement supprimées dans la spécification Java EE 7 !

Antonio a ensuite zoomé sur certaines spécifications :

  • Servlet 3.0 : on peut se passer du web.xml en le remplaçant par des annotations. Pour plus de modularité, il sera également possible de casser le web.xml en fragments. La nouvelle version de la JSR permettra également le mode asynchrone. Une partie du mode asynchrone est déjà implementée dans glassfish et permet de faire du reverse Ajax.
  • JSF 2.0 : de nouvelles annotations vont permettre de simplifier le développement d'applications JSF, et comme pour l'API Servlet 3.0, de rendre optionnel le fichier faces-config.xml. JSF 2.0 intégrera facelet.
  • EJB 3.1 : oh ! des annotations. Entre autres, une annotation Singleton, et une autre facilitant la gestion des appels asynchrones (par simple annotation sur une méthode d'EJB). Cela permet de se passer de l'utilisation de JMS qui peut être plus fastidieuse. Nouveauté également, on peut créer facilement un container d'EJBs à la volée (très pratique pour les tests unitaires). La définition d'EJB devient extrêment simplifiée : il suffit de rajouter l'annotation @Stateless pour qu'un simple POJO devienne un EJB, plus besoin de configuration XML lourde. D'autre part, pour un EJB local, une interface de l'EJB n'est plus nécessaire. Enfin, on pourra dorénavant créer des EJBs directement dans un WAR (plus besoin d'un EAR, qui contient un JAR EJB). Ainsi le développement d'EJB devient beaucoup plus simple à mettre en oeuvre pour un développeur. C'est cette simplicité qui a jusqu'ici fait défaut aux EJB, au profit de Spring. Dernier point : les noms JNDI des EJB deviennent portables (plus de nom JNDI adhérent au serveur d'applications).
  • Timer services : une nouvelle syntaxe apparaît (avec des annotations !), s'inspirant de Cron et de Quartz. Séduisant par son apparente simplicité.
  • JPA 2.0 : La spécification JPA 2.0 est désormais complètement indépendante de la spécification EJB, elle n'est plus vue comme un sous-ensemble de EJB (comme c'était le cas dans JPA 1.0, source de confusion). On notera la possibilité d'utiliser JPA 2.0 dans Java SE, de mapper des collections de types simples, d'utiliser des locks pessimistes, et une API "Criteria" (proche d'easyMock dans l'esprit). Rien de nouveau, mais JPA couvrira désormais plus largement les fonctionnalités d'Hibernate.
  • JAX-RS 1.1 : API permettant d'implémenter des Web Services RESTfull. Encore une fois, tout est basé sur les annotations. Il suffit de rajouter l'annotation @Path("/helloWorld") devant une classe POJO et une annotation @GET devant la méthode qui sera appelée pour les appels en méthode GET, pour obtenir une ressource REST. L'API est donc simple à utiliser. A voir pour les cas plus complexes.

Antonio nous a ensuite affiché un arbre représentant la stack technologique Java EE 6. Maintenant, avec la simplicité apportée par Java EE 6, on peut faire une application JSF / EJB / JTA / JPA dans un simple WAR.
Pour finir, on nous a présenté l'implémentation de référence de chaque JSR. GlassFish V3, présenté dans la 2e partie de soirée, sera l'implémentation de référence de EJB 3.1 et Servlet 3.0.

C'est tout pour la présentation de Java EE 6, qui sortira cette année. A noter que Java EE 5 a 3 ans et que la plupart des serveurs d'applications sont compliant Java EE 5 depuis peu, le dernier en date étant JBoss en décembre 2008...

La présentation s'est terminée par une session de questions-réponses, en voici quelques-unes :

  • D'un côté Java EE 6 présente 5 conteneurs différents, de l'autre Spring n'en présente qu'un, pourquoi, quel est l'intérêt ? Antonio répond que le sujet des Web Beans n'est pas tout à fait réglé, sans plus de détails. Nicolas Martignole semble avoir obtenu plus d'informations sur le sujet au cours de la 3ème mi-temps !
  • Pourquoi ne pas mettre plus le focus sur la JSR Servlet 3.0, ça semble pourtant être la principale avancée ? Réponse : Parce que cette spécification a été sujet à controverse, n'est pas finie, et n'est pas des plus faciles à appréhender.
  • JSF est un framework orienté composant, il n'y a rien sur les frameworks orientés actions ? Réponse : en effet !

GlassFish

Quelques retrouvailles / petits fours / t-shirts Glassfish plus tard, Alex Moussine-Pouchkine nous présente GlassFish. Plus précisément GlassFish V3 Prelude, qui est un "prelude to Java EE 6". GlassFish veut être early adopter de la spécification Java EE 6. La plupart des futures spécifications sont d'ailleurs déjà implémentées, en mode preview. On retrouve ainsi JSF 2.0 Preview et EJB3.1 Preview.

Glassfish est à l'origine basé sur Tomcat, mais se veut un serveur d'applications complet.
Alexis commence la session en essayant une comparaison Glassfish / JBoss pas vraiment équitable, puisque les téléchargements GlassFish prennent en compte le nombre de téléchargements du SDK Java EE 5 (Glassfish est inclus dans le SDK Java EE 5).
Glassfish se présente comme étant "au même niveau côté performances" que WebSphere et WebLogic. La mode étant au light (lightweight containers, lightweight ESBs, EJB lite ...), GlassFish se présente comme un "lightweight application server". Glassfish pourrait d'ailleurs être l'un des premiers à se positionner sur les serveurs d'applications "web profile compliant", mais c'est également bien plus, comme on a pu le voir par la suite.

GlassFish se veut avant tout modulaire et extensible. Modulaire car son noyau est basé sur OSGi (ce qui est transparent pour les développeurs). Extensible car basé sur HK2. GlassFish v3 a ainsi un socle ouvert, permettant à tout le monde de pouvoir créer et déployer ses extensions HK2.
Alexis nous fait ensuite une démonstration : GlassFish possède des fonctionnalités intéressantes pour les développeurs, en particulier la sérialisation de sessions HTTP et le “compile on change” (rechargement à chaud des modifications, très pratique en phase de développement). Le démarrage rapide (15 à 20 secondes sur un ordinateur portable), grâce à un système de mise en cache, est également mis en avant. Enfin GlassFish propose un AppStore façon serveur d'applications : l'Update Center. Semblable au apt-get de Debian, l'Update Center permet d'ajouter des briques logicielles à son serveur d'applications. On y trouve par exemple des composants permettant l'intégration de Grails ou Rails.

Côté versions, la 2UR2 (bientôt 2.1) est celle mise en avant commercialement, pour sa robustesse et son support SUN. La V3 définitive sortira vers juin 2009, pour être présentée à JavaOne 2009, et devrait être certifiée Java EE 6. Attention, certains composants Glassfish v2 ne sont pas portés sur Glassfish v3 pour le moment. Ainsi la V3.1, apportant le clustering, sera disponible fin 2009.


Bienvenue au Paris Java User Group !

GlassFish - Open Source Application Server

Résultats du Tableau Blanc lors du buffet


Article rédigé par les sfeiriens du Paris JUG : Fabien Baligand, Tanguy Bayard et Tarik Filali Ansary.

dimanche 14 décembre 2008

Devoxx 2008 - Introduction to the SpringSource dm Server

Par Fabien Baligand le dimanche 14 décembre 2008, 23:07

Cette session avait pour but de présenter le tout nouveau serveur d'applications de chez SpringSource : SpringSource dm Server. Ce petit nouveau a déjà fait couler beaucoup d'encre sur lui, et pour cause, il révolutionne le monde des serveurs d'applications en proposant de déployer les applications non plus sous forme de WARs ou d'EARs, mais sous forme de bundles OSGI, permettant ainsi la modularisation des applications.

J'étais donc curieux de découvrir plus en détails ce produit assez novateur.

Pour commencer, Sam Brannen (Consultant Senior à SpringSource), rappelle les problèmes avec les serveurs d'applications actuels :
  • Alors que les développements sont aujourd'hui de plus en plus pensés de manière modulaire (notamment avec la montée en puissance de Maven en entreprise), toute cette modularité est perdue au déploiement sur les serveurs d'applications avec un WAR/EAR monolithique.
  • De petites mises à jour requièrent un re-déploiement total de l'application (et non pas du seul module mis à jour)
  • Un même module utilisé par plusieurs WARs sera répliqué dans chacun des WARs sur le serveur d'applications, au lieu d'être partagé
  • Il est impossible de faire cohabiter plusieurs versions d'un même module ou d'une même application sur un serveur d'applications classique.
  • Le serveur d'applications lui-même souffre d'un manque de modularité : nous n'utilisons pas toutes les APIs d'un serveur J2EE (ex: toutes les applications n'ont pas besoin d'un conteneur EJB), et poutant toutes les APIs sont chargées en mémoire au démarrage du serveur d'applications, ce qui peut impacter fortement l'empreinte mémoire ou encore le temps de démarrage du serveur.

Je rebondis sur ce dernier point, en précisant que pour les toutes dernières versions de serveurs d'applications, cela a changé : les serveurs Websphere 6, JBOSS 5, Glassfish 3 ou Weblogic 10 sont basés sur un noyau OSGI.
Néanmoins, cela reste très récent...

Sam Brannen poursuit ensuite sur les avantages qu'apporte OSGI, coeur de dm Server :
  • Partitionnement par bundle (pas d'archive monolithique)
  • Renforcement de la visibilité stricte (chaque bundle décrit les bundles qu'il importe, et surtout quels packages précisément il expose aux autres bundles)
  • Résolution des dépendances
  • Versionning (chaque bundle a une version bien identifiée, c'est une donnée obligatoire)
  • Exposition d'un Service Registry
  • OSGi est dynamique : on peut de manière dynamique installer, désinstaller, démarrer, arrêter ou mettre à jour un bundle, et ceci, sans redémarrage du serveur d'applications.

On arrive enfin au coeur du débat, la présentation de dm Server lui-même, qui je dois dire, a été assez brêve à mon gout, pour donner plus de place à des démos :
  • dm Server se base sur le moteur OSGi EQUINOX (moteur qui a l'avantage d'avoir fait ses preuves depuis bien longtemps sur Eclipse)
  • dm Server se base le moteur de servlet Tomcat (il permet ainsi non seulement de déployer des modules OSGi mais également des WARs pour ceux qui hésiteraient encore à sauter le pas)
  • dm Server ajoute à OSGI, un modèle de composant. Ce modèle de composant est justement l'objet de la RFC-124 de l'OSGI Alliance, dont dm Server est la Reference Implementation, et qui devrait être finalisée d'ici Juin 2009. Ainsi, si actuellement, certains peuvent craindre le côté propriétaire du serveur d'applications SpringSource, la standardisation avec la RFC-124 devrait dans l'avenir rassurer... mais aussi créer de la concurrence.
  • D'autre part, dans le principe de fonctionnement, dm Server bootstraps un contexte d'application par bundle (qui n'est pas sans rappeler un certain framework Spring)
  • Enfin, dm Server existe en deux versions :
    • Community Version, qui est free et open source (sous licence GPL et SpringSource License)
    • Enterprise Version, qui offre le support produit et le pack Performance Suite

Sam Brannen termine avec une démo :
  • Montrant dans un premier temps, comment installer le produit, le lancer, le configurer, et l'administrer par console
  • Puis dans un deuxième temps, comment avec le plugin Eclipse "SpringSource Tool Suite", créer un bundle et le déployer sur dm Server.

Je retiens les points intéressants suivants de la démonstration "serveur" :
  • On peut déployer un bundle juste en le déposant dans le répertoire "repository" ou par console
  • La configuration du serveur est stockée en JSON (language jugé plus compact que XML par SpringSource). Je ne suis pas sûr que ce point fasse l'unanimité : si XML est certes moins compact, il est également plus lisible, ce qui pour une configuration, me parait important...
  • Lors d'un crash inopiné du serveur, un thread dump ainsi qu'un heap dump est automatiquement généré dans le répertoire dump (point que je trouve extrêmement pratique en condition de production pour analyser à posteriori la cause du problème). Je vous rassure, sur ce point, il n'en a pas fait la démo ;)
  • Possibilité de définir des profiles (profile web, ...) et de démarrer uniquement ceux désirés. C'est un des avantages principaux mis en avant par un noyau OSGI du serveur : la légèreté du serveur et l'offre à la carte des APIs démarrées.

Je retiens les points intéressants suivants de la démonstration "développement avec Eclipse" :
  • Le plugin Eclipse "SpringSource Tool Suite" est free et open source
  • Le plugin permet de créer une instance de serveur "dm Server" avec WTP (très pratique pour tous ceux qui sont habitués à WTP). Cela permet ainsi de le configurer dans Eclipse, démarrer/arrêter, mais aussi debugger.
  • Le plugin fournit un wizzard de création de projet "Bundle OSGI".
  • Le plugin fournit un éditeur de fichier MANIFEST, permettant l'édition graphique du fichier MANIFEST, ou encore la complétion lors de l'édition du source. Etant donné l'importance du fichier MANIFEST dans un bundle OSGI, et sa potentielle complexité, cet éditeur de MANIFEST est une très bonne idée de la part de SpringSource ; qui plus est, il est très bien fait.
  • Pour ce qui est du développement pur, il suffit d'ajouter l'annotation @Service devant une classe pour qu'elle devienne un service OSGI.
  • Enfin, pour le déploiement du bundle, un simple drag&drop du projet dans l'instance "dm Server" de l'onglet "Servers", et le déploiement est effectif ! (petit effet de style toujours efficace lors d'une démonstration...)

Au final, j'avoue avoir assez apprécié cette présentation, qui fût tout de même assez riche en une heure de temps.
J'ai été particulièrement séduit par le plugin Eclipse fourni par SpringSource, qui se révèle relativement complet et efficace (le tout en open source).
Pour autant, j'aurai aimé la démonstration de l'une des promesses de dm Server : la mise à jour à chaud. Lorsque l'on met à jour un bundle, toutes les requêtes envoyées à ce bundle par d'autres bundles sont mises en attente jusqu'à ce que le déploiement de la mise à jour soit terminée.
Cette démonstration a été faite lors d'une autre session le vendredi (dommage, je partais le jeudi soir) retranscrite sur le blog de notre confrère Octo : DM Server : from WAR to Web Module


Pour finir sur une note plus large, je pense que la révolution OSGI est en marche...
Après avoir conquéri le domaine de l'embarqué (domaine qui a fait naître OSGI), puis le domaine de l'IDE (avec Eclipse Equinox et les plugins Eclipse), OSGI est aujourd'hui est en train de conquérir le domaine des serveurs d'applications (avec comme je le disais, tous les derniers serveurs d'applications sortis basés sur un noyau OSGI : Websphere 6, JBOSS 5, Glassfish 3 ou Weblogic 10). C'est en soi une mini-révolution dans le domaine des serveurs d'applications (qui a d'ailleurs demandé aux éditeurs de refondre entièrement le noyau de leur serveur).
Prochaine étape : les applications d'entreprise.
Avec SpringSource dm Server, le travail de l'OSGi Enterprise Expert Group, et la sortie mi-2009 d’OSGi R4.2 incluant la version finale de la RFC-124 ; je pense que les applications d'entreprise prendront prochainement le virage du WAR/EAR au module OSGI, bouclant ainsi la révolution OSGI en marche.

L'avenir nous le dira...

Devoxx 2008 - Envers Entity Versionning

Par Mohamed Abdennebi le dimanche 14 décembre 2008, 22:43

Envers est un projet open source dont le but est d'offrir un mécanisme d'historisation des données, une technique dont la réalisation était jusqu'à lors fastidieuse et qui demandait la collaboration du développeur et du DBA. Envers s'intègre naturellement à Hibernate. Il est d'ailleurs devenu, depuis peu, un module à part entière du projet Hibernate.

La présentation était assurée par Adam Warski, ancien employé de JBoss et créateur et développeur principal du projet. En guise d'introduction, l'orateur a commencé le séminaire en présentant les patterns d'historisation les plus connus et la difficulté de leur mise en œuvre. Parmi eux, on trouve le pattern AuditLog pattern ou « la piste d'audit ». Cette technique consiste à écrire dans un fichier texte les données modifiées, la date et l'auteur de la modification. Son avantage réside dans sa simplicité. En contrepartie, elle s'avère rapidement inefficace en raison de la quantité de données qu'elle produit. En effet, il devient difficile de corréler des entités ou de naviguer entre les relations.

De son côté, Envers permet de mettre en œuvre l'historisation de façon transparente et non intrusive (pas de modification du schéma, ni du code de l'application). En effet, son utilisation se limite à ajouter l'annotation @Audited à l'entité à historiser et à renseigner les évènements qui déclencheront l'audit dans le fichier persistence.xml.

De façon similaire au système de contrôle de version Subversion, Envers utilise le concept revision. Une révision correspond à une transaction. Pour ce faire, Envers crée une table identique à la table originale, avec des colonnes supplémentaires. On retrouve parmi celles-ci, la colonne réservée au numéro de révision et le type d'opération (ajout, modification, suppression). Le présentateur nous averti que seules les entités modifiées dans une transaction réussie (commit passé avec succès) seront historisées. Ce comportement est tout a fait normal puisqu'il garantit la cohérence des données historisées.

En plus des données de base telles que les strings, les nombres et les dates, il est possible de versionner les relations. De ce fait, il est possible d'explorer un graphe d'objet à un instant T. Voici un exemple, repris de la présentation de Adam, montrant le fonctionnement de Envers :

// Revision 1 : créer une personne et lui associer une adresse
// une adresse pour être associée à plusieurs personnes

entityManager.getTransaction().begin();

Address a1 = new Address("Rue de la boetïe", 15);
Person p = new Person("Martin", "Dupont");
p.setAddress(a1);
entityManager.persist(a1); 
entityManager.persist(p);

entityManager.getTransaction().commit();

// Revision 2 : On modifie l'adresse de la personne
// et son prénom
entityManager.getTransaction().begin();
Address a2 = new Address("Rue des bourets", 6);
entityManager.persist(a2);
// on suppose que le id de la personne est 1
int id_personne = 1;
p = entityManager.find(Person.class, id_personne);
p.setName("Paul");
p.setAddress(a2);
entityManager.getTransaction().commit();

Envers offre une API pour lire les données historisées. Il est, par exemple, possible de récupérer une entité qui correspond à telle ou telle révision.

// Lecture des données historisées
AuditReader auditReader = AuditReaderFactory.get(entityManager);
// Lire la personne de revision 1
int revision1 = 1;
Person oldPerson = auditReader.find(Person.class, id_personne, revision1);
assert "Martin".equals(oldPerson.getName());
assert a1.equals(oldPerson.getAddress());

// De même pour les adresses à la révision 1
int a1_id = 1;
Address old_a1 = auditReader.find(Address.class, a1_id, revision1);
assert old_a1.getPersons().size() == 1;
assert old_a1.getPersons().contains(p);

int a2_id = 2;
Address old_a2 = auditReader.find(Address.class, a2_id, revision1);
assert old_a2.getPersons().size() == 0;

Envers offre aussi une API similaire à l'API Criteria, en voici un exemple :

List personsAtAddress = getAuditReader().createQuery()
.forEntitiesAtRevision(Person.class, 12)
.addOrder(AuditEntity.property("surname").desc())
.add(AuditEntity.relatedId("address").eq(addressId))
.setFirstResult(4)
.setMaxResults(2)
.getResultList();

Adam a terminé sa présentation par un benchmark opposant la modification massive d'entités sans versionnng à des une modification avec versioning. Le résultat montre qu'avec l'historisation la modification coûte en moyenne 1,5 fois le temps d'une modification sans historisation, et ce, à cause des ordres insert dans les tables d'historisation.

Au moment des questions-réponses, une personne de l'assistance a demandé à l'orateur s’il était possible de configurer Envers avec XML. La réponse fut laconique : non ! Seules les annotations sont autorisées. L'auteur encourage même l'utilisation du standard JPA à la place d'API propriétaire de Hibernate. Il n'est pas possible non plus de stocker les tables d'audit dans un schéma autre que le schéma des tables à auditer.

Pour conclure, l'orateur a exposé les fonctionnalités futures à court et à long terme. Notons par exemple : le revert (remettre une entité à un état antérieur), les branches, appliquer un DIFF ou encore ne versionner que certaines propriétés de l'entité.

Cette présentation a été une bonne introduction au sujet. Il ne nous reste qu'à tester cette technologie grandeur nature et de vous faire partager, bientôt nous l'espérons, notre expérience sur le sujet.

mercredi 10 décembre 2008

Devoxx 2008 - Android : rich clients

Par David MARTIN le mercredi 10 décembre 2008, 19:15

Android est aussi de la partie ici. Le buzz généré depuis ces derniers mois se doit d'être entretenu, surtout lorsque la plateforme est commercialisée depuis plusieurs semaines.

La présentation Filthy Rich Android Client s'est axée sur les fonctionnalités graphiques permises par Android. Cela concerne donc les manipulations possibles sur les images (Transformations, ...), ainsi que la partie animation.

Romain Guy, le speaker en charge de cette présentation, a passé en revue le principe de construction d'un écran, expliquant au passage quelques astuces d'optimisation (ne pas instancier d'objet dans les phases de 'painting', accéder aux attributs des objets directement plutôt qu'au travers les accesseurs - au diable les bonnes pratiques, sacrifiées sur l'autel des perfs sur ce coup :), désactiver le rendu du background du Canvas si celui-ci n'est jamais visible...)

Par contre, il n'a pas été question de la gestion plus poussée du hardware des terminaux (ou plutôt du terminal, car seul le G1 fait tourner officiellement Android à ce jour). Ces aspects sont certes moins sexy, mais entrent en jeu dans le développement d'applications professionnelles, ou tout simplement non graphiques.

Ce point mis à part, Android affirme ici son intention, s'il était encore nécessaire de le redire, de prendre une part non symbolique du gâteau partagé par les RIM, Nokia, Microsoft et assez récemment Apple, en proposant un environnement de développement susceptible de toucher une base de développeurs très large : celle des développeurs Java!

L'avenir est dans le mobile, tout le monde se prête à le dire !

Devoxx 2008 - From concurrent to parallel

Par David MARTIN le mercredi 10 décembre 2008, 18:11

Pour bien commencer Devoxx, j'ai choisi la presentation de Brian GOETZ nommée "From concurrent to parallel".

Pour rappel, Brian GOETZ est auteur du livre Java Concurrency in Practice, une référence sur le sujet.

Sa présentation portait sur le futur JDK 7, et en particulier le fruit de la jsr166y qui y sera integré. La présentation a couvert le spectre des possibilités offertes par cette API, à savoir la possibilité de paralléliser une opération sur un maximum d'unités de traitement (processeur, core, ...) en la subdivisant en sous tâches permettant une répartition de la charge plus efficace.

J'avais il y a quelques temps posté un article présentant justement cette jsr, que je vous invite à relire à l'occasion : Java 7 Fork/Join : Exploiter toute la puissance disponible

Ou si vous souhaitez entrer un peu plus dans le sujet, vous pouvez lire cet article : ForkJoin : Bienvenue dans les mondes parallèles

Devoxx 2008 - Creating amazing user interfaces with Dojo and DWR

Par Bruno le mercredi 10 décembre 2008, 13:58

Arrivé un peu un retard, suite au premier billet sur JavaFX, Fabien, Hossein et moi, nous installons confortablement afin d'assister à la conférence Dojo/DWR.

Pour ma part, j'avais déjà utilisé JQuery et DWR sur un précédent projet, et ayant aimé leur utilisation, j'étais curieux de voir ce que Joe Walker et Nikolai Onken allaient nous présenter.

Tout d'abord, nous avons eu droit à une présentation de Dojo, surtout au moment de notre arrivée, Dojo et GFX pour pouvoir faire de la manipulation d'objets graphiques 2D de bas niveau (rectangle, cercle, ellipse, etc ..).
On a eu droit à une démonstration d'un chat utilisant le serveur Comet et l'api Google Translate. Chacun des speakers écrivait dans sa langue et la traduction était faite de manière automatique par Google Translator à l'affichage sur le poste de l'autre speaker, tout en passant par Comet qui push les données sur le browser (reverse Ajax).

Nous avons eu ensuite une présentation de DWR, qui permet d'utiliser, via proxy, des objets Java dans du Javascript.
Une démonstration d'upload d'image (binary file handling), et récupération sur le client.
Le speaker, nous montre la possibilité de faire du reverse Ajax, via certaines API DWR.
Il nous montre la possibilité pour DWR d'utiliser le reverse Ajax en mixant le meilleur des mondes Comet + Polling + Piggyback.

Voici un exemple :

WebContext wctx = WebContextFactory.get();

String chatPage = wctx.getCurrentPage();



// Find all the browser on window open on the chat page:

Collection sessions = wctx.getScriptSessionsByPage(chatPage);



// Use the Javascript Proxy API to empty the chatlog <ul> element

// and re-fill it with new messages

Util utilAll = new Util(sessions);

utilAll.removeAllOptions("chatlog");

utilAll.addOptions("chatlog", messages, "text");

Au final nous avons eu une présentation des possibilités de couplage des deux technologies, avec une précision sur le packaging de Dojo, qui a priori a été largement facilité,notamment au niveau des imports des fichiers Javascipt.

Pour ma part, étant fan plutôt de JQuery, j'aurai préféré que DWR permette de faire de même avec ce framework.

A suivre en tout cas, je vais me remettre à DWR et voir si la fonctionnalité de Reverse Ajax, sera peu à peu adoptée dans des applications d'entreprise, de moyenne à grande envergure.

Devoxx 2008 - Conference Day1 - KeyNote JavaFX

Par Bruno le mercredi 10 décembre 2008, 12:09

Arrivé tout fraichement de la gare d'Anvers, nous avons eu la chance de pouvoir prendre un Minibus et de se loger à 9 dedans. Sur place, au Metropolis, pas la discothèque, mais le lieu où se déroule le Devoxx, nous avons apprécié l'organisation et l'accueil, le café, les viennoiseries à volonté et les nombreux goodies, dont le canard Adobe noir.

Devoxx c'est 3200 participants, 160 speakers, 6 salles, 40 partenaires, 40 JUGs, 400 étudiants et 35 pays représentés.

Grace au réseau Wifi, nous pouvons vous faire profiter en direct de nos impressions, et grâce au RFID, via le badge, Big Brother is watching you, à chaque livraison de goodies on est repéré.

Le ventre bien rempli, nous nous préparons à assister au keynote sur JavaFX. La version JavaFX GA 1.0, vient tout juste de sortir et avec NetBeans IDE 6.5 for JavaFX. Robert Brewin, nous a présenté les 10 raisons, pour lesquelles il est intéressant d'adopter JavaFX, selon lui. Voici celles que l'on a, principalement, retenu :

1 - Un nouveau langage cool :JavaFX script

2 - Multi plateforme, multi device

3 - Utilisation des outils Adobe via les plugin JavaFX, pour générer une application JavaFX à partir d'un projet Adobe Illustrator/Photoshop

4 - Rich API set : Scene Graph, Media, WebServices ... Any Java API

5 - nouveau plugin pour le browser à partir de Java 6 update 10, pour avoir la gestion de process indépendants tout comme le fait Google Gears via Chrome.

6 - Fonctions IDE Netbeans 6.5 : complétion, compilation, débugging, pré-visualisation, wizzards

Les démos étaient visuellement impressionnantes, mais on reste sceptique sur une utilisation en entreprise, mais plus comme une utilisation Flash like.

Ceci recoupe le dernier billet de David Martin sur notre blog 'JavaFX 1.0 : déception'.


mardi 9 décembre 2008

JavaFX 1.0 : déception

Par David MARTIN le mardi 9 décembre 2008, 11:00

Quand je parle de décevoir, cela concerne plus les personnes qui attendaient comme moi de la part de Sun un concurrent réel aux solutions actuelles pour développer des applications RIA à destination des entreprises. En effet, lorsque j'avais regardé un peu la preview sortie il y a quelques mois, on pouvait y trouver une liste de composants graphiques issus de Swing et permettant d'envisager (sic) une liste encore plus exhaustive à la sortie de la version 1.0 finale.

Déception

Et bien non :-( Et même pire : certains ont tout simplement disparu ! Citons par exemple les composants liés à la création de menus (MenuBar, Menu, ...).

Et toujours pas de composant de plus haut niveau (une DataGrid avec des fonctionnalités maintenant devenues classiques, comme le tri, le choix des colonnes, l'édition "inline"..., des composants de type Tree...). C'est comme si JavaFX était une pâle copie d'un produit sorti il y a déjà pas mal d'années que certains connaissent sans doute sous le nom de ... Flash ;-)

Mais le Flash d'il y a 4 ou 5 ans (voire plus)... On retrouve en effet des jolis effets visuels pour manipuler ronds et carrés à l'infini (génial non ?), des facilités pour jouer des vidéos, détecter les collisions entre objets... Bref, à mille lieues de ce qui est recherché lors d'un développement d'application RIA à destination des professionnels (sauf peut être ceux du jeu en ligne ;-) ).

Aussi, et cet avis n'engage toujours que moi, JavaFX - sauf s'il est rapidement épaulé par une batterie de composants réellement utiles au plus grand nombre - restera probablement aussi marginal que les applets le furent dans le cadre d'applications professionnelles... Une légère odeur de pétard mouillé plane.

Tout ça s'est fait au détriment de l'existant puisque Swing semble avoir été volé de ses ressources et condamné à plus ou moins court terme à ne plus évoluer... Etrange arbitrage lorsque le successeur ne couvre pas le spectre complet du prédécesseur.

Pour conclure, j'attendais (beaucoup) plus de JavaFX que ce qu'il offre à ce jour. En attendais-je trop ? Maintenant, Devoxx sera peut être le lieu d'une annonce contredisant mes propos, c'est ce que j'en souhaite.

mardi 14 octobre 2008

PureMVC Multicore for Java (compatible with GWT)

Par Pierre Mage le mardi 14 octobre 2008, 23:56

The first version of the PureMVC Multicore framework for Java which is compatible with GWT has been relased here under Creative Commons Attribution 3.0 license. For those who do not know MVC, you should look at Wikipedia. Then, if you want to know more about PureMVC, you should continue with the conceptual diagram and best practices. These documents demonstrate the Singleton version, they are a good introduction to PureMVC concepts.

lundi 29 septembre 2008

Google Developer Day Paris 2008 - Résumé de la journée

Par hoshams le lundi 29 septembre 2008, 19:06

2888831206_678d2cdedf Le 18 septembre dernier, à l'ENSA (Ecole Nationale Supérieure d'Architecture), Google faisait étape à Paris pour son tour du monde 2008.

Cette journée avait pour ambition de présenter les technologies Google et de proposer aux développeurs français présents de participer à quelques séances pratiques de codage avec ses APIs et frameworks. Pour certains, c'était les premiers pas comme développeur d'App Engine ou de GWT et pour d'autres, l'objectif était déjà d'aller un peu plus loin et d'échanger avec d'autres présentateurs ou participants sur leur expérience dans ces technologies ou de voir comment les intégrer dans les développements de solutions diverses...

Après la traditionnelle file d'attente devant l'entrée du magnifique bâtiment de l'ENSA, l'évènement a commencé vers 10h00 par une présentation des thèmes de la journée: le standard d'interopérabilité de réseaux sociaux OpenSocial, la plateforme de développement pour téléphones mobiles Android, le framework de développement web GWT, le service d'hébergement d'applications web Google App Engine, et les outils de localisation géographiques basés sur Google Maps et Google Earth.

La présentation du programme de la journée à peine terminée, la foule des participants quittait le hall central pour prendre place dans les amphis et dans les salles équipées afin de suivre des présentations "magistrales" et des sessions de code.

Ces présentations ont été animées par des ingénieurs Google mais également par des acteurs du terrain, des ingénieurs d'entreprises qui mettent en œuvre ces technologies dans leur travail quotidien telles que Sfeir et Viadeo.

Pour ce qui est des " Sfeiriens ": Jieren Wu et Didier Girard ont pu faire découvrir Google Web Tookit lors d'une session de code. Bruno Guedes et Vincent Bostoen ont présenté Google App Engine.

Les thèmes abordés ont été très nombreux : mobilité avec Android et en démonstration une balle fluide et rebondissante; Cloud Computing où on a pu faire héberger un wiki développé bien sûr en Python pendant que dans une autre salle nos collègues Bruno Guedes et Vincent Bostoen montraient à quoi sert l'infrastructure App Engine et comment l'utiliser; RIA où le Directeur Technique de Sfeir Didier Girard a présenté GWT puis accompagné de notre collègue Jieren Wu ils ont aidé les développeurs à écrire une application GWT pendant que d'autres suivaient en amphi une présentation d'Ajax; navigateurs avec la plateforme Chrome et sa gestion innovante de processus; réseaux sociaux où Viadeo a fourni son expertise lors de la session de code dédiée principalement à OpenSocial, avec quelques touches des APIs de géolocalisation et d'intégration dans le Google App Engine; ... Beacoup de sujets intéressants donc mais on ne pouvait pas être partout à la fois!! Difficile pour les participants de faire un choix.

Tout au long de la journée, un espace de détente était accessible à tous. Une occasion de discuter des dernières APIs autour d'un BabyFoot ou encore d'argumenter sur GWT tout en jouant à la Wii. Pour les moins agités, une masseuse ainsi qu'une montagne d'oreillers étaient également à disposition.

La journée s'est terminée vers 21h00 autour d'un buffet, une occasion de discuter avec ceux qui créent les technologies mais également ceux qui les utilisent.

En définitive, ce fût une journée bien remplie, de laquelle chacun des participants est reparti avec un tee-shirt et une clé USB en forme de PLAYMOBIL. En attendant l'édition 2009 des Developer Days, n'hésitez pas à vous rendre sur http://code.google.com pour vous former aux technologies Google. Pour ceux qui veulent voir ou revoir les vidéos, rendez vous sur http://fr.youtube.com/view_play_list?p=22350CB6D86B7A2B.

2 commentaires

lundi 15 septembre 2008

Java 7 Fork/Join : Exploiter toute la puissance disponible

Par David MARTIN le lundi 15 septembre 2008, 18:56

Les processeurs multi-core envahissent les ordinateurs ainsi que les serveurs et cette puissance accrue n'est encore que rarement bien exploitée. Java, dans sa prochaine cuvée (Java 7), intègrera parmi les nombreuses JSR, la JSR-166y, proposant ainsi un système de parallélisation des traitements permettant d'aller chercher cette puissance somnolente et de la mettre à profit de calculs gourmands. Cela permettra 2 choses :

  • gagner en temps de réponse, c'est assez évident à comprendre
  • permettre des traitements plus ambitieux, sur des volumes de données plus importants (Cela est aussi rendu possible grâce au prix toujours décroissant de la mémoire physique, permettant le stockage de ces données volumineuses avec des contraintes d'I/O bien moins fortes que tout autre support de stockage).

En quelques mots, voici comment ce procédé de parallélisation fonctionne.

Lire la suite...

jeudi 11 septembre 2008

Qualité de code : quelques outils

Par David MARTIN le jeudi 11 septembre 2008, 15:25

Quality_is_your_responsabilityDévelopper ne relève pas de l'exploit, mais développer bien, un peu plus... Les nouvelles méthodes de développement imposent un rythme soutenu, une polyvalence permettant d'intervenir sur des portions de code appartenant à un autre membre de l'équipe, etc. Bref, plein de bonnes raisons qui encouragent de maintenir un code propre, suivant des règles communes entre membres de l'équipe, testé de la façon la plus exhaustive possible... On pourrait croire que seul un monde parfait peut permettre d'atteindre cet objectif, et bien pas forcément : il existe différents outils que vous connaissez sûrement, peut être que vous utilisez aussi, qui aident à atteindre cet objectif. Ces outils ne doivent pas être une mallette de secours quand tout commence à aller mal, mais le fil rouge au long du cycle de vie du projet qui sera le gage de la performance de l'équipe.

Voici donc présentés brièvement quelques ténors du secteur.

Lire la suite...

mercredi 10 septembre 2008

Nexus rend la gestion de depot Maven plus facile

Par hoshams le mercredi 10 septembre 2008, 17:49


La première release de Nexus le gestionnaire de dépôt Maven de Sonatype est disponible depuis fin aôut. Nexus est écrit en Java et distribué sous licence GPL. Il appartient à la même gamme de produits que Maven proxy, Apache Archiva ou encore Artifactory.

Basé sur Proximity, Nexus agit bien sûr comme proxy entre l'entreprise et les dépôts publics Maven mais aussi comme destinataire de nos propres artefacts. Il est doté d'une interface utilsateur assez conviviale, basée sur la librairie Javascript Ext JS, qui permet d'administrer l'outil et de gérer les dépôts.

Avec Nexus on peut déployer un artefact via l'interface, rassembler un ensemble de dépôts derrière un seul groupe, visualiser les rapports concernant les déploiements dans un dépôt, s'abonner à un flux RSS pour être prévenu de tout nouveau déploiement d'artefact, etc.

Bref, avec toutes ses fonctionnalités Nexus rend la vie de l'utilisateur Maven un peu plus facile.

Lire la suite...

dimanche 29 juin 2008

débuter avec Restlet

Par Pierre Mage le dimanche 29 juin 2008, 18:18

restlet_logo Dans le cadre d'un projet sur lequel je suis intervenu, j'ai eu a refactorer le format des URIs d'un middleware RESTful. Ce fut également l'occasion d'introduire Restlet, le framework Java de référence pour faire du REST, à la place d'un framework "maison". La refacto fut courte et sans douleur, c'est pourquoi je recommande Restlet aux personnes qui souhaitent faire du REST en Java et leur donne quelques liens pour débuter.

Pour commencer, je me suis appuyé sur l'exemple "First Resource", qui permet de se familiariser avec les notions de Restlet grâce à un exemple simple.

Concernant la sécurité, tout ce qu'il y a à savoir se trouve sur la page "Securing a Restlet application"

Pour la gestion des exceptions, il suffit d'étendre la classe StatusService puis d'affecter la nouvelle classe à l'Application concernée.

Pour finir, il ne faut pas oublier de modifier le fichier "web.xml" comme indiqué ici.

2 commentaires

samedi 21 juin 2008

TheServerSide Java Symposium - Jour 3

Par Olivier Gérardin le samedi 21 juin 2008, 01:58

Troisième et dernier jour du symposium…je n’ai pas gagné l’iPod qui était en jeu, dommage, j’aurais pu tester GWT dessus ;)

On commence par une conférence de Geert Bevin: Boldly go where the Java language has never gone before. On le sait, Java ce n’est pas qu’un langage, c’est un langage, une JVM et une plateforme, qui ont chacun leurs points forts mais aussi leurs limites. Dès lors, l’idée, qui est à la mode ces derniers temps, c’est que l’on peut remplacer ou modifier un de ces composants pour “pousser l’enveloppe” lorsque les limites se font sentir.

Geert cite 4 exemples pour illustrer cette approche.

  1. Terracotta: il s’agit d’une extension de la JVM qui facilite la scalabilité des applications, en permettant de mettre des JVM en cluster. Déclarativement, certains objets (“shared objects”) sont répliqués entre toutes les JVM, et accédés indifféremment (avec du lazy loading) par toutes les instances. On a ainsi étendu le comportement natif de la JVM.
  2. RIFE continuations: déjà évoqué hier au sujet de Comet, il s’agit pour prendre une image de prendre une photo de l’état d’un thread, comme un “save game” (c’est l’image donnée par Geert). On peut à tout moment appeler pause(), ce qui crée une sauvegarde et rend la main immédiatement, puis reprendre à partir de n’importe quel état avec resume(). Les continuations sont organisées en arbre (parent = continuation à partir de laquelle on a restauré). Encore une fois, on change la sémantique habituelle de la JVM dans sa gestion des threads.
  3. GWT: on ne présente plus GWT, Geert fait un rappel des principes de fonctionnement (translation Java->Javascript, mode hosted vs. compilé, debugging, etc.). Ici on a remplacé l’ensemble du stack Java par une plateforme web pure, et seul le développement utilise le stack Java standard. Un participant pose la question du JavaScript généré, et Geert dit que pour lui c’est un problème, car le JavaScript généré est illisible et impossible à débugger… je bondis intérieurement, et j’irai voir Geert à la fin pour lui expliquer que pour GWT, le browser est la plateforme, la lisibilité du JavaScript généré est aussi peu importante que la lisibilité du bytecode généré par le compilateur Java! Je ne pouvais pas laisser passer ça…
  4. Android: la plateforme mobile de Google. Comme pour GWT, le développement et debugging se font en Java, avec les IDEs habituels, et un émulateur de la plateforme mobile (équivalent au mode hosted de GWT). En revanche pour le déploiement, le bytecode Java est converti en bytecode (.dex) pour la machine virtuelle Dalvik, qui est l’équivalent de la JVM.

On aurait pu multiplier les exemples, notamment les langages dynamiques qui fleurissent sur la JVM, mais le point est fait. A mon sens, ces multiples extensions et détournements sont plus des preuves de la puissance de Java que de sa faiblesse, car Java reste toujours au centre d’un écosystème qui est plus bouillonnant que jamais.

 

Deuxième conf: JCR: TheServerSide as a Content Application. David Neuscheler (days.com) introduit JCR, version 1.0 (JSR 170) et 2.0 (JSR 283), les diférentes fonctionnalités d’un système de CM, etc. Puis il fait une démo en prenant une page du site TheServerSide.com, et en la transformant en appli client JCR. Pour tout dire c’est un peu fastidieux, et d’où je suis on n'arrive pas à lire le code ! J'aurais peut-être dû choisir la conf sur MapReduce dans l'autre salle...

 

Dernière conf du matin, Michael Keith présente What's new in JPA 2.0. Les objectifs étaient multiples:

  • standardiser les propriétés
  • remplir les manques de l'ORM
  • rendre la modélisation objet plus flexible
  • fournir une abstraction du contrôle du cache
  • contrôle du verrouillage (locking)
  • fournir des "hooks" pour des frameworks propriétaires
  • améliorations JPQL
  • etc.

Je ne vais pas détailler les nouveautés, mais globalement il semble que le groupe de travail JPA a bien écouté les utilisateurs, et lorsque JPA 2.0 sera sorti, il sera difficile de justifier l'utilisation directe d'une API de persistence propriétaire.Au passage, la présentation a été agrémentée d'une page culturelle sur les oies du Canada...

 

Comme hier et avant-hier, déjeuner avec un lance-pierres... et en plus ils ont enlevé les machines à café !

 

L'après-midi commence avec Choosing a Web framework, par Shashank Tiwari. En fait de conseils pratiques, il s'agit d'une énumération de définitions, de généralités, de questions (quel problème résout un framework, quel problème crée-t-il?), tout ça pour finir par dire que toutes les raisons sont bonnes de choisir un framework, y compris parce qu'il est à la mode ou pour faire bien sur son CV !!! Au final si on est en recherche d'un framework, cette conférence ne fait qu'ajouter à la confusion et à l'incertitude. Ou comment gâcher un bon sujet.

 

Case Study: Better Software with the Spring portfolio, par Eberhard Wolff (SpringSource Allemagne). Pour info, SpringSource est la société qui emploie tous les committers de Spring, mais aussi certains de Tomcat et Apache. Spring, outre le framework bien connu, c'est aussi dynamic modules, batch, integration, webflow, etc.

On nous propose un cas de système de traitement de commande à architecturer autour de Spring. Le système peut recevoir des commandes par Web Services. La démarche classique est de définir une interface Java, implémentée par un POJO, et de générer le WSDL à partir de cette interface. Or cette démarche présente des inconvénients: le WSDL expose de facto l'interface d'une classe interne.. que se passe-t-il si le WSDL doit changer? D'autre part certains types communs en Java, comme Map, ne sont pas supportés en WSDL...Eberhard propose d'inverser la démarche: puisque le contrat avec les clients est le WSDL, on part du WSDL et on base le traitement d'une commande sur le schéma XML correspondant. Ansi on n'expose pas d'interface interne, on traite un objet Java généré à partir du message envoyé, via un système de mapping (JAXB/XStream). La logique est découplée de l'interface. La classe qui traite le message est un Endpoint qui est annoté via les annotations Spring. Eberhard en profite pour rappeler que Spring est trop souvent assimilé à XML, mais qu'on peut très bien faire du Spring sans XML (ou presque, soyons honnête..)

Pour rendre robuste le WebService, on peut aussi baser le traitement du message sur des expressions XPath. Ceci permet d'avoir un contrôle plus fin sur des messages qui seraient incomplets, et donc ne pourraient pas être mappés avec la solution précédente.

Eberhard introduit également les notions de pipes et filtres, qui sont des pipelines de traitement, supportés par Spring Integration, et configurables par XML (tiens donc).

Spring fournit également une approche à la notion de batch, mal résolue en Java; notamment le problème des redémarrages en cas d'interruption volontaire ou non. Un batch Spring c'est une série d'étapes, chaque étape lit quelque chose (un record dans une base probablement) et écrit quelque chose (résultat du traitement). Cette notion est supportée par Spring batch.

 

Dernière conf de la journée, et du symposium: Real GWT applications, par Jeff Dwyer. Une énième présentation rapide des principes de GWT, et une petite démo sur le site tocollege.net, dont une partie est réalisée en GWT. Jeff fait une petite séance rapide de live coding, et montre le débugging en mode hosted. Puis il insiste, un peu trop peut-être, sur les problèmes pour envoyer des objets métier au client provenant d'hibernate: les proxies dynamiques cassent le mécanisme de sérialisation GWT. Il existe des solutions: Hibernate4GWT et GWTHibernateFilter. Je lui ferai remarquer à la fin que ce n'est pas forcément la meilleure idée, et qu'avec Dozer il est facile de populer des objets spécialisés pour les transmette au client, car je n'ai pas forcément envie de voir mes objets métier transiter sur le fil, on ne sait jamais ce qui peut s'y trouver demain...

Jeff conseille judicieusement d'utiliser un pattern Command pour les communications du client. Il aborde la sécurité, notamment les attaques XSRF, et présente Goggle Gears pour les applis offline.

La présentation était un peu rapide, mais l'intérêt pour la techno est évident. J'espère que cette présentation (qui a été donnée deux fois lors du symposium suite à la forte demande !) y aura contribué.

 

Ouf, le marathon est fini ! Beaucoup de choses passionnantes ont été présentées, et on sent qu'on est à un tournant car pour ainsi dire "ça part dans tous les sens", l'écosystème Java, aux frontières autrefois bien nettes, commence à devenir une galaxie en expansion avec des projets qui poussent l'enveloppe et repoussent sans arrêt les limites, des polémiques (et encore, on n'a pas abordé les closures !). Le monde Java de demain sera certainement bien différent de celui d'aujourd'hui, mais Java en restera probablement le centre de gravité...

Il me reste à visiter Prague (superbe ville) et regarder les Turcs se qualifier sur l'écran géant au centre ville...

- page 2 de 3 -