Java 1.1

• Les classes internes (nested classes) : pas mal, mais auraient pu être bien mieux. Elles auraient sans doute du être statiques par défaut, et avec une syntaxe plus concise. Par ailleurs, elles ne sont pas réellement supportées par la machine virtuelle (si vous aimez compiler avec tous les warnings activés, le terme synthetic accessor method vous est sans doute familier).
• La sérialisation : la pire fonctionnalité jamais ajoutée au langage. Joshua ne mâche pas ses mots, on se souvient que la sérialisation fait l’objet d’un chapitre complet dans Effective Java. Elle ouvre de nombreuses failles dans la correction, la sécurité et parfois la performance des programmes.

Java 1.2

• Le modifieur strictfp : une petite « verrue » qui aurait pu être évitée. À l’origine, il garantissait la consistance des calculs flottants entre toutes les plateformes. En pratique, il est obsolète sur la plupart des architectures modernes, qui renvoient le même résultat avec et sans ce mot-clé. Dans toute sa carrière, Joshua n’a rencontré qu’une paire de cas où il avait une importance.

Java 1.4

• Les assertions : gagnant, mais de peu. Joshua est un grand amateur d’assertions (il nous révèle que le compilateur Java contient tellement d’assertions qu’il s’exécute 4 fois moins vite quand elles sont activées). Il a tenté de prêcher la bonne parole, mais a peu été entendu. En résumé, certaines personnes utilisent et adorent les assertions, le reste les ignore.

Java 5

• Les types génériques : une évolution incontournable, mais mal pensée. Sans aucun doute la fonctionnalité la plus controversée de Java. Elle a indéniablement renforcé le typage et favorisé l’expressivité, mais les wildcards, ajoutés à la dernière minute, ont été un désastre. Introduisant en plus des incompatibilités avec les tableaux et des messages d’erreur cryptiques, les types génériques ont désorienté les développeurs les plus aguerris. Joshua nous rappelle quelques commentaires désabusés de l’époque, qui font sourire avec le recul :

• Les annotations : un succès, anecdotique pour beaucoup de cas d’usages, mais vital pour d’autres. Joshua se réjouit de pouvoir implémenter en trois diapositives de code un framework de test rudimentaire, basé sur des annotations @Test comme TestNG et JUnit.
• Les enums : un franc succès. Elles ont révélé très peu de défauts en pratique. L’absence d’héritage est un choix délibéré, il aurait conduit à des incohérences (par exemple, le fait que la méthode values() de l’enum parente ne renvoie pas les constantes de l’enum fille).
• La boucle for-each : une des évolutions les plus réussies à ce jour. Elle a simplifié les parcours de boucle et éliminé toute une classe d’erreurs off-by-one.
• L’autoboxing : il aurait mieux valu étendre la généricité aux types primitifs. Mal utilisée, cette fonctionnalité peut entraîner des problèmes de performances (dans les boucles for par exemple) mais également des bugs assez tordus. Les amateurs de puzzlers apprécieront l’exemple suivant (solution en bas de l’article) :

  public class Searching {
      public static void main(String[] args) {
          String[] strings = { "1", "2", "4", "8", "16", "32", "64", "128" };
          // Translate String array into List of Integer
          List<Integer> integers = new ArrayList<Integer>();
          for (String s : strings)
              integers.add(Integer.valueOf(s));
          System.out.println(Collections.binarySearch(integers, 32, cmp));  // OK
          System.out.println(Collections.binarySearch(integers, 128, cmp)); // KO
      }
      static Comparator<Integer> cmp = new Comparator<Integer>() {
          public int compare(Integer i, Integer j) {
              return i < j ? -1 : (i == j ? 0 : 1);
          }
      };
  }
  

• Les varargs : un succès mitigé, entaché par les interférences avec les génériques. Ils sont très utiles pour quelques fonctionnalités comme printf. Mais le pouvoir de nuisance des warnings de compilation « A generic array of Xxx is created for a varargs parameter » a été sous-estimé. Ceci devrait être résolu avec les simplified varargs de Java 7.
• Les imports statiques : un gain modeste. Ils sont utiles pour les constantes d’énumérations et les classes utilitaires. Heureusement, ils n’ont pas été sur-utilisés, comme on aurait pu le craindre initialement.

Java 7

Vu la jeunesse de cette version, il s’agit plus ici de prévisions. Les puzzlers de Java 7 ne sont pas encore connus.

• Le switch sur les chaînes de caractères : un gain modeste en terme de concision, et vraisemblablement de performances. Son seul défaut est qu’il encouragera peut-être une sur-utilisation des chaînes de caractères, qu’il vaut mieux encapsuler dans des types personnalisés le plus tôt possible.
• Les littéraux binaires, les underscores dans les littéraux numériques : un gain modeste. Les underscores seront aimés et beaucoup utilisés, peut-être trop .
• Le multicatch : un gain assez conséquent. Il élimine les blocs catch redondants.
• La transmission d’exception sans perte de type (more precise rethrow) : un gain modeste. La fonctionnalité fait ce que l’on attend d’elle, reste à voir sa valeur ajoutée à l’usage. Le problème subsistera quand on veut stocker l’exception et la relancer dans un autre thread.
• L’opérateur diamond : un gain important. Complexe en interne, mais transparent pour les développeurs, il simplifie l’écriture du code, et supprime surtout du bruit inutile à la lecture.
• Le try-with-resources : un gain énorme. Sans compliquer le language, il simplifie la syntaxe et résout un problème sérieux et fréquent : Joshua nous révèle que le code du JDK 6 gérait mal les ressources dans 70% des cas !
• Les varargs simplifiés : un gain modeste. Comme indiqué ci-dessus, il élimine un warning pénible lié à l’utilisation d’arguments variables d’un type générique. Il sera surtout utilisé par les développeurs de librairies.

Conclusion

• La plupart des changements des premières versions étaient assez bons, mais une meilleure conception des classes internes aurait sans doute limité le besoin d’intégrer les lambdas dans Java 8. La sérialisation a fait plus de mal que de bien.
• Le bilan de Java 5 est mitigé. En particulier, les erreurs de conception des types génériques ont dilapidé le « budget de complexité » du langage, ce qui lui a fait beaucoup de mal sur le long terme. « L’esprit de Java », insufflé initialement par James Gosling, s’est détérioré au fil des versions.
• Les changements dans Java 7 sont plus prometteurs. Apparemment, la leçon de Java 5 a été retenue, les évolutions ont été introduites avec plus de prudence.
• Joshua est plus inquiet à propos de Java 8 : pour lui, le projet Lambda actuel a réussi à tempérer les excès de ses premières propositions, mais reste trop complexe. Les évolutions des versions suivantes lui font également peur (dans sa conférence du mercredi, Mark Reinhold a mentionné entre autres : une JVM auto-optimisée, la réification et l’unification des types primitifs, un protocole méta-objet…).

Pour finir, l’auteur de How to Design a Good API and Why it Matters nous délivre son « sermon » (selon ses propres termes) :

• « More is not better » : avant d’ajouter une nouvelle fonctionnalité, démontrer son utilité avec de solides arguments (typiquement, une analyse statique du code existant).
• Résister aux sirènes et aux effets de mode : « Java va mourir si nous n’ajoutons pas X », « Tous les autres langages ont Y »…
• Rendre les changements les plus simples possibles, éviter les modifications importantes du système de types.
• Et enfin… ne jamais ajouter une fonctionnalité au dernier moment (on repense bien sûr aux wildcards dans les génériques, que Joshua semble considérer comme sa billion-dollar mistake).

Néanmoins, Joshua termine sa présentation en nous témoignant son attachement au langage Java.

Solution du puzzler : le comparateur manipule des objets Integer. Or il utilise ==, qui se base sur les références et non les valeurs. Le cache de Integer.valueOf masque le problème pour les valeurs entre -128 et 127 ; au delà, le 128 passé en paramètre de binarySearch n’est pas le même objet que le 128 stocké dans la liste, donc le comparateur les considère comme différents et la recherche échoue.

Le projet Ceylon a été initié par Gavin King dont nous connaissons tous la renommée. Emmanuel explique que pour des raisons de frustrations avec le langage Java, Gavin et son équipe ont décidé de monter ce projet. Ils souhaitent développer un langage avec l’esprit Java et étant aussi pratique que ce dernier.

Les buts du développement du langage Ceylon sont les suivants :

• facile à apprendre,
• moins verbeux tout en restant lisible,
• type safety améliorée,
• avoir un nouveau SDK (plateforme),
• possibilité de faire du meta-programming.

Emmanuel poursuit par du code, dont voici quelques exemples.

Les points qui changent par rapport à Java ou à d’autres langages de la JVM

La gestion de la visibilité

Toutes les classes, variables et méthodes sont par défaut avec une visibilité private. Seules deux visibilités existent : private (par défaut) et shared (public). Une classe privée n’est visible que par les autres classes du même module. Une méthode shared est visible par toutes les classes qui peuvent accéder à sa propre classe.

Surcharge

Par défaut, toutes les méthodes, attributs et classes ne peuvent pas être surchargés. À la place, Ceylon fournit dans sa syntaxe deux mots-clés permettant de gérer la surcharge de méthodes en plus du qualifieur par défaut.

• default : peut être surchargée. On définit l’implémentation par défaut.
• formal : doit être surchargée.
• actual : indique la surcharge. Plus ou moins équivalent à @Override en java.

