Hadoop dans les grandes lignes 

Hadoop est un framework java destiné à faciliter la création d’applications distribuées et scalables. Il permet aux applications de travailler avec des milliers de nœuds et des pétaoctets de données.

Hadoop repose sur son système de fichier (HDFS) ainsi que sur son algorithme de Map/Reduce.

Généralement, tous les tutoriaux ou exemples d’implémentation d’Hadoop concernent un calcul basique de calcul du nombre de différents mots contenu dans des fichiers.

Dans cet article, je vais m’attacher à vous présenter un cas concret d’utilisation d’Hadoop pour le calcul de VWAP.

Qu’est ce qu’une VWAP et pourquoi utiliser Hadoop pour la calculer ?

La VWAP (Volume-weighted average price) est un indice financier correspondant au ratio de la valeur échangée par le volume échangé. Plus d’info ici

Notre but est de calculer la VWAP pour tous les titres, sur tout l’historique disponible à des heures données.

Les fichiers historiques sont de la forme txt. Il y a un fichier par jour, ce fichier pèse en moyenne 1GigaOctet. Donc selon la taille de notre historique, ce calcul peut s’avérer très fastidieux et couteux en ressources.

Voici à quoi ressemble un fichier en entrée (enfin une infime partie) :

C;FR0000130338;09:00:03;3;310;24.6;50;24.5
C;FR0000130338;09:00:03;4;231;24.62;665;24.4
C;FR0000130338;09:00:03;5;686;24.63;309;24.37
C;BE0003796134;09:00:03;1;3360;4.51;5306;4.5
N;FR0000120222;09:00:00;00000042;67.99
N;FR0000120222;09:00:00;00000019;67.99
N;FR0000120222;09:00:00;00000012;67.99
N;FR0000120222;09:00:00;00000002;67.99
N;FR0000120222;09:00:00;00000041;67.99

En séparant par “;”

1. C ou N, C pour carnet d’ordre N pour une transaction
2. Code ISIN du titre
3. Heure de la transaction
4. Volume de titres échangés
5. Prix

Hadoop va donc être utilisé pour ces fonctionnalitées de calcul distribués afin de répartir la charge de parsing et calcul sur différentes machines et tout aggréger pour donner en sortie un fichier avec les vwap demandées.

Voici un extrait du fichier de sortie :

FR0010112524-20100104-09:00:00     25.656256
FR0010112524-20100104-12:00:00     26.125364
FR0010112524-20100104-17:00:00     26.28817
FR0010112524-20100106-09:00:00     26.560003
FR0010112524-20100106-12:00:00     26.684067
FR0010112524-20100106-17:00:00     26.756487
FR0010112524-20100217-09:00:00     25.949999

Implémentation d’Hadoop pour un calcul de VWAP

En entrée, on a donc toute une série de fichiers txt. Chaque fichier correspond aux extractions Euronext des transactions d’un jour donné.

Seules les lignes commençant par «N;» nous intéressent, les autres correspondant aux carnets d’ordre.

Au niveau du Mapper, nous allons extraire toutes les lignes commençant par «N;» pour un ou plusieurs code ISIN donnés.

Dans le Reducer, on va vouloir récupérer toutes les lignes correspondant à notre/nos ISIN triées par jour puis heure afin de calculer la Vwap pour les heures données. Or Hadoop ne permet pas de trier directement la liste de <Values> reçue par le Reducer

Tri des <Values> grâce à une clé composite

Avec Hadoop il est impossible d’effectuer un tri sur les valeurs. Par contre, à la place on peut placer les données qu’on veut trier dans la clé et ainsi utiliser une clé composite. Ensuite on utilise une classe de Partition spécifique ainsi que deux classes RawComparator afin de trier et partitionner notre map en sortie correctement.

La solution est d’utiliser un système de clé composite, dans notre exemple, je la nomme IsinKey.

L’objet IsinKey sera utilisé comme la Clé et contient :

• Une String key qui est la concaténation de l’ISIN puis du jour de l’extraction (par exemple : FR0010112524-20120913)
• Une String hour qui correspond à l’heure d’une transaction

Un objet Tick sera lui utilisé comme Valeur pour stocker le volume et le prix.

Ensuite, il va nous falloir définir 3 réglages dans le JobConf d’Hadoop :

• setPartitionerClass
• setOutputValueGroupingComparator
• setOutputKeyComparatorClass

Le Partitioner

La première classe qu’on doit setter étend de org.apache.hadoop.mapred.Partitioner. Cette classe a pour unique fonction de déterminer dans quelle partition notre map de sortie doit aller. On ne peut aller en dessous de 0 ou au dessus de numPartitions -1 dans notre retour. En général il est préférable de récupérer le HashCode d’une partie de la Clé et d’y appliquer un modulo du nombre de partitions.

Dans notre exemple, on récupère le hashcode de notre Clé qu’on module ensuite avec le numPartitions.

public int getPartition(IsinKey key, Tick val, int numPartitions) {
   int hash = key.getKey().hashCode();
   return hash % numPartitions;
}

L’ Output Value Grouping Comparator

L’OutputValueGroupingComparator dans les paramètres du JobConf utilise un org.apache.hadoop.io.RawComparator. Le RawComparator est utilisé pour déterminer dans quel Reducer notre ligne de sortie de mapping doit aller. Ce RawComparator ne trie pas la liste de Valeurs du Reducer, mais trie l’entrée du Reducer,  pour que le Reducer sache quand un nouveau groupe commence.

