Lorsque l’on met en place les mocks, il est fréquent que l’on ait besoin de tester qu’un objet créé à l’intérieur de la méthode testée correspond bien à ce que l’on attend, cet objet étant passé en tant que paramètre à une méthode d’un objet mocké.

Prenons pour exemple, la classe Service et sa méthode processRequest. La méthode processRequest prend en entrée deux paramètres et se sert de ces paramètres pour créer un objet Bond, qui sera passé ensuite à la méthode persist du service BondDao.

package fr.java.freelance.easymock;

import java.math.BigDecimal;

public class Service {
	private BondDao bondDao;

	public String processRequest(String name,BigDecimal quantity) {
		Bond bond = new Bond(name,quantity);
		return bondDao.persist(bond);
	}

	public void setBondDao(BondDao bondDao) {
		this.bondDao = bondDao;
	}
}

package fr.java.freelance.easymock;

public interface BondDao {
	String persist(Bond bond);
}

package fr.java.freelance.easymock;

import java.math.BigDecimal;

public class Bond {
	private String name;
	private BigDecimal quantity;

	public Bond(String name, BigDecimal quantity) {
		super();
		this.name = name;
		this.quantity = quantity;
	}
	public String getName() {
		return name;
	}
	public BigDecimal getQuantity() {
		return quantity;
	}
}

Il est a priori impossible pour un test unitaire d’accèder à l’objet « bond » pour le vérifier.

Ce que l’on cherche à garantir, c’est que la méthode processRequest construit un objet de type Bond ayant comme attributs name et quantity les 2 valeurs passées en paramètres, qu’elle le transmet à la méthode persist de ServiceDao et retourne le paramètre de retour de cette méthode persist.

Utilisation d’EasyMock.anyObject()

La première méthode pour tester ceci est d’utiliser la méthode anyObject de l’objet EasyMock.

Service service = new Service();
BondDao bondDaoMock = EasyMock.createMock(BondDao.class);
service.setBondDao(bondDaoMock);

final String persist_return = "123AX";
final String name = "Name 5%";
final BigDecimal quantity = BigDecimal.TEN;

EasyMock.expect(bondDaoMock.persist((Bond) EasyMock.anyObject()))
.andReturn(persist_return);

EasyMock.replay(bondDaoMock);
String idInternal = service.processRequest(name, quantity);
Assert.assertEquals(persist_return,idInternal);
EasyMock.verify(bondDaoMock);

Le test fonctionne, néanmoins rien ne garantit que l’objet que l’on transmet à la méthode persist de BondDao est confirme à ce que l’on attend.

Pour pouvoir analyser l’objet Bond transmis, il existe plusieurs possibilités, dont une utilisant la redéfinition de la méthode equals de l’objet Bond et deux fournies par la librairie EasyMock, l’utilisation d’un IArgumentMatcher ou de EasyMock.capture.

Rédéfinition de la méthode equals()

Supposons que l’objet bond redéfinisse la méthode equals de manière à tester l’égalité des paramètres name et quantity.

	@Override
	public boolean equals(Object obj) {
		if (this == obj)
			return true;
		if (obj == null)
			return false;
		if (getClass() != obj.getClass())
			return false;
		Bond other = (Bond) obj;
		if (name == null) {
			if (other.name != null)
				return false;
		} else if (!name.equals(other.name))
			return false;
		if (quantity == null) {
			if (other.quantity != null)
				return false;
		} else if (quantity.compareTo(other.quantity)!=0)
			return false;
		return true;
	}

Il suffit alors d’écrire le test suivant pour garantir que l’objet passé à la méthode persist est bien égal au bond attendu :

        @Test
	public void testProcessRequestWithEquals() {
		Service service = new Service();
		BondDao bondDaoMock = EasyMock.createMock(BondDao.class);
		service.setBondDao(bondDaoMock);

		final String persist_return = "123AX";
		final String name = "Name 5%";
		final BigDecimal quantity = BigDecimal.TEN;
		final Bond bondExpected = new Bond(name,quantity);

		EasyMock.expect(bondDaoMock.persist(bondExpected))
				.andReturn(persist_return);
		EasyMock.replay(bondDaoMock);
  	        String idInternal = service.processRequest(name, quantity);
		Assert.assertEquals(persist_return,idInternal);
		EasyMock.verify(bondDaoMock);
	}

Cette démarche est la plus naturelle, néanmoins elle ne s’applique pas dans le cas où la méthode equals n’est n’est pas redéfinie (dans ce cas, c’est la méthode equals de Object qui est prise en compte et donc, les deux objets ne seraient pas égaux (pas la même instance)). Elle ne s’applique pas non plus dans le cas où la méthode equals ne correspondrait pas à ce que l’on à définit comme étant utile pour tester l’égalité. Par exemple une méthode equals qui ne testerait que l’égalité de l’attribut name dans l’objet Bond alors que nous souhaitons garantir les valeurs des deux paramètres. On ne peut évidement pas modifier la méthode equals d’un objet pour le tester, cela changerai son comportement !!
Il faut donc se tourner vers d’autres solutions.

Utilisation d’un IArgumentMatcher

EasyMock permet d’utiliser un certain nombre de matcher déjà définit ( eq, isNull, matches ..). Néanmoins dans le cas présent, il nous faut définir notre propre matcher pour pouvoir tester l’égalité des paramètres name et quantity.
La redéfinition d’un matcher s’effectue en deux temps.
D’abord, il faut créer une classe implémentant IArgumentMatcher.

package fr.java.freelance.easymock;

import org.easymock.EasyMock;
import org.easymock.IArgumentMatcher;

public class BondEquals implements IArgumentMatcher {
	private final Bond expected;

	public BondEquals(Bond expected) {
		this.expected = expected;
	}

	public boolean matches(Object obj) {
		if (this == obj)
			return true;
		if (obj == null)
			return false;
		if (expected.getClass() != obj.getClass())
			return false;
		Bond other = (Bond) obj;
		if (this.expected.getName() == null) {
			if (other.getName() != null)
				return false;
		} else if (!this.expected.getName().equals(other.getName()))
			return false;
		if (this.expected.getQuantity() == null) {
			if (other.getQuantity() != null)
				return false;
		} else if (this.expected.getQuantity().compareTo(other.getQuantity()) != 0)
			return false;
		return true;
	}