abstract class Shape() {
 shared formal Natural area() ;
shared actual default String string {
  return "Abstract area : " area.string " m^2 ;
}
class Square(Natural width) extends Shape() {
  shared actual Natural area() {
    return width * width ;
  }
  shared actual String string = "Square area : " area.string " m^2" ;
}

Dans cet exemple, la méthode string est équivalente à toString en Java. Elle est surchargée dans Shape, elle doit donc être préfixée avec actual.

Overloading

Pas d’overloading que ce soit pour les méthodes standards ou le constructeur. Un seul constructeur est donc possible par classe. Mais il fournit en contrepartie des attributs optionnels. Emmanuel propose, pour le constructeur, d’utiliser un switch sur le type de l’argument.

void workWithRectange(Rectangle rect) { }
void workWithCircle(Circle rect) { }
void workWithFigure2D(Figure2D rect) { }
void supportsSubTyping(Shape fig) {
  switch(fig)
  case(is Rectangle) {
    workWithRectangle(fig) ;
  }
  case(is Circle) {
    workWithCircle(fig) ;
  }
  case(is Figure2D) {
    workWithFigure2D (fig) ;
  }
}

Rectangle, Circle et Figure2D sont ici des sous-classes de Shape.

Gestion du null

De la même manière que Kotlin, Ceylon utilise le caractère ‘?’ pour définir si une variable peut être nulle ou pas.

void typeSafety() {
  Cube? cubeOrNull() { return null; };
  Cube? Cube = cubeOrNull() ;
  print(cube.area.string) ;
}

Cet exemple génère une erreur de compilation. Il convient d’utiliser la forme ci-dessous.

void typeSafety() {
  Cube? cubeOrNull() { return null; };
  Cube? Cube = cubeOrNull() ;
  if (exists cube) {
    print(cube.area.string) ;
  } else {
    print("No cube") ;
  }
}

Union type

class Apple() {
  shared void eat() {}
}
class Snail() {
  shared void throwAway() {}
}
void unions() {
  Sequence<Apple|Snail> plate = {Apple(), Snail()};
  for (Apple|Snail food in plate) {
    print(food.string);
    if (is Apple food) {
      food.eat();
    } else if (is Snail food) {
      feed.throwAway();
    }
  }
}

L’union de types permet d’être sûr d’avoir un objet de type Apple ou Snail. Le mot-clé is permet de vérifier le type.

Autres fonctionnalités

Dans les autres fonctionnalités et syntaxes plus classiques, on retrouve :

• les closures,
• les annotations,
• un système d’interceptor pour la programmation par aspect,
• un système de modules.

Concernant l’outillage, Stéphane nous montre du code en live avec le plugin Eclipse. Ce dernier est assez avancé et nous retrouvons la coloration syntaxique, le refactoring, le type checking ainsi que le debugger.

Conclusion

Emmanuel termine la présentation en nous annonçant la mise en ligne du site sur Ceylon. N’hésitez pas à le consulter : la documentation est bien fournie (fonctionnement du langage, spécifications, etc…) et les exemples sont nombreux.

Enfin il ajoute que tout le monde est bienvenu sur le projet. Un github est disponible et il est possible de contribuer au projet dès à présent.

La séance s’est terminée par des questions/réponses. Nous avons notamment eu la question suivante : « Où se situe Ceylon par rapport à Kotlin ou à d’autres langages (Scala, Fantom) ? » Emmanuel explique que Ceylon se trouve entre le monde Kotlin et Fantom. Il justifie cela par le fait que le langage Fantom a pris le parti de supprimer certaines notions du langage Java et que dans Kotlin on ne retrouve pas la notion d’Union type.

À travers cette conférence, nous constatons que les nouveaux langages sont à la « mode ». Ceylon tente de se faire un chemin dans la bataille aux « successeurs de Java » avec d’autres challengers comme Kotlin. Il ne nous reste plus qu’à surveiller les évolutions de ces différents langages et de voir lequel proposera les meilleures approches de programmation dans les mois à venir.

Joe a débuté sa carrière comme architecte logiciel, mais nous explique avec enthousiasme qu’il a découvert sa passion pour les interfaces utilisateur en travaillant sur des toolkits graphiques. Adepte de course automobile, il occupe aujourd’hui le poste de ses rêves : Tesla motors l’a chargé de concevoir le panneau de contrôle intérieur du futur Modèle S.

Comme on pouvait s’y attendre, sa présentation est très professionnelle, avec des diapositives minimalistes mais efficaces, qui rappellent Presentation Zen. Il s’attache surtout à définir des principes directeurs, à la façon de Don’t make me think, qu’il citera d’ailleurs comme référence.

Avant l’interface utilisateur, il faut s’intéresser à l’expérience utilisateur : peaufiner l’interface est la dernière étape. Il faut avant tout définir ce que fait le produit, comment il rend service à une personne. Le processus de design suit les étapes suivantes :

• L’expression du concept, c’est à dire du besoin métier ;
• L’architecture de l’information et la conception des interactions, qui se caractérisent par des itérations sur des prototypes de bas niveau (diagrammes de flux ou modèles en « fil de fer ») ;
• La conception visuelle, qui itère cette fois-ci sur des mockups très fidèles au rendu final ;
• Enfin, le plan de mise en production.

Le design est subjectif : il n’y a pas de réponse objectivement correcte à un problème donné. Cependant, l’interaction homme-machine repose sur quelques principes de base, qu’il faut respecter. Pour Joe, le design par comité ne marche pas : les discussions sont bénéfiques dans les phases d’itération, mais une seule personne doit prendre la décision finale. De même, il estime que le design par heuristique (mesurer les temps de réflexion, le nombre de clics…) fonctionne mais ne donne pas de bons résultats visuels (« looks assy » selon ses propres termes).

La seconde partie de la présentation est plus pratique, Joe nous livre ses « règles d’or » du design :

1. La structure des données sous-jacentes ne doivent pas influencer l’interface utilisateur. Inversement, l’interface ne doit pas non plus influencer l’implémentation. Souvent, une bonne interface évite ces problèmes grâce à une couche de transformation de données.
2. Le besoin doit primer sur la technologie. Il faut résister à la tentation de se « faire plaisir » sur la technique. Idéalement, les choix techniques doivent être repoussés le plus tard possible, une fois que le besoin est bien cerné.
3. Démarrer le processus avec de vrais cas d’utilisation. Voir comment les utilisateurs répondaient au besoin précédemment, ce qui marchait et ne marchait pas.
4. Identifier les catégories d’utilisateurs qui vont utiliser le produit. Les incarner sous forme de personnages avec un nom, une photo, qui aidera à les identifier. Envisager de leur proposer des interfaces différentes.
5. Penser en terme de flux, pas de fonctionnalités. Une interface est vivante, en mouvement. Par exemple, ne pas penser en terme d’écran de connexion, mais de processus de connexion. Ceci facilitera les retours des utilisateurs dès les premières itérations.
6. Prototyper souvent, jeter les prototypes souvent. Ne pas trop investir, construire rapidement et jeter sans regret.
7. Rendre la prochaine étape évidente. Joe nous donne l’exemple de la page principale de Google, où les boutons « Recherche » et « J’ai de la chance » sont côte à côte et ont exactement le même style. Si vous découvriez cette page pour la première fois, la différence entre ces deux boutons serait-elle évidente ?
8. Réduire le nombre d’éléments perçus. Face à un écran, le cerveau perçoit une charge cognitive, sur laquelle il se base pour estimer le travail nécessaire pour « gagner » l’écran. Il évalue dans l’ordre :
   • les formes négatives et l’esthétique, qui produisent une réponse émotionnelle ;
   • le nombre d’éléments, qui détermine la charge de travail perçue ;
   • et enfin l’emplacement du premier élément, qui déclenche l’exécution.
      Joe montre un exemple avec les mêmes champs organisés de deux manières différentes, le résultat est frappant : le premier écran, avec tous ses champs en colonne, est complètement rébarbatif ; le second, utilisant quelques regroupements et des titres de section, paraît beaucoup plus simple à remplir.
9. Utiliser la mémoire musculaire, être consistant.
10. Penser à ce qui peut être fait sans rechargement de page. Par exemple, une liste chargée progressivement en AJAX peut être plus efficace qu’une liste paginée : l’utilisateur se souviendra mieux de la position approximative d’un élément que d’un numéro exact de page.
11. Utiliser des transitions pour changer d’état. Montrer à l’utilisateur où il va, et comment revenir. Joe nous montre la page descriptive de la Tesla Modèle S, où la transition vers les sections se fait avec un défilement automatique vers le bas.
12. Itérer et raffiner, itérer et raffiner. Joe valorise les designers qui cherchent continuellement à améliorer leur produit.
13. Et avant tout, fournir une expérience de qualité à l’utilisateur. Ne pas juste « livrer cette fichue interface ».

Une présentation remarquable par la qualité de son orateur, et fourmillant de conseils utiles.

Après une intervention controversée de Matt Raible à Devoxx 2010 concernant la comparaison de frameworks Web, cette année trois personnes ont choisi de remettre le couvert :  Stijn Van den Enden, Guy Veraghert et Ward Vijfeijken.

Stijn débute la présentation en nous rassurant : leur recherche concerne une poignée de frameworks Web et est basée sur la scalabilité. Pour lui cette dernière est une notion importante :

• Elle influe sur l’infrastructure
• Elle assure une qualité de service
• Elle a un coût non négligeable

Stijn nous explique qu’ils ont pris le parti de baser leur expérience sur les frameworks Web suivants :

• GWT
• JSF
• Wicket
• Spring MVC

Il poursuit avec le type d’application qui les intéresse :

• Ecrans détaillés
• Navigation de pages
• Autocompletion
• Ajax validation
• Mise à jour du DOM

Ensuite pour tester la scalabilité de ces frameworks, l’expérience a porté sur :

• Les temps de réponse
• Think time (temps d’attente par un utilisateur avant de pouvoir effectuer une autre action)
• Throughput (nombre de requêtes en succès par secondes)

Concernant la plateforme, les tests ont été effectués sur Amazon Web Server avec un Tomcat et une base de donnée MySQL.

Avant de nous dévoiler les résultats, Stijn nous explique que pour les analyser son équipe s’est basée sur le modèle théorique de la loi de Little afin d’avoir une référence pour faire parler les données. En résumé, le principe est de trouver un optimum concernant les temps de réponse et le nombre de threads supportés.

Ayant collecté énormément de données (plus de 300 millions de mesures), l’équipe a mis en place une application Web permettant de tracer des graphiques basés sur un bon nombre de paramètres activables / désactivables (CPU data, Memory data, nombre d’utilisateurs, etc..)

Après toutes ces explications sur l’environnement de tests, les résultats tombent enfin :

GWT est le grand gagnant suivi de très près par Spring MVC. Un peu plus loin nous avons Vaadin et dans les plus mauvais élèves nous retrouvons dans l’ordre JSF/Wicket et MyFaces. L’équipe a choisi d’intégrer Vaadin et MyFaces car ils n’avaient pas beaucoup de modifications à apporter.

A ce stade de la présentation, l’équipe nous dévoile qu’elle a été plus loin : la réalisation de tests sur le rendu des navigateurs.

Leur principal problème était que JMeter ne permet pas ce genre de tests. Ward nous présente alors leur solution: des plugins sur les navigateurs (firebug + network, Chrome developpment tool, HTTPWatcher) permettent d’extraire les données. Il nous parle ensuite de l’outil HAR Viewer qui permet d’interpréter et analyser ces données exportées, et nous explique l’automatisation de ces processus avec Selenium Web Server.

Encore une fois les résultats tombent : Wicket est le gagnant suivi de JSF, GWT et Spring MVC.

Néanmoins, Ward nous explique que les résultats sont légèrement biaisés : HAR déclenche son analyse trop tôt pour GWT. En effet, ce dernier a besoin de télécharger les javascripts avant de pouvoir effectuer un rendu. Des solutions en cours de développement peuvent y remédier (W3C Navigation timing API et W3C Resource timing API), mais ne sont pas encore disponibles.

Ward finit par nous présenter rapidement l’outil SpeedTracer, capable d’analyser les points de contentions sur les navigateurs (disponible seulement sous Chrome).

A travers tous ces tests, nous voyons que l’équipe a réalisé un travail réfléchi : mise en place d’un bon environnement de test, modèle théorique d’analyse des données, etc…, rendant les résultats justifiés et pertinents. Nous pouvons cependant regretter qu’ils n’aient pas intégré d’autres frameworks Web.

L’équipe conclue par le palmarès des frameworks en terme de coût de scaling pour 10000 utilisateurs avec des temps de réponse moyen à 200 ms

Le résultat final est GWT en premier, Spring MVC et JSF/Wicket.

Pour finir, Stijn ouvre le débat et pose la question suivant : c’est bien d’être rapide, mais le framework Web est-il vraiment le point de contention ? A méditer.

Productivity Enhancements in Spring 3.1

Costin Leau a commencé par remettre Spring dans le contexte actuel: l’évolution de Java EE tend vers une adoption rapide de EE6, Tomcat 7 apporte le support des Servlet 3 (de JEE 6) et le Cloud propose des solutions très diverses, de GAE basé sur Jetty à Amazon Elastic Cloud en passant par VMWare CloudFoundry proposant Tomcat. Bref les solutions sont multiples et Spring entend s’imposer en tant qu’élément commun permettant les bonnes pratiques facilitant le passage d’un environnement à l’autre.

Costin est ensuite entré dans le vif du sujet en détaillant les nouveautés qu’apportera Spring 3.1. Mais une précision s’imposait d’abord. Spring est souvent critiqué pour la verbosité de ses appplicationContext.xml, mais Costin a tenu à rappeler que depuis plusieurs années on peut configurer entièrement le conteneur en Java. Et c’est même disponible en Spring 2.0, grâce à un add-on ! Les critiques envers le xml ne sont donc pas fondées: comme toujours, Spring offre le choix.

Les nouveautés de Spring 3.1 sont les suivantes:

Nos applications doivent pouvoir être déployées dans différents environnements (serveur local, Cloud) ainsi que différents contextes. 2 fonctionnalités aident à cela:

• Afin de disposer des MEMES artefacts à déployers dans les différents environnements, il faut être capable de savoir dans quel environnement se trouve l’application pour qu’elle puisse adapter son comportement. On ne veut pas avoir à contruire des war/jar/ear/etc spécifiques à un environnement donné ! Une abstraction des propriétés a donc été effectuée (plus de détails ici) et elles peuvent donc être accédées de façon quasi-transparente tout en étant stockées dans:
  • JNDI
  • des propriétés systèmes
  • des fichiers .properties.
• Des profiles de beans permettant d’activer ou non certains beans seulement dans certains contextes. Par exemple en dev, vous n’utiliserez que qu’un mock d’authentification alors qu’en production le vrai service sera appelé. Couplé avec la configuration Java-based, on se contentera d’annoter un bean @Profile(« dev ») par exemple.
• Le c-namespace permet de simplifier légerement ses ApplicationContexts. Ainsi un bean pourra s’écrire

  <bean id="foo" class="x.y.Foo" c:bar-ref="bar" c:baz-ref="baz" c:email="foo@bar.com">
  <!-- au lieu de: -->
  <bean id="foo" class="x.y.Foo">
    <constructor-arg ref="bar"/>
    <constructor-arg ref="baz"/>
    <constructor-arg value="foo@bar.com"/>
  </bean>
  

• L’utilisation d’un cache se fera de manière aisée, de façon déclarative. Cette fonctionnalité est basée sur les paramètres d’entrée de la méthode et le principe est « même entrée, même sortie ». Les annotations @Cacheable et @CacheEvict parlent d’elle-même. Pour cacher les données, EHCache est prévu (ainsi qu’une ConcurrentMap pour le dev) mais on pourra aussi se brancher aisément sur GemFire ou Redis.

