Le Paris JUG fête ses deux ans avec une soirée spéciale !

Le Paris JUG est le groupe d’utilisateurs du langage Java qui se retrouve mensuellement à Paris.

Cette soirée aura pour thème l’Open Source en France. Les représentants de Obeo, XWiki, Développons en Java, jCaptcha, eXo Platform, jax-doclets, Play! framework serons là pour vous présenter leur projet et vous pourrez les retrouver sur les stands pour discuter avec eux.

La  soirée d’anniversaire aura lieu le Mardi 9 février, de 18h45 à 23h00 exceptionnellement dans les locaux de la Sorbonne Paris IV dans le 17ième. Elle sera suivie d’une 3ième mi-temps qui aura lieu au Dôme de Villiers (4 Avenue de Villiers, 75017 Paris).

N’oubliez pas de vous inscrire 2ième anniversaire du Paris JUG pour l’accès à la conférence et si vous le souhaitez pour la 3ième mi-temps.

L’équipe du JUG vous attend nombreux et nombreuses pour cette soirée exceptionnelle.

Ce tutoriel a pour objectifs de mettre en place un environnement de développement Android 1.6 sous Eclipse.
A la fin de ce tutoriel vous saurez :

• Mettre en place Eclipse 3.5 avec le plugin Android
• Créer une application Android
• Déployer une application Android dans l’émulateur de votre choix

Installer Eclipse Galileo

Rien de plus simple, il suffit de le télécharger à http://www.eclipse.org/downloads/ et de choisir la version “Eclipse IDE for Java EE Developers” pour votre système d’exploitation.
Une fois téléchargé, pour l’installer il vous suffit de le dézipper !

Installer Android SDK 1.6r1

Commencez par vous rendre à l’url : http://developer.android.com/sdk/ et choisissez la version correspondant à votre plateforme.
Pour l’installer, c’est comme Eclipse, il suffit de dézipper l’archive dans le répertoire de votre choix; dans le cadre de ce tutoriel, j’appellerai ce répertoire $ANDROID_HOME_DIRECTORY.

C:\Documents and Settings\anthony.dahanne>adb
Android Debug Bridge version 1.0.20
 
-d - directs command to the only connected USB device
returns an error if more than one USB device is present.
-e - directs command to the only running emulator.
returns an error if more than one emulator is running.
-s - directs command to the USB device or emulator with
the given serial number
-p - simple product name like 'sooner', or
a relative/absolute path to a product
out directory like 'out/target/product/sooner'.
If -p is not specified, the ANDROID_PRODUCT_OUT
environment variable is used, which must
be an absolute path.
devices - list all connected devices

Installation du plugin Eclipse Android SDK

Démarrez Eclipse, et créez un nouveau workspace en choisissant un répertoire au choix (le workspace contiendra tous vos projets)
Juste après, rendez vous dans “Help->Install new software…”
Cliquez sur “Add new site” pour ajouter le site du plugin Android : choisissez le nom que vous souhaitez, et l’url suivante : https://dl-ssl.google.com/android/eclipse/

Ceci étant fait, sélectionnez les 2 cases : DDMS et android tools for eclipse, cliquez sur next, acceptez la licence et c’est fini !

Ecllipse vous demande de redémarrer, acceptez, et au redémarrage d’Eclipse configurez votre plugin Android en allant dans Window->Preferences->Android, de là indiquez votre $ANDROID_HOME_DIRECTORY
Vous pouvez maintenant créez un nouveau projet Android 1.6

Au redémarrage d’Eclipse, il vous sera demandé de configurer Eclipse pour qu’il sache où se trouve le SDK Android :

Pour cela, vous devez vous rendre dans Window->Preferences->Android et indiquer le répertoire de votre SDK
C’est bon, vous êtes prêt pour créer votre premier projet Android !

Création de votre premier projet HelloAndroid

Nous allons pour cela utiliser le plugin eclipse Android.
Cliquez sur File->New->Android Project (ou alors File->New->Project et sélectionner Android Project)
Rentrez les informations de votre projet, en particulier, choisissez la version 1.6 de l’API (la plus récente à ce jour, Donut); cependant, sachez que tous les possesseurs de téléphone Android n’ont pas encore mis à jour vers Donut, vous pouvez alors choisir la version 1.5 (Cupcake) pour un maximum de compatibilité