	public void appendTo(StringBuffer buffer) {
		buffer.append("eqException ").append(expected.toString());
	}

	public static Bond eqBond(Bond in) {
	    EasyMock.reportMatcher(new BondEquals(in));
	    return null;
	}
}

Pour pouvoir utiliser le BondEquals ainsi crée, la méthode persist de l’interface BondDao n’acceptant que les objets de type Bond, on utilise l’astuce suivante :

public static Bond eqBond(Bond in) {
	    EasyMock.reportMatcher(new BondEquals(in));
	    return null;
	}

On peut alors utiliser le test suivant, pour garantir d’une part le bon retour de la méthode processRequest ainsi que le passage du bond ayant les caractéristiques souhaitées à la méthode persist du BondDao.

        @Test
	public void testProcessRequestWithArgumentMatcher() {
		Service service = new Service();
		BondDao bondDaoMock = EasyMock.createMock(BondDao.class);
		service.setBondDao(bondDaoMock);

		final String persist_return = "123AX";
		final String name = "Name 5%";
		final BigDecimal quantity = BigDecimal.TEN;

		final Bond bondExpected = new Bond(name,quantity);
		EasyMock.expect(bondDaoMock.persist(BondEquals.eqBond(bondExpected)))
				.andReturn(persist_return);
		EasyMock.replay(bondDaoMock);
		String idInternal = service.processRequest(name, quantity);
		Assert.assertEquals(persist_return,idInternal);
		EasyMock.verify(bondDaoMock);
	}

Utilisation de org.easymock.Capture

Une autre méthode consiste à capturer l’objet bond passé à la méthode persist du DAO et de faire des tests dessus dans un deuxième temps.
Une capture s’effectue en 3 temps.
1. Déclaration de la capture : Capture capture = new Capture();
2. Capture du paramètre lors de l’exécution via : EasyMock.expect(bondDaoMock.persist(EasyMock.and(EasyMock.isA(Bond.class), EasyMock.capture(capture))))
3. Récupération de l’objet capturé : Bond captured = capture.getValue();

	@Test
	public void testProcessRequestWithCapture() {
		Service service = new Service();
		BondDao bondDaoMock = EasyMock.createMock(BondDao.class);
		service.setBondDao(bondDaoMock);

		final String persist_return = "123AX";
		final String name = "Name 5%";
		final BigDecimal quantity = BigDecimal.TEN;

               Capture capture = new Capture();

		EasyMock.expect(bondDaoMock.persist(EasyMock.and(EasyMock
                          .isA(Bond.class), EasyMock.capture(capture))))
                .andReturn(persist_return);

		EasyMock.replay(bondDaoMock);
		String idInternal = service.processRequest(name, quantity);
		Assert.assertEquals(persist_return,idInternal);

		Bond captured = capture.getValue();
		Assert.assertEquals(name,captured.getName());
		Assert.assertTrue(quantity.compareTo(captured.getQuantity())==0);
		EasyMock.verify(bondDaoMock);
	}

Il existe également d’autres méthodes utilisant des outils externes pour atteindre un but similaire mais je n’ai pas encore trouvé de limitation à la création d’un nouveau matcher ou la capture de l’élément à tester. Si il y a besoin plusieurs fois de tester l’objet de manière identique, j’ai tendance à créer un nouveau matcher et à utiliser la capture dans le cadre d’objets plus petits ou de besoin spécifique à un test.

Les actions menées en France seront de plusieurs types :
- La création d’un réseau virtuel, via twitter, linkedin, une mailing list …
- Inciter les femmes à participer à des évènements locaux, comme les soirées JUG ou les autres conférences.
- Se rencontrer pour échanger, avant ou après les soirées JUGs, autour d’un apéro ou d’un repas.
- Lister les différents évènements en France pour ne pas les rater et éventuellement trouver quelqu’un avec qui y aller.

Pour se tenir informer des évènements de ce groupe, vous pouvez nous rejoindre sur twitter @duchessfr , sur LinkedIn ou via notre mailing list.

Le premier évènement aura lieu le 9 mars à 18h30 , juste avant le paris JUG au Vavin Café (18 rue Vavin 75006 Paris). Lorsque vous serez inscrites au JUG, contactez ellene(dot)dijoux(at)jduchess(dot)org qui vous accueillera Mardi prochain.

Le Paris JUG c’est aussi une ‘troisième mi-temps’ dans un bar-resto après la soirée. Me retrouver après les confs pour discuter avec des passionnés sur des sujets variés (mise en place de pair programming, Groovy, se lancer en freelance …) est vraiment une composante importante de mon intérêt pour le Paris JUG !

Pour la soirée d’hier, les choses avaient été faites en grand : amphi de 500 places, bien rempli, goodies, présence de stands, buffet, énormément de gens venus de partout dont pas mal rencontrés à Devoxx. Au niveau des sujets, la keynote d’ouverture de Sacha Labourey abordait le thème ‘la révolution open-source a t elle eu lieu ?’. Se sont suivis ensuite quelques questions/réponses à Sacha et Marc Fleury, invité surprise de la soirée et fondateur de Jboss.  La notion de ‘passion’ a pour la première fois été abordée et il faut reconnaître, et tous les intervenants l’ont fait lors de la soirée, que s’investir dans l’open-source est chronophage et avant tout, une affaire de passion.

Quelques business models de projets Open Source (Acceleo, XWiki, eXo Platform) ont  été présentés sur la forme de quickies par les différents acteurs de ces projets, permettant de donner des exemples concrets à la keynote plus générale de Sacha. Des  outils open-source (jCaptcha, jax-doclets, Play!) ont eu également le droit à leurs quickies, plus techniques.

Jean-Michel Doudoux, architecte Sfeir Benelux , a également parlé de son travail de rédaction et du choix de la license autour de Développons en Java, quelques 1888 pages en français, le tout sur 10 ans, mis à jour désormais 3 à 4 fois par ans et qui correspond à une véritable bible, en français sur le langage Java : http://www.jmdoudoux.fr/accueil_java.htm#dej . Les prochaines évolutions seront sur JEE, Android ! Un travail titanesque pour lequel il a choisit la license GNU FDL, bien conscient des problèmes pour faire valoir ses droits dès que l’on publie sur le net.