  // ici on utilise seulement la valeur brute de l'ISBN comme clef
  @Cacheable(value="book", key="#isbn.rawNumber")
  public Book findBook(ISBN isbn, boolean checkWarehouse, boolean includeUsed)
  // Suppression des entrées du cache avant de le recharger
  @CacheEvict(value = "books", allEntries=true)
  public void loadBooks(InputStream batch)
  

• Les servlet en version 3.0 seront de la partie avec un support de l’upload asynchrone grâce au nouveau MulitpartResolver.
• Spring sera à jour pour supporter de nouvelles versions de librairies:
  • Hibernate 4, pas encore sorti, déjà supporté.
  • Quartz 2.0 et 2.1. Mais leurs API n’étant pas compatible avec les précédentes versions, il faudra sans doute écrire du code spécifique. La compatibilité Quartz 1.5+ est de toutes façons conservée.
  • JDBC 4.1 apporté par Java 7
  • le framework fork-join lui aussi dans Java 7

Et la question qui vous brûle les lèvres est de savoir quand vous pourrez enfin mettre la main sur toutes ces bonnes choses: la RC1 est déjà disponible, la RC2 devrait débarquer la semaine prochaine et la version finale, Spring 3.1 GA « soon after ». Courage, ça ne va pas tarder !

Pour une description exhaustive des nouveautés de Spring 3.1, rien de mieux que la doc officielle.

Spring Social

Josh Long nous a quant à lui présenté Spring Social, une librairie qui fournit des abstractions pour faciliter les interactions avec les réseaux sociaux.

Comme nous le savons tous, les réseaux sociaux de nos jours sont fondamentaux: nombre de marques comptent sur eux pour leur marketing, pour assurer un support et suivi des utilisateurs, pour obtenir du trafic qualifié sur leur site… Même si vous n’êtes pas vous-même sur ces réseaux, tôt ou tard, vous travaillerez sur des projets où vous devrez interagir avec eux.

Tous ces réseau offrent des API HTTP/REST, ce qui est bien. Ce qui est mal par contre, c’est qu’ils disposent tous de formats et particularités qui nécessitent d’écrire du code spécifique à chacun.

Se connecter

Avant d’interagir avec les réseaux sociaux, il faut commencer par s’y connecter. Là intervient la notion de service provider.

Paramétrer la Connection

Mais encore faut il que votre webapp soit autorisée à manipuler le compte de votre utilisateur sur le réseau social. Pour cela, il faut que celui-ci l’y autorise. Et comme la suite des étapes, notamment pour l’authentification OAuth n’est pas triviale, Spring Social fournit le nécessaire pour faciliter et rendre générique ces étapes dans Spring MVC: c’est le ConnectController.

Interragir

Et pour utiliser toute la puissance de chaque réseau social, un module client spécifique est implémenté pour chacun et vous permettra d’accéder à vos listes d’amis (Facebook), de twitter (Twitter) ou d’autoriser un énième chasseur de tête à vous parler du poste extraordinaire qu’il a pour vous ou vos collègues (LinkedIn).

L’avantage d’un tel système est que si Facebook, par exemple, décide du moindre changement  de comportement de son API, le module client spécifique fournit par Spring sera rapidement mis à jour de façon à ce que vous puissiez continuer de façon transparente à y accéder.

Bien sûr un tel système d’abstraction a un certain coût et si vous souhaitez seulement interagir avec Twitter par exemple, vous feriez peut être mieux de passer directement par une librairie spécifique comme Twitter4J. Mais si vos besoin évoluent et que vous pouvez être amené à ajouter Facebook ou TripIt, la petite plomberie requise par Spring Social sera bien négligeable face au gain apporté par l’API unifiée.

Pour terminer, Josh a parlé de l’intégration de Spring Social avec Spring Intégration. Ce dernier apporte tout particulièrement le principe d’Hollywood (« don’t call us we’ll call you ») permettant de définir des callback qui seront appelés lorsque certains critères (plus de x mails reçus, arrivé d’un tweet, etc…) seront vérifiés. L’intégration se fait aisément avec des flux comme Twitter, RSS/Atom, l’envoi et la réception de mails POP3, SMTP, IMAP…

Bref, en plus du stand CloudFoundry, Spring était bien présent cette année sur le salon au travers de plusieurs conférence. Le framework continue à évoluer et à abstraire les accès à d’autres APIs. On regrettera juste ne pas avoir eu la moindre présentation sur Grails à se mettre sous la dent, d’autant que la version 2.0 ne saurait tarder.

Clojure est un dialecte de Lisp fonctionnant sur la JVM. Dans cette présentation, Alex Miller s’adresse aux développeurs sans expérience préalable du langage. Son but est d’en présenter les concepts de base et de montrer la puissance et l’expressivité qui lui ont fait choisir Clojure comme langage principal chez son employeur actuel.

Alex revient sur les paradigmes de base du langage :

• fonctionnel
• dynamique
• compilé
• favorisant l’immutabilité et l’évaluation paresseuse.

Il ouvre le capot du langage en nous expliquant le fonctionnement du compilateur :

En particulier, Clojure dispose d’un système de macros, qui seront détectées et transformées en un bloc de code par le reader.

Types de base

On retrouve sans surprise les équivalents des types Java : booléens, entiers et flottants. Parmi les particularités du langage, on peut noter que Clojure gère de manière transparente la conversion vers des types de précision arbitraire quand cela est nécessaire. Comme en Javascript, n’importe quel type peut être utilisé en tant qu’expression booléenne. Mais seuls nil et false sont considérés comme valeurs falsy, toutes les autres valeurs sont évaluées à true (y compris 0 et la liste vide ()).

Collections

Clojure fournit un ensemble de structures de base, que le développeur est encouragé à réutiliser au maximum :

(def myList '(1 2 3 4))        ;; liste chaînée, l'apostrophe est expliquée plus loin
(def myVector [1 2 3 4])
(get myVector 1)               ;; accès par index (renvoie 2)
(def mySet #{1 2 3 4})
(def myMap {:a 1, :b 2, :c 3}) ;; les clés sont des symboles (préfixés par ':' comme en Ruby)
(get myMap :a)                 ;; récupération par clé (renvoie 1)
(myMap :a)                     ;; notation plus concise
(:a myMap)                     ;; les symboles peuvent également se comporter comme des fonctions d'extraction

Au-dessus de tous ces types, on trouve la notion de séquence. Une séquence correspond à une liste logique composée d’un premier élément et d’une séquence contenant les éléments restants :

(first '(1 2 3 4)) ;; renvoie 1
(rest  '(1 2 3 4)) ;; renvoie (2 3 4)

Cette abstraction est très utilisée dans Clojure et ne se limite pas aux collections : ainsi, un fichier est une séquence de lignes, un répertoire une séquence de fichiers, un ResultSet une séquence d’enregistrements dans une base de données, etc.

La puissance des séquences réside dans les fonctions d’ordre supérieur qu’elles fournissent, comme nous allons le voir ci-dessous.

Fonction

Nous avons déjà vu quelques exemples d’applications de fonctions :

(+ 41 1) ;; renvoie 42

Un point intéressant à noter est qu’une expression est elle-même une liste : par défaut, Clojure invoque le premier élément en lui passant les valeurs issues de l’évaluation des éléments restants (il est possible de désactiver cette évaluation en précédant l’expression d’une apostrophe, comme nous l’avons fait pour écrire les listes littérales dans les exemples précédents).

Le code est donc écrit comme des données et les données comme du code ; on dit que le language est homoiconique (un mot à retenir pour briller lors de votre prochain dîner geek).

La définition de fonctions se fait avec le mot-clé fn :

(def square (fn [x] (* x x)))
;; ou sous forme raccourcie :
(defn square [x] (* x x))

Les séquences fournissent des fonctions d’ordre supérieur, c’est-à-dire auxquelles on peut passer d’autres fonctions (généralement des fonctions anonymes définies à la volée) :

;; Applique une fonction à tous les éléments d'une séquence
(map (fn [x] (+ x 1)) '(1 2 3 4))    ;; retourne (2 3 4 5)
;; Filtre les éléments d'une séquence selon un prédicat
(filter (fn [x] (> x 2)) '(1 2 3 4)) ;; retourne (3 4)

Au passage, les structures de données sont généralement immuables (les expressions ci-dessus renvoient une nouvelle liste). Clojure favorise également l’évaluation paresseuse et est capable de travailler avec des séquences infinies.

Alex dispose maintenant de suffisamment d’éléments pour nous présenter un exemple un peu plus concret :

;; Compte les lignes d'un fichier:
(defn line-count [file]
  (count (line-seq  (reader file))))
;; Compte les lignes de chaque fichier d'un répertoire:
(defn file-counts [dir]
  (map line-count
    (filter #(. % isFile)
      (file-seq (file dir)))))
;; Compte le nombre de lignes total dans le répertoire
(defn total-count [dir]
  (reduce + (file-counts dir)))

Sans expliquer en détail le code, on retrouve la concision et l’expressivité communément présentées comme des avantages clés des langages fonctionnels.

Objet

Dans les cas les plus simples, un objet peut être une simple map, mais Clojure permet également de créer un type d’enregistrement spécifique :

;; Un exemple de circonstance à Devoxx:
(defrecord Beer [name brewery])
;; Instanciation et affectation à une variable
(def beer (->Beer "Tremens" "Delirium"))
;; Accès à une propriété (comme pour les maps, plusieurs syntaxes)
(get beer :name)
(:name beer)
(beer :name)

Alex présente trois méthodes pour faire du polymorphisme :

1. dans le cas le plus simple, donner le même nom aux propriétés communes à plusieurs types, elles seront ainsi accédées de manière transparente quel que soit le type ;
2. les multimethods permettent de définir une fonction et de spécifier des implémentations différentes selon le type sur lesquels elle est invoquée ;
3. enfin, les protocoles définissent un contrat, qu’il faut implémenter pour chaque type participant :

(defprotocol Beverage
  (source [beverage]))
;; Pour une bière, la fonction source est implémentée en invoquant le getter de la propriété 'brewery'
(extend-protocol Beverage Beer
  (source [beer] (:brewery beer)))
;; Pour un vin, il s'agit de la propriété 'winery'
(extend-protocol Beverage Wine
  (source [wine] (:winery wine)))

On remarque ici une différence importante avec la notion d’objet en Java : la déclaration des données est séparée de celle des comportements. Bien que cette approche réduise l’encapsulation, elle est aussi plus flexible : ainsi, le développeur peut créer un protocole et le faire implémenter par des types qui ne sont pas forcément sous son contrôle (y compris les types de base de Clojure). Les amateurs de Haskell reconnaîtront ce mécanisme : les protocoles sont les équivalents des typeclasses.

Concurrence

Alex aborde rapidement les fonctionnalités offertes pour la programmation concurrente :

• les atoms sont similaires aux AtomicReferences de Java ;
• les refs sont utilisées uniquement à l’intérieur de transactions (Clojure dispose d’une mémoire transactionnelle logicielle) ;
• les agents sont des composants isolés communiquant à travers des files de messages, comme les acteurs d’Erlang ou Scala.

Démo

La session se termine par une session de coding pré-enregistrée, montrant l’implémentation du jeu de la vie de Conway. Les résultats intermédiaires sont affichés après chaque fonction développée, ce qui explicite bien comment l’application est assemblée en combinant des blocs de base.

L’affichage des résultats est un peu austère, mais Alex nous révèle qu’il a codé une interface graphique basée sur Processing pendant la keynote du matin (comment ça, la keynote n’était pas intéressante ?) et nous la démontre sous les applaudissements de la foule.

Pourquoi Clojure ?

Au final, Alex a réussi son pari en offrant un tour d’horizon de Clojure sans perdre son audience. La présentation donne envie d’aller plus loin dans l’expérimentation du langage.

Cependant, beaucoup des aspects présentés rappellent d’autres langages fonctionnels, en particulier Scala. Interrogé après la présentation, Alex explique que son équipe avait effectivement préselectionné Scala et Clojure sur la base des critères suivants :

• un langage sur la JVM ;
• permettant un niveau d’abstraction élevé ;
• avec un bon support pour la programmation concurrente.

Après quelques tests, c’est finalement Clojure qui l’a emporté, principalement car c’est le langage avec lequel l’équipe a ressenti le plus d’affinité.

Depuis quelques mois, Kotlin fait parler de lui. Rien de tel qu’une conférence comme Devoxx pour prendre la température de ce nouveau langage.

Lors de cette session, Andrey Breslav nous a expliqué d’abord les motivations qui ont poussé JetBrains à investir dans le développement de Kotlin :

• se détacher des limitations du langage Java dues à la compatibilité ascendante,
• avoir un outillage performant. Notamment, une intégration de qualité dans les IDE, un debugger et un compilateur au moins aussi rapide que celui de Java. Pour garantir cela, JetBrains développe en parallèle du langage et du compilateur, un plugin pour l’intégration dans leur IDE IntelliJ ainsi qu’un plugin simple pour Eclipse,
• avoir une syntaxe plus expressive.

Ensuite, il nous a expliqué les choix de design du langage :

• entièrement compatible avec java,
• code concis,
• statiquement typé.

Ces choix ont été fait de manière à limiter les erreurs à l’exécution de l’application.

Pour cela, ils ont implémenté différentes fonctionnalités.

Pour les plus classiques :

• Closure,
• Pattern matching,
• Inférence de type,
• Simplification des accesseurs sur les propriétés,
• Les Traits.

Et pour les plus innovantes :

• Extensions Function,
• Casting ‘intelligent’,
• Static null safety guarantees,
• Inline function,
• Reified Generics,
• Build infrastructure.

Andrey nous a montré ensuite un grand nombre d’exemples notamment :

• Hello world avec le parcours d’une itération :

  namespace demo
  fun main(args : Array<String>) {
    for (name in args)
      println("Hello, $name!")
  }
  

• Extensions Function qui peut notamment permettre d’étendre les fonctions d’une classe. Ici, on ajoute la fonction plusAssign que l’on peut appeler par + ou += à StringBuilder :

  namespace demo
  fun main(args : Array<String>) {
    val names = new StringBuilder()
    for (i in args.indices) {
      names += args[i]
      if(i+1 < args.size) {
        names += ","
      }
    }
    println("Hello, $name!")
  }
  fun StringBuilder.plusAssign(s : String) {
    this.append(s)
  }
  

• Smart Cast pour ne pas caster l’objet si le type est déjà testé. Il peut être aussi utilisé dans un pattern matching comme dans l’exemple suivant :

  namespace demo
  fun foo(obj : Any?) {
    if(obj is String) {
      obj.substring(2)
    }
    when (obj) {
      is String => obj[0]
      is Int => obj + 1
      !is Boolean => null
      else => ...
    }
  }
  

• Le pattern matching accepte des expressions ou un ensemble de valeurs :

  fun bar(x : Int) {
    when (x) {
      0 => "Zero"
      1, 2, 3 => "1, 2 or 3"
      x + 1 => "Really strange"
      in 10...100 => "In range"
      !in 100...1000 => "Out of range"
    }
  }
  

Cerise sur le gâteau, Andrey nous a montré le compilateur et le debuggeur sous IntelliJ parfaitement fonctionnels.

Cette session était surtout participative avec pas mal de questions dans la salle. À chaque fois, Andrey répondait à ces dernières de manière pertinente et nous avons constaté que l’équipe JetBrains a bien réfléchi pour faire un langage simple. Kotlin possède une syntaxe proche de celle de Java et de Scala, tout en les allégeant.

Kotlin est encore en phase de développement et les discussions sont encore vives sur les choix de conception du langage. Pour preuve, la page de Kotlin contient énormément de commentaires sur les améliorations ou évolutions à lui apporter. Un langage de plus à surveiller de près.

• Working Off the Grid: HTML5 Offline
• Bleeding Edge HTML5

Elles ont toutes été réalisées par des personnes de Google, preuve de l’implication de la compagnie dans le futur du HTML.

Il y avait aussi un sujet « Intro to HTML5 Game Programming – WebGL Edition » mais auquel aucun Xebian n’a pu assister: il faut bien faire un choix lorsque plusieurs sessions intéressantes sont en parallèle !

Working Off the Grid: HTML5 Offline

Sam Dutton de Google nous a présenté les différentes solutions de stockage hors ligne. Les problématiques adressées par ces technologies sont multiples:

• Problèmes de bande passante.
• Connexions peu stables.
• Amélioration des performances des applications web.
• Diminution de la consommation de ressources sur le serveur.
• Amélioration générale de l’expérience utilisateur.

Auparavant, nous ne disposions que de méthodes peu satisfaisantes: cookies, flash…

Maintenant, des solutions plus adaptées sont à notre disposition:

• Web Storage (localStorage/sessionStorage): permet de stocker de façon simple des paires clef/valeur.
• IndexedDB/WebSQL: stockage de structures plus complexes et support des transactions (utile si plusieurs onglets ou sessions ouverts simultanément).
• AppCache: l’utilisation d’un fichier manifeste permet de déclarer des ressources (images, CSS…) à mettre en cache.

Bref, les possibilités s’annoncent énormes mais des problématiques fondamentales demeurent: quid de la compatibilité entre navigateurs ? Tous ne supportent pas toutes les APIs et cela peut augurer de belles galères. C’est malheureusement un aspect sur lequel la présentation n’a pas du tout insisté.

Pour plus de renseignements sur les possibilités de stockages hors ligne, le site html5Rocks en offre un vaste aperçu.

Bleeding Edge HTML5

Paul Kinlan (dont voici le blog) a effectué une présentation assez généraliste sur nombre de nouveautés apportées par HTML 5. Les slides sont en ligne et voici les points marquants:

• Début en douceur avec la nouvelle balise <mark /> qui s’utilise pour mettre en avant, de façon sémantique, une partie de texte. Bon, ce n’est pas cela qui changera la face du web !
• Les champs susceptibles d’être remplis par la voix, les speech input, sont aussi une nouveauté: un attribut x-webkit-speech, pour l’instant disponible seulement sur Chrome, permet d’offrir la possibilité de saisir du texte avec un micro. On peut se demander pourquoi laisser au développeur le choix d’activer ou non cette possibilité: il serait peut être plus simple de laisser le choix au niveau du navigateur, ce qui permettrait à tous les champs texte de bénéficier de cette fonctionnalité.
• On passe ensuite à des nouveautés plus impressionnantes concernant les animations. On en profitera pour remarquer que Google a en ce moment un intérêt certain pour les jeux videos: que ce soit avec Angry Birds dans Chrome ou le nouveau framework avec lequel il a été réalisé, PlayN, Google a envie de réussir dans ce domaine. Pour revenir aux animations, donc, au lieu de coder en dur un timeout définissant le framerate à une valeur fixe, les navigateurs proposent maintenant la notion de « RequestAnimationFrame » qui appelle un callback définit par l’utilisateur quand le navigateur le juge utile. Ainsi le CPU ne travaillera pas pour rien: d’une part, pas besoin de calculer 100 images secondes si le rafraichissement de l’écran est de 60Hz, et d’autre part le callback ne sera pas appelé si l’onglet de l’animation n’est pas l’onglet actif. Cette fonctionnalité fait aussi partie de la « page visibility API« : les vidéos ou sons pourront être mis en pause lors du changement d’onglet.
• Les « prerendered pages » sont des pages liées à d’autres par un lien spécial permettant leur chargement en arrière plan pour un rendu immédiat lors du clic sur le lien. On peut imaginer Google utiliser ce type de liens pour précharger les 2 ou 3 premiers résultats affichés lors d’une recherche. Par contre, on voit mal comment ce type de liens pourra se passer d’augmenter virtuellement le traffic des sites même s’ils n’ont pas été visités réellement par des utilisateurs.
• Un attribut « online » de l’objet js navigator permet maintenant de connaitre l’état de l’ordinateur, connecté ou non à un réseau. Un callback permet d’être notifié sur un changement d’état (connexion/déconnexion).
• Après le succès qu’on leur connait dans Android, les « intents » débarquent sur le web. On pourra grâce à eux partager du contenu entre plusieurs sites. Il suffira que les sites fournisseurs se déclarent au navigateur pour que l’on puisse les sélectionner comme tel et, par exemple, importer directement des photos en provenance de Picasa lors de la rédaction de son mail sur gmail.com. Plus de détails dans les slides.
• Le projet WebRTC a pour but de donner la possibilité de réaliser des chats vidéos sans flash, directement avec les API javascript fournies par le navigateur. Le but avoué est de casser le paradigme de la numérotation en permettant des communications instantanées en un clic. Mais du coté software, cela suppose bien sûr des notions de:
  • Capture/rendu de flux audios/vidéos.
  • Énumération des périphériques matériels de capture.
• Pour finir, nous avons eu droit à une démonstration plutôt impressionnante de génération dynamique de sons, en temps réel et en javascript. Des filtres successifs peuvent être appliqués pour déformer le son original.

Dès demain, de nouvelles présentations sur HTML5 devraient avoir lieu, notamment en relation avec JavaFX et Play!/Scala. Il n’y a pas de mystère, HTML5 gagne ces temps-ci une crédibilité énorme, avec notamment les soutiens récents de Microsoft et Adobe, qui incitent nombre d’entre nous à s’intéresser de près au projet qui est en perpétuelle évolution.

David commence par poser la question suivante : comment créer une application Web avec le comportement d’une application desktop ? La réponse réside dans de petites démonstrations des possibilités d’HTML 5 :

• Sauvegarde de fichiers du navigateur vers le filesystem et inversement.
• Sauvegarde des données saisies localement
• Détection des déconnexions et reconnexions automatique.

Assez bluffantes, ces fonctionnalités se mettent en place en seulement quelques lignes !

David poursuit avec le CSS3 et nous parle des possibilités de transitions et d’animations. Pour les fans de jeux, la version Web d’Angry Birds est basée sur CSS3 et lorsque nous voyons le résultat, nous ne pouvons qu’être admiratifs.

Vient ensuite une discussion autour de la conception des applications. David nous explique que les frameworks MVC (Backbone, ExtJS, etc) nous impose une limitation de par leur structure.

Une première solution réside dans l’utilisation du triplet HTML, javascript et CSS, mais cette dernière pose un certain nombre de problèmes :

• Manque de performances.
• Difficulté de debugging.
• Pas de typage fort, rendant le développement d’outils difficile.

La seconde solution est l’utilisation du framework GWT. Le principe est de coder du Java qui est automatiquement « traduit » en javascript. Ce dernier permet d’adresser les problèmes précédemment cités, mais GWT reste difficile à maîtriser et peut se révéler lourd à mettre en place.

David nous présente alors DART. Ce dernier est né de la volonté d’avoir un langage de scripting plus léger tout en utilisant la structure d’un langage orienté objet. Dart est un langage construit pour plaire à la fois aux personnes fluides en Java ou en JavaScript. La courbe d’apprentissage devrait être particulièrement courte pour ces deux populations. Aujourd’hui Dart est un langage qu’il faut « compiler » pour produire du javascript, dans la même veine que coffeescript.

Voici un exemple de code en DART :

interface Shape {
  num perimeter();
}
class Rectangle implements Shape {
  final num height, width;
  Rectangle(num this.height, num this.width);  // Compact constructor syntax.
  num perimeter() => 2*height + 2*width;       // Short function syntax.
}
class Square extends Rectangle {
  Square(num size) : super(size, size);
}

Nous retrouvons ainsi les notions de classes, interfaces et méthodes entre autres.

Concernant l’outillage, nous avons à disposition Dart VM, dartc (compilateur javascript écrit en java), frog (compilateur javascript écrit en Dart, qui fait figure de futur compilateur) et le dartboard. Un début d’IDE Dart (appelé Dart Editor) existe également pour Eclipse. Tous ces éléments peuvent être retrouvés sur le site du langage. Il est à noter que Dart est encore en version alpha, et que des changements dans le langage vont encore intervenir. Il n’existe pas non plus de binaire disponible en téléchargement pour toutes les plateformes, mais nous sommes invités à télécharger les sources et à construire les différents outils (VM, compilateur etc..)

David termine sa présentation en nous expliquant qu’il reste encore du travail sur ce langage, mais que Google travaille d’arrache pied pour nous donner la possibilité de développer du javascript avec une syntaxe allégée. Notamment ils discutent avec l’équipe en charge de Google Chrome pour une intégration native de Dart dans le navigateur, poussant pour que demain, les navigateurs du marchés embarquent une vm dart, comme ils embarquent aujourd’hui une vm javascript.

Nul doute que l’évolution de ce langage est à surveiller et que ce dernier fera parler de lui dans les mois à venir.

Les slides de cette présentation sont disponibles, en html5 bien sur.

Xebia a le plaisir de continuer à supporter la communauté Java, comme elle le fait depuis 4 ans, en étant sponsor platinum de ce qui va devenir une conférence majeure java en France : Devoxx France.

Cette annonce vient d’être faite à Devoxx à Anvers en Belgique, sous la forme d’une vidéo.

Nous serons donc présents les 18,19 et 20 avril 2012 pour Devoxx France.

L’événement incontournable de la communauté Java arrive enfin ! Devoxx, un des plus grands salons européens, fête ses 10 ans et se déroule cette semaine à Anvers en Belgique. Comme chaque année, Xebia sera présent.

A travers les conférences et les rencontres, ce rendez vous annuel majeur est l’occasion de prendre la température de l’écosystème Java. Les thèmes de cette année sont une fois de plus assez variés avec une plus forte tendance vers de nouveaux langages :

• Fantom, Ceylon et Kotlin : ces langages proposent des approches de programmation différentes et tentent de se faire une place dans notre écosystème entre les langages Java et Scala.
• HTML5 : il s’agit d’un des sujets majeurs de cette édition avec pas mal de sessions sur les possibilités offertes par ce dernier.
• NoSQL : encore représenté cette année, des sessions sur la communication avec des frameworks de l’écosystème Java seront présentées.
• JDK 8 : à peine remis de la sortie du JDK 7, la prochaine version aura droit à son lot d’annonces.

Bien entendu, d’autres sujets seront présentés comme les nouveautés du langage Scala, Android, JavaEE, Spring… Pour vous donner envie, voici le programme complet des réjouissances.

Comme les années précédentes, vous retrouverez sur le blog nos retours des principales sessions qui se tiendront à Anvers cette semaine, ou sur nos twitters respectifs @francoismarot, @njozwiak, @JulienBuret, @olim7t, @cyrilleleclerc & @morlhon pour une activité live.

La culture du partage de la connaissance étant la valeur fondatrice de Xebia, ces journées mensuelles réunissent nos passionné(e)s qui discutent, entre autres, des dernières technologies de l’écosystème Java JEE et font partager leurs retours d’expérience sur des sujets techniques (mais pas seulement) choisis à l’avance.

C’est donc à travers des présentations formelles, des sessions de travaux pratiques, des débats, que chacun peut faire profiter de son point de vue et de son expérience.

Après un vote collégial sur les sujets qui seront abordés au cours de cette journée, les volontaires ont plusieurs semaines pour travailler seuls ou en groupe sur leurs sujets plébiscités par l’ensemble de leurs collègues.

Xebia souhaitait vous en dévoiler un peu plus sur ces journées, au coeur de l’ADN et des synergies de Xebia.

Au programme ce mois ci :

Après le café du matin, qui aide à oublier le grand froid, la journée commence avec une session News / Actus au cours de laquelle les 45 consultants de Xebia échangent librement sur les actualités qui ont retenu leur attention ce mois-ci.

Pour continuer, les consultants ont eu le choix entre deux sessions parallèles :

• Une présentation sur la collecte de logs sur des architectures massivement distribuées, par Pablo Lopez.
• Un slot Acceptance Test Tools Contest, par Nathaniel Richand.

Après le déjeuner, qui est l’occasion de poursuivre les débats et discussions de la matinée et de faire connaissance avec les invités autour d’une pizza, nous accueillons Michaël Chaize évangéliste de la plateforme Flash qui nous présente les nouveautés des plateformes Flash et Flex d’Adobe.

L’après midi, se poursuit avec deux Hands On en parallèle :

• Un Hands On « BDD (Behaviour Driven Development) avec « jBehave », animé par Hamza Benmansour et Aurélien Masse.
• Un Hands On « Développement iPhone », animé par Amin Fathallah.

La dernière session de la journée est un retour complet sur Devoxx, par Ellène Dijoux, Romain Maton et Michael Figuière, nos reporters pour l’évènement !

Le XKE s’est terminé, comme à son habitude, par un apéritif improvisé pour célébrer une nouvelle journée d’émulation technique et de partage de connaissances…

La keynote de Mark Reinhold, Chief Architect de la plate-forme Java chez Oracle, était particulièrement attendue après une actualité très riche sur le JDK ces derniers mois.

L’année dernière, l’annonce d’un nouveau délai pour la sortie de JDK 7, afin de permettre la ré-intégration des closures, avait provoqué la surprise. L’été arrivant, la communauté se rendait alors compte que le planning initial prévoyant un JDK 7 features complete pour juin était déjà dépassé et irréaliste. Quelques mois plus tard, Mark Reinhold annonçait sur son blog un « plan B » : on ne conserverait alors dans JDK 7 que les fonctionnalités déjà implémentées pour repousser celles qui sont encore en cours d’élaboration, telles que les closures ou la modularité, au JDK 8.

Plus récemment l’actualité était marquée par l’annonce de nouveaux entrants dans le projet OpenJDK : IBM dans un premier temps, s’étant résigné à mutualiser ses efforts de développements avec Oracle, et Apple qui après l’annonce de l’arrêt du support de Java dans Mac OS X avait décidé de léguer les développements spécifiques à son OS au projet OpenJDK.

Dans ce contexte rempli de rebondissements et d’incertitudes, Mark Reinhold a apporté quelques clarifications et une visibilité appréciable sur l’avenir de Java.

Productivité

Project Coin

Le projet Coin fait partie de l’actualité Java depuis de nombreux mois maintenant et l’on a pu se familiariser avec la plupart des évolutions du langage qu’il va apporter. Aucun ajout n’a été annoncé aujourd’hui. Rappelons qu’il contient les évolutions suivantes :

• L’opérateur <> permettant d’instancier facilement des classes génériques en ne répétant pas le(s) paramètre(s). On obtient ainsi (Map<String, String> map = new HashMap<>();).
• La gestion des ressources via la structure de contrôle try..catch, qui simplifie grandement l’écriture de code d’E/S et résout la confusion autour de la fermeture de flux lançant de multiples exceptions.
• La prise en charge des string dans les structures switch.
• Une notation plus lisible pour les constantes numériques.
• Le multi-catch permettant de capturer en une seule structure plusieurs types d’exceptions.
• La simplification de l’invocation des méthodes utilisant des varargs.

La réification au secours de l’érasure

Pour des raisons de compatibilité ascendante, les generics ont été ajoutés à Java 5 en procédant par type erasure. Cette technique consiste à ne manipuler les generics que dans le code source et à les faire disparaître du bytecode compilé. Les generics permettent alors uniquement d’effectuer diverses vérifications de typage lors de la compilation mais n’ont aucun apport à runtime. Il est donc impossible d’écrire

Object list = new ArrayList<String>();
if (list instanceof List<String>)
...

De même, la surcharge de méthodes ne se différenciant que par leur type de paramètre generics est impossible.

Très rapidement après l’arrivée de Java 5, ces limitations ont été critiquées. Mark Reinhold affirmait aujourd’hui son souhait de voir la réification de type intégrée dans une future version de Java. La réification consiste en l’ajout du typage generics dans le bytecode rendant ainsi cette précieuse information disponible à runtime.

L’absence de connaissance sur le typage des generics à runtime est également la raison pour laquelle les paramètres ne pouvaient pas être des types natifs. Ignorante du typage des paramètres, la JVM ne pouvait en effet qu’émettre l’hypothèse que ceux-ci héritaient de la classe Object. On peut alors se prendre à rêver à la possibilité d’écrire :

List<int> list = new ArrayList<>;

Et ainsi de se passer de classes de collections spécialement écrites pour ces types natifs. Mais de nombreux défis devront toutefois être relevés pour en arriver là : le passage en paramètre d’un objet est différent de celui d’un type natif, ce qui pourrait mener à des comportements inattendus pour les classes développées avant l’arrivée de la réification et qui supposeraient donc que la modification d’une variable serait propagée au-delà du contexte des méthodes. Ce type de défi lié à l’exigence historique de compatibilité ascendante entre versions de Java est courant pour l’équipe en charge du JDK.

Aucune version de Java n’a été précisée pour la réification, classant donc cette fonctionnalité comme étant « à l’étude » pour le moment.

Les value class

Les value class constituerait une nouvelle famille de types dans Java que l’on peut formaliser comme un javabean intégré au langage. Les différents champs seraient alors exposés sous forme de propriétés. Ce type de classe pourrait prendre la forme suivante :

value class Node {
    Node property parent;
    Node property leftChild;
    Node property rightChild;
}

Le retour des propriétés dans le radar de l’équipe en charge du JDK ravira sans nul doute tous ceux qui sont lassés de devoir s’en remettre à leur IDE pour la génération des getters / setters !

Aucune version n’a malheureusement été spécifiée pour l’intégration de cette fonctionnalité.

Performance

On le sait depuis quelques années, l’amélioration des performances des applications passe dorénavant par l’utilisation du multithreading pour bénéficier de l’augmentation du nombre de cœurs sur les serveurs. Java est armé face à ce défi grâce aux apports liés à java.util.concurrent dans Java 5. L’enjeu est maintenant de rendre ces fonctionnalités plus simples et productives à utiliser.

Les extensions de java.util.concurrent

Java 5 avait introduit un ensemble de classes facilitant l’écriture de programmes parallèles dans le package java.util.concurrent. La JSR-166 (Concurrency Utilities) les avait standardisées. Java 6 avait amené de légères évolutions à ce package qui avait été noté JSR-166x. Java 7 apportera à son tour des avancées dans ce domaine crucial pour l’avenir, sous la forme de la JSR-166y. On compte parmi elles :

• La très attendue API Fork / Join mais sans le ParallelArray,
• Une API donnant accès à des possibilités atomiques de bas niveau, permettant à terme la disparition de la classe interne non-standard sun.misc.Unsafe
• Une TransferQueue et une LinkedTransferQueue pour faciliter la communication entre threads,
• Une ConcurrentReferenceHashMap permettant la manipulation concurrente de références fortes ou faibles (weak references).

Les closures

Novembre 2009, Devoxx. Une session de Mark Reinhold sur JDK 7 crée l’évènement, il y annonce le retour des closures justifié par le besoin de simplifier le développement multithread. Aujourd’hui les closures sont toujours sur la roadmap, mais décalées au JDK 8.

Le lien qu’Oracle fait entre programmation parallèle et closures s’explique par l’exemple suivant. Ici on souhaite étendre l’API Collection pour offrir des méthodes filter(), map(), ou encore max() qui de manière transparente délègueront au besoin le travail à plusieurs threads :

Collection<Student> students = ...;
double max = students.filter(new Predicate<Student>() {
    public boolean op(Student s) {
        return s.gradYear == 2010;
    }
}).map(new Extractor<Student, Double>() {
    public Double extract(Student s) {
        return s.score;
    }
}).max();

Pour obtenir ce type d’exécution parallèle implicite, il est ici bien entendu nécessaire de fournir une classe anonyme implémentant le code à exécuter. Cette approche est verbeuse et rapidement inadaptée à une application d’entreprise complexe ; suffisamment tout du moins pour éloigner les développeurs de ce type d’API.

Mark Reinhold montre alors ce que pourrait devenir l’exemple précédent avec les closures :

double max = students.filter(#{ Student s -> s.gradYear == 2010 })
                     .map(   #{ Student s -> s.score })
                     .max();

Le code est concis, et une fois la syntaxe basée sur les symboles # et -> assimilée, il s’avère tout à fait lisible.

Les méthodes d’extensions

L’ajout des closures étant destiné à améliorer la programmation parallèle, il doit forcément être accompagné de nouvelles méthodes sur les collections permettant de leur soumettre du code.

Le problème est que l’interface java.util.Collection a été mainte fois implémentée dans diverses librairies et applications. Lui ajouter une méthode casserait donc le code existant.

Les méthodes d’extensions viennent résoudre ce problème en permettant d’adjoindre à la nouvelle méthode une implémentation par défaut. Ainsi dans l’exemple de la classe java.util.Collection on obtiendrait :

Collection<T> filter(Predicate<T> p) default Collections.<T>filter;

L’implémentation par défaut est alors une méthode statique définie dans une classe tierce et qui prend en premier argument l’objet sur lequel s’applique la méthode. Dans l’exemple précédent, le prototype de la méthode d’extension filter() serait donc :

static <T> Collection<T> filter(Collection<T> collection, Predicate<T> p);

Modularité

Jigsaw reste l’avenir de la modularité

Le besoin pour un mécanisme de modularité intégré au langage se fait ressentir pour assurer la logique d’encapsulation au-delà des frontières des classes. Parallèlement, Maven a montré l’intérêt d’une gestion de versions pour ces modules.

A l’heure actuelle, il semble qu’OSGi peinera a être accepté comme solution de modularisation pour Java. Sa complexité a probablement contribué à rendre SpringSource dm Server trop peu attractif pour attirer un large public. Dès lors, la voie est libre pour Jigsaw pour proposer une solution simple et efficace à cette problématique.

Mark Reinhold ne s’est pas étendu en détails sur Jigsaw mais a exprimé fermement son souhait de le voir remplacer à terme la notion de classpath aujourd’hui inadaptée aux applications complexes et denses que l’on connaît.

Gestion des dépendances

Maven est de nos jours omniprésent dans les entreprises. Cet outil s’est imposé au fil des années comme un standard dans la gestion des dépendances Java : même ses concurrents tels qu’Ivy ou Gradle sont basés sur le système de définition des modules de Maven et sur son réseau de dépôts.

Java se dotant d’un mécanisme de modules, une intégration intelligente se devait d’exister. Mark Reinhold a ainsi expliqué que Maven serait pris en compte pour la gestion et le téléchargement des modules Java sur la machine.

Là encore, aucune version n’est spécifiée pour l’intégration de Maven avec Jigsaw, mais on peut logiquement imaginer (ou tout du moins espérer) son arrivée pour le JDK 8.

D’autres formats que le Jar

Mark Reinhold a surpris l’audience avec cette annonce. Il s’agirait de permettre d’autres formats de packaging pour les applications Java que le jar. On parle tout d’abord d’un nouveau format baptisé jmod qui serait basé sur une autre compression que zip, telle que pack200.

Mais la réflexion va plus loin en envisageant d’étendre les formats de packaging jusqu’aux archives propres aux systèmes d’exploitation de production tels que rpm ou deb. Ceci simplifierait grandement les déploiements et les interactions avec les équipes d’exploitation !

La roadmap

Après avoir énoncé les différentes évolutions, il fallait forcément aborder l’épineuse question du planning. Les retards successifs de JDK 7 laissent planer le doute quant à la date de finalisation effective, mais reconnaissons que l’allègement de la liste des fonctionnalités de JDK 7 rend cette fois la roadmap plus réaliste ; la plupart des fonctionnalités restantes étant en effet déjà implémentées. Le calendrier présenté par Mark Reinhold et posté sur le site du projet OpenJDK quelques heures plus tard est le suivant :

• 16/12/2010 : Feature Complete
• 12/04/2011 : Rampdown start: P1-P3 bugs only
• 28/04/2011 : API/interface changes: Showstoppers only
• 11/05/2011 : All targeted bugs addressed, First release candidate built
• 18/05/2011 : Bug fixes: Showstoppers only
• 08/06/2011 : Final test cycle starts
• 28/07/2011 : General Availability

Les aspects politiques

Oracle et Java

Mark Reinhold a également consacré quelques instants pour évoquer les aspects politiques qui entourent Java. Les inquiétudes sont en effet nombreuses au sein de la communauté : on reproche souvent à Oracle son comportement très agressif vis-à-vis des autres acteurs du marché ainsi que de sa vision parfois éloignée du monde de l’Open Source.

Son message se voulait clair sur cette question : l’intérêt d’Oracle est d’assurer la pérennité de Java, dans la mesure où nombre de ses produits commerciaux sont basés sur cette plate-forme.

Les nouveaux entrants dans l’OpenJDK

L’OpenJDK a vu ses troupes s’enrichir de deux soutiens majeurs ces dernières semaines : IBM et Apple.

IBM avait rejoint le projet un mois auparavant dans un but de mutualiser les efforts de développement avec Oracle et reconnaissant par ce geste implicitement un intérêt commun à assurer l’évolution, la stabilité et la pérennité de la plate-forme Java, supportant nombre de leurs produits commerciaux.

L’annonce du ralliement d’Apple est encore plus récente. Apple avait en effet exprimé son souhait de ne plus assurer le support de Java dans son OS à l’avenir, puis avait annoncé léguer les développements spécifiques à Mac OS X au projet OpenJDK.

Mark Reinhold s’est logiquement montré enchanté de ces divers ralliements permettant de concentrer les différentes forces au développement futur de Java.

Conclusion

Mark Reinhold s’est attaché à formaliser les objectifs qu’Oracle se fixe pour l’avenir du langage Java : conserver la facilité de lecture du langage, plus importante à leurs yeux que la productivité d’écriture. Pour cela chaque nouvelle fonctionnalité est évaluée avec soin afin de déceler les potentiels effets secondaires qu’elle pourrait provoquer. Mark Reinhold expliquait ainsi son souhait de voir Java encore présent en 2030.

Le planning à venir ne s’étalant que sur les 6 prochains mois, il sera aisé de se rendre compte de la potentielle ponctualité de Java 7. Le niveau d’avancement actuel permet toutefois d’être très confiant quant à sa finalisation courant 2011. Les fonctionnalités plus audacieuses de Java 8 pourraient par contre repousser ce dernier au-delà de 2012…

L’avantage du Flash

L’avantage du Flash est la possibilité de développer des applications plus intuitives, efficaces et faciles à utiliser. Michael nous présente une application pour la finance réalisée pour une grande banque française. Le backend est resté le même, seul le client a été modifié pour être remplacé par du Flex. Une amélioration de la productivité des utilisateurs a pu être constatée. En effet, les données étaient plus facilement lisibles et exploitables par les utilisateurs qui prenaient donc des décisions plus rapidement.
Michael met en avant la productivité par le design. L’avantage de Flex est la facilité avec laquelle on peut réaliser des applications. Elle est productive pour le développeur et pour l’utilisateur.

Les nouveautés de la plateforme Flash

Tout d’abord Adobe a intégré dans sa plateforme le support d’HTML5 pour que ses outils, tels que Dreamweaver et Illustrator par exemple, le supportent .
La plateforme Flash est un panel complet de solutions permettant de réaliser des applications riches sur tous les supports qui vont du mobile à l’ordinateur, en passant par la télé. Cette plateforme fournit tous les outils indispensables au développement d’applications, vidéos et autres. Les applications sont natives pour tous les supports. Adobe et d’autres partenaires ont d’ailleurs créé le projet open-screen qui a pour but de travailler ensemble à l’élaboration d’un environnement consistant pour la navigation web et le lancement d’application sur n’importe quel écran. Ce projet exploite les avantages de Flash Player et d’Adobe Air.

Flash Player 10.1

Le taux de pénétration de Flash Player 10.1 est actuellement supérieur à 70%.
Les nouvelles fonctionnalités permettent maintenant d’exploiter les avantages des mobiles :

• le multi-touch et les gestures,
• l’acceléromètre,
• la gestion de l’orientation de l’écran,
• les champs textes pour mobile …

La performance a également été améliorée sur l’audio, la vidéo, la gestion des ressources en général pour économiser de la batterie (surtout pour les mobiles). Une nouvelle API vidéo a été développée pour réduire la charge sur le processeur comme certains ont pu le constater sur Mac OS. Elle utilise plutôt les ressources de la carte graphique pour fonctionner. L’utilisation de la mémoire a été optimisée. Pour tester ces nouvelles fonctionnalités, vous pouvez télécharger l’application de démonstration TourDeFlex et tester la partie Flash Player APIs. Le multi-touch est assez bluffant si vous avez un trackpad adapté .

Applications pour Mobile

Pour développer des applications pour mobile, vous pouvez utiliser Device Central CS5. Il fait partie de la Creative Suite et fournit toutes les configurations des smartphones, telles que la mémoire, le processeur … Ces dernières sont mises à jour dynamiquement. Vous trouverez une démonstration de ce que l’on peut réaliser en terme d’application mobile sur le blog de Michael Chaize où il présente un Doodle Jump développé avec Air et qu’il a pu déployer sur son Android en version 2.2 (Froyo).

AIR 2

Air est une application desktop, ce qui signifie qu’il exploite les ressources de l’ordinateur. Maintenant le déploiement est possible sur Android, et pour plus d’informations je vous renvoie vers cet article. Autre nouvelles fonctionnalités avec AIR :

• ouverture des fichiers avec l’application par défaut définie par l’OS,
• détection de l’OS avec l’objet Capabilities.os,
• exécution possible de commandes grâce à NativeProcess.

Quoi de neuf sur Flex Hero ?

Flex Hero est le petit nom de la release majeure 4.1 de Flex. Dans cette nouvelle version, de nouveaux composants spark sont disponibles :

• une datagrid spark avec :
  • gestion des déplacements avec les touches,
  • une skin class (apparence) plus simple à personnaliser que celui de Halo
  • et un chargement des données dynamique au moment du scroll. Ce qui rend le chargement plus rapide grâce à la pagination.
• un formulaire spark,
• des formatters spark avec gestion de l’internationalisation,
• un MobileApplication pour gérer les applications mobiles,
• une API pour la navigation dans les vues,
• ActionBar,
• MobileItemRenderer pour les rendus de liste spécifique aux applications mobiles,
• gestion de la géolocalisation,
• gestion de l’orientation,
• génération de l’application sous forme de package Android (APK).

Flash Catalyst

La sortie en release preview de Flash Builder « Burrito » s’accompagne aussi de celle de Flash Catalyst « Panini ». Celui-ci a été revu pour faciliter la collaboration entre le développeur et le designer. Précédemment, le problème était que le designer ne pouvait pas retravailler sur ce qu’avait réalisé le développeur. Avec cette nouvelle version de Flash Catalyst, c’est maintenant possible.

LiveCycle Collaboration Service

Le LiveCycle Collaboration est une solution hébergée par Adobe pour proposer aux développeurs de réaliser des applications Flex collaboratives. Ils ont à leur disposition des composants : tableau blanc pour les dessins, gestion de la webcam … pour réaliser des applications où il est possible aux utilisateurs d’échanger des informations. Michaël nous a d’ailleurs invité à accéder à une des applications qu’il a réalisé. C’était très intéressant de voir sur le grand écran de la salle une dizaine de webcams afficher le visage de quelques participants curieux.

Crédit photo : les images proviennent du site d’Adobe et de l’album Picasa de Stephan Jaansen pour Devoxx 2010

Actualité éditeurs / SSII

• Terracotta publie BigMemory en version stable
• L’intégration continue dans les nuages

Le coin de la technique

• JDK7 & JDK8 arrivent !

Evènements de notre communauté en France et à l’étranger

• Devoxx 2010

Actualité éditeurs / SSII

Terracotta publie BigMemory en version stable

BigMemory le nouveau module livré avec la suite Enterprise Ehcache dont nous avions parlé dans une revue de presse précédente, passe en version stable. Pour mémoire, ce module permet de stocker une grande quantité de données dans la mémoire du processus Java sans impacter la heap. Le pari de BigMemory, est de diminuer la taille de la heap pour éviter la surconsommation du GarbageCollector tout en supportant un cache en mémoire vive à grande capacité. Ari Zilka le CTO de Terracotta interviewé sur InfoQ évoque des capacités montant jusqu’à 350Go. Pour stocker ses données en-dehors de la heap, BigMemory utilise les DirectByteBuffer supportés depuis la version 1.4 de la JVM. Les tests de performances réalisés par Terracotta sont assez impressionnants sur les temps d’exécution du FullGC en comparaison avec le stockage habituel dans la heap. Outre certaines craintes soulignées dans notre précédente revue, un des défauts de cette solution est de reposer sur la sérialisation des objets Java qui est connu pour ajouter un surcoût non négligeable lors de l’écriture et la lecture des objets dans le cache. L’utilisation de BigMemory se configure très simplement en ajoutant deux nouveaux attributs à la configuration du cache (overFlowToHeap et maxMemoryOffHeap):

<cache name="sample-offheap-cache"
    maxElementsInMemory="10000"
    eternal="true"
    memoryStoreEvictionPolicy="LRU"
    overflowToOffHeap="true"
    maxMemoryOffHeap="1G"/>

La simplicité d’utilisation d’Ehcache ne souffrira donc pas de cette nouveauté. Avec BigMemory Terracotta semble s’armer pour concurrencer des produits comme Memcached, voir même, des produits de type noSQL avec Ehcache Search l’API de recherche pour Ehcache.

L’intégration continue dans les nuages

D’un côté nous avons Hudson, la plateforme d’intégration continue qu’on ne présente plus, développé par Kohsuke Kawaguchi, qui a quitté Oracle début avril pour fonder sa propre société, InfraDNA. Comme il l’explique sur son blog, le nom de sa société reflète sa vision de l’intégration continue en tant que partie prenante de l’infrastructure d’un projet. Il cite d’ailleurs le cas intéressant de Liferay qui s’est installé une ferme de 100 serveurs dédiés uniquement à Hudson pour apporter une vraie réactivité sur la qualité de leurs produits.

De l’autre côté, nous avons CloudBees, une société créée par Sacha Labourey, ancien CTO chez JBoss, qui propose depuis Août un service de Platform as a Service, pour les applications Java. Comme il l’est expliqué sur la « vision » de la société, CloudBees a pour objectif avant tout de proposer un environnement pour gérer les cycles de vie d’un projet pour des outils comme Maven, Git, Svn ou … Hudson ! Dans cette perspective il s’agit de promouvoir ces outils comme des Software as a Service, comme nous l’explique Sacha Labourey ici:

And while CloudBees’ platform will initially appeal to end-user companies, our platform is built with ISVs in mind : we envision that most ISVs will have to morph into a SaaS model if they want to outlive their SaaS competitors.

(ISV signifie éditeur logiciel)

Il était donc assez naturel que les deux groupes se rejoignent. L’offre est encore en béta mais nous pouvons déjà avoir une idée du prix de l’abonnement. Celui-ci se découpe en deux parties (ces prix seront peut-être réajustés avec la fin de la version béta):

• un abonnement mensuel de 25$ ou 35$ par mois selon le nombre d’utilisateur et de dépôts SVN ou GIT
• un paiement à la carte de 1 cent par minute utilisée par Hudson pour la construction du projet

L’avantage de ce mode de paiement est que cela pousse à une rationnalisation de la construction de ses projets qui ne peut qu’être bénéfique. A surveiller également si à plus long terme il est prévu une offre sur étagère qui pourrait convaincre les entreprises toujours réticentes à externaliser leurs données pour des raisons compréhensibles de sécurité.

Le coin de la technique

JDK7 & JDK8 arrivent !

Non, nous ne reviendrons pas sur les récentes news autour de OpenJDK et de Oracle/Google/Apache/IBM/Apple etc… car cette fois c’est bon, on sent réellement que Java 7 est sur les rails! En effet, Oracle a profité de Devoxx pour annoncer officiellement les JSRs « umbrella » pour Java 7 et Java 8. Ce sont donc des JSRs qui en regroupent d’autres, déjà existantes et sur lesquelles InfoQ nous fait un petit topo.

Java 7 est défini par la JSR 336, regroupant elle-même:

• la JSR 203, connue sous le nom de NIO 2 et améliorant la gestion des filesystems et des sockets. On se réfèrera à la description complète sur le blog de Masoud Kalali en 6 parties: 1, 2, 3, 4, 5 et 6.
• la JSR 292, apportant l’instruction bytecode invokedynamic, très attendue par des langages comme Groovy ou JRuby afin de gagner en performances.
• la JSR 334, connue en tant que « Project Coin », apporte du sucre syntaxique. Des petits détails pas fondamentaux mais contre lesquels nous pestons souvent en nous demandant « mais pourquoi on ne peut pas faire ca en Java ?! ». Avec le JDK 7, on pourra !

Mais d’autres bonus pourraient aussi être inclus nous indique Alex Miller: citons en vrac Unicode 6, des modifications des Locale, JDBC 4.1, des améliorations de Swing…

Pour le JDK 8, spécifié par la JSR 337, les choses commencent aussi à prendre forme avec la vraisemblable inclusion des JSR 308 (annotations sur les types), JSR 310 (like API inspirée de Joda-Time) et JSR 335 (le projet Lambda apportant les fameuses closures). Le projet Jigsaw, qui apporte lui la modularité d’une manière plus developer friendly que OSGI, devrait aussi être de la partie.

Cerise sur le gâteau, ces 2 JDKs sont même datés: juillet 2011 pour le JDK 7 et fin 2012 pour le JDK 8.
Pendant ce temps, un sondage complètement informel a permis de prendre le pouls des Devoxxiens et de leur attentes envers les futurs JDKs. Il semble que beaucoup d’entre nous, dans la communauté, seraient prêts à payer le prix d’une incompatibilité ascendante de Java pour permettre au langage de s’améliorer en réparant certaines de ses erreurs. Devrons nous en passer par là ? En tout cas ce n’est pas pour tout de suite et nous devrons nous contenter t’attendre le Next Big Java Language !

Evènements de notre communauté en France et à l’étranger

Devoxx 2010

La semaine dernière, se tenait à Anvers, le plus grand rassemblement (un peu plus de 3000 personnes) de la communauté java en Europe : Devoxx 2010.
Si vous souhaitez avoir un aperçu de ce qui s’y est passé, voici quelques retours des consultants Xebia présents à Devoxx 2010 (d’autres billets devraient arriver sous peu) :

• Augmenter votre productivité avec Mylyn par Romain Maton.
• Productive Programmer par Ellène Dijoux et Romain Maton.
• Les nouveautés d’Hibernate, une perspective JPA 2 par Romain Maton.
• La keynote de bienvenue par Ellène Dijoux.
• Java Puzzlers par Joshua Bloch et William Pugh par Romain Maton.
• Comparaison des Frameworks Web sur JVM par Romain Maton et Jean-Laurent De Morlhon.
• Getting Things Done for Programmer par Ellène Dijoux.
• Déployer vos applications Air sur Android par Ellène Dijoux.

A noter également, l’épisode 31 des Cast codeurs « Spécial Devoxx 2010″ enregistré sur place par Emmanuel Bernard et Antonio Goncalves avec deux invités : Nicolas Martignole et Michaël Figuière.

Adobe Air pour iOS

Pour le développement d’applications iPhone, Apple avait émis une restriction pour interdire l’utilisation d’outil de développement en dehors de ceux autorisés par Apple. Suite à la levée de cette restriction, Adobe peut donc enfin réaliser des applications pour iPhone à partir de ses outils. Parmi les fonctionnalités d’Adobe Air, vous trouverez un packager pour iOS qui permet de transformer une application Air en IPK (format des package pour l’iPhone). Ce packager est aussi disponible dans la Creative Suite 5. Le packager permet de générer une application native pouvant être exécutée pour iOS. Attention, certaines APIs n’ont pas été implémentées dans le packager.

Les nouveautés dans Air 2.5

La grande nouveauté de Air 2.5 est la possibilité de développer des applications mobiles. Pour ce faire, deux nouvelles classes héritant d’Application sont disponibles : MobileApplication et TabbedMobileApplication. Un nouveau skin a été créé pour les applications mobiles et certains composants en bénéficient comme Button, CheckBox, DataGroup, Label, List, Scroller … Parmi les nouveaux composants dédiés, vous trouverez le MobileItemRenderer et le MobileIconItemRenderer pour les rendus de listes .

Flash Builder « Burrito »

Burrito est le petit nom du dernier Flash Builder. Il prend en charge toutes les nouveautés disponibles dans Flex 4. La fonctionnalité mise en avant est la possibilité de développer des applications mobiles à partir de votre Flash Builder !

Flash Builder « Burrito » est disponible en version d’évaluation (pour une durée de 60 jours) ; vous pouvez le récupérer ici. Pour ma part, très curieuse de voir ces nouvelles fonctionnalités je l’ai téléchargé et effectivement, on peut créer des applications flex mobiles.

Une fois votre projet créé, vous pouvez visualiser dans la partie Design de nouvelles options associées à votre vue.

Vous pourrez sélectionner une configuration de téléphone, vous aurez le choix entre plusieurs téléphones android.

Vous pourrez également modifier l’orientation du téléphone pour vérifier le bon positionnement de vos composants.

   

Une fois votre application réalisée, vous pouvez l’exécuter. Celle-ci sera affichée dans une fenêtre au format du téléphone que vous avez sélectionné. Elle propose aussi un menu contenant les actions disponibles pour le téléphone que vous avez sélectionné (changement de l’orientation, menu, retour arrière …).
Il est également possible d’exécuter votre application directement sur votre Android si bien évidemment vous en avez un . Une simple connexion USB suffit pour cela. Malheureusement, je n’ai pas pu tester cette partie mais espérons que le père Noël m’apporte un Android 2.2 le mois prochain.

Ce n’est pas tout. Vous avez développé votre application et l’avez testée. Vous voulez maintenant la partager ? Il suffit simplement de préparer le package pour le déposer sur Android Market. Et avec Flash Builder « Burrito » rien de plus simple, exportez votre projet et sélectionnez Release Build. La seule plateforme disponible pour le moment est Google Android. Après avoir donné votre certificat et mot de passe, Flash Builder vous génère un APK contenant une application native Android que vous pouvez déposer sur Android Market.

Le déploiement semble simple et pourrait motiver de nouveaux développeurs à réaliser des applications pour mobile.

Et c’est Kito D. Mann, auteur de JSF In Action qui nous présente cette méthodologie qu’il a pu appliquer à son quotidien.

Des tâches, encore des tâches, toujours des tâches

Il commence par demander qui se sent débordé dans sa vie quotidienne, et une bonne partie de la salle lève la main. Nous avons notre vie personnelle, le travail, nous participons aussi à la vie de diverses communautés, associations … Et il n’est pas toujours facile de tout gérer au quotidien. Plus vous avez de tâches à réaliser et moins vous savez quoi faire de vos journées. C’est ainsi que l’on tombe dans de nombreuses boucles infinies et cela consume beaucoup d’énergie. Il faut tenter de fermer ces boucles.

Collecter les informations

La première étape pour s’organiser est de collecter les informations et les mettre dans une boîte. Cette boîte peut être une feuille de papier, une boite mail ou autre chose. Puis, une par une, on traite les données contenues dans cette boite. Une fois les informations collectées, il faut décider de ce que l’on va en faire. Que dois-je faire de cette information ?

• Je la jette ?
• Je la range ?
• Je la traite ?
• Je la délègue ?
• Je la mets de côté ?

Le processus de collecte

L’idée est donc de collecter les informations de toutes vos sources et de les centraliser à un unique endroit. Cela peut être un logiciel comme Evernote, des post-it, un agenda ou encore un outil de mind mapping par exemple. Vous pouvez aussi utiliser Gmail ou encore une boite recevant les papiers, ou votre smartphone via vos emails.
Ensuite vous pouvez les traiter en les classant en différentes catégories :

• A faire
• A reporter
• A déléguer
• A supprimer

Le but final est d’avoir une boîte d’entrée toujours vide.

Le contexte

Une tâche est une action unitaire qui peut prendre de quelques minutes à plusieurs heures. Pour certaines tâches vous devez vous situer dans un certain contexte. Effectivement, nettoyer le jardin n’est pas une tâche que vous pouvez réaliser au bureau…
Identifiez les projets : un projet est une action qui se réalise en plus d’une étape, comme écrire un livre, refaire sa cuisine ou travailler sur un projet open source par exemple. Organisez vous donc et classez par dossier en fonction des tâches que vous avez à réaliser. Vous pouvez aussi utiliser un gestionnaire de tâches et identifier les actions par projet.

La revue

Il est très important de ne pas oublier les tâches et les projets que l’on a en cours. Et pour ce faire, il est conseillé, une fois par semaine, de faire le point sur l’avancement des tâches.

Comment sélectionner des tâches ?

Vous devez sélectionner vos tâches en fonction :

• du contexte,
• du temps disponible,
• de votre niveau d’énergie,
• et de vos priorités.

Restez concentrés !

Kito fait à nouveau un petit sondage : Qui d’entre nous regarde systématiquement ses mails tout au long de la journée. Beaucoup dans la salle lèvent la main.;. Nous avons tous la manie de vérifier trop souvent nos mails, ce qui est très mauvais pour la concentration. La solution : se fixer des moments clés dans la journée pour les vérifier.
Essayez aussi de ne travailler que sur une tâche à la fois, d’éviter les distractions et de fixer un temps de concentration en employant le Pomodoro.

Les outils et logiciels pour vous aider

Pour gérer vos tâches, vous pouvez utiliser des outils comme une simple feuille de papier ou un fichier texte. Parmi les logiciels, vous aurez le choix dans un large panel avec entre autres Nozbe (sur le web, pour iPhone et iPad), ActiveInBox (un plugin gmail), RememberTheMilk, Things, ToDo, ToodleDo …

Pour stocker les informations, vous pouvez utiliser un cahier, ou un logiciel comme EverNote, OneNote ou encore un logiciel de Mind Mapping comme Mind Manager ou mind42.com.

Application de GTD au quotidien des développeurs

Kito fait maintenant le parallèle entre GTD appliqué au quotidien et comment cela pourrait être appliqué au quotidien des développeurs.
Le meilleur moyen pour un développeur de gérer son quotidien est l’utilisation d’un issue tracker. Il peut être assimilé à une liste de tâches. En entrée, vous avez un nouveau problème qui vous est affecté. Lorsqu’une anomalie peut être coupé en plusieurs tâches, il s’agit d’un nouveau projet.
Les TODOs dans le code peuvent aussi être vu comme des tâches à réaliser.
Le contexte peut être défini dans une boîte commune pour toutes les équipes. Elles pourront ainsi partager les tâches et les projets et fournir une visibilité de leur progression. C’est aussi un bon moyen pour déléguer les tâches.

Pour résumer, ce qu’il faut retenir de cette conférence, c’est de fermer les boucles, collecter les informations à un seul endroit et décider de ce que l’on en fait (le faire, le déléguer, le supprimer ou le reporter). Le méthode vous intéresse ? Pour plus d’informations, vous pouvez lire l’article de Nathaniel Richand ou tout simplement acheter le livre .

Comment choisir ces fameux Frameworks Web qui sont, et c’est le moins que l’on puisse dire, assez nombreux. Et bien tout d’abord, il va falloir restreindre cette liste à quelques Frameworks et, pour chacun d’entre eux, prototyper une application. A partir de ces prototypes, il sera alors possible de créer une matrice comprenant différents critères qui seront notés pour chaque Frameworks. De là, on pourra faire ressortir les meilleurs prétendants, un petit document et faire nos recommandations. C’est ce qu’a fait Matt Raible durant cette présentation et voici ses résultats !

Matt fait un petit rappel sur les facteurs clés qui nous permettaient de choisir un Framework Web en 2007 (de son expérience) :

• composant, requête ou RIA,
• facilité de développement,
• communauté autour du Framework,
• roadmap et futur du Framework,
• maintenance,
• fonctionnalités.

Aujourd’hui, nous en demandons beaucoup plus à nos Frameworks Web et, pour Matt, nous passons de 6 à 20 ! Avec un peu d’exagération sur cette fulgurante croissance car certains points faisaient déjà parti de nos préoccupations en 2007 ; de là à dire que ce sont de nouveaux points… En tout cas, les voici au complet :

• productivité du développeur,
• perception du développeur,
• courbe d’apprentissage,
• santé du Framework,
• disponibilité des développeurs (sur le marché),
• offres d’emploi,
• templating,
• composants,
• ajax,
• plugins ou add-ons,
• scalabilité,
• support pour les tests,
• i18n et l10n,
• validation,
• support du multi-langage (groovy, scala…),
• qualité de la documentation / tutoriaux,
• publications,
• support de REST,
• support mobile,
• et degré de risque.

Bien sûr, nous pouvons remettre en cause certains points de cette liste et passer plusieurs journées à en débattre mais le débat n’est pas là. Matt assume que les choix qui sont fait sont les siens et il nous invite à participer pour ajouter des éléments à la liste ou lui indiquer pourquoi il se trompe sur telle ou telle appréciation. L’idée est ici de donner une base solide afin de pouvoir comparer sur plusieurs points importants de nos projets d’entreprise ces fameux innombrables Frameworks Web.

Roulement de tambour… voici la matrice ! (google spreadsheet)

Les gagnants de ce « concours » sont :

• Spring MVC,
• GWT,
• Ruby on Rails (non JVM mais non exclu car très présent sur le marché),
• Grails,
• Wicket.

Vient ensuite une partie avantages / inconvénients pour chacun d’eux. Cette partie est à prendre avec des pincettes car les inconvénients relevés sont souvent surmontables (certains sont même juste des comportements par défaut modifiable par configuration !) mais encore une fois cela donne un overview de ce que font ou ne font pas ces Frameworks :

• Spring MVC : configuration simple par conventions et annotations, intégration de plusieurs formats d’affichage (JSP, JSTL, FreeMarker, JSON, PDF…) et excellent support de REST mais pas de rechargement à chaud par défaut (toutefois possible avec JRebel ou Spring Roo), projet non ouvert à la communauté pour contribution (SpringSource mandatory) et pas de librairie ajax en bundle (ce qui peut aussi être vu comme un point positif car mise à jour des librairies Javascript non bloquée par le Framework) ;
• GWT : code Java traduit en un Javascript extrêmement optimisé, apprentissage facile et rapide (petit bémol car sur ce point les développeurs Web n’ont pas forcément cette compétence du code Swing-like) et une communauté vibrante mais il faut connaître Java (alors que l’on produit du Javascript), compilation très lente et code difficile à tester ;
• Ruby on Rails : apprentissage rapide pour tout développeur Web, documentation abondante et communauté de passionnés mais moins performant que les autres langages, langage dynamique = plus de tests pour éviter les cast exceptions au runtime et un manque d’outils de développement et de débugger comme dans le monde Java ;
• Grails : transition facile depuis le monde Java, utlise Groovy et nombreux plugins mais Groovy vise directement les développeurs Java (ce qui peut bloquer d’autres développeurs), stack traces affreuses (dans le slide ) et connaissances des sous-modules non nécessaires mais peut aider ;
• Wicket : parfait pour les développeurs Java, binding des pages et des vues et communauté active mais pas ou peu d’offres d’emploi, stateful par défaut et templates HTML juste à côté des classes Java (ce qui ne va pas aider le graphiste).

Pour finir, nous avons droit à quelques jolis graphiques qui nous montre à quelle point Ruby On Rails est très présent au niveau de la communauté mais ainsi en terme d’offres d’emploi.

Matt a insisté sur deux points importants tout d’abord sur le fait que ce sont les développeurs qui devraient choisir leur framework web, plus les développeurs sont heureux, plus ils seront productifs. D’autre part, javascript n’est pas si difficile comme on l’entend souvent de la part des développeurs java, plus on le pratique, plus on l’apprécie, et c’est vital si l’on veut être sérieux pour le développement d’application web.

Cette méthode peut être appliqué dans votre entreprise pour choisir votre framework web :

1. priorisez les fonctionnalités importantes de votre application
2. sélectionnez ensuite 3 ou 4 Frameworks pour prototyper une application (1 semaine chacun), documentez
3. calculez votre matrice et choisissez !

C’est parti pour le show : les puzzlers en photo, et les remarques et solutions en commentaire !

Puzzler n°1

BigDecimal permet un calcul de précision que l’on ne peut avoir avec des doubles donc vous pensez tout de suite à a) ou b). En même temps, ça sent le piège car nos doubles sont toujours utilisés directement donc plutôt la c). Et bien vous avez tout faux, réponse d) !

En effet, le code passe par le constructeur public BigDecimal(double val) qui va donc représenter la valeur décimale exacte (jusque là tout va bien) d’un double à virgule flottante… donc incorrect. Et comme nous sommes en présence d’un double, nous avons la réponse d), la réponse c) étant la représentation pour un float. La solution est de passer par un String et d’utiliser ainsi le constructeur public BigDecimal(String val).

Puzzler n°2

La bonne réponse est la réponse a). La solution de ce Puzzler mériterait un article complet car beaucoup de paramètres entrent en jeux. Et ça tombe bien puisque cet article existe ! Je vous laisse donc apprécier le détail chez Alex Miller pour ce Puzzler qui s’amuse avec la méthode entrySet() d’EnumMap (même comportement pour IdentityHashMap, ConcurrentHashMap a été corrigé) et le constructeur addAll() du HashSet.

Puzzler n°3

Les solutions possibles pour ce Puzzler sont : a) 99 b) 100 c) Throws an exception d) None of above.