Cliquez sur “Finish”, le plugin vous génère alors votre projet, dans mon cas HelloAndroid
Nous allons commencer par observer la classe HelloAndroid.java, qui constitue l’unique activité (considérez pour l’instant qu’il s’agit d’un écran; est une activité une classe qui hérite de Activity) de votre projet :

package com.valtech.helloandroid;
 
import android.app.Activity;
import android.os.Bundle;
 
public class HelloAndroid extends Activity {
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
}
}

Le code de HelloAndroid.java stipule qu’à la création de l’activité, on va définir son contenu avec la mise en page (layout) main.

public final class R {
public static final class attr {
}
public static final class drawable {
public static final int icon=0x7f020000;
}
public static final class layout {
public static final int main=0x7f030000;
}
}

Le layout (mise en page) de votre activité est donc définie dans res/layout/main.xml :

Je vous laisse retrouver la valeur de @string/hello dans les ressources !
On voit ici que un TextView (un label) a été défini, ainsi, lors du déploiement de HelloAndroid, on devrait s’attendre à voir un écran avec un label

D’ailleurs pour que cette activité soit activée, elle doit être référencée dans le manifest de votre projet : AndroidManifest.xml

Vous l’avez compris, le manifest est le fichier le plus important de votre projet : il référence toutes vos activités (et bien plus !)
Nous pouvons maintenant passer au déploiement du projet dans un émulateur.

Déploiement de votre projet Android

Votre projet peut être déployé sur un téléphone équipé d’Android, ou sur un émulateur.
Pour celà, cliquez droit sur votre projet et sélectionnez “Run as Android Application.”

Comme il s’agit de votre premier déploiement, le plugin Android vous propose de créer une nouvelle instance d’émulateur: un AVD (Android Virtual Device) :

Une fois votre AVD paramétrée, cliquez sur “Create Avd”, votre AVD est créée, vous pouvez alors la sélectionner pour déployer votre projet sur cette dernière ! (après éventuellement avoir fait un “Refresh”)

Félicitations ! Votre premier projet, HelloAndroid, est déployé dans votre émulateur !

Références :

• La documentation Android officielle pour les développeurs
• La documentation complete de l’Android Virtual Device (AVD)
• Le site officiel du market place Archos, appslib.com
• Un des blogs qui explique en détail comment faire apparaître les sources contenues dans android.jar

Mardi 27 Septembre 2009, j’ai animé un cours du soir (durée 2h. environ) dans les locaux de Valtech, à destination des consultants Valtech Technology Consulting.
On était presque une dizaine, et dans une atmosphère conviviale et intéressée (plusieurs membres de l’audience avait leur téléphone Android sur eux, çà aide !), j’ai déroulé ma présentation, dont voici les diapositives (format  OpenOffice OpenDocument sous licence Creative Commons) et les TPs :

En gros, nous avons parcouru :

• l’environnement de développement sous Eclipse
• les activités et les intents
• le broadcastReceiver de SMS

Le prochain cours du soir sera présenté par Sadek Drobi et parlera de Scala, vivement la semaine prochaine !

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 !

Ces sessions ont eu lieu durant Jazoon 09, le Mercredi 24 Juin 2009. You can read the original english transcript here.

Ouverture de la journée par Danny Coward , architecte en chef chez Sun 9:00 – 10:00

Bon je suis arrivé un peu en retard mais voici de quoi çà parlait :

Java 7

Nouvelles fonctionnalités Java SE 7 (sort en 2010) : modularité , l’opérateur null safe ?. qui permet de ne pas avoir de NullPointerException quand on fait : MonObjet?.monAttribut, une nouvelle API pour java.io (çà a l’air d’être très bien : on parcoure un répertoire et on est rappelé par une callback lorsque l’on rencontre un fichier avec tels attributs, par exemple); vous voulez en savoir plus ? c’est par là : http://openjdk.java.net/projects/jdk7

Java FX