Dans notre exemple, le grouping comparator va trier par la «Key» de notre object IsinKey (c’est a dire «Isin-date»

public int compare(WritableComparable w1, WritableComparable w2) {
   IsinKey k1 = (IsinKey)w1;
   IsinKey k2 = (IsinKey)w2;
   return k1.getKey().compareTo(k2.getKey());
}

L’ Output Key Comparator

L’outputKeyComparatorClass dans les paramètre du JobConf utilise aussi un org.apache.hadoop.io.RawComparator. Ce RawComparator est utilisé pour trier les Clés que reçoit le Reducer. Les données envoyées au comparateur sont nos objets clés (IsinKey dans notre exemple). Il est très important aussi de retenir que le KeyComparator doit comprendre la règle définie dans l’OutputValueComparator.

Dans notre exemple, ça veut dire qu’on va d’abord comparer la Key de l’objet IsinKey, puis, si ces Key sont égales, alors on va comparer les champs Hours de l’objet IsinKey.

public int compare(WritableComparable w1, WritableComparable w2) {
   IsinKey k1 = (IsinKey)w1;
   IsinKey k2 = (IsinKey)w2;
   SimpleDateFormat f = new SimpleDateFormat("HH:mm:ss");
   int result = k1.getKey().compareTo(k2.getKey());

   if(0 == result) {
      try {
         result = f.parse(k1.getDate()).compareTo(f.parse(k2.getDate()));
      } catch (Exception e) {
         e.printStackTrace();
      }
   }
return result;
}

Grâce à ces trois classes redéfinies, le Reducer sera appelé une fois par clé IsinDate, puis lorsque l’on itère sur les «values», l’heure de la «Key» prend successivement ses différentes valeurs, ce qui nous permet  de déterminer la vwap à chaque tick, et de repartir à 0 pour chaque nouvelle journée

Lancement en “Stand-Alone” et reste des classes

Afin de démarrer le projet en mode «Stand-Alone», il suffit d’inclure les sources d’hadoop dans un projet eclipse par exemple, puis d’inclure ce projet dans le projet courant.

CalcVWAPDriver

public class CalcVWAPDriver {
   public static void main(String[] args) throws IOException, InterruptedException, ClassNotFoundException {

      Configuration conf = new Configuration();
      GenericOptionsParser parser = new GenericOptionsParser(conf, args);
      args = parser.getRemainingArgs();
      conf.setStrings("ISIN", "FR0010112524");
      conf.setStrings("DATES", "09:00:00", "12:00:00", "17:00:00");
      Job job = new Job(conf, "calcVWAP");
      job.setPartitionerClass(NaturalKeyPartitioner.class);
      job.setGroupingComparatorClass(NaturalKeyGroupingComparator.class);
      job.setSortComparatorClass(CompositeKeyComparator.class);
      job.setMapOutputKeyClass(IsinKey.class);
      job.setMapOutputValueClass(Tick.class);
      job.setInputFormatClass(TextInputFormat.class);
      job.setOutputFormatClass(TextOutputFormat.class);
      job.setMapperClass(CalcVWAPMapper.class);
      job.setReducerClass(CalcVWAPReducer.class);
      FileInputFormat.setInputPaths(job, new Path(args[0]));
      FileOutputFormat.setOutputPath(job, new Path(args[1]));
      System.out.println(job.waitForCompletion(true));
   }
}

Dans l’exemple, on attribue en dur des valeurs ISIN et DATES dans la configuration d’Hadoop (lignes 7 et 8) afin d’y avoir accès dans le Mapper et le Reducer. Il est tout à fait envisageable de le rendre paramétrable avec les arguments passés à la méthode main.

CalcVWAPMapper

public class CalcVWAPMapper extends Mapper<LongWritable, Text, IsinKey, Tick> {
   private String currFile = null;
   private String currDate = null;
   private String currHour = null;
   private String currIsin = null;
   private List<String> isins = null;

   public String getFileName(Context context) {
      FileSplit fileSplit = (FileSplit)context.getInputSplit();
      return fileSplit.getPath().getName().toString();
   }

   protected void map(LongWritable key, Text value, Context context) throws IOException, InterruptedException {
      if (!getFileName(context).equals(currFile)) {
         currFile = getFileName(context);
         currDate = currFile.replace(".txt", "");
      }
      if (isins == null) {
         isins = Arrays.asList(context.getConfiguration().getStrings("ISIN"));
      }

      String line = value.toString();
      if (line.startsWith("N;")) {
         String[] result = line.split(";");
         if (result.length >= 5) {
            if (isins.contains(result[1])) {
               if (!result[1].equals(currIsin)) {
                  currIsin = result[1];
               }
               if (!result[2].equals(currHour)) {
                  currHour = result[2];
               }
               String volume = result[3];
               String price = result[4];
               context.write(new IsinKey(currIsin+"-"+currDate, currHour), new Tick(volume, price));
            }
         }
      }
   }
}

Le Mapper est assez simple. Si ce n’est pas déjà fait, on prend le nom du fichier traité afin d’en extraire la date. Puis pareil, on récupère la liste d’ISIN entrée  en paramètre dans la JobConf Hadoop. (lignes 14 à 20)

Ensuite, on lit ligne par ligne le fichier. Si la ligne commence par “N;” alors on la split (lignes 23 et 24). L’Isin est la deuxième partie, l’heure la troisième, tandis que le volume et le prix sont respectivement les quatrièmes et cinquièmes parties.

Enfin, on écrit dans le context nos objets. D’un côté, la Clé composé de l’Isin-Date et de l’heure, et de l’autre côté la Valeur qui est composé du volume et du prix. (ligne 35)

CalcVWAPReducer

public class CalcVWAPReducer extends Reducer<IsinKey, Tick, IsinKey, OutputVWAP> {

   private String isin = null;
   private float vwap = 0.0f;
   private long totalVolume = 0;
   private List<Date> hoursList = null;
   private SimpleDateFormat f = new SimpleDateFormat("HH:mm:ss");

   protected void reduce(IsinKey key, Iterable<Tick> values, Context context) throws IOException, InterruptedException {
      IsinKey lastKey = null;
      OutputVWAP lastOutput = null;
      int currIdx = 0;

      if (hoursList == null) {
         hoursList = new ArrayList<Date>();
         String []dates = context.getConfiguration().getStrings("DATES");
         for (int i = 0; i < dates.length; i++) {
            try {
               hoursList.add(f.parse(dates[i]));
            } catch (Exception e) {
               e.printStackTrace();
            }
         }
      }

      for (Tick value : values) {
         try {
            if (currIdx >= hoursList.size()) {
               return;
            }
            if (f.parse(key.getDate()).after(hoursList.get(currIdx))) {
               context.write(lastKey, lastOutput);
               if (currIdx < hoursList.size()-1) {
                  currIdx++;
               } else {
                  return;
               }
            }
            Float price = Float.parseFloat(value.getPrice());
            Integer volume = Integer.parseInt(value.getVolume());
            vwap = (volume * price + totalVolume * vwap)
               / (totalVolume + volume);
            totalVolume += volume;

            lastKey = new IsinKey(key.getKey(), f.format(hoursList.get(currIdx)));
            lastOutput = new OutputVWAP(vwap);
         } catch (Exception e) {
            e.printStackTrace();
         }
      }
   context.write(lastKey, lastOutput);
   }
}

Pour le Reducer, dans un premier temps, on récupère les heures rentrés dans la configuration d’hadoop (lignes 14 à 24). Le but est d’écrire en sortie la vwap pour les heures voulues et ordonnées.

Puis on itère sur les <Values>. A chaque itération on calcule la vwap et on stocke le retour. (lignes 26 à 50)

Si à l’itération d’après l’heure de la clé dépasse l’heure en paramètre, alors on écrit la dernière vwap calculé dans le context. Puis on passe à l’heure d’après en paramètre. Une fois qu’on a traité toutes les heures voulues, on sort de la méthode. (lignes 28 à 38)

Vous pouvez récupérer les sources complètes sur le GitHub Infine

Conclusion

Nous avons donc vu comment calculer les vwap en utilisant le framework Hadoop en mode Stand-Alone.
Mais la où Hadoop tire toute sa puissance, c’est dans la parallélisation et le clustering.
Je vous montrerai donc dans un prochain article comment monter, configurer et utiliser un cluster avec Hadoop.

The post Calcul de VWAP avec Hadoop en StandAlone first appeared on In Fine - Le Blog.

In Fine, en tant que partenaire de l’évènement majeur qu’est Devoxx France, a le plaisir de mettre à disposition une application pour Devoxx France sur Android. Cette première version permet :

• De mettre en favoris vos sessions préférées
• De consulter le planning des sessions, et le détail des speakers
• De voir ce qui se passe sur Twitter avec le tag devoxxfr
• D’avoir accès au plan des 2 étages de l’hôtel où se déroulera la conférence
• Et d’autres fonctionnalités…

Cette application fonctionne parfaitement sur téléphone , mais n’est pas encore totalement adaptée pour les tablettes. Dans les semaines qui viennent, nous allons continuer à mettre à jour l’application pour qu’elle soit la plus simple à utiliser possible. Voici une prévision des futures évolutions :

• Complète adaptation de l’ergonomie de l’application aux tablettes
• Ajout de la recherche sur les speakers. Actuellement elle ne fonctionne que sur les sessions
• Quand on clique sur une salle, afficher la carte de l’étage correspondant
• Pouvoir mettre en favori des speakers
• Et bien d’autres choses qui dépendront des retours que nous aurons

Nous sommes très fiers de mettre à disposition cette application. Elle sera mise en open source au moment de la conférence Devoxx France, certainement en licence Apache 2.
Si vous rencontrez des problèmes ou avez des suggestions, écrivez un commentaire ici, ou envoyer un mail au compte indiqué sur la fiche du Google Play Store.

Dans la suite de l’article, nous allons approfondir l’aspect technique de l’application. Si au contraire vous souhaitez directement aller télécharger l’application, alors il faut aller ici : Play Store

Architecture technique

Comme le montre le schéma ci-dessus, nous n’avons pas directement connecté l’application Android avec les API RESTful fournies par le site Devoxx. En effet les temps de réponse sont très variables, certains service ont déjà mis plus de 5 minutes à répondre. D’autre part, certains service renvoient des données en double ou incomplètes.
Le serveur intérmédiaire permet donc de mieux maîtriser les données. Grâce à Play et à Mongo DB, les temps de réponse sont excellents et la charge que peut encaisser le serveur est bien au dessus de ce que nous atteindrons. Un test JMeter a mesuré que le serveur pouvait encaisser 300 requêtes par secondes. La plupart des requêtes répondent en moins de 0.1 seconde. Nous estimons que le serveur aurait à supporter, au maximum de son activité, 25 requêtes par minute

The post L’application Devoxx France d’In Fine est disponible sur le Google Play Store first appeared on In Fine - Le Blog.

Cet article est destiné à ceux qui ont la ‘chance’ d’avoir Tomcat 6 comme serveur pour leurs applications et qui doivent paramétrer le pool de connexions par JNDI.

Voici un petit article issu d’une demande d’un client.

Le client : C’est bien la configuration par JNDI, ça serait mieux si on ne voyait pas le mot de passe en clair …

Moi: No problem, everything is possible (enfin je crois) …

Effectivement c’est possible. D’après la documentation, il suffit d’implémenter une classe de type ‘factory’ pour instancier les connexions avec la base de données.

Dans cet article, vous verrez comment crypter facilement un mot de passe ou autre mais aussi comment remplacer le pool de connexion DBCP  par le pool de connexion de Tomcat 7 (plus performant à  mon goût).

Tout ceci se fait en 3 étapes :

• Codage d’une classe ‘Factory’
• Configuration de la ressource JNDI
• Copier les jar dans le répertoire lib de Tomcat

Le processus de cryptage ne sera pas détaillé ici.
Pour plus d’information, vous avez une classe “EncryptHelper” dans les sources (voir à la fin).

1° La classe Factory

Ici j’utilise le pool de connexion de Tomcat 7 :

public class Tomcat7EncryptedFactory extends org.apache.tomcat.jdbc.pool.DataSourceFactory implements SecuredFactory{

	@SuppressWarnings("rawtypes")
	@Override
	public Object getObjectInstance(Object obj, Name name, Context nameCtx, Hashtable environment) throws Exception {
		Object o = super.getObjectInstance(obj, name, nameCtx, environment);
		if (o != null && o instanceof org.apache.tomcat.jdbc.pool.DataSource) {
			org.apache.tomcat.jdbc.pool.DataSource ds = (org.apache.tomcat.jdbc.pool.DataSource) o;
			// recuperation du login et mot de passe cryptes
			String cryptedUsername = ds.getUsername();
			String cryptedPassword = ds.getDbProperties().getProperty("password");
			// on decrypte le password
			if (cryptedPassword != null && cryptedPassword.length() > 0) {
				String pwd = EncryptHelper.decryptData(secretKeyPassword, cryptedPassword);
				ds.setPassword(pwd);
			}
			// on decrypte le login
			if (cryptedUsername != null && cryptedUsername.length() > 0) {
				String username = EncryptHelper.decryptData(secretKeyUser, cryptedUsername);
				ds.setUsername(username);
			}
			// on set la taille initiale avec le minimum idle
			// on doit laisser le initialSize a 0 car il ne faut pas cree de connexion tout de suite car on a les identifiants cryptes.
			int minIdleSize = ds.getMinIdle();
			ds.setInitialSize(minIdleSize);
			ds.setConnectionProperties(ds.getConnectionProperties());

			// on ferme le pool deja parametre
			ds.close();
			// on recree le pool avec les nouveaux parametres
			ds.createPool();
			System.out.println("Initialisation de la datasource JNDI : OK");
			return ds;
		} else {
			System.out.println("Initialisation de la datasource JNDI : KO");
			return null;
		}
	}
}

Juste que la rien de difficile ^_^

2° Configuration JNDI

Extrait du fichier de configuration des ressources de Tomcat 6 (conf/context.xml)

    auth="Container" type="javax.sql.DataSource"
    factory="fr.cnvt.tomcat.Tomcat7EncryptedFactory"
    username="sD20tsCeFQPP3HuQV17yXw=="
    password="LoPCUiDWD47S6wIOTZWvBX7X9XTLt2vS9Sv52csoEGo="
    driverClassName="my.driver.class"
    url="my.jdbc.url"
    initialSize="0" maxActive="20" minIdle="5" maxIdle="10"
    validationQuery="SELECT 1 FROM Dual" validationQueryTimeout="300"
    maxWait="30000"
    removeAbandoned="true" removeAbandonedTimeout="600" logAbandoned="true"
    timeBetweenEvictionRunsMillis="20000"
    testWhileIdle="true"
    connectionProperties="CHARSET=utf8;" />

Comme vous pouvez le voir, le login (username) et le mot de passe (password) sont cryptés.

Vous pouvez avoir le même login et mot de passe (c’est bizarre comme c’est fréquent…) , les 2 chaines cryptés seront différentes (normal j’utilise 2 clés de cryptage différentes ^_^)

3° Librairies dans Tomcat

Dernières étapes, il suffit de copier les fichiers tomcat-datasource-factory-1.0.0.jar et tomcat-jdbc-7.0.22.jar(dans le répertoire lib du zip) dans le répertoire “lib” de Tomcat 6.

Voila en 3 copié-collé, vous avez un pool de connexion sans mot de passe en clair ^_^

Pour générer vos propres login et password cryptés, il suffit d’utiliser la classe EncryptHelper comme ceci:

	@Test
	public void generateEncryptedValues(){
		String login = "monsupertest";
		String password = "monsupertestaussi";
		String cryptedLogin = EncryptHelper.encryptData(SecuredFactory.secretKeyUser, login);
		String cryptedPassword = EncryptHelper.encryptData(SecuredFactory.secretKeyPassword, password);
		String decryptedLogin = EncryptHelper.decryptData(SecuredFactory.secretKeyUser, cryptedLogin);
		String decryptedPassword = EncryptHelper.decryptData(SecuredFactory.secretKeyPassword, cryptedPassword);
		assertEquals(login, decryptedLogin);
		assertEquals(password, decryptedPassword);
		System.out.println("Login crypte : " + cryptedLogin);
		System.out.println("Mot de passe crypte : " + cryptedPassword);
	}

Pour les curieux, le fichier zip contient également un pool DBCP et C3P0 qui gèrent aussi le login et mot de passe cryptés. Les clés de cryptages sont dans l’interface SecuredFactory.

Enjoy

Les sources sont disponibles ici

The post Tomcat 6 – JNDI – password crypté et pool de connexion V7 first appeared on In Fine - Le Blog.

Comparatifs de frameworks web à Devoxx 2011

Cet article a pour but de présenter brièvement la présentation de Stijn Van den Enden, lors du Devoxx 2011, sur les performances brutes de plusieurs frameworks connus et de partager quelques impressions sur ce sujet.

Dans la première partie, il présente la méthodologie de tests ainsi que les outils : le coté test.
Dans la seconde partie, il nous montre les résultats qu’il a obtenu : le coté performance.
Les slides de la présentation sont disponibles ici

En résumé, on y voit la mise en place de la plateforme de tests ainsi que les outils utilisés.

Plateforme de tests :

Conclusion :

Sa conclusion étant qu’en terme de performance brute, on a :

1. GWT
2. Spring MVC
3. JSF 2.1.2 (Implementation Mojarra) ou Wicket
4. MyFaces (n’apparait pas dans le slide)

Dans sa conclusion, qui n’apparait pas dans les slides, il dit aussi que souvent, ce n’est pas le framework web qui est la principale cause de la mauvaise performance d’une application.
Pendant sa présentation, il a souligné que le seul framework qui a posé problème est JSF 2 (problème de mémoire, ce qui ne m’étonne pas).
Enfin, il nous rappelle qu’il faut aussi penser à la facilité de développement pour garder une bonne productivité.

Avis personnel

Pour ma part, la conclusion de Stijn Van den Enden ne doit pas tenir compte du temps de rendu de la page, sinon Spring MVC serait 1er avec GWT voire même devant.

Sur le point où il faut privilégier la facilité de développement, on regrettera l’absence du comparatif des frameworks Grails et Play qui sont tous deux excellents sur ce point.

Si vous avez envie de changer de framework, d’après plusieurs présentations vu sur le même sujet (par exemple l’article de Peter Thomas), il faut se fixer un prototype de page à faire et si cela vous parait trop difficile, c’est que celui-ci n’est surement pas adapté à vos besoins.

Personnellement, je me demande pourquoi il y a tant de personnes qui démarrent un projet encore avec JSF pour le web alors qu’il a autant de problèmes de performance et qu’il est parfois si compliqué de faire des choses simples avec (exemple pagination coté serveur…).

Pour finir, son approche de Spring MVC est intéressante car elle tend vers une pratique que j’ai adopté. Pour ma part, j’ai abandonné l’idée que le Java était fait pour le web, car c’est loin d’être le cas. Je préfère juste garder Java pour la partie serveur et utiliser essentiellement des langages du web pour la vue : très peu de JSP et EL(Expression Language) avec beaucoup de HTML, CSS et JQuery (avec des données fournies au format JSON, d’ailleurs Spring MVC fait très bien cela).

S’il fallait choisir un framework pour le web en ce moment, je prendrai Grails pour un projet ‘from scratch’ ou Spring MVC pour un projet existant. Je n’ai pas assez d’expérience sur GWT mais sa génération du javascript me fait hésiter… Je garderai dans les deux cas, JQuery pour les composants riches car il existe énormément de plugins pour ce framework javascript ou ExtJS ou voir même du flash (flex).

En ce qui concerne Wicket, sa programmation ressemble un peu à du Swing (client lourd) qui pourrait dérouter un développeur web. Tapestry est intéressant mais le temps d’apprentissage est assez important.

Comparatif plus étendu

Pour ceux qui comme moi ont regretté l’absence de Grails et Play, voici un article intéressant avec un comparatif des deux et surtout une légère ‘customisation’ pour gagner en performance.
Notez que l’utilisation de Japid pour Play booste grandement ses performances et que Netty semble plus rapide que Tomcat.

Extrait du site JT Dev (vous pouvez cliquer sur les images pour les agrandir)

Plus de détails ici

The post Devoxx 2011 – Comparatif de performances des frameworks web Java et plus encore … first appeared on In Fine - Le Blog.

Ceylon est un nouveau langage s’exécutant sur la JVM. Il rejoint une liste désormais assez longue qui comprend notamment :

• Groovy
• Jython
• Jruby
• Scala
• Kotlin
• Fantom
• Gosu
• …

Gavin King a créé Ceylon parce qu’il était frustré par les limitations de Java. Cette session a été animée par deux français, Emmanuel Bernard et Stéphane Epardaud qui sont commiters sur le projet. Ils ont débuté la session en définissant les objectifs de Ceylon, avant de continuer sur ses fonctionnalités à l’aide de code. Je ne vais pas reproduire le code qu’ils ont utilisé pendant la présentation dans cet article, je vais essayer d’être plus concis.

Emmanuel commence par nous indiquer les objectifs de Ceylon :

• Permettre d’écrire du code plus simple que l’équivalent en java
• Éviter au développeur de tomber dans les principaux pièges de java

Ceylon est pensé pour être lu facilement par des développeurs venant du monde Java. Emmanuel insiste bien sur ce point : Ceylon doit être simple à utiliser mais également simple à lire. Le code ne doit pas soulever d’ambiguïté.

Principes de base

Classe simple

shared class User(String username, Natural age) {
    shared String username = username;
    shared Natural age = age;

    shared void printUser() {
        print("User name : " username " with age " age " is printed");
    }
}

Cette classe est courte, mais il y a déjà plusieurs choses à dire dessus :

• Le mot-clé class indique évidemment qu’il s’agit d’une déclaration de classe
• Le mot-clé shared est l’équivalent du public de Java. Si le mot-clé shared est omis, alors la visibilité est privée (visibilité par défaut en Ceylon)
• A la suite de la déclaration de la classe User se trouvent des paramètres (String username, Natural age), il s’agit de la déclaration du constructeur. Je dis bien du car une Ceylon interdit la surcharge de méthode et donc un seul constructeur est autorisé
• Natural est l’objet représentant un nombre entier naturel. En Ceylon, il n’y a pas de type primitif
• Les attributs de la classe sont obligatoirement initialisés, il n’y a pas de valeur par défaut, même null n’est pas implicite. Ici, les valeurs sont celles fournies au constructeur
• La déclaration de la méthode printUser se fait comme en Java, le mot-clé shared en plus si on souhaite l’exposer
• La concaténation de chaîne de caractère peut se faire sans le caractère +. La concaténation avec le caractère + fonctionne également

Méthodes

shared class Parent() {
    shared default void printMe() {
         print("I'm in parent class");
    }

    shared void printMessage(String messageToPrint = "default argument value") {
         print("I'm in parent class and I print " + messageToPrint);
    }
}

shared class Child() extends Parent() {
    shared actual void printMe() {
         print("I'm in child class");
    }
}

void testCeylon() {
    // appel de méthodes
    Parent p = Parent();
    p.printMe();
    p.printMessage(); // default value of parameter used - will work on milestone 2
    p.printMessage("message given as argument");  // classic call
    p.printMessage {  // name argument used
        messageToPrint = "message with named arguments";
    };
}

Encore une fois, malgré la petite taille de code et sa lisibilité, plusieurs fonctionnalités sont à décrire :

• Comme dit plus haut, les méthodes ne sont pas surchargeables. Pour palier à cette obligation les paramètres peuvent avoir des valeurs par défaut (ligne 6), des varargs peuvent être utilisés (comme en java), ou des union types peuvent être utilisés (voir la doc pour plus de détails)
• Les paramètres des méthodes sont nommés – ligne 22
• Les méthodes peuvent être redéfinies dans les classes filles mais il faut l’autoriser explicitement grâce au mot clé default dans la classe parent (équivalent du virtual du C++ utilisé dans la classe parent) – ligne 2
• Lors de la rédéfinition de la méthode dans une classe fille, il faut obligatoirement utiliser le mot-clé actual (équivalent à l’annotation @Override de Java) – ligne 12

null et immuabilité

Par défaut toutes les variables sont immuables en Ceylon. Afin de les rendre modifiables il faut explicitement adapter la syntaxe de déclaration d’une variable en ajoutant le mot-clé variable et effectuer l’affectation avec l’opérateur := :

shared class ImmutableExample(Natural year) {
    // immutable
    Natural year = year;
    // Mutable
    variable Natural writableYear := year;
}

Afin d’éviter les trop nombreux NullPointerException de Java, une variable qui pourrait contenir la valeur null doit être déclaré à l’aide d’un ?. Ceci a des conséquences sur la manière d’utiliser ces variables comme le montre le code ci-dessous :

// myBestVariable can be null
String? myBestVariable = functionThatCanReturnNull();
// to work on myBestVariable, a null check must be done
if (exists myBestVariable) {
    functionThatNeedAString(myBestVariable);
}
else {
    functionThatNeedAString("default value");
}

Autres fonctionnalités

Emmanuel et Stéphane ont présenté d’autres fonctionnalités importantes de Ceylon telles que les union type et les intersection type. Pour plus de détails, reportez vous à la documentation officielle.
Malgré les arguments nommés, il est possible d’utiliser les generics. Les annotations sont également disponibles.
La compatibilité entre Java et Ceylon est également disponible. Ceylon peut utiliser du code écrit en Java, et Java peut appeler du code Ceylon.

En pratique

Emmanuel et Stéphane, après avoir transmis les bases à l’auditoire, effectuent une démo en live de Ceylon dans Eclipse. Un plugin Eclipse a été développé et est déjà fontionnel. L’autocomplétion fonctionne bien, la coloration syntaxique et le refactoring également. Plus d’infos sur le repo git associé.

Aucune version de Ceylon n’a encore été releasée. La prochaine version à sortir sera la milestone 1 qui ne comprendra pas encore toutes les fonctionnalités de la spécification. Trois milestones sont prévues avant que la version 1.0 ne sorte.

Test de Ceylon

Il est évidemment possible aujourd’hui de tester dès aujourd’hui Ceylon et pour cela, j’ai réalisé un petit screencast afin de vous montrer qu’avoir le compilateur Ceylon utilisable sur son poste est vraiment simple et rapide.

Les prérequis sont d’avoir sur sa machine Java 6, Ant et Git. Dans le screencast, je clone les trois repositories Git nécessaires à la création du compilateur. Chacun nécessite Ant afin d’être compilé. Une fois le compilateur généré, je le teste en compilant l’exemple de code que j’ai donné ci-dessus dans le paragraphe Méthodes, et je l’exécute.

Pour ceux qui veulent tester, je vous retranscrits les commandes utilisées dans le screencast afin de faciliter le copier coller

Une fois le compilateur généré, je l’ai testé. Mon fichier source se nomme florian_boulay.ceylon et se trouve dans le répertoire samples. Le répertoire build contient les fichiers Ceylon compilés. testCeylon correspond au nom de la fonction appelée pour lancer le programme.

Ceylon est un langage simple à comprendre pour qui vient de Java. En écrire est également à la portée de tous. Jusque là les objectifs de Gavin King sont atteints.

Fin de la session

Pour finir, Emmanuel nous indique que Ceylon a enfin sont site web : http://ceylon-lang.org

Il contient une documentation très complète, la spécification du langage écrite par Gavin King, un blog et tout ce qu’il faut pour contribuer au développement du langage. C’est là bas qu’il faut aller si vous souhaitez tester le langage qui n’a pas encore été releasé, mais peut être testé via la récupération du code source sur Github.

Comme vous le voyez, le logo de Ceylon est un éléphant, est-ce un hommage à PHP ? On peut lui souhaiter qu’il ait le même succès que PHP

De nombreux nouveaux langages ont émergé ces derniers mois fonctionnant sur la JVM (Eclipse Xtend, JetBrains Kotlin). Comme dit plus haut, Ceylon veut rester accessible à tout le monde en restant simple et facilement compréhensible. Est-ce que ces atouts seront suffisants pour faire de Ceylon une alternative à Java réellement utilisée, comme l’est Scala aujourd’hui ? Faites vous votre propre opinion et essayez le.

The post Devoxx 2011 – Ceylon first appeared on In Fine - Le Blog.

Les fondamentaux

En java, la comparaison s’effectue principalement en utilisant 3 méthodes qui n’ont pas les mêmes buts :

1. L’opérateur == est utilisé pour comparer les types primitifs et les objets. Il compare uniquement les références. Cela signifie que l’opérateur retournera “true” uniquement si les 2 objets comparés sont les mêmes en mémoire.
2. La méthode ‘equals()’ permet de comparer 2 objets. Toutes les classes ont une méthode ‘equals()’ héritée de la classe Object. Cette méthode compare la valeur de 2 objets. S’ils représentent la même chose, alors la méthode doit renvoyer “true”. Cette méthode est plus difficile qu’il n’y paraît à implémenter. Je pourrais revenir dessus ultérieurement dans un prochain article.
3. La méthode ‘compareTo()’ permet de comparer 2 objets comme la méthode ‘equals()’. Contrairement à ‘equals()’, les classes ne définissent pas toutes cette méthode. Pour cela il faut hériter de l’interface Comparable. Cette méthode est utilisée pour pouvoir trier les objets l’implémentant. Si les 2 objets sont égaux, alors la méthode doit renvoyer 0 ; si un object O1 est considéré précédent un autre object O2 alors il faut renvoyer -1, si O2 précède O1 alors il faut renvoyer 1.

int i = 5, j = 5, k=8;
Integer int1 = new Integer(42) ;
Integer int2 = new Integer(42) ;
String str1 = "Blog";

java.util.Date t1 = new java.util.Date();
Thread.sleep(1000l);
java.util.Date t2 = new java.util.Date();

System.out.println (i == j); // print true
System.out.println (int1 == int2); // print false
System.out.println ("Blog".equals(str1)); // print true
System.out.println (str1 == "Blog"); // déconseillé mais écrit true
System.out.println (t1.compareTo(t2)); // print -1

Les comparaisons faites avec ‘equals()’ ou ‘compareTo()’ entre une variable et une constante doivent être réalisées comme à la ligne 13 de l’exemple précédent, c’est-à-dire qu’il faut comparer la constante avec la variable à tester. Ceci permet d’éviter une potentielle NullPointerException si l’on faisait ‘str1.equals(“Blog”)’.

Le cas particuliers des enum

Depuis java 5, les enum ont été introduits dans java. Les enum pourraient faire l’objet d’un article complet, mais il est bon de savoir que les enum ont été créés pour être comparés avec l’opérateur ‘==’. N’hésitez donc pas à les utiliser ! En plus d’être très lisibles, ils sont performants à l’usage.

Les performances unitaires

Si on a le choix, quel opérateur/méthode utiliser pour faire la comparaison ? Un des critères de choix peut être la performance. Sur une application où les comparaisons sont très nombreuses, il peut être judicieux d’optimiser les comparaisons et donc de choisir en connaissance de cause.

Voici le petit programme qui m’a permis de tester les performances de chacun. Dans la boucle j’ai utilisé une des instructions en commentaire à chaque test :

long start = System.currentTimeMillis();
for (long l = 0; l < 2 << 60; l++) {
    // "1".equals("1");
    // if ("1" == "1") ;
    // "1".compareTo("1");
}
long end = System.currentTimeMillis();
long timePassedInMs = end - start;
&#91;/sourcecode&#93;

Sans surprise les résultats sont les suivants :
<ul>
	<li><strong>==</strong> : 978 ms de moyenne</li>
	<li><strong>equals()</strong> : 991 ms de moyenne, soit 1.35 % que ==</li>
	<li><strong>compareTo()</strong> : 1004 ms de moyenne, soit 2.62% de plus que ==</li>
</ul>
Quelques remarques sur ces résultats :
<ol>
	<li>La première instruction de la méthode 'equals()' de la classe String est de tester que les 2 objets comparés ont la même référence grâce à l'opérateur ==. La différence de temps entre == et 'equals()' s'explique donc uniquement par l'appel de la méthode et le retour de cette méthode. La différence vient aussi en partie du fait que la JVM va inliner la méthode 'equals()' et que ceci prend un certain temps.</li>
	<li>'compareTo()' de la classe String effectue plusieurs boucles et de nombreux tests. Il est tout à fait logique qu'elle soit plus lente que les 2 autres comparateurs. Elle n'est pas optimisée pour gagner du temps comme l'est 'equals()'.</li>
</ol>
Ces quelques tests montrent bien que faire un == est plus rapide que l'appel d'un 'equals()', même si dans le cas de la classe String la différence est faible. Si vous avez le choix, privilégiez donc le == à 'equals()', même si les performances ont l'air très proches. Il peut arriver que vous utilisiez du code que vous ne pouvez pas modifier (API, framework, librairie partagée...) et dans ce cas la méthode 'equals()' peut être mal écrite et donc bien plus lente qu'elle ne l'est pour la classe String. Mais la question est la suivante : comment faire pour avoir le choix entre == et 'equals()' ? Je vais essayer de vous montrer une manière d'avoir le choix un peu plus loin dans ce post, après vous avoir expliqué un peu plus en détail comment fonctionne la classe String.

Nous laissons de côté 'compareTo()' pour la fin du post, car elle n'a pas la même utilité que les 2 autres méthodes de comparaison.
<h2>Le cas de la classe String</h2>
Comme nous l'avons vu au début du post, les String doivent être comparés à l'aide de la méthode 'equals()'. Cependant il est tentant de vouloir utiliser l'opérateur == plus rapide et renvoyant quasiment tout le temps le même résultat que la méthode 'equals()'.

La classe String a beaucoup de particularités : c'est la seule classe que l'on peut initialiser sans appel explicite à un constructeur ou méthode statique ; elle possède des opérateurs surchargés... et d'autres spécificités encore. Une de ses particularité est que la JVM garde un pool d'instances des objets String. Ainsi, si deux String sont initialisés avec la même valeur, alors la JVM utilisera le même objet. Mais ce n'est pas vrai dans tous les cas. Regardons cet exemple :

[sourcecode language="java"]
final String TEST_VALUE = "infine";

String inPool = "infine";
String inPool2 = "in" + "fine";
String noPool = new String("infine");
String suffix = "fine";
String noPool2 = "in" + suffix;

System.out.println(inPool == TEST_VALUE);  // true
System.out.println(inPool2 == TEST_VALUE);  // true
System.out.println(noPool == TEST_VALUE);  // false
System.out.println(noPool2 == TEST_VALUE);  // false

En voyant les résultats, vous comprenez pourquoi il ne faut pas utiliser l’opérateur == pour la comparaison de String, le résultat est trop incertain. Lorsqu’un objet String est créé en utilisant l’opérateur new (comme pour un objet “normal” en fait), alors la JVM ne renvoie pas un objet String du pool, mais crée un nouvel objet (cas de l’objet “noPool”). De plus, si un objet String est calculé à l’exécution, par une concaténation par exemple, alors il n’est pas créé à partir du pool (cas de l’objet “noPool2”).

Pour se rendre compte de la manière dont le compilateur gère les String, voici un extrait du bytecode généré obtenu avec la commande javap :

0:	ldc	#16; //String infine
2:	astore_1
3:	ldc	#16; //String infine
5:	astore_2
6:	ldc	#16; //String infine
8:	astore_3

Dans cet extrait, nous voyons que 3 variables font référence au même objet String valant “infine” (matérialisé par la référence #16). Ces 3 variables sont dans le code précédent TEST_VALUE, inPool et inPool2. Elles sont déclarées différemment mais le compilateur ne crée qu’une seul référence dans le pool de String de la JVM.

Si on souhaite forcer la récupération d’un objet String à partir du pool, alors il faut utiliser la méthode ‘intern()’. Reprenons l’exemple ci-dessus, mais en utilisant la méthode ‘intern()’ :

final String TEST_VALUE = "infine";

String inPool = "infine";
String inPool2 = "in" + "fine";
String noPool = new String("infine");
String suffix = "fine";
String notPool2 = "in" + suffix;

System.out.println(inPool == TEST_VALUE);  // true
System.out.println(inPool2 == TEST_VALUE);  // true
System.out.println(noPool.intern() == TEST_VALUE);  // true !
System.out.println(notPool2.intern() == TEST_VALUE);  // true !

Pour en savoir plus, n’hésitez pas à chercher String literal pool dans votre moteur de recherche préféré.

Étude de cas : == doit renvoyer la même chose que equals()

La classe String arrive bien à faire que dans certains cas == et ‘equals()’ renvoient le même résultat. Nous allons donc essayer de faire mieux ! Nous allons donc partir d’un exemple simple dans lequel == et ‘equals()’ ne sont pas interchangeables. Enfin, nous allons modifier le code afin d’utiliser == pour chaque comparaison, ceci dans le but d’avoir de bonnes performances, et une meilleure gestion de la mémoire.
Bien entendu, nous pourrions gagner des performances de plein de manières différentes, mais ce n’est pas le but de cet article.

Présentation du code existant

Voici une classe permettant de gérer des couleurs RGB. Elle est donc composée de 3 attributs pouvant avoir une valeur comprise entre 0 et 255 chacun. Voici une partie du code de la classe avec son constructeur :

public class RgbColor {

    private final int green;
    private final int red;
    private final int blue;

    public RgbColor(int green, int red, int blue) {
        super();
        this.green = green;
        this.red = red;
        this.blue = blue;
    }

    // ...other methods, including hashcode() and equals()
}

Comme nous le voyons, cette classe possède un unique constructeur. Il est donc possible de créer autant d’objet de type RgbColor que nous voulons, et s’ils sont identiques nous seront obligés de les comparer avec ‘Equals()’ car chaque objet RgbColor sera différent.
Ce constructeur est l’équivalent du ‘String test = new String(“test”)’ vu précédemment dans ce post. Un appel crée toujours un objet.

Pool de gestion des instances

La version améliorée ajoute une nouvelle méthode statique. Cette méthode permet de créer un objet s’il n’existe pas encore dans le pool, ou alors de renvoyer l’objet existant si il a déjà été créé auparavant. Ce pattern est appelé static factory pattern, et est très bien décrit dans le livre Effective Java de Josh Bloch.

public class RgbColor {

private final int green;
private final int red;
private final int blue;
// pooling
private static Map pool = new ConcurrentHashMap();

/**
* Values must be between 0 and 255.
*
* @param green
* @param red
* @param blue
* @return
*/
public static RgbColor getColor(int green, int red, int blue) {
if (!isAllowedColorValue(green) || !isAllowedColorValue(red) || !isAllowedColorValue(blue)) {
throw new IllegalArgumentException(“Allowed color value is between 0 and 255”);
}
// same key as hashcode
int key = green << 16 | red << 8 | blue; if (pool.containsKey(key)) { return pool.get(key); } RgbColor color = new RgbColor(green, red, blue); pool.put(key, color); return pool.get(key); } private static boolean isAllowedColorValue(int color) { if (color < 0 || color > 255) {
return false;
}
return true;
}

private RgbColor(int green, int red, int blue) {
super();
this.green = green;
this.red = red;
this.blue = blue;
}

@Override
public boolean equals(Object obj) {
if (this == obj)
return true;
if (obj == null)
return false;
if (getClass() != obj.getClass())
return false;
RgbColor other = (RgbColor) obj;
if (blue != other.blue)
return false;
if (green != other.green)
return false;
if (red != other.red)
return false;
return true;
}

@Override
public int hashCode() {
return green << 16 | red << 8 | blue; } // ...other methods } [/sourcecode] La méthode statique 'getColor()' permet de gérer un pool de toutes les instances de la classe RgbColor. De plus le constructeur est devenu privé, ce qui oblige l'utilisateur de cette classe à construire un object avec la méthode 'getColor()'. Contrairement à la classe String, tous les objets seront donc comparable avec l'opérateur == car un objet unique est créé par triplet rouge, vert, bleu. Elle est l'équivalent de la construction d'un object String sans constructeur : String test = "test"; Je ne vous joins pas de classe de test, mais les performances sont désormais améliorées car toutes les instances de RgbColor sont comparables avec l'opérateur ==. La mémoire est également mieux gérée car toutes les instances se retrouvent dans le pool. On pourrait encore améliorer cette classe, en remplaçant la 'ConcurrentHashMap' par une SoftHashMap par exemple, avec un peu d’adaptation du code.

Fichiers joints
Code source utilisé pour faire ce post : Archive zip

The post “==”.equals(“equals()”) first appeared on In Fine - Le Blog.

On n’y croyait plus, mais c’est arrivé ! Oracle vient de présenter à JavaOne ses projets pour Java SE et la communauté. Plusieurs points à retenir :

– openJDK plus que jamais d’actualité, avec 2 releases majeures prévues en 2011 et 2012 qui seront la base pour JDK7 & JDK8
– Fusion du meilleur de jrockit et hotspot
– JDK et JRE restent gratuit (!) avec la même license

Les interminables débats pour savoir si telle ou telle fonctionnalité  devait être intégrée dans la version 7 sont derrière nous. Pour ceux qui attendaient les closures (lambda expression), la modularité (jigsaw) ou encore le framework swing, on sait désormais que ça ne sera pas pour la version 7, et rien n’est promis pour la version 8.
Pour la liste complètes des fonctionnalités , c’est par ici

The post Java, enfin une roadmap ! first appeared on In Fine - Le Blog.