Ouverture de la journée, 9:00 – 9:45 par Adrian Colyer

Cette présentation avait pour but de nous décrire ce qu’il est probable d’arriver dans l’écosystème Java pour les années à venir, car Java est bel et bien là pour durer en entreprise.
Un axe de progression présente les langages dynamiques comme Groovy, JRuby, Scala et Clojure.
Parmi ceux là, Groovy est peut être le mieux placé car c’est celui qui s’intègre le mieux à la JVM, la réutilisation de classes Java y est plus aisée. (il faut aussi garder à l’esprit que SpringSource détient désormais les projets Groovy et Grails).
Pour les frameworks Web du futur sur la JVM, le présentateur mise sur Grails (qui repose sur Groovy), Rails (qui repose sur Ruby et donc JRuby) ou encore Lift (écrit en Scala); il a aussi mentionné l’avantage de Grails qui s’intègre à Spring facilement, Spring étant d’ailleurs vastement déployé en entreprise, cela risque de faciliter l’adoption massive de Grails…
Enfin, il a terminé sa présentation en évoquant OSGi et Spring DM : le futur des applications d’entreprise se situe certainement dans le “nuage”, à savoir des applications facilement déployables et facilement dimensionnables (pouvoir passer de 1 à 1M d’utilisateurs)

The android runtime environment, 10:30 – 11:20, by Joerg Pleumann

L’orateur a d’abord présenté la plate forme Android comme une alternative à Windows Mobile et Palm.
Elle est basée sur un noyau linux, avec les drivers nécessaires (audio, video, etc…)
Ensuite, vient au dessus le runtime android et des librairies (de plus ou moins haut niveau).

Dalvik VM

La dalvik VM tourne sur un CPU entre 250 et 500MHz, avec au moins 64 Mo de Ram (comme un PC de 1999)
La VM Dalvik est plus efficace que la JVM standard car elle utilise des registres explicitement.
L’auteur nous a comparé le résultat obtenu par une compilation d’un bout de code Java vers du bytecode Dalvik et vers du bytecode JVM : c’est sans appel, le résultat est bien plus léger (30% de lignes en moins) sur Dalvik.
Un binaire Dalvik est stocké sous forme de fichier DEX; un fichier Dex peut contenir plusieurs classes Java (réduisant ainsi les imports), et n’est pas compressé dans un Jar.
Il vient de sortir aujourd’hui un SDK pour utiliser JNI (et donc exécuter du code natif ARM) sur la plateforme Android, la plateforme elle même utilise JNI pour toutes sortes d’optimisations (ré implémentation des regex, de la sécurité, etc..)

Les “Core Libraries”

dalvik vm specific libraries : dalvik.*
java compatibility libraries : java.* et javax.*
des librairies apache (surtout pour http) : org.apache.*
Ces librairies sont moitié issues du projet Apache Harmony, moitié écrites exprès.
On peut considérer ces librairies comme fournissant un sous ensemble de J2SE 5.0.
On peut résumer en disant qu’avec Android on peut ré utiliser nos connaissances sur le langage et sur les outils (enfin, de mon expérience Android certaines choses, comme les composants sont à découvrir, d’ailleurs la prochaine présentation en dit plus long dessus !)

Android Application Model, 11:30 – 12:20, par Dominik Gruntz

Dans Android, il y a 4 types de composants : les activités, les services, les content provider et les broadcast receivers.

Activity

Il s’agit typiquement d’un écran, dont la définition tient juste en une classe, utilise les intents pour communiquer avec les autres activités : intent qui peut être lancé en attendant un retour, ou pas.
Ainsi, on peut définir des intent filters qui permettent de décrire quelle est l’application qui rattrape tel intent. (par exemple le navigateur rattrape l’intent URL)
Il existe d’ailleurs à ce propos une spécification en cours sur les intents : http://www.openintents.org
Chaque activité a un cycle de vie contenant les étapes suivantes : new, running, paused, stopped, killed; il existe d’ailleurs des méthodes pour chaque étape (onCreate, onStop, etc…)
Pour chaque activité, un process avec un unique thread est créé; les actions sont dispatchées par Looper.loop sur une queue.
Si une activité ne répond pas à un événement en moins de 5sec, le système détecte une anomalie et propose à l’utilisateur de tuer l’application.

Service

Une application, qui contient plusieurs composants, est contenue dans un APK (android package)
Un service tourne en tâche de fond, et peut communiquer avec des activités (si elles sont issues du même package, la communication est intra process, sinon, elle est inter process et nécessite que le service soit déclarer dans un fichier AIDL : Android Interface Definition Language)