La nouvelle version est Java FX 1.2, elle tourne sur tous les OS (dont Linux et Solaris, une télé LG, des téléphones qui vont sortir dans quelques mois), fournit des nouveaux composants graphiques (que l’on peut personnaliser avec des feuilles de style CSS), de nouveaux layouts, et une meilleure performance.
On a eu droit, en fin de présentation, à des démonstrations d’applications JavaFX : sympa, surtout avec les composants videos (si vous avez vu la démo de parleys.com en Java FX au 1er anniversiare de ParisJug, vous avez déjà vu çà !)

OSGi and Java Modularity, 10:30 – 11:20, par Peter Kriens

Une application Java, de base, n’est pas modulaire ! pourquoi ? car on ne peut pas cacher les interfaces au runtime, et il est souvent inefficace de fournir un système de protection…
Avec OSGi, on peut cacher les interfaces de son choix, et, en utilisant le MANIFEST de son jar, on peut spécifier explicitement les interfaces exportées.
Avec un bundle OSGi( un jar !) on peut spécifier dynamiquement quels sont les autres bundle dont on dépend; si ce dernier n’est plus disponible, OSGi enlèvera ce chemin de dépendance, s’il redevient disponible, OSGi rétablira cette dépendance .
Un problème de taille : d’autres implémentations de modularité existent en Java (Guice, Jigsaw) et dans la JSR 294, il n’y a pas de choix précisé… La conséquence pour le programmeur ? Problèmes de dépendance entre bundles OSGi / Guice/ Jigsaw à venir…

Next generation Wikis: Mixing Content-Oriented Applications with Wikis, 11:30 – 12:20, par Vincent Massol

Avant, il y avait : Wiki 1.0 : juste pour du texte…
Maintenant, avec Wiki 2.0, il y a : images, videos, comments, notes, les données peuvent être structurées ou non, provenir de différents sites webs, etc…
Ensuite Vincent a présenté une démo de XWiki : en particulier comment créer une application pour saisir ses congés : un peu de code (velocity mais aurait pu être groovy apparemment) pour créer le formulaire ainsi que le modèle de cette application, reste à savoir à qui s’adresse cette fonctionnalité : pour des fonctionnels ou des développeurs ? (j’ai pas pensé à poser la question…)
Pour conclure, Vincent nous dévoilait les prochaines fonctionnalités de XWiki : fusion entre CMS et wiki, une vision mobile, des connexions aux réseaux sociaux, collaboration temps réel (comme dans google wave), etc…

JavaFX Rich Internet Applications connected to GlassFish Java EE 5 services, 16:00-16:20, par Ludovic Champenois – Sun Microsystems