Et la réponse est d) avec un calcul qui va tourner très longtemps

Nous sommes face à un catastrophic backtracking qui génère un calcul exponentiel pour trouver le résultat !

La solution ? Retirer le ?. Cette nouvelle RegExp (aa|aab) fonctionne exactement comme (aa|aab?) mais sans exposer ce catastrophic backtracking. Ce Puzzler n’est donc pas un bug Java mais une manière de mal écrire une RegExp.

Willian Pugh nous confirme donc que nous aurons le même problème en Ruby, Python, Perl… Joshua Bloch se demande alors Even in Scala ? Réponse de son partenaire : Yes, even in Scala ! Ce qui a bien fait rire la salle

Puzzler n°4

Les solutions possibles pour ce Puzzler sont : a) ["null", null] b) [null] c) [null, null] d) None of above.

La solution est la réponse d) avec une superbe ClassCastException qui sort de nulle part ! Et bien, pas vraiment de nulle part quand on regarde de plus près. L’exception est levée dans la classe StringSink, mais il est difficile de voir quelle partie du code a pu générer une exception. En fait, ce sera même très difficile à diagnostiquer car le code qui provoque l’exception n’est pas visible ! Par contre, une fois la classe décompilée, on voit apparaître ce code non visible sous la forme d’une bridge method :