La présentation sur le framework Play!  était vraiment bien mené et a éveillé pas mal les curiosités ! Ce framework web, fait par des développeurs web constitue une alternative pour développer sur une architecture REST. Ce framework permet entre autre un rechargement à chaud (la démo est faite via un simple éditeur de texte), le code modifié impactant immédiatement l’appli web, un système de gestion des exceptions à l’écran, un système de templating, avec la possibilité de créer ses propres tags ou d’utiliser le système d’expression langage de groovy et beaucoup d’autres choses encore.

Pour avoir plus d’infos : http://www.playframework.org/

Pour avoir le détail des conférences, Olivier Croisier a très bien retranscrit tout le détail dans son blog http://thecodersbreakfast.net/index.php?post/2010/02/05/Suivez-le-Paris-JUG-anniversaire-en-live !

La troisième mi-temps s’est déroulé au Dome dans le 17ème avec petits fours.  J’ai eu l’occasion de discuter avec Nicolas Leroux (contributeur) et Guillaume Bort (lead developper) autour de Play! , principalement sur l’utilisation en industrie et des questions plus techniques.  On en a également profité pour parler d’un projet de réseautage de la communauté féminine de Java, j’en parlerai plus en détail quand cela sera avancé mais c’était agréable de voir du monde réunis autour de la table !

Comparaison avec == sur des java.lang.Integer

Le problème, c’est que sur des integers entre -128 et 127, cela peut marcher.  Dans la suite de l’exemple, integer1 et integer2 seront de type java.lang.Integer, int1 sera de type primitif int.

        Integer integer1 = 127;
        Integer integer2 = 127;
        System.out.println(integer1 == integer2); // true

        integer1 = 128;
        integer2 = 128;
        System.out.println(integer1 == integer2); // false

Par contre, on a bien pour toutes les valeurs, y compris celles entre -128 et 127 :

integer1 = new Integer(127);
integer2 = new Integer(127);
System.out.println(integer1 == integer2); // false - normal on a instancié 2 objects différents

integer1 = new Integer(129);
int1 = 129;
System.out.println(integer1 == integer2); // true

Si on regarde la doc de Sun, pour tous les objets entre -128 et 127, l’autoboxing garantit que l’objet renvoyé Integer sera identique pour un même entier primitif. Ce qui ne sera pas le cas au delà de l’intervalle. De plus, rien ne garantit qu’une implémentation étende l’intervalle de cache, raison pour laquelle il est risqué de se baser dessus.
Byte,  Short,  Long ont également le même type de cache. Character a également un cache mais de 0 à 127 (un nombre négatif n’aurait pas eu de sens).

d. Autoboxing is guaranteed to return the same object for integral
values in the range [-128, 127], but an implementation may, at its
discretion, cache values outside of that range. It would be bad style

http://java.sun.com/developer/JDCTechTips/2005/tt0405.html#1

Ainsi, utiliser == en se fiant à l’autoboxing et au cache est une mauvaise pratique, même pour comparer des constantes de faible valeur.

Utiliser plutôt valueOf()  plutôt que new

Il est préferable d’utiliser un valueOf plutôt qu’une nouvelle instanciation à l’aide du constructeur. Valable pour la certains objets immutables.

Exemple avec des types java.lang.Integer, si on regarde la javadoc pour la méthode Integer.valueOf(int i) :

public static Integer valueOf(int i)

Returns a Integer instance representing the specified int value. If a new Integer instance is not required, this method should generally be used in preference to the constructor Integer(int), as this method is likely to yield significantly better space and time performance by caching frequently requested values.

Idem pour les Byte, Long, Character, BigInteger … Par contre, préférer quand c’est possible de construire les valeurs accessibles directement via une méthode statique (BigInteger.ONE plutôt que BigInteger.valueOf(1), Boolean.FALSE plutôt que Boolean.valueOf(false) …)

Éviter d’utiliser new String

String test1 = "abc";
String test2 = "abc";
String test3 = new String("abc");
String test4 = new String("abc");

System.out.println(test1 == test2); // true
System.out.println(test1 == test3); //false
System.out.println(test3 == test4); //false

Utiliser new String implique de créer un nouvel object en mémoire. Les String étant immutables, avoir 2 objets différents ayant la même valeur ne fait que consommer de la mémoire. Attention à bien noter le cas 2, « abc » est différent de new String(« abc »).  Cet exemple permet également de montrer l’importance d’utiliser la méthode equals pour comparer les valeurs des objets java.lang.String .

Comme précisé par Jérôme et Nicolas Le Coz en commentaire, l’instanciation d’un nouvel objet String est conseillée lors de l’utilisation de substring sur des très grandes chaînes de caractères. En effet, la valeur stockée avec un substring n’est pas uniquement la substring, mais la chaîne entière avec un offset (premier caractère à utiliser) et un compteur (nombre de caractères à utiliser).

