Je suis tombé amoureux de Scala. Et je suis fier de vous présenter mes premières lignes de code en Scala :
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/
Pour commencer 2013 en beauté, rien de mieux que de finir l’année avec une mission pleine de nouveaux challenges et de nouvelles technos : Cassandra, Play!, EJB3 (!) et Arquillian.
Java | Jean-Baptiste | 12 décembre 2012 | 
Comments (3) 
Arquillian, Base url, Glassfish, http, JUnit, restassured, selenium, test, webdriver
EasyMock est un framework de test qui peut dérouter dans un premier abord. Une fois qu’on a compris comment l’utiliser, on tombe sur un certain nombre d’erreurs qui reviennent très souvent et qui ne sont pas souvent explicites. Même si EasyMock 3.0 a clarifié un certain nombre d’erreurs, cet article (fait sous la 2.5.2) servira de pense-bête à ceux qui débutent avec ce framework. 