Utiliser un Generic T dans une méthode qui prend un Varargs (donc un tableau de T) a causé la création de cette méthode void add(Object a) qui retourne notre objet casté en String. En effet, le compilateur ne connaissant pas le type T (erasure mon amie…) et devant aussi gérer ce tableau, il est obligé de créer une méthode avec Object. A noter que le compilateur nous a prévenu dans les logs de compilation. Donc comme le rappelle Joshua Bloch : « Don’t ignore warnings ! ».

Puzzler n°5

Ce Puzzler est définitivement mon préféré :

Et une fois de plus, on se retrouve face à une exception, toujours de type ClassCastException. Encore un problème de Generics ? Oui… Car la classe Glommer() a été instanciée sans préciser le type T. Donc la classe passe en Raw type. Et ce qui se passe dans le cas présent, c’est que toutes les informations de Generics… sont supprimées de la classe !
Ainsi, les méthodes glom qui prenaient une Collection<?> et une List<Integer> se retrouvent désormais à recevoir une Collection et une List non typée. Comme la liste de String est instanciée avec Arrays.asList("a","b","c") qui retourne une List, la priorité va à la méthode qui prend en paramètre une List. Et devinez quoi : c’est la méthode qui initialement devait s’occuper des Integer ! D’où le ClassCastException dès la première valeur lors de la boucle (qui essaie de caster un String en int).
Dans ce cas, la solution est d’enlever ce type T de la classe (non utilisé dans le corps). La recommandation liée à ce Puzzler : n’utilisez pas les Raw Types et, une fois de plus, n’ignorez pas les warnings de compilation (car il y en aurait eu un) !