Content Provider

Fournit du contenu, c’est l’unique moyen d’échanger des données (que ce soit en base SQlite, sur fichier ou sur un stockage distant) entre applications Android.

Scalable Agile Web Development: REST meets JCR meets OSGI, par Michael Marth

Dans cette présentation, nous avons pu voir en action le framework web Apache Sling, qui vient de sortir de l’incubateur Apache.
Un bref rappel de JCR (Java COntent Repository, JSR 270) : est utilisée pour accéder à du contenu stocké soit sur base/système de fichiers/etc…; le contenu peut être versionné, il se présente sous la forme d’un noeud ayant des droits et appartenant à 1 groupe.
Apache Sling présente une interface REST, la possibilité de scripter ses pages en langages dynamique (Ruby, Groovy, Scala, etc…), est déployé dans OSGi et puise son contenu dans un repository JCR !
Pendant la démo, les démonstrateurs ont pu mettre en avant les possibilités de Sling : branchement/débranchement de bouts du framework (grâce à OSGi), création/consommation du contenu en utilisant du REST, ajout de contenu via un explorateur de fichiers monté sur Webdav (merci JCR) et dynamisation de pages HTML avec du Groovy.
Belle démo, çà donnait vraiment l’impression de quelque chose facile à utiliser, propre (grâce aux URLs REST qui ressemblent comme deux gouttes d’eau aux URI du contenu sur JCR); bref un projet à suivre !

The charm of Mockito: Test Spies in action, 14:30 – 15:20, par Szczepan Faber

Dans l’audience, une majorité d’utilisateurs d’EasyMock ( la moitié des 60 spectateurs dont moi !), 2 ou 3 utilisent JMock, 5 utilisent Mockito.
Szczepan, l’auteur de Mockito a alors codé , en TDD, une classe dictionnaire, qui dépend d’un traducteur.
Qui dit dépendance dit difficulté pendant les tests; enfin quand on utilise pas de frameworks de mock.
L’orateur a alors commencé à écrire son test de dictionnaire, en mockant le traducteur avec EasyMock et en l’injectant dans la classe dictionnaire.
On retrouve alors le createMock/expect/replay/assert/verify classique d’EasyMock; il a ensuite d’ailleurs refactoré son code pour déplacer les phases de replay et de verify dans une méthode annotée @After ainsi que la pahse de création d emock dans un @Before (selon lui beaucoup d’utilisateurs d’EasyMock font çà pour ne pas sans cesse répéter ces phases dans chaque test de la classe de Test).
Avec Mockito, çà donnait plutôt du mock/when/assert/verify, un peu plus sympa, d’autant plus que l’orateur utilisait des tempaltes eclipse, qui, à l’écriture d’un test, écrivaient en commentaires : given/when/then, les piliers du BDD.
Alors qui est le meilleur ? Mockito ou EasyMock ?
Et bien Mockito s’en tire avec un léger avantage :
*la syntaxe, plus concise et plus proche du BDD, permet aux développeurs de ne pas s’emmêler les pinceaux avec une syntaxe difficile dont on ne se souvient pas toujours…
*le “good point of failure” de Mockito joue en sa faveur : quand votre test échoue, dans Eclipse on peut retrouver tout de suite la ligne en échec et la raison de l’échec est claire.
C’est tout ? et bien fondamentalement les 2 sont d’excellents frameworks de Mock, Mockito a quand même l’avantage d’être jeune (entre 1 et 2 ans) et déjà complet, et en plus il fait des émules dans d’autres langages (Python, javaScript, C++, etc…)
Szczepan a conclus en disant ces quelques mots : “Faites du TDD et d’excellents tests avec les outils qui vous conviennent”.
Je crois qu’on est tous d’accord !

Eclipse Galileo and JBoss Tools, 16:30 – 16:50, par Max Andersen

Galileo (Eclipse 3.5) est une version majeure d’Eclipse.
A ne pas rater lors de sa sortie : (en fait il est déjà téléchargeable sur eclipse.org !)

• Eclipse Memory Analyzer : un outil pour analyser la consommation mémoire d’Eclipse, à utiliser conjointement avec Jmap
• Le nouvel éditeur XML /XSL : avec requetage XPath des noeuds
• Le nouveau P2 (le eclipse update manager) : çà y est, il marche, et bien en plus ! Même en mode déconnecté il n’est plus nécessaire de dézipper les plugins et features (dropins), téléchargeables une archive compatibles avec P2, sur le site de votre plugin !

Tags: Java, jazoon 09

This entry was posted on Thursday, June 25th, 2009 at 10:15 pm and is filed under Valtech. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.