Après avoir présenté la console d’admin de Glassfish V3 et nous avoir rappelés les principes de REST (méthodes HTTP, les ressources, etc…) ainsi que les annotations REST dans Java EE6; Ludovic a présenté les quelques lignes de code Java nécessaires pour créer un service REST (code Java EE6 à l’aide de Netbeans bien sûr), comment le tester à travers curl (curl -HAccept:application/xml http://localhost/domain), un navigateur ou encore… la console d’admin de GlassFish V3 (Admin Backend Tester)
Enfin, écriture d’une application JavaFX qui consomme ce service, en quelques lignes de Java FX Script le tour était joué !
La présentation s’est terminée avec une présentation d’applications JavaFX … qui a dit que Sun mettait JavaFX en avant ?

JavaFX / Android: Competing technologies or the ideal partnership? , 16:30 – 16:50 par Mike Mannion and Andreas Hölzl

Cette présentation a été présentée comme une pièce de théâtre (un peu comme la présentation que j’ai co animé avec Yannick Ameur et Stéphane Malbéqui aux XP Days : “Tdd avec ou sans mocks”) : 2 développeurs se retrouvent autour d’un bon café à comparer leurs applications (en fait 2 fois la même : permet de se connecter avec des services web flickr, last fm, youtube) : l’une créée en JavaFX, l’autre créée avec Android.

• Interface graphique : en Java FX faite avec PhotoShop ou Illustrator par des designers, avec Android, décrite en XML
• Interface Graphique (encore) : Android fournie BEAUCOUP plus d’API de hauts niveaux que JavaFX : ici 1 galerie était utilisée
• Langage : il faut apprendre JavaFX Script, alors qu’avec Android, c’est du Java 5 (avec des packages en moins, certes…)

Pour finir, les orateurs nous ont confié que si Sun disait vouloir supporter Android il y a un an, et bien… toujours aucun support à l’horizon ! Quoiqu’il en soit, JavaFx Mobile ne semble vraiment pas faire le poids en terme d’APIs face à Android !

Jazoon 09 c’est pas fini, çà continue demain !

Ces sessions ont eu lieu durant Jazoon 09, le Mardi 23 Juin 2009. You can read the original english transcript here.

La keynote de James Gosling : 9:50 à 10:45

En tout début de session, une vidéo nous a été projetée, un film d’animation très amusant sur l’histoire de Java, et comment Java a conquis le monde !(n’hésitez pas à nous donner l’url en commentaire si vous l’avez !)
James a d’abord commencé son discours en plantant le décor : il y a désormais plus de JVM installées que d’humains (!) : sur ordinateur, téléphone, cartes intelligentes (transport), dans les télés, etc… (15 millions de JRE téléchargées par jour) et donc il y a aujourd’hui 6 millions de développeurs Java dans le monde ! On peut donc parler de “Learn Once, Work everywhere” tant la connaissance et l’utilisation de Java sont répandues !
Pour illustrer ces chiffres, James a cité des exemples comme l’assurance maladie brésilienne qui utilise Java et des bases de données pour conserver toutes sortes de documents comme des radios, des ordonnances, etc…
D’ailleurs, le plus important dans Java ce n’est pas le langage mais la plate forme : aujourd’hui toutes sortes de langages tournent dessus : Ruby, Scala, JavaScript, etc…
Glassfish profite de cette plateforme et aussi de Java EE6 : juste en sauvegardant une servlet, sans redéployer, on obtient le résultat en rafraichissant la page dans le navigateur (même en rajoutant un EJB dans la servlet) ! La productivité va s’améliorer !
L’IDE de choix est alors Netbeans, qui dans sa version 6.7 s’intègre au projet Kenai, une sorte de sourceforge où l’on peut faire toute sorte d’opération comme dans un gestionnaire de sources (ex : Subversion), aussi 6.7 amène une meilleure compatibilité Maven, je connais des cast codeurs qui vont aimer !
Sortie de nulle part, mais plutôt marrant un exemple de code Java embarqué : le refactoring d’1 vieille Lincoln en véhicule Hybrid avec du code Java pour mesurer et contrôler le véhicule, code déployé à distance par internet (connexion 3G dans la voiture)
James a aussi évoqué les performances, et a mis fin à la rumeur comme quoi Java est moins performant que C++ en fournissant des chiffres plaçant java comme une plateforme très performante.
Pour la téléphonie mobile, de nouvelles specs arrivent (un peu tard quand on voit iphone os et android ?),le Mobile Service Architecture (MSA ou JSR 248) les rassemblant toutes.
Java 7 sera modulaire (comme Java EE6) et permettra l’utilisation de langages dynamiques, en attendant Java SE 6 a des mises à jour qui arrivent avec entre autres une meilleur intégration dans le navigateur web.
java FX est toujours là ! rien de nouveau à son sujet (meilleur collaboration entre développeurs et designers, se déploit sur mobile comme sur desktop, etc..) si ce n’est que la version 1.2 sort sous peu.
Enfin James nous a rappelés les différentes communautés Java existantes : glassfish, netbeans, java.net
Bref une keynote qui nous montre que Java est sacrément présent, voire même inévitable, et pour de longues années encore ! Sun investissant toujours dans le développement de sa plate forme phare !

Java EE 6 11:00 – 11:50 par Roberto Chinnici de Sun

Java EE est souvent reproché d’être trop compliqué… pour répondre à ces critiques, Java EE6 sera plus flexible, plus modulaire, plus puissant et plus facile à utiliser!
Ainsi ont été créés les profiles, qui répondent aux attentes particulières de chaque utilisateur : par exemple il existe le profil Web qui embarque les JSP, JSF, Bean validation des EJB lite, pour déployer dans un war.
Voyons en détail quelles sont les specs sur lesquelles repose Java EE 6 :

Servlet 3.0

Nouvelles annotations @WebServlet, @WebFilter, @WebListener, la possibilité d’enregistrer de nouveaux composants Web juste en les déposant dans le WEB-INF/lib, plus besoin de web.xml (cool !) et la possibilité d’exécuter des requêtes en mode asynchrone (et avec plusieurs requêtes sur 1 thread…)

JAX-RS 1.1 : RestFul webservices

C’est l’API qui permet d’encapsuler toute la couche technique HTTP de Rest : avec des annotations comme @POST ou @GET , on définit les méthodes qui feront les opération de création ou de récupération des objets; d’ailleurs la transformation JSON ou XML vers objets java est prise en charge par JAX-RS !

Bean Validation 1.0 (JSR-303)

Cette API est arrivée un peu tard comme l’a dit Roberto, elle sert à définir des contraintes sur des champs d’un formulaire Web par exemple…
Pour en avoir parlé un peu plus tard avec Emmanuel Bernard, (qui a participé à la spec BeanValidation), il existe un ensemble d’annotations pré définies (@Max, @Min, etc…) et il suffit d’une dizaine de lignes de code pour en rajouter dans son projet.

EJB 3.1

Finies les interfaces ! un fichier source par EJB !
Une nouveauté remarquable : on peut désormais définir des tâches périodique, un peu comme dans Cron, avec l’annotation @Schedule : quand je pense quand dans mon projet actuel on a écrit des MBeans qui sont appelées par des tâches Cron pour raffraîchir le cache, je me dis que que EJB 3.1 a du bon !
EJB 3.1 lite peut tourner dans Java SE (super pour tester sans deployer !) et aussi être embarqué dans un simple war !
Le speaker manque de temps tant pour JPA 2.0 (quand on utilise Hibernate avec les annotations çà doit pas bien changer…) et JNDI (qui proposent de nouveaux modes d’accès )
Du très bon ce Java EE 6 !

“Design Patterns” in Dynamic Languages 12:00 – 12:50 par Neal Ford (nealford.com)

Cette présentation avait pour but de montrer qu’il n’est pas toujours nécessaire de se référer aux patterns du Gang Of Four, surtout dans les nouveaux langages dynamiques comme Groovy ou Ruby, qui sont déjà équipés pour faire face à des problème récurrents.
Quelques exemples (j’ai pas pu tout noter ! le présentateur a cité les patterns iterator, strategy, template, interpreter, decorator, recorder, adapter)
Pour le pattern iterator : est il nécessaire en Ruby de créer 3/4 classes pour implémenter ce pattern ? et non, il suffit d’appeler collection.each{[x| puts x} … plus rapide non ?
Pour interpreter aussi (pour rappel ce design pattern a été créé pour ajouter des fonctionnalités au langage utilisé), rien de plus simple que de créer un nouveau DSL en Groovy en créant de nouveaux comportements à une classe existante, Integer dans l’exemple.
Pour conclure, Neal a cité qu’avec les langages dynamiques, apparaissent de nouveaux design pattern, grâce à leur syntaxe plus riche; profitons des outils fournis par ces nouveaux langages plut que d’essayer de reproduire des situations inadéquates !

Gradle : A build system for Java 14:00 – 14:50, par Hans Dockter

Au tout début de la présentation, Hans rend honneur à Ant et Maven en nous rappelant leurs fonctionnements, défauts et avantages.( un peu comme Eric Lemerdy et Grégory Boissinot dans leur podcast Gradle que je vous conseille d’ailleurs tout particulièrement)
Avec Ant, souvent on copie colle des taches , c’est souvent répétitif… Dans Ant il n’y a pas de listeners pour surveiller ou logger les phases de build…
Avec Gradle, on peut importer des scripts ant et invoquer des tâches Ant, en Groovy. (et même déployer le résultat de son build sur apache Ivy)
Maven est quant à lui un framework qui repose sur les conventions et a introduit la gestion des dépendances; par contre il faut 25 lignes de XML avant de pouvoir écrire le moindre script de construction; aussi Maven n’utilise que des dépendances transitives, ce que Gradle peut éviter en spécifiant ses dépendances.
D’ailleurs Gradle peut réutiliser et importer en groovy les builds maven; et même envoyer le resultat de son build sur un repository maven.
Gradle se veut un langage de builds et non un framework de builds, afin de pouvoir plus souple qu’un framework.
Enfin, Gradle peut s’utiliser sans s’installer sur tout système d’intégration continue grâce à un script bash ou shell qui télécharge sur la machine d’intégration continue les librairies nécessaires.

Next Generation Enterprise Builds: Maven, Mercury, and Tycho (pour les builds OSGi) par Jason van Zyl de Sonatype

Maven 3.0

Sera mieux intégré dans les IDE (eclipse, netbeans, intellij, sera plus rapide, resoudra mieux les dépendances, aura un nouveau système de plugins
Maven 3 sera plus concentré sur les tests d’intégration, il aura un cycle de vie déclaré, qui permettra aux outils l’embarquant de prédire la séquence de build et donc de pouvoir sauter des étapes.
Enfin Maven 3 utilisera Mercury, un nouveau moteur de transport et de gestion, qui pourra d’ailleurs être utilisé avec autre chose de que des POMs (des gems ou les dépendances Eclipse P2)

M2eclipse

M2Eclipse, le plugin maven pour Eclipse va pouvoir choisir les bonnes actions maven à appeler lors d’une sauvegarde, et non pas tout le cycle maven.
Il pourra aussi gérer les projets Flex, et importer dans Eclipse les préférences du projet Maven (modification des préférences du workspace)

Nexus

Seulement 5% des utilisateurs de Maven Central utilisent un repository manager comme Nexus ou Archiva.
On peut voir Nexus comme un gestionnaire de binaires pour l’entreprise, en plus d’un système de cache évolué !
Nexus va pouvoir être utilisé à travers Eclipse, son API pourra aussi être appelée via REST (ce qui facilitera la création de plugins ! )

Hudson

Dans sa prochaine version, Hudson intégrera un nouveau moteur de workflow : drools workflow integration (avec un editeur de workflow), une couche REST pour être interrogé et commandé par des plugins, et aussi pour unifier l’intégration avec m2eclipse, nexus et bien sûr Maven.

Testing Zen 16:00 – 16:20 par Thomas Mueller, Day

Session rapide de 20 minutes, où Thomas, après nous avoir donnés 10 raisons à la question “Pourquoi tester ?”, nous cite 3 moyens de tester…
En faisant du “fuzz testing”, où l’on génère des données pour tester.
Avec Emma, pour faire de la couverture de code.
Et enfin les tests de base de donnée : pour cela, il faut utiliser une base de données Java comme HSQL (bien), Derby (pas bien) ou encore H2 (la meilleure, celle sur laquelle travaille Thomas actuellement d’ailleurs )
A la question : “Pourquoi ne pas utiliser de mocks au lieu de peupler une base de données ?” il répond “C’est trop long à initialiser… mais en même temps j’en utilise rarement”…

Creating Performance Test Data with benerator, par Volker Bergmann

D’habitude lors de tests de performance, on préfère utiliser des données de production…
Mais parfois, pour des raisons de disponibilité (nouveau système) ou de confidentialité (outsourcing, etc…) on ne peut pas injecter des données de production dans les tests…
Volker a alors développé Benerator, un créateur de jeux de tests, qui peuplera une base, ou un fichier plat, ou LDAP, ou JCR, etc…
A tester avec le plugin benclipse ou le plugin Maven 2.

La journée s’est terminée avec un speech très amusant sur la prédictibilité des technologies par Neal Ford, c’était vraiment sympa, plein de référence à la science fiction et aux succès récents et à ceux qui le sont devenus que plus tard, excellente réflexion et conclusion : “Le meilleur moyen de connaître le futur, c’est de le faire soi même”
Un autre speech de fin sur l’agilité, par Ivar Jacobson, rien de nouveau…

Du Mardi 23 Juin au Jeudi 24 Juin 2009 se tiendra à Zürich, en Suisse, LA conférence européenne sur Java.

Des speakers aussi connus que James Gosling, le papa de Java, et Dany Coward, l’actuel responsable de la plate forme client de Java (Java ME, Java SE, et Java FX) auront chacun la parole durant la keynote.

Le programme de ces 3 jours s’annonce vaste, pour preuve le planning de Jazoon 09 ; (sessions du Mardi , du Mercredi, du Jeudi)

A Jazoon cette année de nombreux conférenciers aborderont la plate forme mobile Android (et même l’iphone!), GWT, Spring 3.0, Java EE6, Gradle, OSGi, Hibernate, Java FX, Mockito, les frameworks REST, bref, tout ce qui occuppe le devant de la scène Java !

Suivez en direct l’actualité de ce Jazoon 09 entre Mardi 22 et Jeudi 23 Juin 2009 sur ce même blog et sur twitter : anthonydahanne

A bientôt !

Suite à beaucoup de mystère, Didier Girard nous à présenté hier les évolutions réalisé par Google de l’App Engine Java hier chez Google France.

Ayant eu la chance d’être parmi les développeurs sélectionnés, voici les points présentés :

• Chiffres : 150k développeurs travaillent avec App Engine, 50k app sont déployés : Ebay, BuddyPoke …

• Présentation des évolutions de la console d’administration :

1. différentes métriques de consommation,
2. la possibilité de gérer sa consommation et de payer du dépassement à la demande
3. présentation du système de Cloud computing pour la gestion de la performance et de la consommation
4. l’accès à la base de données,
5. import export des données
6. La gestion du Cache pour faire des économies
7. La gestion de CRON : interrogation d’URL (avec un petit + la définition de la Time Zone)
8. le SDC, Secure Data Connector : pour créer une connexion ssl à votre SI …

• Présentation du plugin Google pour eclipse

1. Création de projet simple et prêt à être déployé via App Engine (Sur les bases de GWT)
2. choix des sdk gwt et App Engine à utiliser dans votre application
3. seul obligation pour votre application : définir le nom de l’application ( à voir + tard la définition des noms de domaines)
4. présentation de la gestion de persistance en JDO (ou JPA) via la base Google de type BigTable.

Google nous propose donc un moyen simple de créer des application web en java simple à déployer, dans le cadre d’application Open-Social.

Pour le moment cela semble très prometteur. A vous de faire une demande de compte chez google pour commencer à réaliser vos applications.

A voir les applications de Didier :

Wolfengine et ergosum

Annonces :

• Guillaume Laforge a réalisé la portabilité de Groove sur App Eng.
• Un plugin Maven devrait être mis à disposition cette semaine sur google code.

Voila pour les infos glanés lors de la présentation chez Google France.

Valtech Lunch, une rencontre conviviale autour d’un déjeuner !
Avec le témoignage du Club Méditerranée
Le 7 Avril 2009 à Paris la Défense

Votre emploi du temps ne vous permet pas toujours d’accorder suffisamment de temps à la veille technologique ;
c’est pourquoi Valtech vous propose une rencontre de 12h15 à 13h45.

Ainsi, sans surcharger votre agenda, vous aurez l’occasion de faire le point sur ce qu’il est envisageable de faire en termes de migration progressive de systèmes d’information de type Mainframe vers des technologies moins onéreuses et plus flexibles.

Cette présentation durera 1h30 et sera accompagnée d’un déjeuner léger (type plateau repas).

Pour chaque inscription (60 € par personne), nous vous proposons d’inviter gratuitement une personne de votre choix.

Inscrivez-vous à la session Valtech Lunch du 7 Avril 2009

Mon collègue Jérôme Piétri présentera le framework web Grails (basé sur le langage Groovy) jeudi 12 février à 18h30 dans les locaux de Valtech près des Champs Elysées.

Cette soirée cible principalement les consultants Valtech. Néanmoins, nous pouvons accueillir des personnes externes, dans la mesure des places disponibles.

La soirée couvrira les points suivants:

• la place de Grails dans le monde Java
• les principes du framework
• l’architecture
• le scaffolding
• quelques plugins
• les avantages, inconvénients et les concurrents

Si vous souhaitez y participer, envoyer un mail à eric POINT lefevre AT valtech POINT fr.

A bientôt!