Puzzler n°6

Autant le deuxième est trouvable, autant pour le premier, tout le monde dans la salle est tombé dans le panneau (certains ont même crié « voleur, c’est pas un Puzzler ça ! »). La bonne réponse est la réponse b) avec 17777 et 43878.

Le premier calcul et le sujet du vol : ce n’est pas écrit 12345+54321 mais 12345+5432l.
Vous ne voyez toujours pas ? Je vous aide : 12345+5432L ! Et là évidemment cela change tout ! Nous n’avons donc plus 54321 mais 5432 (5432L en long) qui donne bien 17777.

Le deuxième calcul : 01234+43210 correspond en fait à 668+43210 ! Que s’est-il encore passé sous nos yeux… et bien le premier 0 de 01234 convertit notre 1234 en base 8 ! Ce qui nous donne 668 et donne une somme de 43878.

La morale de ce Puzzler : mettez des majuscules à vos long (5432L est un long et cela se voit) et ne préfixez jamais vos entiers avec un 0 à moins que vous ne vouliez vraiment le convertir en base 8.

Si ces Puzzlers vous ont plu, un seul livre : Java Puzzlers ! Un grand merci à Joshua Bloch et William Pugh pour cette excellente présentation !

La présentation débute, Stephan prend la parole. Cette année 3000 personnes sont attendues, venant de 40 pays différents. On peut aussi noter 300 étudiants pour l’Université, 67 JUGs (dont un paquet en France !) et 27 sponsors. Si on continue dans les chiffres, citons 10 modems VDSL 2 qui tournaient à 45% de leur capacité : on ne pouvait pas se plaindre du Wifi cette année, il était d’excellente qualité. Devoxx c’est aussi 13000 plateaux repas, 7200 croissants, 2000 yaourts, 1500 frites et 10 fûts de bière (pour la réception le soir même).
L’équipe Devoxx est composée de 25 techniciens pour le son, la vidéo, l’enregistrement et le wifi.