C’est clair si l’on regarde la classe java.lang.String

  public final class String
  	implements java.io.Serializable, Comparable, CharSequence
  {
  /** The value is used for character storage. */
  private final char value[];

  /** The offset is the first index of the storage that is used. */
  private final int offset;

  /** The count is the number of characters in the String. */
  private final int count;
[...]
public String substring(int beginIndex, int endIndex) {
 [...]
 return ((beginIndex == 0) && (endIndex == count)) ? this :
 new String(offset + beginIndex, endIndex - beginIndex, value);
 }

Plus d’infos ici http://blog.xebia.fr/2009/08/03/revue-de-presse-xebia-120/#AttentionvotremmoireavecString et dans les autres liens en commentaires.

Se méfier de la construction des BigDecimal.

On utilise ici 3 manières de faire pour créer un BigDecimal que l’on souhaite égal à 4.12.  Néanmoins, les résultats ne sont pas conformes à ce qu’on pourrait en attendre.

Double myDouble = 4.12D;

BigDecimal bd1 = new BigDecimal(myDouble);
BigDecimal bd2 = new BigDecimal(String.valueOf(myDouble));
BigDecimal bd3 = BigDecimal.valueOf(myDouble);

System.out.println(bd1.equals(bd2));  // false !
System.out.println(bd1.equals(bd3)); // false !
System.out.println(bd2.equals(bd3));  // true

Il n’y a donc pas égalité de valeur entre l’object construit à partir du double et les 2 autres objets. En effet, si on affiche les différentes valeurs des 3 BigDecimal, le problème est facilement visible :

RESULT 1: 4.12000000000000010658141036401502788066864013671875
RESULT 2: 4.12
RESULT 3: 4.12

Il vaut mieux donc éviter d’utiliser le constructeur BigDecimal(double double) et de lui préférer les deux autres méthodes.

public BigDecimal(double val)

Translates a double into a BigDecimal which is the exact decimal representation of the double’s binary floating-point value. The scale of the returned BigDecimal is the smallest value such that (10^scale × val) is an integer.Notes:

1. The results of this constructor can be somewhat unpredictable. One might assume that writing new BigDecimal(0.1) in Java creates a BigDecimal which is exactly equal to 0.1 (an unscaled value of 1, with a scale of 1), but it is actually equal to 0.1000000000000000055511151231257827021181583404541015625. This is because 0.1 cannot be represented exactly as a double (or, for that matter, as a binary fraction of any finite length). Thus, the value that is being passed in to the constructor is not exactly equal to 0.1, appearances notwithstanding.
2. The String constructor, on the other hand, is perfectly predictable: writing new BigDecimal("0.1") creates a BigDecimal which is exactly equal to 0.1, as one would expect. Therefore, it is generally recommended that the String constructor be used in preference to this one.
3. When a double must be used as a source for a BigDecimal, note that this constructor provides an exact conversion; it does not give the same result as converting the double to a String using the Double.toString(double) method and then using the BigDecimal(String) constructor. To get that result, use the static valueOf(double) method.

MAJ :  la date de l’évènement Clojure a été avancée au 8 février !

Ajout événement noSQL 16 février

Ajout évènement EulerGUI 13 février

Le KawaCampParis1 – 3 février – Décalé en mars

Les BarCamp sont des rencontres, non formelles sous forme d’ateliers-événements participatifs ou simplement de discussions libres autour d’un thème. Chacun arrive avec son propre contenu.  Comme lors des JavaCamps les participants finissaient la plupart du temps par parler d’autres choses que Java, l’idée d’un KawaCamp, plus large, a germé Les sujets seront donc nombreux, de NoSQL à Groovy en passant par les technos Google, sans oublier  HTML5, les frameworks Javascript etc ..

Site web : http://barcamp.org/KawaCampParis1
Wave publique : with:public KawaCampParis1

Clojure : Vers l’essence de la programmation – 8 février

Clojure est un langage fonctionnel apparu en 2007 de type Lisp et tournant sur la JVM. Howard Lewis Ship , créateur de Tapestry, présentera le langage, ses atouts ainsi que les concepts fondamentaux de la programmation fonctionnelle.

Site web : http://www.zenika.com/conference/web_ria/clojure-essence-de-programmation-par-howard-lewis-ship

2ème Anniversaire du Paris Jug – 9 février

Le Paris JUG fête ses deux ans en grand ! Un amphi de 500 places nous accueillera entre 18h45 et 19h (donc 30 minutes plus tôt que d’habitude) sur le sujet de l’open-source en France. Au moins 6 présentations sur des thèmes variés :

• Keynote de Sacha Labourey
• Obeo : exemple d’un éditeur d’outils de développements Open Source ayant réussi à se développer
• Les licences permettant la diffusion libre de la documentation
• Le framework Play!
• jCaptcha
• jax-doclet , permettant de génèrer de la JavaDoc à partir des des commentaires JavaDoc et des annotations de manières spécifiques (notamment pour JAX-RS et JAXB)

Et toujours suivi d’une 3ème mi-temps pour des discussions plus informelles mais tout aussi intéressantes !

Comme au mois de Décembre, la salle est à la faculté de la Sorbonne : http://www.parisjug.org/xwiki/bin/view/Location/SorbonneParisIV

Site web : http://www.parisjug.org/xwiki/bin/view/Meeting/20100209

Les secrets de la concurrence Java – 11 février

Heinz Kabuts est un des premiers Java Champion. Il publie régulièrement une newsletter très pointue sur Java et la JVM sur http://www.javaspecialists.eu/ suivie par approximativement 30 000 développeurs Java. Il abordera au cours de cette soirée 10 lois pour nous apprendre à mieux gérer le multi-threading.

Site web : http://www.zenika.com/conference/java/secret-de-la-concurrence-java-par-heinz-kabutz

EulerGUI – 13 février

EulerGUI est une interface graphique pour le Web Sémantique, et les moteurs de règles, Open Source, en Java. ( http://eulergui.svn.sourceforge.net/viewvc/eulergui/trunk/eulergui/html/documentation.html )

Site web : http://jmvanel.free.fr/seminaires/seminaires_gratuits.html#L436

Domain Driven Design : Les modèles en action – 17 février

Eric Evans est de retour à Paris. Auteur de Domain-Driven Design, il  présentera les différents modèles (comment les choisir, les faire cohabiter …). Cette conférence s’adresse plutôt aux développeurs expérimentés.

Site web : http://www.zenika.com/conference/architecture/domain-driven-design-par-Eric-Evans

Deuxième rencontre noSQL – 16 février

Les sujets de cette deuxième conférence sont « noSQL for Fun and Profit » et Redis.

Site web :  http://sites.google.com/a/octo.com/nosql/project-updates/usergroupparis-round2

Création du Spring User Group – 25 février

La première conférence du Spring User Group balayera les différentes nouveautés de la version 3.0 de Spring par Arnaud Cogoluègnes. La migration vers Spring 3.0, les nouveautés (Spring Expression Language, Support Rest) ainsi que le rapport avec Java EE seront abordés.

Site web :  http://groups.google.fr/group/sugfr/web/evnements

Src image :  Iulian Nistea

import java.io._

class Reader(dir: String) {

	// Concatène les contenus de n fichiers dans une liste
	def readAll() = {

		// Mets toutes les lignes d'un fichier dans une liste
		def readLines (name : String) = {

			// Mets toutes les lignes d'un bufferedReader dans une liste
			def read(buf : BufferedReader, acc : List[String] ) : List[String] = buf.readLine match {
				case null => acc
				case s => read(buf, s::acc)  // Appel recursif optimisé par Scala
			}

			// Compose le nom complet du fichier et appel read
			read(new BufferedReader(new FileReader(dir + "/" + name)), Nil).reverse
		}

		// Applique readLine sur tous les fichiers et renvoi la concaténation des listes
		// Pas de return : En scala c'est la derniere expression qui fait office de retour
		new File(dir).list.flatMap(readLines)
	}
}

13 lignes de code, pour lire tous les fichiers d’un répertoire puis concaténer l’ensemble des lignes dans une liste chaîné.

Une compatibilité à 100% avec Java

Ce qui n’est pas une surprise, car Scala est compilé en ByteCode.

Cela se traduit par la possibilité d’importer  n’importe quelle classe pourvu qu’elle soit dans le classpath :

import java.io._

Et d’appeler des méthodes Java dans le code Scala :

buf.readLine

new BufferedReader(new FileReader(dir + "/" + name))

Et même d’utiliser très simplement un framework comme JUnit :

import org.junit.Test

class ReaderTest() {
  @Test
  def unTest() : Unit = {
    val read = new Reader("src/test/resources/cotations")
    read.readAll().map((x) =>println(x));
  }
}

Oui je sais, ce test n’est pas un test, c’est juste un exemple

Chaque méthode que j’ai écrite ne fait qu’un seul traitement. Cela les rends faciles à comprendre, à maintenir et à tester. La programmation fonctionnelle n’étant pas « impérative », il est de toute façon très difficile d’écrire une méthode sur 1000 lignes alors qu’il est malheureusement très fréquent d’en trouver dans du code Java…

Pas de boucle

En programmation fonctionnelle il est tout à fait possible, et même conseillé de ne pas utiliser de boucle. La façon de penser et de concevoir son programme n’est plus la même. C’est je  pense, la principale raison qui rend les langages fonctionnel « obscurs » pour un développeur impératif.

En programmation impérative, on pense « enchaînements d’instructions », c’est un peu comme écrire une recette de cuisine : faire ci, puis ça, puis ça.

En programmation fonctionnelle on s’attache au « comment ». Comment transformer tel fichier en liste et tel liste en table de base de données. C’est le principe d’une fonction : transformer une entrée en « autre chose ». Les éléments impératifs, comme les boucles ne sont utiles que dans un langage impératif (encore que..).

On utilisera plutôt la récursion :

			def read(buf : BufferedReader, acc : List[String] ) : List[String] = buf.readLine match {
				case null => acc
				case s => read(buf, s::acc)  // Appel recursif optimisé par Scala
			}

			// Compose le nom complet du fichier et appel read
			read(new BufferedReader(new FileReader(dir + "/" + name)), Nil).reverse

Notez qu’il ne se produira pas de StackOverflowError car ce code récursif est traduit par une boucle. Oui ne riez pas, c’est vrai. Un code récursif identique en java produira un beau StackOverflowError lorsque les fichiers dépasseront un certain nombre de lignes.

Scala a quand même une petite faiblesse, il n’optimisera que si l’appel récursif est direct. Une pile {read, read, read, read, read} sera optimisée alors qu’une pile {read2, read1, read2, read1} ne le sera pas. Ce qui nous empêche d’écrire ce code qui aurait été plus élégant :

def read(buf : BufferedReader) : List[String] = buf.readLine match {
      case null => Nil
       case s => s::read(buf)  // Appel recursif
}

  // Compose le nom complet du fichier et appel read
  read(new BufferedReader(new FileReader(dir + "/" + name)))

La stack ici est {read, ::, read, ::, read, ..} « :: » est la fonction d’ajout d’élément à une liste en Scala !

En fait, Java nous interdit carrément d’utiliser la récursion sur une trop grande profondeur, ce qui est clairement une énorme lacune du compilateur Java, qui pourrait très bien optimiser les fonctions récursives pour éviter les stackOverflow. Scala à une longueur d’avance sur ce point. Ceci dit je pense que cela donnera des idées pour Java7.

Cette traduction en Java ne sera pas optimisée malgré une pile d’appel optimisable :

private List readLines(final BufferedReader buf, final List acc) {
		String line;
		try {
			line = buf.readLine();
			if (line != null) {
				acc.add(line);
				return readLines(buf, acc);
			}
		} catch (IOException e) {
			e.printStackTrace();
		}

		return acc;
	}

Voici une autre façon de ne pas utiliser de boucle :

// flatMap est une méthode native.
new File(dir).list.flatMap(readLines)

Ici on créé un objet java.io.File, on appel la fonction list() puis on appel la fonction readLines sur chacun des fichiers.

La méthode « map » applique la méthode readLines à tous éléments de la liste et retourne cette nouvelle liste. On effectue donc bien un mapping d’une liste de valeurs vers une nouvelle liste de valeurs : List<FileName> => List<ContenuDuFichierFileName>. Le tout, sans boucle !

La méthode flatMap() diffère de la méthode map() car au lieu de renvoyer une List<List<String>> (ReadLines renvoie une List<String>, elle va « aplanir » (ou concaténer) les listes, ce qui donnera une simple List<String> contenant toutes les lignes de tous les fichiers situés dans le répertoire « dir ».

Alors en vérité, et je pense que c’est une lacune du langage Scala, il existe un mot clé « for » qui permet d’écrire certaine ligne de mon code d’une autre manière faisant grandement penser à une boucle « for » Java… mais sans l’être.. bref, je conseil d’éviter cette écriture, Scala étant déjà assez difficile à appréhender pour un programmeur impératif, inutile d’ajouter de la confusion en codant un truc ressemblant à de l’impératif..

Et pas de variable

Scala encourage l’utilisation d’objet immutable. C’est à dire avec un état fixe, sans setters par exemple. Je vous renvoie à la lecture de l’excellent livre « Effective Java » pour en savoir plus sur les avantages de l’immutabilité en Java, et donc a fortiori en Scala. Et bien entendu il beaucoup plus simple de faire de l’immutable en Scala qu’en Java !

Scala permet de différencier très clairement les valeurs des variables via les mots clé « val » et « var ». « val s : MyObject  » est l’équivalent de « final MyObject o; » alors que « var s : MyObject  » sera l’équivalent de « MyObject o; » En Scala les paramètres des fonctions sont des « val ». Un objet immutable sera forcément une valeur.

Il est donc tout à fait possible et même conseillé de ne jamais utiliser de variables. En fait, lorsqu’on aura besoin d’un objet avec état changeant on utilisera le pattern « Actor », dont Scala fourni le support et qui permet d’avoir des objets mutables « sans risques ».

Développer avec le Bloc-notes : Facile !

Le gros défaut de Scala, c’est qu’il n’existe pas d’IDE aussi avancé que pour Java. Ceci dit, je n’ai pas du tout souffert de ce manque. J’utilise le plugin eclipse fourni sur le site officiel, qui permet l’auto complétion et rajoute de la couleur et honnêtement, ça suffit largement. C’est à se demander si une grosse partie de l’outillage nécessaire en Java n’était finalement pas lié aux lacunes de Java !

Pour comparer voici les 2 codes Java et Scala mis côte à côte. J’ai essayé de réduire au maximum le code Java ! On remarquera qu’en Java, j’ai été obligé d’avoir une variable non final.

import java.io.*;
import java.util.*;

public class Reader {

	private final String directory;

	public Reader(final String dir) {
		this.directory = dir;
	}

	public final List<String> readAll() {
		final String[] fileNames = new File(directory).list();
		final List<String> ret = new LinkedList<String>();

		for (String name : fileNames) {
			try {
				BufferedReader buf = new BufferedReader(new FileReader(directory + "/" + name));
				String line = buf.readLine();
				while (line != null) {
					ret.add(line);
				}
			} catch (FileNotFoundException e) {
				e.printStackTrace();
			} catch (IOException e) {
				e.printStackTrace();
			}
		}

		return ret;
	}
}

No comment :

import java.io._

class Reader(dir: String) {
    def readAll() = {

        def readLines (name : String) = {

            def read(buf : BufferedReader, acc : List[String] ) : List[String] = buf.readLine match {
                case null => acc
                case s => read(buf, s::acc)
            }

            read(new BufferedReader(new FileReader(dir + "/" + name)), Nil).reverse
        }

        new File(dir).list.flatMap(readLines)
    }
}

Réactiver votre cerveau

Apprendre un nouveau langage, c’est apprendre à penser autrement, cela bouscule nos neurones et comment dire : Ça fait du bien !

Scala offre beaucoup d’autres choses intéressantes, comme les traits,  les actors, sa gestion native du XML, son framework web « Lift », Comet etc. J’espère avoir le temps d’approfondir tout ça et d’en faire quelques articles.

Plus généralement, la programmation fonctionnelle offre d’énormes avantages, rendant obsolète bon nombre de patterns et de framework qui n’existent finalement que parce que, Java et les langages impératifs en général ont de nombreuses imperfections.

Source : http://www.scala-lang.org/

Voici son calcul de charges obligatoires :

TNS RSI (Commerçant / Artisan) :  45,2 %

TNS Prof. Libérale : 33%

Salarié : 22% de cotisations salariales et 30% de charges patronales donc : charges = 50%.

Vu comme ça, et étant donné la différence de prestation entre un salarié et un TNS (indemnités journalières, retraite, chômage..), il est plus souvent avantageux d’être salarié, voir complétement préférable pour un artisan au RSI.

Où est l’erreur ?

Alors pourquoi tout le monde ne se met pas salarié ? Les solutions pour le faire sont pourtant multiples ! L’erreur est simple, les taux sont corrects mais la base de calcul n’est absolument pas la même.

Pour le régime salarié, on applique les taux sur le brut versé alors qu’en TNS on applique le taux sur le net versé.

Petit rappel mathématique : y * taux = x  n’est pas égal a x * taux = y.

D’un coté on a brut * (1-taux) = net

de l’autre coté on a : net * (1 + taux) = brut (<=> net = brut * (1/(1+taux)) )

Jusqu’à preuve du contraire 1/(1+taux) n’est pas égal a (1-taux). On compare donc des choux et des carottes.

Pour être plus clair, voici un tableau comparatif avec des exemples facile à comprendre :

Attention, les taux ne sont qu’un ordre de grandeur, en réalité cela varie un peu en fonction des situations.

La comparaison entre salarié et TNS pour un indépendant en informatique, donc en profession libérale, se fera  soit en comparant 81% à 33%  de charges sur le net,  soit en comparant 45% à 25% de charges sur le brut.

En passant, attention au simulateur que l’on trouve sur http://www.freelance-info.fr, il est faux pour les mêmes raisons. Utilisez plutôt notre simulateur.

La troisième journée est assez différente des deux précédentes. Le planning des journées change. Le matin, plus de session de 3 heures mais une Keynote de deux heures suivie par une conférence d’une heure.

Après un rappel de quelques chiffres (2500+participants, 56 jugs …),  Stephan Janssen, l’organisateur de Devoxx nous présente la prochaine version de parleys.com . Parleys.com permet de voir de chez soi l’ensemble des conférences de devoxx mais également d’autres évènements, comme par exemple certaines présentations des différents JUG. Le service est également proposé aux entreprises pour héberger leurs vidéos. Outre cette nouvelle version, les présentations de devoxx 2009 sont déjà arrivées en grand nombre,  les versions gratuites des conférences seront disponibles au compte goutte tout au long de l’année. Toutes les conférences seront disponibles gratuitement  à la fin 2010. A noter qu’il est possible de télécharger les présentations sur son PC très facilement avec ce site et de les revoir à volonté.

Oracle

Le deuxième sujet est une présentation d’Oracle. J’avoue avoir envisagé quelque chose de plus grand, mais l’acquisition de Sun par Oracle n’étant pas finalisé, il n’y aura rien de croustillant de ce côté là. On a le droit à la place d’une démo du moteur de module dynamique de Weblogic.

Sun

La présentation de Sun a été plus intéressante. Outre le fait que la final release sortira le 10 décembre 2009, une belle démo, bien rodée, a pu démontrer la puissance de JEE6. Création d’une Servlet, intéraction avec EJB et ensuite avec un service OSGi. La simplicité de l’ensemble est vraiment à remarquer, aucun plantage lors de la démo. Certaines fonctionnalités de Glassfish V3 notamment le rechargement à chaud … sans perte de session a vraiment eu un impact chez tous ceux qui auront essayés de debugger un problème liée à une session.

Flash Catalyst

La dernière présentation fut celle d’Adobe. Une démonstration de Flash Catalyst et son intégration avec les différents outils Adobe très bien ficelée, avec un vrai show des deux présentateurs. La puissance de Flash Catalyst et son intégration avec la suite Adobe donnent une réelle impression de simplicité, que ce soit pour mapper deux vues, pour modifier un bouton, pour permettre d’envoyer le code vers Flash Builder, qui est plus à destination des développeurs. A voir ce que cela donne dans la réalité.

JDK 7 Update

Place ensuite à JDK7 update. Les plus grandes nouveautés sont le project Jigsaw, qui permet une grande modularité de la jdk, avec la possibilité de n’embarquer que les librairies utiles à notre application. Le project coin qui regroupe quelques évolutions du langage :

L’apparition de l’opérateur diamond qui nous permet d’écrire :

Map<String,String> myMap  = new Hashmap<>();

Il sera également plus simple de construire des collections sans avoir des myList.add(…) à la chaine, la solution implémentée aura une syntaxe proche de celle des tableaux. D’autres nouveautés, comme la possibilité de faire un switch sur des String ou l’apparition  de closures (simples). Un point à également été clarifié sur la différence entre Java SE et le jdk, le Java SE représentant la spécification, le jdk7 l’implémentation. A noter que bien qu’il y ait un open jdk 7, il n’y a pas de Java SE 7.

Comet

Jean-Francois Arcand présente ensuite le framework Atmosphère qui permet de pousser un message du serveur vers le client.
Il existe trois types de méthodes pour pousser ce message :

• Le Polling
• Le long Polling
• Http Streaming, souvent utilisé dans les jeux mais qui devient compliqué dans certaines situations.

Atmosphère se veut un framework simple, basée essentiellement sur des pojos et disponibles sur de nombreux serveurs (de tomcat à google app engine) et supporte certains frameworks de présentations (GWT/Wicket). La démo, très simple, se déroule bien. Encore une fois, il faut voir ce que cela donne dans la réalité de nos environnements.

Distributed programming the google way

Gregor Hohpes présente ensuite une conférence d’une heure sur « Distributed programming the google way ». Cette conférence se révèle être une des plus intéressantes conférences de Devoxx. Il détaille le fonctionnement de BigTable, de MapReduce, de Sawzall et de Google File System au travers de 8 recommandations :

• Utilisez la fragmentation, ne pas hésiter à partionner les données.
• Rester simple et n’implémentez que les fonctions de base
• S’attendre à  l’échec
• Faites des processus autonome, pouvant poursuivre sans supervision
• Le runtime est le plus important. Mieux vaut une circulation fluide à des règles très strictes.
• Préférer la vitesse à la précision. Plus c’est rapide, mieux c’est.
• Privilégier tout ce qui est sans état. Les processes qui conservent un état sont plus couteux que les opérations sans états
• Tout est affaire de compromis

L’importance de ces 8 règles permettent d’avoir une bonne scalabilité. Il n’est souvent pas nécessaire de produire toutes les fonctions possibles pour avoir un outil scalable. Ainsi, les différents outils présentés ont chacun leurs limites :  par exemple, Sawzall permet de faire des aggrégations extrêmement rapide mais ne permet pas de faire de traiter la duplication.

Les deux BOFs auquel j’ai assisté de la soirée n’ont pas été interessante du tout. Trop de monde, impossible à entendre.

Première partie de la journée

La deuxième journée est la dernière journée de la partie université de Devoxx. La partie université à la particularité de présenter deux slots de 3 heures de conférence sur un unique sujet, un le matin et l’autre après midi.

JEE6

La journée débute par une présentation sur JEE 6 par Antonio Goncalvez et Alexis Moussine-Pouchkine. Bien ficelée, la présentation passe en revue l’ensemble des nouveautés. Beaucoup de démos rendent la présentation plus concrète, les mise à jour/nouveautés de la spécification sont bien détaillées. Une présentation un peu plus ‘pratique’ ( Qu’est ce qui ne va pas et qu’il faut revoir ? que conseillez vous ?) aurait pu également être interessant, heureusement que la BoF du soir (Why you should care about JEE6) a répondu en parti à cette problèmatique .

Google App Engine

La deuxième moitié de la présentation Google App Engine a porté sur des questions très pratiques. En ce qui concerne l’interaction avec les données, JDO est preferé à JPA. Tout simplement du aux constraintes de BigTable qui est le système de gestion de données de Google sur App Engine. JDO bien que décrié est remis au gout du jour, JPA n’étant pas totalement disponible sur GAE du à l’utilisation de BigTable, le type de système ‘NoSQL’ de Google qui ne gère que les one-to-many et pas les many-to-many.
Un autre point important, à l’autre bout de la chaine est l’intégration avec GAE de certains framework de présentation (Spring MVC / GWT / JSF 2). En ce qui concerne JSF2, l’intégration se révèle être la plus hardue. En effet, les problèmes sont nombreux (problème avec la sauvegarde d’état, avec les beans de scope session et application (uniquement request code and view code), l’ensemble des états doit être sérialisable, le component binding n’est pas possible pour la raison précédente. GWT se révèle plus facile mais ce qui est réellement conseillé, si l’on recherche quelque chose de pratique est l’utilisation de Spring MVC.

Pour développer l’interface utilisateur de l’application de démo, il a fallu environ 3 jours avec Spring MVC, 2 semaines avec GWT et énormément avec JSF. D’autres frameworks ne sont pas disponibles Rich Faces and Ice Faces par exemple. Pour savoir si une librairie est supportée totalement, partiellement ou non supportée, il suffit de chercher la page ‘Will it play on app engine’ où beaucoup de frameworks/librairies sont référencées, avec leurs limites.

SOA

La session de l’après midi était sur SOA(Service Oriented Architecture), avec une approche assez théorique. C’est un paradigme, une manière de concevoir les choses. L’objectif de SOA est de découper les fonctionnalités complexes en un ensemble de fonction simple, les services. Un des points de la présentation à montrer que chaque choix avait un coût, notamment la manière de coupler faiblement les données mais également d’utiliser un ESB. Il faut compter un ou deux ans avant de réellement avoir une architecture SOA, et bien sûr, commencer par un projet non critique, puis un deuxième, refactorer, ajouter un troisième, refactorer. Le refactoring est une composante essentielle : SOA ne s’achète pas, c’est une philosophie qui se crée sur le long terme et, parceque c’est du long terme, elle nécessite un investissement politique de l’entreprise.

Java-monitor & TeamCity

La première présentation sur l’outil java-monitor a montré des cas spécifiques de problèmes (java heap space, impossible d’allouer la mémoire pour lancer le thread …). Cette présentation très synthétique a permis de mettre en évidence quelques mauvaises pratiques : utilisation de System.gc(), une mauvaise configuration du garbage. Il existe une démo en live des possibilités de l’outil.
TeamCity est un outil d’intégration continue. La présentation était constituée essentiellement d’une démo. Quelques fonctionnalités à retenir : possibilité de déclarer plusieurs agents, par exemple en fonction des OS, bonne intégration avec les IDEs existants, possibilité de prendre la responsabilité d’un échec de build ou d’affecter la responsabilité à un membre de l’équipe, de garder un build propre en permanence (test de la construction du build avant le commit). Néanmoins, la présentation n’a pas montré un outil si simple que ca à manipuler. Un but de TeamCity semble être également d’avoir une place dans les outils qui permettent de monitorer la qualité du code (couverture de code avec Emma, d’autres métriques, la possibilité de voir des mauvaises pratiques) mais encore peut finaliser (pas encore possible apparement de pouvoir modifier les règles sans IntellijJ IDEA).

Les BoF

La première, Why I should carry about java EE6 a pu réunir une belle équipe de speakers. Les questions posées ont amené certaines bonnes pratiques à être définie, comme utiliser les @ManagedBean principalement avec CDI mais les approches JSR/JCP ont également était approchée. La prochaine session du Paris Jug aura j’espère l’occasion de développer encore plus le sujet.

Pour conclure, l’ensemble des présentations seront disponible prochainenment sur le site http://parleys.com/ pour une abonnement de 49€. Ce qui est une très bonne affaire !

Qu’est ce que c’est ?

C’est 5 jours de conférences, principalement orientés java à Anvers en Belgique.  La réception des devoxians à lieu au Metropolis, une salle de cinéma dans la banlieue d’Anvers, à environ 20 min de la gare centrale en tramway. Après avoir récupéré nos badges, on nous fournit un sac de goodies (sac/stylo/bloc note/Tee shirt).

Kanban

La première conférence à laquelle j’ai assisté sur Kanban a duré 3 heures. Kanban est une méthode agile avec un fonctionnement plus simple que Scrum, dans le sens où elle est beaucoup moins contraignante. C’est une méthode avec une forte composante visuel où un radiateur d’information constitue un point central de la méthode. Ses trois principes sont la confiance, l’esprit d’équipe et la transparence. Il n’y a pas de notions de sprint ou d’itération . Les demandes arrivent en permanence et sont traitées au fur et à mesure.

JSF

La deuxième conférence sur JSF 2 était assez pointue, organisée en 3 parties : une heure sur la vue, une heure sur le controleur, une heure sur le modèle. L’aspect orientation composant au lieu de contenu comme c’est le cas avec JSP est assez interessant. L’inconvénient de JSF 1.2 était la quantité très importantes d’XML, JSF 2.0 passe aux annotations, ce qui la rend beaucoup plus simple à manipuler. D’autres améliorations : pouvoir passer des paramètres en GET (sans commentaire), gérer des bookmarkables URLs …
Un des points qui a été souvent abordé lors de la présentation est le futur de JSF. Par exemple, le fait d’avoir une API standard pour AJAX mais également les points bloquants (certaines lourdeurs de configurations). J’ai beaucoup aimé la franchise de Peter, qui a bien montré ce que l’on peut faire et ce qui peut être améliorer.

Hadès & NoSQL

Place ensuite à 2 petites présentations qui m’ont laissé sur ma faim. En une quarantaine de minutes, difficile de rentrer dans un sujet technique, tout au moins d’en montrer ses limites.
Une présentation scolaire mais malgrès tout intéressante d’Hades, qui permet de simplifier l’utilisation de JPa n’a cependant pas montré les cas limites d’utilisation.
De même, la présentation NoSQL n’est pas rentrée assez dans les détails pour que cela deviennent vraiment interessant.

Et le meilleur pour la fin

De 19h à 22h, place à 3 BoFs : Une session très intéressante sur le NoSQL qui a abordé beaucoup de points, comme l’efficacité, les différents types d’outils, l’importance de choisir un système qui correspond à nos attentes. Pour choisir un bon type de base de données, il est conseillé de faire ressortir 2 priorités entre : Consistency, Partition Tolerance et Availability. Ainsi, Cassandra  par exemple,  dans le cas de serveurs distribués, va remonter la dernière information mais sans que cela ne soit garantie (choix fait sur Partition Tolerance et Availability ). L’utilisation pour les boutiques en ligne est tout indiquée (c’est le système d’Amazon). Alors que d’autres systèmes tel que HBase garantissent eux une consistance des données, ils seront plutôt utilisés dans des environnements type CMS, où ce qui est visible à l’écran doit correspondre aux dernières données.

Sur JSF2, la BoF est venu compléter la présentation de l’après midi.

La BoF d’hibernate a été assez intéressante. Une présentation assez longue de l’API Criteria (qui n’est pas très sexy au premier abord) ne m’a pas vraiment fait changé d’avis mais néanmoins, le fait que le meta-modèle soit généré automatiquement par l’IDE simplement est quand même important. Le principal intêret de cet specification est le fait que cela soit typé, néanmoins, peut être parceque je ne suis plus habituée à utiliser un ORM (JDBC pur), je trouve cela très (trop) verbeux. Cet aspect verbeux provient du fait que l’API critéria est très puissante et supporte énormément de choses. On peut l’imaginer encapsulée dans un framework plus simple pour ne retenir que les choses ‘utiles’ à son projet dans une forme verbeuse plus simple.

Et voilà le bilan de cette première journée. D’autre articles arriveront sous peu !