Stephan a également parlé de l’engouement qu’il y a eu autour de l’interface JAX-RS qu’il a défini. Cette interface permet de visualiser le programme de Devoxx (avec le détail des sessions) et de se créer son agenda de la conférence. Beaucoup d’applications ont été développées autour de cette interface : Vaadin, des applications pour iPhone, pour Android et même en Scala ! Son code est open source, et d’autres personnes l’utilisent déjà pour gérer leur conférence.

Maintenant, parlons de son bébé, Parleys.com qui héberge toujours toutes les captures vidéo des années passées. Actuellement, il contient 800h de vidéos sur Java et possède 41 canaux de JUG. Les premières vidéos de Devoxx seront disponibles la semaine prochaine. Le site fournit aussi les vidéos en haute résolution. Vous pourrez avoir accès aux vidéos pendant un an pour 79€.
Cette keynote était disponible en live streaming pour ceux qui ne pouvait pas être présent. Et quelques présentations seront accessibles gratuitement tout au long de l’année. Comme par exemple celle de Joshua Bloch qui a fait salle comble mercredi.

Un nouveau client mobile est disponible, développé avec Adobe Air 2.5, où il est possible par Drag’n'Drop de récupérer ses vidéos sur son Android. L’application Parleys est disponible sur l’Android Market.
Côté iPad, Jan-Kees van Andel a réalisé un gros travail avec JSF2. Cette application est open source et disponible sur Google Code.

Beaucoup d’émotions et une belle ambiance dans la salle, Stephan nous souhaite à tous la bienvenue, même si les universités ont commencé lundi.

La couverture est large : Hibernate Core, Search, Envers, Validator et Spatial. De nombreuses démos nous ont permis de nous familiariser avec ces nouveautés liées à JPA 2.
La session était animée, comme il se doit, par Emmanuel Bernard. Le code de la session est disponible sur GitHub et ce pour encore une petite semaine.

Hibernate Core – ORM

Après quelques nouveautés, dont le support de l’annotation @MapsId de JPA 2, le partial generator (pour générer une clé selon un algorithme spécifique) et le runtime fetch profile (qui définit plusieurs stratégies de fetch), Emmanuel commence sa première démo et nous présente la nouvelle API Criteria :

• query building API orientée objet,
• type-safe,
• fortement typé,
• avec la possibilité d’utiliser le méta-modèle statique (par annotation processor).

Et c’est sur ce dernier point qu’il insistera pendant toutes ses démos. En effet l’API est construite de telle manière que nous récupérerons des erreurs compile-time si un mauvais méta-modèle ou un mauvais attribut de méta-modèle est défini.

Concrètement, le méta-modèle est généré par annotation processor. Une fois celui-ci activé dans votre IDE, chaque compilation de fichier lancera le processus de génération des méta-modèles. Par exemple, une classe User aura un méta-modèle associé User_ qui contiendra plusieurs attributs statiques reflétant les attributs de la classe. Ainsi, si un attribut change de nom, toutes les requêtes utilisant l’ancien nom seront en compilation error. Voici un exemple à partir d’une capture d’un bout de code lors de cette démo :

On remarque ainsi dans les contraintes l’utilisation de User_.credits, credits étant un attribut de la classe User. On voit dès lors l’intérêt d’un tel mécanisme qui justifie ainsi son appellation type-safe et fortement typé. En effet, sur le 3ème exemple, imaginons que l’on donne un argument autre que User_.gender mais du même type que gender ; l’API nous donnera tout de même une erreur de compilation car ce qui est attendu est un Path<Gender> qui ne peut être obtenu qu’en ayant pris en paramètre un gender. Une fonctionnalité plutôt intéressante donc mais qu’il convient mieux de voir de ses propres yeux dans un IDE pour bien comprendre la puissance de la chose.

Cette nouvelle API criteria prend en compte toutes sortes de Joins et Where, les Subquery et les Map et Like. Cette API supporte ainsi tout le JP-QL : collections, maps, aggregation, order by, group by, having count, subselect, …

Le lock mode, qui prévient entre autres des dirty reads,  supporte l’optimistic et le pessimistic read/write. Le cache de second niveau a été amélioré et Hibernate supporte aussi Infinispan. Enfin, CGLIB se retrouve déprécié et se voit remplacé par Javassist.

Côté packaging, Hibernate passe de plusieurs modules à un seul core module qui contient Hibernate Annotations, Entitymanager, Envers et l’ancien Core. De même, tous les modules auront le même numéro de version simplifiant ainsi la gestion des dépendances entre modules (si un module est en 3.6.0, les autres devront l’être aussi).

Hibernate Search

Le point important est une fois de plus l’API programmatique permettant de faire ses requêtes full text directement telles que :

Dans les petits plus : un error handling pour reporter dans un log ou dans une pile, des statistiques avancées, une indexation des valeurs null, des query timeout et bien d’autres.

Hibernate Spatial

Hibernate Spatial est une extension d’Hibernate permettant de gérer des données géographiques. Il s’appuie sur le package Java Topology Suite ou JTS pour représenter les données géographiques dans le monde Java.

Voici ce que rajoute le projet à Hibernate :

• GeometryUserType.
• SpatialRestrictions API.
• HQL Spatial functions.
• SpatialDialectProvider.

Les bases de données supportées sont les suivantes :

• Oracle Spatial.
• Postgresql/Postgis.
• MySQL.
• Microsoft SQL Server 2008.
• H2 (GeoDB).
• IBM Informatix IDS (en cours).
• IBM DB2 (à planifier).

Les spatial queries s’écrivent comme des requêtes criteria normales mais dans le monde spatial. Un exemple tiré du slide :

A noter que pour l’instant le projet est un module à part d’Hibernate 3 mais qu’il sera packagé dans Hibernate Core en version 4.

Hibernate Envers

Comme pour les autres modules, l’API programmatique est tout de suite mise en avant avec des requêtes Criteria par révision sur les objets :

Hibernate Validator

Là encore, l’API a aussi été remaniée et l’on peut ainsi appeler directement des méthodes du type .constraint(SizeDef.class).min(1) dans notre requête Criteria (équivalent de l’annotation @Min).

Conclusion

Un bon tour d’horizon des produits Hibernate mais surtout beaucoup de démos les mains dedans où l’on voit le tout fonctionner en @Inject et Weld sous IntelliJ IDEA. Une bonne session !

Accélération

Taper au clavier est bien plus rapide que la navigation avec la souris. On perd beaucoup de temps à chercher alors que les raccourcis clavier sont bien plus rapides. Chaque OS fournit ses raccourcis claviers pour ouvrir l’explorateur Windows ou le Finder. Pour naviguer sur internet, utilisez NumberFox, il numérote les liens sur les pages et permet en saisissant un numéro d’accéder à la page associée. Pour la gestion du presse papier, utilisez par exemple jumpcut sur MacOS X qui permet de visualiser ce que vous avez coupé ou copié avec un historique des données. Le changement de contexte prend du temps également, surtout en ligne de commande. Avec les commandes pushd/popd, vous pourrez mémoriser un répertoire avec pushd pour le réutiliser ensuite à tout moment avec popd.
Lignes de commande ou explorateur ? Les explorateurs sont intéressants dans certains cas, les lignes de commandes dans d’autres. Pour switcher facilement de l’un à l’autre, vous pouvez utiliser cmd prompt explorer bar pour Windows et Path Finder pour Mac OS X. Ils proposent dans une même fenêtre la console et l’explorateur.
Quand vous codez, vous devriez toujours utiliser le clavier plutôt que la souris. Forcez vous à apprendre les raccourcis clavier. Un outil existe sur IntelliJ pour forcer les développeurs à utiliser un raccourci clavier, au bout de la troisième utilisation la fonctionnalité se grise dans le menu. Les conseils : se les répéter et se créer un aide mémoire. Accédez directement à la classe que vous cherchez par les raccourcis clavier et en utilisant les majuscules. Prenez l’habitude de créer les variables avec votre EDI. Bien que destiné au refactoring, vous pouvez aussi l’utiliser en ne déclarant que la partie gauche de la déclaration et générer le reste.

Focus

Pour commencer, il y a des choses simples à mettre en place : une chaise confortable, un double écran, les droits admin sur son poste et un bon clavier. Ensuite la concentration doit être total. Pour être productif, il faut supprimer toutes distractions tels que les pop-ups Windows de mis à jour ou autres notifications. Il existe par exemple Jedi Concentrate qui permet de mettre en noir toutes les fenêtres pour se concentrer sur une en particulier le plus longtemps possible. Désactivez toutes les notifications d’emails et de messageries instantanées, mettez des écouteurs et créez des « moments de silence » dans votre bureau.
L’idée n’est pas de s’isoler des autres mais de créer des conditions idéales à la concentration.

Focus technique

Utilisez un outil de recherche tel que Google Desktop Search pour rechercher sur votre poste au lieu de naviguer dans votre explorateur. Utilisez un virtual desktop pour séparer votre espace de travail du reste. Cela permet d’éviter l’empilement de fenêtres sur un unique bureau.

Canonicité

Faire les choses simples en évitant les répétitions. Neal Ford a un sigle de référence : DRY (Don’t Repeat Yourself).

• DRY o/r mapping : il s’agit d’une tâche assez répétitive dans le développement d’application. Optimisez la partie mapping avec la base de données en construisant celui-ci à partir des méta-données en base. Puis générez les POJOs correspondant.
• DRY documentation : Neal Ford a utilisé SVN2Wiki un petit utilitaire de SVN qui relève tous les commentaires de commits des développeurs pour les aggréger dans un wiki.

Automatisation

Les aspects visiblement automatisables sont le build en une commande, l’intégration continue, le contrôle de version et la documentation. Il recommande Selenium pour les tests automatisés. Ce dernier permet au développeurs de tester plus rapidement les applications suite à une modification.
Sa philosophie est : « Ne perdez plus de temps à faire à la main ce que vous pouvez faire automatiquement ».
Pour déterminer si une tâche est automatisable ou pas, il faut mesurer le temps qu’elle prend et analyser le retour sur investissement. Il faut éviter également d’en faire trop.

Pratique

Neal Ford nous propose ensuite 10 bonnes pratiques pour améliorer notre productivité et notre qualité de code.

1. Pattern Composed Methods

Celui-ci est directement tiré du livre Smalltalk Best Practice Patterns de Kent Beck. L’idée est de diviser son programme en plusieurs méthodes, chacune ayant un et un seul rôle bien défini. De même, chaque opération dans la méthode devra avoir le même niveau d’abstraction. Le résultat : des méthodes avec un rôle précis écrites en très peu de lignes de code. Cela a pour avantage de favoriser et simplifier les tests unitaires. Cela permettra aussi de vraiment mettre en avant la vraie réutilisabilité du code.

2. TDD

Couplé avec le pattern Composed Methods, TDD nous oblige à réfléchir à notre design objet, à définir de quels objets dépend mon objet et ainsi à mocker ces objets dépendants. Un premier constat est que l’on obtient très souvent de meilleurs métriques de manière globale.

3. Analyse de code

Les outils d’analyse de code, ce n’est pas quelque chose de nouveau. Mais un petit rappel ne fait jamais de mal Passer par ce type d’outils va nous permettre de détecter des bugs de type mauvaise pratique, code mort ou bien encore du code violemment copier-coller. 2 types d’analyse :

• byte code : à l’aide de FindBugs qui nous range nos bugs par catégorie comme la mauvaise pratique, le problème de performance ou du code douteux ;
• source code : par PMD qui lui nous détectera le code mort ou bien encore le fameux algorithme CPD pour Copy/Paste Detector.

4. Bonne citoyenneté

Avec une formule : getters + setters != encapsulation ! Le speaker insiste alors : ne générez pas automatiquement sans réfléchir ces fameux getters et setters. Et si vous en avez réellement besoin, il faudra peut-être les tester.
Et un exemple d’API worst citizenship in the java world selon lui : java.util.Calendar ! Et un exemple très saisissant : que donne une instance de Calendar avec 31 février ? Et bien une instance de Calendar au 1er mars ! Alors que l’on ne serait pas surprit de se prendre une petite exception à la figure… Avec un constructeur sans paramètre, un autre avec tout, encore un autre avec seulement la moitié des paramètres demandés… En bref : prenez JodaTime

5. YAGNI

L’idée est simple : si vous n’en avez pas besoin tout de suite, pourquoi le faire ? Et oui, You Ain’t Gonna Need It !

6. Remettre en cause l’autorité

J’ai beaucoup aimé l’exemple cité : le nom des méthodes en Java. La norme est en effet d’utiliser le CamelCase pour le nom de nos méthodes. Mais prenons par exemple les test unitaires et par exemple ce test :
testUserCannotAccessThisPageWithHisActualGrantedAuthorities
Pourquoi, pour une question de lisibilité, ne pas le nommer :
test_user_cannot_access_this_page_with_his_actual_granted_authorities
Le nom de la méthode devient alors plus lisible et on obtient plus facilement l’information de ce que fait le test.
Autre cas : le chainage de méthode. Là où l’on écrirait des appels successifs de méthodes setXXX avec un retour de type void, pourquoi ne pas revoir l’API et utiliser le Chaining Pattern pour avoir quelque chose du type : Car.describedAs().box().length(12).includes(Equipment.LADDER);. Neal Ford insiste sur cet exemple car celui-ci remet directement en cause la spécification Java Beans.
Il ne faut donc pas forcément s’arrêter sur des phrases telle que c’est comme ça qu’il faut faire, un point c’est tout !

7. Slap

Slap pour Single Level of Abstraction Principle, ce principe rejoint fortement le Composed Pattern puisque le concept est d’avoir plusieurs lignes de code dans une méthode ayant le même niveau d’abstraction.

8. Polyglotte

Java n’est pas le seul et, pour certaines problématiques ou certains environnements, il est peut-être préférable de partir sur d’autres langages. Exemple : JRuby pour faire de l’interface graphique ou Jaskell pour écrire du code fonctionnelle. En bref, ne pas se limiter à Java.

9. Chaque Nuance

Java traîne avec lui des idées reçues bien fausse comme par exemple que l’API reflection est lente, certes vrai en fin des années 90 mais plus aujourd’hui. Il faut donc nuancer les propos, ne garder que ce qui est vrai et ne pas hésiter à faire passer le message pour que toutes ces choses ne soit plus dites !

10. Anti-objets

Neal Ford nous explique qu’un anti-objet peut-être vu comme un objet qui fait exactement l’opposé de ce pourquoi il a été créé. L’exemple du vase ou visage nous permet ainsi de voir qu’un objet vase peut voir sa réelle existence complètement détournée.

Conclusion

Une session extrêmement riche et un livre à lire de toute urgence !

NB : Les slides de Neal Ford sont disponibles sur son site : Devoxx 2010 – Neal Ford – The Productive Programmer.

Mylyn, c’est le framework ALM (Application Lifecycle Management) d’Eclipse. Il réorganise tout l’IDE autour de tâches. Celles-ci seront ensuite traduites par Mylyn pour nos différents outils comme notre gestionnaire de sources, notre intégration continue ou bien encore notre bugtracker. Le développeur pourra ainsi ne se préoccuper que de ses tâches, Mylyn s’occupant du reste.

Oliver Gierke nous oriente vers 3 grands domaines concernant cette fameuse productivité recherchée du développeur : focus, productivity et traceability.

Focus

Tout se passe dans l’onglet Task List d’Eclipse avec une liste de tâches à effectuer. A noter qu’on ne peut activer qu’une seule tâche à la fois.

Le concept : chaque tâche aura son propre contexte de travail.

Ainsi, dès lors que l’on a activé une tâche, l’onglet Task List se vide et laisse apparaître tous les fichiers sur lesquels nous sommes en train de travailler. L’intérêt est que si l’on change en cours de route de tâche, la nouvelle tâche repartira d’un contexte vide et, en revenant sur notre première tâche, on récupérera notre contexte avec tous nos fichiers modifiés.

Productivity

L’idée ici est de gagner du temps en ayant tout de suite à sa disposition les bons outils intégrés dans son environnement de travail. En effet, avoir plus d’une dizaine d’outils répartis sur son IDE, dans son navigateur, sur son desktop… cela donne des alertes un peu n’importe où Il faut donc passer d’un patchwork à un integrated toolset.

Par défaut, Mylyn gère un nombre assez important de bugtrackers et d’outils en tout genre avec dans le désordre : Bugzilla, Jira, Bamboo, Crucible, Trac, Mantis, Hudson, Egit, CVS…

Pour la récupération des informations de l’outil, prenons par exemple Jira, il est possible de définir ses propres requêtes afin de ne récupérer qu’une certaine partie des bugs. Pour la saisie d’un bug, on dispose d’un éditeur Rich Task Editor pour la saisie des informations liées au bug (OS, version…) et pour la partie commentaire on dispose de l’éditeur WikiText qui nous permet d’écrire de la syntaxe Wiki.

Toujours en terme de productivité, il est possible d’organiser ses requêtes ou ses outils en Working Sets. On pourra aussi exporter ses contextes avec de les partager avec toute l’équipe.

Traceability

Ce concept découle du point précédent. On peut ainsi pour une tâche donnée récupérer toute les informations utiles du type qui, quoi et pourquoi, tout étant regroupé en un seul point.

Démo

Vient ensuite une petite démo avec un projet directement connecté sur le bugtracker de SpringSource :

Code2Cloud

Pour terminer, Oliver nous parle de Code2Cloud, la solution complète de SpringSource pour simplifier la vie du développeur (annonce faite au SpringOne2GX 2010).

Pourquoi parler de Code2Cloud ? Bugzilla, Git, Hudson, STS mais surtout…. Mylyn ! Olivier propose l’exemple de son intégration avec Spring Insight. On pourra ainsi configurer Spring Insight pour créer automatiquement un bug dans le bugtracker pour toute exception levée par l’application. Le bug sera bien sûr rempli avec la stack trace dans le bon champ, les classes impactées, OS/versions… Tout ceci toujours prévu pour le premier trimestre 2011.

Pour conclure

A noter enfin que Mylyn sous-projet de l’IDE Eclipse est devenu top level Eclipse project depuis mi-Septembre. Il rejoint entres autres WTP et EMF dans cette short list de projets qui représentent les secteurs clés d’Eclipse.

L’outil est bon mais pour ma part un point très gênant réside toujours : Un changement de contexte ne met pas de côté les changements effectués à la manière d’un git stash que l’on pourrait récupérer plus tard avec un pop. Si vous connaissez un plugin ou une petite commande qui fait ça, n’hésitez pas à commenter !

Le rendez-vous annuel incontournable de la communauté Java européenne est arrivé ! 3000 participants inscrits et une centaine de speakers pour 5 jours de conférences à Anvers en Belgique : Devoxx s’annonce cette année comme grandiose après une édition 2009 en léger retrait en raison du contexte économique. Xebia sera présent à cet évènement pour vous retransmettre l’information qui y sera véhiculée.

Au-delà des connaissances techniques qui y circulent, des échanges et des rencontres qui s’y font, Devoxx est aussi un formidable baromètre de l’éco-système Java actuel. Il est donc intéressant d’observer les sujets les plus en vogue cette année :

• NoSQL : il s’agit clairement du sujet majeur dont il sera question cette année. Très peu représenté l’année dernière (2 sessions seulement), on compte pour cette édition pas moins d’une douzaine de sessions dédiées à ce thème. Il sera ainsi question de Cassandra, HBase, Hadoop, Hive, Pig, MongoDB ou encore Voldemort.
• Java EE 6 et JPA 2 : déjà très représenté l’année dernière, ce sujet sera encore d’actualité cette année à Devoxx, ces APIs n’ayant pas encore été digérées par les entreprises.
• JDK 7 : le sujet devient récurrent, mais la récente actualité le concernant le rend incontournable dans une conférence Java de cette envergure. Cette semaine à Anvers sera l’occasion de faire le point sur les dernières avancées et orientations avec l’équipe responsable du JDK chez Oracle.

Outres ces sujets majeurs, on retrouve de nouveaux venus tels que DevOps, ce mouvement prônant le rapprochement des équipes de développement et d’exploitation, ainsi que des sujets maintenant plus classiques qui présenteront leurs dernières évolutions tels que Grails, Android, Scala, ou HTML5.

Comme l’année dernière, vous retrouverez jour après jour sur ce blog et celui de Duchess France nos retours des principales sessions qui se tiendront à Anvers cette semaine. Retrouvez également l’information en live sur nos comptes Twitter : dijouxellene, mfiguiere, morlhon et rmat0n.

Agilité

• L’agilité à la sauce Pixar
• Evitez le multi-tâches dans les équipes de développement

Le coin de la technique

• Développez vos applications Android sans écrire une ligne de code
• Mettez à jour votre JVM

Evènements de notre communauté en France et à l’étranger

• Le programme du Devoxx 2010 se dévoile

Agilité

L’agilité à la sauce Pixar

C’est une question d’actualité avec la sortie de Toy Story 3 : mais comment Pixar fait-il pour cartonner à chaque nouveau film ? InfoQ lève une partie du voile : la cohérence construit la confiance. Derrière cette maxime ‘à l’américaine’ se cache un processus créatif original : Pixar construit des équipes pluri-disciplinaires, qui travaillent ensemble (éventuellement durant plusieurs films) et qui créent des liens de confiance inaliénables. Chaque jour, l’équipe se réunit pour discuter du travail effectué la veille : critiques, remises en cause, les équipes travaillent dans un processus d’amélioration constante. Chaque membre de l’équipe est encouragé à donner son avis, même ses membres les plus juniors.
Ce mode de fonctionnement laisse la place à l’erreur. Comme chacun est impliqué, chacun peut se tromper. Les erreurs sont mêmes une des clés du processus créatif. L’essentiel est de se tromper rapidement, pour pouvoir corriger le tir.

Changez maintenant de point de vue, et regardez cet article sous l’angle du développement logiciel. N’y retrouve t’on pas un fort goût d’agilité ?

Evitez le multi-tâches dans les équipes de développement

Toujours sur InfoQ, Roger Brown nous met en garde contre les méfaits du traitement simultané de projets (tâches, user stories …) par une personne.
Le changement de contexte lorsque l’on passe d’une tâche à l’autre peut prendre plus ou moins de temps en fonction de la complexité de la tâche, du temps et de la nature de l’interruption. Le traitement d’un appel téléphonique, par exemple, pourra engendrer un délai d’un quart d’heure pour se remettre dans le contexte de la tâche précédente. D’autres types d’interruptions (travail sur une autre tâche de développement par exemple) peuvent nous faire perdre beaucoup plus de temps.
L’auteur nous explique que le travail en parallèle sur plusieurs projets implique généralement un surcoût induit par les changements de contexte pouvant représenter de 20% à plus de 50% du temps de travail lorsque nous travaillons simultanément sur plus de deux projets. Il est donc préférable de terminer une tâche (User Story par exemple) avant d’en commencer une autre, plutôt que de fragmenter son travail.
Les méthodes agiles comme Scrum ou le Kanban préconisent un nombre limité de User Stories ou de tâches en cours, et de ne pas en commencer une autre avant d’avoir atteint le statut « Done ».
Le cerveau humain ayant tendance à vouloir traiter plusieurs tâches en parallèle, Roger Brown préconise quelques techniques telles que le pair-programming afin d’aider les développeurs à rester concentrés sur leur tâche et à gagner ainsi en efficacité.
On peut aussi citer le pomodoro qui est une discipline consistant à se ménager un laps de temps de 25 minutes sans interruption, permettant de se focaliser sur une tâche et ainsi de gagner en efficacité.
L’auteur conclut en ajoutant que non seulement le traitement séquentiel des projets (tâches, user stories …) permet de gagner du temps, mais il permet aussi de créer des synergies entre les différents membres de l’équipe qui peuvent ainsi travailler de concert sur le projet.

Le coin de la technique

Développez vos applications Android sans écrire une ligne de code

Google Labs vient d’annoncer l’arrivée d’App Inventor, un éditeur d’applications pour Android destiné aux non-développeurs. L’objectif est de permettre à tout androphile de dessiner sa propre application depuis le logiciel, puis de la transférer sur son smartphone.

To use App Inventor, you do not need to be a developer. App Inventor requires NO programming knowledge. This is because instead of writing code, you visually design the way the app looks and use blocks to specify the app’s behavior.

Pour le moment, il n’est pas possible de s’inscrire. Vous pouvez seulement montrer votre intérêt en remplissant un formulaire dans lequel vous exprimerez votre enthousiasme pour l’utilisation d’AppInventor dans un cadre universitaire. Si vous n’avez rien à voir avec quelconque formation, vous pouvez toujours laisser les réponses vides.

En épluchant le site, on constate la forte volonté d’installer cet éditeur dans le monde universitaire, voire scolaire. En effet, il est fait mention à plusieurs reprises des possibilités de développements de jeux, d’applications communautaires ou d’outils d’interaction entre étudiants. Malgré tout, Google n’oublie les autres… le particuliers lambda, ou le collègue que nous sommes en précisant:

The App Inventor team has created blocks for just about everything you can do with an Android phone, as well as blocks for doing « programming-like » stuff.

Nous nous posons tout de même quelques questions à ce sujet:

• Google préfèrerait-il que nous apprenions à utiliser son logiciel plutôt qu’écrire du code propre personnalisé?
• Ne se cache-t-il pas un envie de maîtriser le code généré? (en y ajoutant des statistiques par exemple…)
• N’y a-t-il pas un risque de voir proliférer sur le market des applications réalisées en 5 minutes, pleines de pubs et pauvres sur les plans fonctionnel et graphique? (comme HelloPurr, cf. vidéo de démo)

Le futur nous le dira…

Du côté de la technique, les outils utilisés sont OpenBlocks et Kawa Language Framework. Le premier est le fruit de la thèse de Ricarose Roque (MIT) : une librairie Java permettant de programmer des systèmes à l’aide de blocs visuels. Le second est utilisé par le compilateur pour traduire en bytecode les blocs graphiques.

En attendant d’avantage d’informations et pourquoi pas un article plus complet sur l’outil, vous trouverez déjà quelques tutoriaux sur le site.

source : site de l’éditeur

Mettez à jour votre JVM

Après une dernière release qui corrigeait un problème de sécurité, Oracle nous invite à télécharger la release 21 qui, outre la correction de bugs (mais pas de correction liée à la sécurité), apporte des améliorations sur la JVM HotSpot et VisualVM.

Sur la Java HostSpot VM, les améliorations portent sur la compression des pointeurs d’objets, escape analysis (qui améliore la gestion des piles), la gestion du cache sur le byte code, sur le garbage collector CMS (Concurrent Mark-Sweep) et G1. Pour rappel, G1 est le nouveau garbage collector en préparation pour la JDK 7 mais déjà utilisable dans la version 6 depuis la release 17. Pour l’activer il faut passer les options -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC.

La version 1.2.2 de VisualVM, sortie il y a quelques mois, est à présent incluse dans la distribution de Java SE. Elle apporte beaucoup d’améliorations sur l’analyse de la mémoire et sur le profilage.

Enfin pour les développeurs de RIA java, un listener a été ajouté pour suivre l’évolution du chargement de l’application. Plus de détails ici.

Evènements de notre communauté en France et à l’étranger

Le programme du Devoxx 2010 se dévoile

J’espère que vous avez créé une règle sur votre outil de mailing préféré qui décline toute demande de réunion sur la période du 15 au 19 novembre 2010 car c’est … Devoxx!
À moins d’être parti 8 ans en mission dans l’océan arctique sur un brise glace, vous ne pouvez pas ne pas connaître Devoxx. C’est LA conférence européenne spécialisée sur LA technologie (i.e. Java) qui se déroule tous les ans à Anvers en Belgique.

Tout le gratin des meilleurs speakers et spécialistes sera présent dont certains français: Antonio Goncalves, Guillaume Laforge, Emmanuel Bernard pour ne citer qu’eux, mais aussi des incontournables comme Heinz Kabutz, John Smart ou bien Michael Cote.
Mais ce n’est pas tout! En effet, un BoF (Bird of Feather) organisé par les JDuchess se prépare.

Le programme commence à prendre forme. Vous pouvez commencer à saliver sur des conférences plus intéressantes les unes que les autres avec quelques titres accrocheurs:

• JAX-RS, Java EE 6, and the future,
• Reflection Madness,
• Improve the performance of your Spring app,
• HTML 5 Fact and Fiction,
• Comparing JVM Web Frameworks,
• Groovy update, ecosystem, and skyrocketing to the cloud with App Engine and Gaelyk,
• Restfulie: quit pretending, use the web for real,
• Women in IT an unconference,
• etc.

Dans le programme de cette année, c’est surtout la présence de plus d’une dizaine de sessions dédiées aux technologies NoSQL et Cloud que l’on retiendra. On se souvient en effet que l’édition 2009 de cette conférence n’avait proposé qu’une trop courte session d’introduction à NoSQL suivie d’un BOF. Cette augmentation sensible de la part accordée à ces technologies témoigne de leur popularité croissante en 2010. Une fois de plus Devoxx s’affirme comme le baromètre de notre écosystème !