Java on Jean-Christophe Gay

Tester son code Java avec Groovy et Spock

Thu, 04 Jun 2015 22:18:00 +0200

Spock est un framework de tests écrit sous la forme de spécifications pour des applications Java ou Groovy. Il offre une alternative tout en un au trio JUnit (TestNG), Mockito et AssertJ.

Mise en place
#

Maven
#

Il s’agit de dépendances à ajouter et d’un peu de configuration supplémentaire :

<dependency>
 <groupId>org.codehaus.groovy</groupId>
 <artifactId>groovy</artifactId>
 <version>2.4.3</version>
 <scope>test</scope>
</dependency>
<dependency>
 <groupId>org.spockframework</groupId>
 <artifactId>spock-core</artifactId>
 <version>1.0-groovy-2.4</version>
 <scope>test</scope>
</dependency>
<!-- (Optionnel) Nécessaire pour mocker des classes concrètes -->
<dependency>
 <groupId>cglib</groupId>
 <artifactId>cglib-nodep</artifactId>
 <version>3.1</version>
 <scope>test</scope>
</dependency>

<build>
 <plugins>
 <plugin>
 <groupId>org.codehaus.gmavenplus</groupId>
 <artifactId>gmavenplus-plugin</artifactId>
 <version>1.5</version>
 <executions>
 <execution>
 <goals>
 <goal>testCompile</goal>
 </goals>
 </execution>
 </executions>
 </plugin>
 <plugin>
 <artifactId>maven-surefire-plugin</artifactId>
 <configuration>
 <includes>
 <include>**/*Spec.java</include>
 </includes>
 </configuration>
 </plugin>
 </plugins>
</build>

Et voilà on peut écrire des spécifications de type *Spec.groovy dans src/test/groovy.

Gradle
#

apply plugin: 'java'
apply plugin: 'groovy'

repositories {
 mavenCentral()
}

dependencies {
 testCompile group: 'org.codehaus.groovy', name: 'groovy', version: '2.4.3'
 testCompile group: 'org.spockframework', name:'spock-core', version: '1.0-groovy-2.4'
 testRuntime group: 'cglib', name: 'cglib-nodep', version: '3.1'
}

Et voilà on peut écrire des spécifications de type *Spec.groovy dans src/test/groovy.

Spécification
#

Squelette
#

Une spécification est une classe qui étends spock.lang.Specification. Elle est composée de champs, de méthodes de configuration (fixture) et enfin de méthodes pour décrire des fonctionnalités (feature).

class MyFirstSpec extends Specification {

 ClassUnderSpecification underTest = new ClassUnderSpecification()
 
 @Shared
 VeryExpensiveResource resource = new VeryExpensiveResource()
 
 def setup() {}
 def cleanup() {}
 def setupSpec() {}
 def cleanupSpec() {}
 
 def "pushing an element on the stack"() {}
}

Les champs ne sont pas partagés entre les méthodes de feature.
Pour partager un objet (par exemple un peu long à initialiser), il faut annoter le champ avec @Shared.

Equivalence fixture avec les annotations JUnit :

Méthode	JUnit
setup	@Before
cleanup	@After
setupSpec	@BeforeClass
cleanupSpec	@AfterClass

On peut de toute façon aussi utiliser les annotations JUnit directement.
Une fonctionnalité est équivalente à une méthode annotée avec @Test dans JUnit.

Blocs
#

Une fonctionnalité est structurée autour de blocs. Il en existe six : setup, when, then, expect, cleanup, et where. Il fait au minimum un bloc pour qu’une méthode soit considérée comme une fonctionnalité (et donc exécutée).
Chaque bloc joue un rôle dans l’expression d’un test et sa bonne utilisation est validée par la librairie quand c’est possible (ordre de déclaration, autorisation du contenu, etc).

setup, given
#

Il permet l’initialisation du test, given est un alias de setup.

when, then
#

when contient le stimulus du test tandis que then permet d’écrire les assertions.
when peut contenir n’importe quel type d’instructions contrairement au bloc then qui lui est limité aux : conditions, vérification des exceptions, interactions (avec les mocks), et définition de variables.

expect
#

Permet d’exprimer les bloc when et then en un seul. Dans la documentation officielle il est conseillé d’utiliser la forme when / then pour tester les méthodes avec des effets de bord et de garder la forme expect pour les fonctions pures.

cleanup
#

Le bloc pour nettoyer les ressources utilisées lors d’un test. Son contenu est tout le temps exécuté même si une exception est levée dans une autre partie de la fonctionnalité.

where
#

Toujours défini en dernier, on peut y écrire la génération des données pour exécuter des tests paramétrés.

Assertions (conditions)
#

Les assertions avec Spock peuvent être remplacées par de simples expressions booléennes.

given:
def list = []

when:
list.add(1)

then:
!list.isEmpty
list.size() == 10

Si un test échoue, on a un affichage complet de l’état du test.

Condition not satisfied:

list.size() == 10
| | |
[1] 1 false

C’est plutôt pratique et lisible dans la majorité des cas. Quand ce ne l’est pas, on peut très bien continuer d’utiliser sa librairie d’assertions préférées.

Vérification des exceptions
#

Il existe divers solutions pour tester des exceptions dans les tests unitaires.
Avec Spock on peut utiliser les conditions thrown(), notThrown et noExceptionThrown().

def "should not throw exception"() {
 when:
 [1].get(0)

 then:
 noExceptionThrown()
}

def "should not throw IndexOutOfBoundsException"() {
 when:
 [1].get(0)

 then:
 notThrown(IndexOutOfBoundsException)
}

def "should throw exception"() {
 when:
 [1].get(1)

 then:
 thrown(IndexOutOfBoundsException)
}

def "should throw exception with message"() {
 when:
 [1].get(1)

 then:
 IndexOutOfBoundsException e = thrown()
 e.message == 'Index: 1, Size: 1'
}

Mock
#

Spock utilise sa propre librairie de mock qui se sert des possibilités du langage Groovy pour définir les interactions.
Comme avec Mockito les mocks sont permissifs par défaut (une interaction non définie ne fera pas échouer un test), par contre les interactions non définies ne retournent que les valeurs par défaut (0, null ou false).

Prenons l’exemple d’une classe écoutant l’état d’un build qui chercherait à envoyer des notifications à la fin de celui-ci.

public class BuildListener {

 private final Notifier notification;

 public BuildListener(Notifier notification) {
 if (notification.checkCompatibility(System.getProperty("os.name"))) {
 throw new IllegalArgumentException("Notifier not compatible with current os");
 }
 this.notification = notification;
 }

 public void onSuccess(BuildResult result) {
 if (notification.isReady()) {
 notification.send("Build success !");
 }
 }
}

Création
#

La définition d’un mock passe par l’utilisation de l’api Mock().

def notifier = Mock(Notifier)

Notifier notifier = Mock()

interaction
#

La spécification du comportement du mock se fait directement dans le bloc then.

class MockSpec extends Specification {

 Notifier notifier = Mock()

 BuildListener listener = new BuildListener(notifier)

 def "should send notification when build ends and notifier is ready"() {
 when:
 listener.onSuccess(new BuildResult())

 then:
 1 * notifier.isReady() >> true
 1 * notifier.send("Build success !")
 }
}

Cela peut paraitre peu naturel au début de définir les interactions dans le bloc then. Mais c’est parce que l’api ne se limite pas à la définition du comportement, on a en plus la vérification que le mock a bien été appelé (l’équivalent d’un Mockito.verify()) !

Si l’interaction avec le mock ne s’est pas passée comme prévu on a un message d’erreur :

Too few invocations for:

1 * notifier.send("Build success !") (0 invocations)

Unmatched invocations (ordered by similarity):

1 * notifier.isReady()

On peut aussi ne pas vérifier les interactions (dans ce cas l’usage d’un Stub() est préférable). Le test précédent peut s’écrire :

def "should send notification when build ends"() {
 given:
 notifier.isReady() >> true

 when:
 listener.onSuccess(new BuildResult())

 then:
 1 * notifier.send("Build success !")
}

On peut déclarer le nombre d’appel attendu :

1 * notifier.send("Build success !") // un appel
0 * notifier.send("Build success !") // pas d'appel
(2..5) * notifier.send("Build success !") // entre deux et cinq appels
(1.._) * notifier.send("Build success !") // au moins un appel
(_..2) * notifier.send("Build success !") // deux appels au plus

La vérification du/des arguments d’une méthode est lui aussi assez riche :

* notifier.send("a") // argument vaut "a"
* notifier.send(!"a") // argument différent de "a"
* notifier.send(_) // n'importe quel argument (dont null)
* notifier.send(!null) // argument non null
* notifier.send(_ as String) // argument de type String
* notifier.send({ it.startsWith 'a' }) // argument commençant par "a"

L’utilisation d’une closure dans le matching d’argument (comme le dernier exemple ci-dessus) peut permettre dans certains cas limites de reproduire le comportement d’un ArgumentCaptor de Mockito :

def "should send notification when build ends"() {
 def captured

 given:
 notifier.isReady() >> true

 when:
 listener.onSuccess(new BuildResult())

 then:
 1 * notifier.send(_) >> { arguments -> captured = arguments[0] }

 captured == "Build success !"
}

Pour retrouver l’équivalent du @InjectMocks de Mockito il existe une extension Spock (Spock Subjects-Collaborators Extension) qui permet d’injecter automatiquement des mocks dans l’objet que l’on souhaite tester.
Les mocks doivent être annotés avec @Collaborator et le sujet du test avec @Subject.

class MockWithSubjectSpec extends Specification {

 @Collaborator
 Notifier notifier = Mock()

 @Subject
 BuildListener listener

 def "should send notification when build succeed"() {
 when:
 listener.onSuccess(new BuildResult())

 then:
 1 * notifier.isReady() >> true
 1 * notifier.send("Build success !")
 }
}

Par défaut Spock ne vérifie pas l’ordre dans lequel les interactions sont invoquées. Si vraiment on en a besoin on peut définir les interactions dans des blocs then différents. Dans ce cas les mocks devront être appelés dans l’ordre dans lequel ils ont été déclarés.

def "should send notification when build ends"() {
 when:
 listener.onSuccess(new BuildResult())

 then:
 1 * notifier.isReady() >> true
 
 then:
 1 * notifier.send("Build success !")
}

Définition retour des méthodes
#

Pour retourner une valeur dans la définition d’une interaction on utilise l’opérateur >>.

notifier.isReady() >> true

L’opérateur >>> permet de définir des valeurs de retours différentes pour des appels successifs.

notifier.isReady() >>> [true, false, false, true]

On peut également retourner une valeur après un calcul dépendant d’un argument.

notifier.checkCompatibility(_) >> { String os -> !os.startsWith("win") }

Et enfin pour lever une exception :

notifier.isReady() >> { throw new NullPointerException() }

Stub, Spy, Partial mock
#

Spock gère aussi tous ces autres type de mocks.

Un stub peut-être créé avec l’api Stub(). La grande différence avec un Mock() est qu’on ne peut pas vérifié le comportement du stub (d’ailleurs une erreur se produira si l’on essaie). L’initialisation par défaut est aussi plus “intelligente” que celle des Mock().
Si une interaction n’est pas définie et qu’un appel a lieu, la valeur retournée tentera de s’adapter au type de retour défini (une collection vide sera retournée par exemple).

Les autres s’utilisent avec l’api Spy(). Tout est décrit dans la documentation

Tests paramétrés
#

Parfois on a besoin d’exécuter plusieurs fois le même test avec des données différentes.
Avec JUnit on a le choix entre :

Généralement j’utilise junit-dataprovider qui mime le comportement des DataProvider de TestNG mais avec Spock on va avoir accès à des solutions bien plus élégantes.

Data Tables
#

La déclaration des données se fait dans un bloc expect.

def "should return maximum of two numbers"() {
 expect:
 Math.max(a, b) == c

 where:
 a | b || c
 1 | 2 || 2
 2 | 1 || 2
 1 | 0 || 1
 0 | 0 || 0
}

Le test sera exécuté pour chaque ligne du tableau, chaque colonne définissant une variable du test.
Le double séparateur de colonne est optionnel, c’est du sucre syntaxique pour séparer les valeurs d’entrée et le résultat attendu.

Par défaut le test est vu comme un seul, ce qui fait que ce n’est pas toujours facile de retrouver quelle ligne du tableau entraine un échec.
Pour améliorer la lisibilité du rapport de test, on peut utiliser l’annotation @Unroll. Elle permet de créer un rapport par ligne du tableau et d’injecter les valeurs du test dans le nom de la méthode.

On peut donc remplacer le nom du test précédent en utilisant #variable comme placeholder :

@Unroll
def "maximum of #a and #b should be #c"()

et le rapport de l’exécution des tests ressemblera à :

maximum of 1 and 2 should be 2
maximum of 2 and 1 should be 2
maximum of 1 and 0 should be 1
maximum of 0 and 0 should be 0

Data Pipes
#

Les data pipes sont la seconde forme de data provider disponible.

def "even numbers"() {
 expect:
 a % 2 == 0

 where:
 a << [0, 2, 4, 6]
}

Le test sera exécuté quatre fois avec les valeurs 0, 2, 4, 6. Tout objet connu comme étant iterable par Groovy peut être utilisé dans un data pipe.

Test génératifs
#

Spock-Genesis est une collection de générateurs pour écrire des tests génératifs.

@Unroll
def "should reverse #string"() {
 when:
 String reversed = string.reverse()

 then: 'It maintains length'
 reversed.size() == string.size()

 and: 'It is not destructive'
 reversed.reverse() == string

 where:
 string << Gen.these('', 'aba', 'aa').then(Gen.string).take(10000)
}

Tout se passe à partir de spock.genesis.Gen, il y a des générateurs pour les String, int, long, double, Date, etc.
La documentation est succincte mais il y a des exemples d’utilisation ici.

Pour améliorer l’analyse statique dans l’IDE il est possible d’ajouter en paramètre de la méthode de test les types des variables nécessaires.
Dans l’exemple précédent, IntelliJ Idea se plaint de ne pas trouver les méthodes reverse et size pour la variable string (reconnu comme étant de type Object). Si on déclare un paramètre pour la méthode, plus de problème.

@Unroll
def 'should reverse #string'(String string)

Extensions
#

Spock possède un mécanisme permettant d’enrichir son cycle de vie. Les extensions disponibles par défaut sont listées dans la documentation.

Parmi les plus sympa, il y a :

@IgnoreIf permet d’ignorer un test quand une condition n’est pas respectée,
@Timeout pour faire échouer un test s’il ne s’est pas exécuté en un certain temps,
@AutoCleanup appelle automatiquement une méthode sur un champ annoté pour libérer des resources à la fin de son cycle de vie,
@RestoreSystemProperties rétabli les valeurs des propriétés systèmes quand elles ont été modifiées au cours d’un test.

Et il en existe d’autres développés par la communauté :

Spock Reports pour générer un rapport HTML des spécifications,
@TempDirectory crée des dossiers temporaires,
Spock Subjects-Collaborators Extension pour injecter des mocks dans la classe que l’on teste,
Et bien d’autres…

Et finalement Spock est aussi compatible avec les @Rule de JUnit !!

Documentation
#

Spock met en avant le fait que les tests sont des spécifications qui peuvent-être documentées comme telles.
Les blocs sont en fait des labels, on peut donc y associer une description :

when: "a build notifies a listener when ending"
listener.onSuccess(new BuildResult())

then: "the listener asks a notifier if it is ready"
1 * notifier.isReady() >> true
 
then: "the listener asks the notifier to send a notification"
1 * notifier.send("Build success !")

Un bloc peut être découpé en plusieurs étapes avec le label and:

given: "something"
// code

and: "something else"
// code

when:
then:

Il existe aussi des extensions à fin documentaire :

@Title, @Narrative définissent une spécification,
@Issue indique qu’une fonctionnalité ou une spécification sont liées à un ticket,
@Subject pour identifier la classe que l’on spécifie.

Conclusion
#

Les tests écrits avec Spock sont globalement plus concis et lisibles. Les noms de méthodes sont de vrais phrases, les spécifications sont structurées autour de blocs bien définis (given, when, then) et le langage Groovy permet d’écrire moins de code.

Spock vient avec son propre framework de mocks et ses assertions pensés pour l’outil. Ça évitera de se retrouver avec des tests écrits avec des librairies différentes et de devoir retenir plusieurs API. Rien n’empêche d’ailleurs d’utiliser Mockito (ou un autre) par exemple à la place des mocks livrés avec Spock.

Spock est compatible avec de nombreux outils puisqu’il est accompagné d’un runner JUnit. Pas de soucis pour exécuter les spécifications depuis son IDE ou son outil de build préféré. Cela le rend aussi compatible avec les Rule JUnit !

Groovy a une courbe d’apprentissage rapide pour un développeur Java. Le langage en est très proche et on peut se permettre d’en apprendre les spécificités et les concepts au fur et à mesure. Utiliser Groovy pour ses tests a encore plus de sens quand on maintient du code Java dans des versions un peu ancienne.

Même si les exemples se sont concentrés sur du code Java, Spock fonctionne aussi très bien pour tester du Groovy 😇

Encore ?
#

Le guide d’utilisation de Spock mérite une lecture attentive, ses mécanismes y sont très bien expliqués.
La présentation Smarter testing Java code with Spock Framework propose tout une série d’astuces pour encore améliorer son utilisation de Spock !
Et pour finir les auteurs de l’outil maintiennent un projet d’exemple dans lequel on peut aller piocher de bonnes idées.

Ecrire une migration Liquibase en Java

Sun, 01 Feb 2015 13:37:00 +0200

Liquibase est un outil très utile pour versionner sa base de données. La succession de refactoring à appliquer à une base peut-être décrite dans plusieurs formats de données (XML, YAML, JSON et SQL). Seulement il arrive qu’une migration soit “trop” complexe pour être décrite à partir des refactoring standards (ou alors tout simplement que l’on ne soit pas très à l’aise avec PL/SQL).
Dans ce cas on peut écrire un changement particulier en Java.

Implémenter un CustomChange
#

Liquibase propose deux interfaces pour créer son refactoring personnel, CustomTaskChange et CustomSqlChange. La première permet d’appliquer des changements qui ne génèrent pas de SQL contrairement à la seconde.
Cette dernière est à privilégier quand c’est possible puisque cela permet de sauvegarder le SQL généré dans un fichier (via un dryRun par exemple).

public class MyCustomChangeThatGenerateSql implements CustomSqlChange {

 @Override
 public SqlStatement[] generateStatements(final Database database) throws CustomChangeException {

 List<SqlStatement> statements = new ArrayList<>();
 
 JdbcConnection connection = (JdbcConnection) database.getConnection();
 try {
 ResultSet persons = connection.createStatement().executeQuery("select nom, prenom from person");
 while (persons.next()) {
 // Write your complex logic in here !
 // and generate SqlStatement(s)
 }
 } catch (DatabaseException | SQLException e) {
 throw new CustomChangeException(e);
 }
 
 SqlStatement insert = new InsertStatement(database.getDefaultCatalogName(), database.getDefaultSchemaName(), "person")
 .addColumnValue("nom", "Gay")
 .addColumnValue("prenom", "Jean-Christophe");
 
 SqlStatement update = new UpdateStatement(database.getDefaultCatalogName(), database.getDefaultSchemaName(), "person")
 .addNewColumnValue("prenom", "Jc")
 .setWhereClause(String.format("nom='%s'", Gay))
 
 statements.add(insert);
 statements.add(update);
 
 return statements.toArray(new SqlStatement[statements.size()]);
 }
 
 @Override
 public String getConfirmationMessage() {
 return null;
 }

 @Override
 public void setUp() throws SetupException {}

 @Override
 public void setFileOpener(ResourceAccessor resourceAccessor) {}

 @Override
 public ValidationErrors validate(Database database) {
 return null;
 }
}

La principale logique se passe dans la méthode generateStatements. L’API de Liquibase nous donne accès à la connexion Jdbc et il suffit de générer des SqlStatement pour décrire son refactoring.
Le reste des méthodes à implémenter permet de valider la configuration, accéder à des fichiers, etc. La Javadoc explique tout ça.

Configurer son changeset
#

L’élément customChange permet de déclarer la classe implémentant le refactoring.

<changeSet id="20140606-super-complex-change" author="jc.gay">
 <customChange class="fr.jcgay.MyCustomChangeThatGenerateSql" />
</changeSet>

Et voilà on peut décrire des changements complexes dans son langage préféré !

A la découverte de Java 8

Sun, 04 May 2014 17:58:00 +0200

Java 8 est maintenant disponible depuis plusieurs semaines, voici un “petit” résumé des fonctionalités de Java 8 que j’ai testé à travers tous les articles sur lesquels je suis tombé.

Default methods sur les Interfaces
#

Java 8 utilise le mot clef default pour définir une implémentation par défaut au sein d’une interface.
C’est utile pour les développeurs d’API, c’était même indispensable pour la plupart des nouveautés du langage sinon comment enrichir les interfaces comme java.util.Collection sans briser toutes les implémentations existantes ?

public interface A {
 default void printSomething() {
 System.out.println("something");
 }
}

public class Implementation implements A {}

La classe Implementation n’a pas besoin de définir la méthode printSomething.

public class Examples {
 public static void main(String[] args) {
 new Implementation().printSomething();
 }
}

Que ce passe t-il si deux interfaces implémentent la même méthode par défaut et qu’une classe implémente ces deux interfaces ?

public interface B {
 default void printSomething() {
 System.out.println("something else");
 }
}

public class DoesNotCompile implements A,B {}

Et bien le code précédent ne compile pas:

class DoesNotCompile inherits unrelated defaults for printSomething() from types A and B

On est obligé de surcharger la méthode dans l’implémentation pour résoudre le conflit,

public class ItCompiles implements A,B {

 @Override
 public void printSomething() {
 System.out.printf("I can print what I want !");
 }
}

Pour faire référence à une des méthodes par défaut :

public class ItCompilesToo implements A,B {

 @Override
 public void printSomething() {
 B.super.printSomething();
 }
}

Je pense que cette fonctionalité va être très utile pour les développeurs de librairies, on va pouvoir oublier les fameuses classes abstraites dont il fallait hériter pour ne pas risquer de tout casser lors de mises à jour d’interfaces.

Expressions Lambda
#

Surement une des évolutions les plus attendues, une expression lambda est une sorte de méthode “anonyme”. Jusqu’à aujourd’hui en Java pour simuler ce comportement on utilisait une classe anonyme qui implémentait une interface avec une seule méthode abstraite (SAM).

List<Integer> numbers = asList(10, 1, 1000, 100);

Collections.sort(numbers, new Comparator<Integer>() {
 @Override
 public int compare(Integer a, Integer b) {
 return a.compareTo(b);
 }
});

peut-etre remplacé par :

Collections.sort(numbers, (a, b) -> a.compareTo(b));

Le compilateur est capable de trouver les types des paramètres, pas besoin de les préciser et la méthode tenant sur une ligne, on peut également omettre les {} et le return.

Accès variable locale
#

Contrairement à une classe anonyme, une expression lambda peut accéder aux variables locales même si celles ci ne sont pas déclarées comme étant final.

Integer n = 4;
Function<Integer, Integer> modulo = (Integer a) -> a % n;

assert modulo.apply(8) == 0;

mais en fait il faut qu’elles le soient, le code suivant ne compile pas :

Integer n = 4;
Function<Integer, Integer> modulo = (Integer a) -> a % n;
n = 8;

avec comme erreur :

local variables referenced from a lambda expression must be final or effectively final

Membre et variable static
#

Contrairement aux variables locales, les membres de classe sont accessibles en écriture.

public class Lambda {

 private static int staticNumber;
 private int number;

 public void write() {
 Function<Integer, Integer> function = (Integer a) -> staticNumber = a;
 Function<Integer, Integer> function2 = (Integer a) -> number = a;
 }
}

Functional Interfaces
#

Les expressions lambda ne sont en fait pas si “anonymes” que ça. Elles correspondent en fait à des types spécifiés par des interfaces avec exactement une méthode abstraite. C’est pour ça que les classes anonymes implémentant une interface de type SAM peuvent être remplacées par des expressions lambda.
Java 8 propose l’annotation @FunctionalInterface pour s’assurer qu’une interface ne déclare qu’une seule méthode abstraite.

@FunctionalInterface
public interface Function<T, R> {

 R apply(T t);
}

Si une deuxième méthode abstraite est ajoutée la compilation échoue :

Function is not a functional interface, multiple non-overriding abstract methods found in interface

Lambda
#

On peut ajouter des méthodes par defaut sur une @FunctionalInterface.

@FunctionalInterface
public interface A {

 default void printSomething() {
 System.out.println("something");
 }

 void print();
}

mais on ne peut pas accéder à ces méthodes depuis une lambda.

A doesNotCompile = () -> printSomething();

Function, Predicate, etc
#

De nombreuses @FunctionalInterface sont disponibles par défaut. D’anciennes interfaces de l’API ont été migrées, Comparable et Runnable par exemple. Si vous connaissez déjà Guava vous ne serez pas complètement perdu.

Function
#

Une Function prend un argument et retourne un résultat.

Function<Integer, String> toString = n -> String.valueOf(n);
Function<String, Integer> toInteger = s -> Integer.valueOf(s);

assert "4".equals(toString.apply(4));
assert toInteger.apply("4") == 4;

assert "4".equals(toString.compose(toInteger).apply("4"));
assert toString.andThen(toInteger).apply(4) == 4;

La méthode compose applique la fonction toInteger puis la fonction toString alors que la méthode andThen applique toString puis toInteger.

BiFunction
#

C’est un spécialisation d’une Function qui prend deux arguments et retourne un résultat.

BiFunction<Integer, String, String> concat = (Integer i, String s) -> s + ": " + i;

assert "un: 1".equals(concat.apply(1, "un"));

UnaryOperator
#

C’est une Function qui prend un argument et retourne un résultat du même type. Par exemple la fonction identity retourne toujours la valeur passée en argument.

assert UnaryOperator.identity().apply("un").equals("un");

BinaryOperator
#

Un BinaryOperator est une spécialisation d’une BiFunction dont les paramètres et le résultat partagent le même type.

BinaryOperator<String> concatString = (s1, s2) -> s1.concat(": ").concat(s2);

assert "un: 1".equals(concatString.apply("un", "1"));

Predicate
#

Un Predicate prend un argument et retourne un booléen.

Predicate<String> isEmpty = s -> s == null || s.isEmpty();
Predicate<String> isTrimmed = s -> s.equals(s.trim());
 
assert isEmpty.test(null) == true;
assert isEmpty.test("") == true;
assert isEmpty.test("not empty") == false;

assert isEmpty.negate().and(isTrimmed).test("not empty") == true;
assert isEmpty.negate().and(isTrimmed).test(" not empty ") == false;

assert isEmpty.or(isTrimmed).test("") == true;
assert isEmpty.or(isTrimmed).test("not empty") == true;

assert Predicate.isEqual("hello").test("hello") == true;

negate inverse un prédicat,
and et or permettent de chaîner des prédicats selon l’opérateur logique,
La méthode statique isEqual teste l’égalité de deux objets selon Object#equals

BiPredicate
#

Un BiPredicate prend deux arguments et retourne un booléen.

Supplier
#

Un Supplier ne prend pas d’argument et produit un résultat.

Supplier<String> emptyString = () -> "";

assert "".equals(emptyString.get());

Consumer
#

Un Consumer prend un argument mais ne retourne pas de résultat.

Consumer<String> print = s -> System.out.println(s);
Consumer<String> hello = s -> System.out.printf("Hello %s !", s);

print.accept("something"); // something
print.andThen(hello).accept("JC"); // JC Hello JC !

La méthode andThen permet de chaîner les consommateurs.

Comparator
#

Les Comparator sont devenus des FunctionalInterface.

Comparator<Integer> ascending = (a, b) -> a.compareTo(b);

assert ascending.compare(10, 1) > 0;
assert ascending.reversed().compare(10, 1) < 0;

Sans grande surprise reversed inverse la comparaison.
Il existe des méthodes par défaut pour appliquer une Function avant le Comparator dans les différents thenComparating.

A retenir
#

Ça fait beaucoup d’interfaces fonctionnelles (et je n’ai même pas lister les versions spécifiques pour les types primitifs), ce qu’il faut retenir :

s’il n’y a pas de retour, on utilise un Consumer,
s’il faut retourner un booléen, on utilise un Predicate,
s’il faut produire un numérique primitif (int, double, long), on utilise un (Type)ToIntFunction, (Type)ToDoubleFunction, (Type)ToLongFunction,
s’il faut retourner une valeur sans prendre d’argument, c’est un Supplier,
si le seul argument de la fonction est un int, double, long on utilise un Int(something), Double(something), Long(Something),
si la fonction prend deux arguments, c’est une Bi(something),
si la fonction prend deux arguments de même type, c’est un BinaryOperator,
si une fonction retourne une valeur de même type que son unique argument, c’est un UnaryOperator,
si une fonction prend en argument un type primitif et un autre type sans retourner de valeur, c’est un Obj(Int|Double|Long)Consumer,
sinon c’est une Function.

Surcharge de méthode
#

On peut surcharger une méthode utilisant une FunctionalInterface en paramètre par une autre plus spécifique (la manière classique d’overloading).

Par exemple, un BinaryOperator est une spécialisation d’une BiFunction,

public class A {

 public void is(BiFunction<Boolean, Boolean, Boolean> function) {
 System.out.println("bifunction");
 }

 public void is(BinaryOperator<Boolean> function) {
 System.out.println("binaryoperator");
 }
}

le code suivant affichera "binaryoperator"

new A().is((a, b) -> true);

Par contre le compilateur ne peut pas toujours trouvé “un type le plus spécifique”. Dans le cas où les types en questions n’ont pas de relation, seul le nombre d’arguments de la FunctionalInterface permet de différencier les méthodes surchargées.

@FunctionalInterface
public interface StringPredicate {
 boolean test(String string);
}

public class A {

 public void anotherMethod(Predicate<String> predicate) {
 System.out.println("predicate");
 }

 public void anotherMethod(StringPredicate predicate) {
 System.out.println("string predicate");
 }
}

Le code suivant ne compile pas

new A().anotherMethod(input -> true);

reference to anotherMethod is ambiguous
both method anotherMethod(java.util.function.Predicate<java.lang.String>) in fr.jcgay.example.java.overload.A and method anotherMethod(fr.jcgay.example.java.overload.StringPredicate) in fr.jcgay.example.java.overload.A match

Même si c’est techniquement possible, je ne suis pas sûr que ce soit une super idée de surcharger de telles méthodes, dans le premier cas par exemple la résolution est bien moins claire lors de la manipulation de l’expression lambda que lors de cas classiques de surcharge où l’on manipule directement des types.

Références de méthodes
#

Java 8 introduit le mot clef :: pour extraire des références de méthodes. C’est utile pour remplacer des expressions lambda qui se contentent de faire appel à une méthode qui existe déjà.

On peut remplacer :

Function<Integer, String> toString = n -> String.valueOf(n);

par :

Function<Integer, String> toString = String::valueOf;

On peut faire référence à des méthodes statiques mais aussi directement depuis une instance,

String hello = new String("hello");
Predicate<String> startsWith = hello::startsWith;

assert startsWith.test("he") == true;

et aux constructeurs,

Supplier<String> newString = String::new;

et aussi aux méthodes d’instance sans référence d’objet en particulier :

List<String> names = Arrays.asList("Barbara", "James", "Mary", "John");
Collections.sort(names, String::compareToIgnoreCase);

Fonctionnement
#

C’est bien magique mais comment on détermine qu’une méthode existante est compatible avec une FunctionalInterface ?

statique
#

La plus simple à se représenter, il suffit que la dite méthode ait bien la même signature que la méthode unique de l’interface désirée.

Par exemple, on peut écrire notre Function toString précédente,

Function<Integer, String> toString = new Function<Integer, String>() {
 @Override
 public String apply(Integer integer) {
 return String.valueOf(integer);
 }
};

String#valueOf(Integer) est bien utilisable pour implémenter Function<Integer, String>#apply(Integer), et remplacer une expression lambda par une référence de méthode statique.

instance
#

Ce type de référence permet de capturer une instance qui sera utilisée lors de l’évaluation de l’expression lambda.

Ainsi notre exemple du début revient à écrire :

String hello = new String("hello");
Predicate<String> startsWith = new Predicate<String>() {
 @Override
 public boolean test(String s) {
 return hello.startsWith(s);
 }
};

instance arbitraire
#

Ce sont les plus difficiles à se représenter au début. Ces références permettent de pointer des méthodes sur des instances qui seront découvertes à l’exécution. En fait celà veut dire que l’instance en question sera le premier argument de l’expression lambda et le reste des paramètres seront ceux passés à la méthode en référence.

Reprenons l’exemple de la comparaison de chaînes de caractères,

BiFunction<String, String, Integer> concat = new BiFunction<String, String, Integer>() {
 @Override
 public Integer apply(String self, String argument) {
 return self.compareToIgnoreCase(argument);
 }
};

Optional
#

C’est un conteneur pour une valeur qui peut être null. Ce conteneur possède deux états, contenant une valeur ou ne contenant rien.
Retourner un Optional à la place d’un null permet d’obliger le traitement du cas “pas de valeur de retour”.

Optional<String> hello = Optional.of("hello");

assert hello.isPresent() == true;
assert "hello".equals(hello.get());

Si la valeur contenu est null,

Optional<Object> absent = Optional.ofNullable(null);

assert absent.isPresent() == false;
absent.get() // throws java.util.NoSuchElementException: No value present

La classe Optional regorge de méthodes utilitaires pour transformer/filtrer la valeur qu’il contient, pour retourner une valeur par défaut et également un orElseThrow qui pour le coup n’existe pas dans Guava.

Stream
#

Un Stream est une séquence d’éléments sur laquelle on peut effectuer des opérations. Un Stream se compose d’une source (un tableau, une collection, etc), de zéro ou plusieurs opérations intermédiaires (transformation du Stream en un autre via filter par exemple) et d’une opération terminale (qui produit le résultat).
Les calculs ne sont effectués qu’à l’initialisation de l’opération finale et la source est consommée que si c’est nécessaire.

On peut créer un Stream à partir d’une collection en utilisant la méthode stream(),

List<Person> persons = asList(
 new Person("John", "Doe", 30),
 new Person("Jane", "Doe", 20),
 new Person("Jim", "Smith", 15)
 );

assert persons.stream().count() == 3;

En utilisant IntStream, DoubleStream, LongStream pour créer des Stream numériques,

assert IntStream.range(0, 10).sum() == 45;

Ou encore avec différentes méthodes utilitaires sur la classe Stream,

Stream.of("a", "b", "c").forEach(System.out::println);

Stream.builder().add("a").add("b").add("c")
 .build()
 .forEach(System.out::println);

Un Stream peut-être infini, dans ce cas il faut avoir une opération stoppante,

Random random = new Random();
Stream.generate(() -> random.nextInt())
 .limit(10)
 .forEach(System.out::println);

new Random().ints()
 .limit(10)
 .forEach(System.out::println);

En gros il y a des Stream un peu partout :)

forEach
#

Effectue une opération sur chacun des éléments en utilisant un Consumer. C’est une opération terminale qui consomme le Stream. On ne peut pas appeler d’autres opérations après un forEach.

persons.stream()
 .forEach(p -> System.out.println(p.getLastName() + " " + p.getFirstName()));

// Doe John
// Doe Jane
// Smith Jim

filter
#

Accepte un Predicate pour filtrer les éléments. C’est une opération intermédiaire qui nous permet donc de chaîner d’autres opérations à sa suite.

persons.stream()
 .filter(p -> p.getLastName().startsWith("D"))
 .forEach(System.out::println);

// Person{firstName='John', lastName='Doe', age=30}
// Person{firstName='Jane', lastName='Doe', age=20}

sorted
#

Une opération intermédiaire qui permet de trier les éléments à l’aide d’un Comparable.

persons.stream()
 .sorted((p1, p2) -> p1.getFirstName().compareTo(p2.getFirstName()))
 .forEach(System.out::println);

// Person{firstName='Jane', lastName='Doe', age=20}
// Person{firstName='Jim', lastName='Smith', age=15}
// Person{firstName='John', lastName='Doe', age=30}

map
#

Applique une Function sur les éléments, c’est également une opération intermédiaire.

persons.stream()
 .map(Person::getAge)
 .sorted()
 .forEach(System.out::println);
 
// 15
// 20
// 30

allMatch, anyMatch, noneMatch
#

Plusieurs méthodes permettant de vérifier que zéro/un/des éléments vérifient un Predicate. Toutes ces opérations sont terminales.

assert persons.stream()
 .allMatch(p -> p.getFirstName().startsWith("J"))
 == true;

assert persons.stream()
 .noneMatch(p -> p.getAge() == 35)
 == true;
 
assert persons.stream()
 .anyMatch(p -> "Doe".equals(p.getLastName()))
 == true;

count
#

Une opération terminale qui retourne le nombre d’élément dans un Stream.

assert persons.stream()
 .filter(p -> p.getAge() >= 20)
 .count()
 == 2;

sum
#

Retourne la somme de tous les éléments.

assert IntStream.rangeClosed(1, 10).sum() == 55;

reduce
#

C’est une opération terminale qui réduit les éléments du Stream avec un BinaryOperator.
On obtient au final le résultat sous la forme d’un Optional,

On va créer un monstre en fusionnant nos personnes,

persons.stream()
 .reduce((p1, p2) -> new Person(p1.getFirstName(), p2.getLastName(), p1.getAge() + p2.getAge()))
 .ifPresent(System.out::println);

// Person{firstName='John', lastName='Smith', age=65}

On peut additionner les âges de nos personnes,

assert persons.stream()
 .map(Person::getAge)
 .reduce(0, Integer::sum)
 == 65;

L’argument idendity est l’élément identité de la réduction, il ne doit avoir aucun effet sur la fonction d’accumulation (accumulator dans la signature de reduce). C’est le cas ici puisque x + 0 = x.

Et on peut encore écrire le reduce sous la forme

assert persons.stream()
 .reduce(0,
 (result, person) -> result + person.getAge(),
 (a, b) -> a + b
 )
 == 65;

L’accumulator définit l’opération effectué sur chacun des éléments et retient ce résultat tandis que le combiner décrit l’opération effectuée pour combiner deux résultats de la fonction accumulator.
Cette fois ci identity ne doit pas avoir d’effet sur le combiner.
La fonction combiner doit être associative pour assurer la cohérence du résultat lors du traitement du Stream en parallèle.

collect
#

Permet de réunir tous les éléments en utilisant un Collector. C’est bien entendu une opération terminale.

persons.stream()
 .map(Person::getLastName)
 .collect(Collectors.toList());

// [Doe, Doe, Smith]

La classe Collectors regorge d’implémentations de Collector pour faciliter l’opération.
On peut en avoir un très bon aperçu dans la présentation de José Paumard : Java 8 Streams & Collectors : patterns, performances, parallélisation

concat
#

On peut concaténer des Stream.

IntStream.concat(
 IntStream.range(0, 4),
 IntStream.range(4, 6)
).forEach(System.out::print);

// 012345

findFirst, findAny
#

Des opérations terminales qui permettent de retourner le premier élément du Stream s’il existe en tant qu’Optional,

persons.stream()
 .findFirst()
 .ifPresent(System.out::print);

// Person{firstName='John', lastName='Doe', age=30}

ou encore n’importe quel élément,

persons.stream()
 .parallel()
 .findAny()
 .ifPresent(System.out::print);

Le résultat de findAny n’est pas constant, le résultat peut varier.

flatMap
#

C’est une opération intermédiraire qui permet de mettre à plat un Stream.
On peut par exemple transformer un Stream<List<Person>> en Stream<Person> via une Function<List<Person>, Stream<Person>> :

Stream.<List<Person>>builder()
 .add(asList(new Person("John", "Doe", 30), new Person("Jane", "Doe", 20)))
 .add(asList(new Person("Jim", "Smith", 15)))
 .build()
 .flatMap(persons -> persons.stream())
 .filter(person -> "Doe".equals(person.getLastName()))
 .forEach(System.out::println);
 
// Person{firstName='John', lastName='Doe', age=30}
// Person{firstName='Jane', lastName='Doe', age=20}

limit, skip
#

Permet de se déplacer ou de bloquer le nombre d’éléments d’un Stream. Ce sont des opérations intermédiaires.

persons.stream()
 .limit(2)
 .skip(1)
 .findFirst()
 .ifPresent(System.out::print);

// 	Person{firstName='Jane', lastName='Doe', age=20}

min, max
#

Des opérations terminales pour trouver le minimum ou le maximum (en tant qu’Optional) d’un Stream s’ils existent à l’aide d’un Comparator.

assert IntStream.rangeClosed(1, 10)
 .min()
 .getAsInt()
 == 1;

assert IntStream.rangeClosed(1, 10)
 .max()
 .getAsInt()
 == 10;

peek
#

Une méthode utile pour débugger entre les opérations efféctuées sur un Stream. C’est une opération intermédiaire qui exécute un Consumer sur chacun des éléments.

persons.stream()
 .filter(p -> "Doe".equals(p.getLastName()))
 .peek(System.out::println)
 .filter(p -> p.getAge() < 25)
 .peek(System.out::println)
 .collect(Collectors.toSet());

// Person{firstName='John', lastName='Doe', age=30}
// Person{firstName='Jane', lastName='Doe', age=20}

// Person{firstName='Jane', lastName='Doe', age=20}

Parallel Stream
#

Par défaut les opérations effectuées sur un Stream sont séquentielles. Pour paralléliser les processus il suffit d’utiliser la méthode parallel.
On peut changer l’état d’un Stream au cours de son utilisation en utilisant sequential et parallel.
Bien ententu il ne s’agit pas d’utiliser parallel sur chaque Stream en espèrant un temps de traitement moins long (ça peut même être le contraire). Il conviendra donc de s’assurer de la pertinence de son utilisation.

Map
#

Les Map ne sont pas compatibles avec les Stream. Elles ont quand même le droit à leur lot de nouvelles fonctionalités.

putIfAbsent
#

Associe une valeur avec une clef seulement si la clef n’existe pas encore ou si la valeur associée à la clef vaut null.

Map<String, String> map = new HashMap<>();

assert map.putIfAbsent("key", null) == null;
assert map.get("key") == null;

assert map.putIfAbsent("key", "value") == null;
assert map.get("key").equals("value");

assert map.putIfAbsent("key", "new-value").equals("value");
assert map.get("key").equals("value");

forEach
#

Utilise un BiConsumer pour consommer tous les couples d’une Map.

Map<String, Integer> map = new HashMap<>();
map.put("un", 1);
map.put("deux", 2);
map.put("trois", 3);

map.forEach((key, value) -> System.out.printf("%s(%d) ", key, value));

// trois(3) un(1) deux(2)

computeIf
#

Permet d’appliquer une BiFunction sur les valeurs de la map.

compute
#

Si la Function retourne null, le couple est supprimé de la map.

assert map.compute("un", (key, value) -> null) == null;
assert map.compute("deux", (key, value) -> value == null ? null : value + 2) == 4;

// trois(3) deux(4) 

computeIfAbsent
#

Tente la création d’une valeur pour une clef si celle-ci n’est associée à aucune valeur (ou si elle est null) en utilisant une Function.

assert map.computeIfAbsent("un", key -> null) == 1;
assert map.computeIfAbsent("quatre", key -> 4) == 4;

// trois(3) quatre(4) un(1) deux(2)

computeIfPresent
#

Tente de mettre à jour la valeur associée à une clef si la valeur en question est non-null avec une BiFunction. Si la Function retourne null, le couple est supprimé de la Map.

Map<String, Integer> map = new HashMap<>();
map.put("un", 1);
map.put("deux", 2);
map.put("trois", 3);
map.put("quatre", null);

assert map.computeIfPresent("trois", (key, value) -> value + 5) == 8;
assert map.computeIfPresent("un", (key, value) -> null) == null;
assert map.computeIfPresent("quatre", (key, value) -> value + 5) == null;

// trois(8) quatre(null) deux(2)

remove
#

Supprime l’Entry pour la clef en argument si et seulement si la valeur associée à cette clef est égale à celle en argument.

assert map.remove("un", 1) == true;
assert map.remove("deux", 3) == false;

// trois(3) deux(2) 

getOrDefault
#

Retourne une valeur par défaut si aucune valeur n’est associée à la clef en argument.

assert map.getOrDefault("un", -1) == 1;
assert map.getOrDefault("six", -1) == -1;

merge
#

Associe la valeur non-null en argument à une clef si cette clef n’est pas déjà associée à une valeur (ou si la valeur est null), sinon applique la BiFunction sur la valeur existante.

Map<Integer, String> map = new HashMap<>();
map.put(1, "un");
map.put(2, "deux");

assert map.merge(1, " exemple", String::concat).equals("un exemple");
assert map.merge(2, "exemples", (key, value) -> null) == null;

// 1(un exemple) 

replace, replaceAll
#

Remplace une valeur associée à une clef si cette valeur est égale à celle en argument.

Map<String, Integer> map = new HashMap<>();
map.put("un", 1);
map.put("deux", 2);

assert map.replace("un", 1, 5) == true;
assert map.replace("deux", 3, 5) == false;

// un(5) deux(2)

Remplace toutes les valeurs en appliquant la BiFunction en paramètre

Map<String, Integer> map = new HashMap<>();
map.put("un", 1);
map.put("deux", 2);

map.replaceAll((key, value) -> "un".equals(key) ? value + 1 : value + 2);

assert map.get("un") == 2;
assert map.get("deux") == 4;

Date
#

Une toute nouvelle API pour les dates est disponible dans le package java.time. Elle s’inspire de Joda-Time et toutes les classes de cette API sont enfin immuables et threadsafe !

LocalTime
#

Cette classe représente une heure au sein d’une journée sans information de timezone, c’est l’heure qu’on affiche sur une horloge.

LocalTime time1 = LocalTime.of(13, 37, 26);
LocalTime time2 = LocalTime.of(15, 47, 54);

assert time1.isBefore(time2) == true;

LocalTime time3 = time1.plusMinutes(5);

assert ChronoUnit.HOURS.between(time1, time2) == 2;
assert ChronoUnit.MINUTES.between(time1, time3) == 5;

time1.format(DateTimeFormatter.ISO_LOCAL_TIME); // 13:37:26
time3.format(DateTimeFormatter.ofPattern("Ha")); // 13PM

DateTimeFormatter formatter = DateTimeFormatter
 .ofLocalizedTime(FormatStyle.SHORT)
 .withLocale(Locale.FRANCE);
LocalTime time4 = LocalTime.parse("17:17", formatter);

assert time4.getHour() == 17;
assert time4.getMinute() == 17;

LocalDate
#

Représente une date sans information d’heures, c’est ce qu’on utilise pour une date de naissance.

LocalDate today = LocalDate.now();
LocalDate tomorrow = today.plus(1, ChronoUnit.DAYS);
LocalDate yesterday = today.minusDays(1);

LocalDate birthday = LocalDate.of(2014, Month.DECEMBER, 18);
assert birthday.getDayOfWeek() == DayOfWeek.THURSDAY;

DateTimeFormatter formatter = DateTimeFormatter
 .ofLocalizedDate(FormatStyle.LONG)
 .withLocale(Locale.FRANCE);
LocalDate date = LocalDate.parse("14 juillet 2014", formatter);

assert date.getDayOfMonth() == 14;
assert date.getMonth() == Month.JULY;
assert date.getYear() == 2014;

LocalDateTime
#

Et voilà une date avec des heures mais toujours sans timezone. L’API reste toujours très similaire aux Local* précédents.

LocalDateTime time = LocalDateTime.of(2014, Month.DECEMBER, 25, 12, 10);
assert time.get(ChronoField.YEAR) == 2014;

time.format(DateTimeFormatter.ofPattern("dd/MM/yyyy HH:mm")); // 25/12/2014 12:10

ZonedDateTime
#

La version ultime avec une timezone en plus.

ZonedDateTime today = ZonedDateTime.now(ZoneId.of("Europe/Paris"));
System.out.println(today.format(DateTimeFormatter.ISO_ZONED_DATE_TIME)); 

// 2014-04-21T20:26:53.275+02:00[Europe/Paris]

ZoneId
#

Cette classe représente les timezone manipulables dans l’API.

ZoneId.getAvailableZoneIds();
// [Asia/Aden, America/Cuiaba, Etc/GMT+9, Etc/GMT+8, Africa/Nairobi, America/Marigot...

ZoneId paris = ZoneId.of("Europe/Paris");
paris.getDisplayName(TextStyle.FULL, Locale.FRENCH); // Heure d'Europe centrale
paris.getDisplayName(TextStyle.SHORT, Locale.FRENCH); // CET

Instant
#

Représente un instant au cours du temps.

Instant.parse("2007-12-03T10:15:30.00Z");

On peut récupérer cet objet un peu partout depuis l’API, par exemple

Instant now = LocalDateTime.now().atZone(ZoneId.systemDefault()).toInstant();
// 2014-04-21T19:27:26.759Z

Et il permet de créer un bon vieux java.util.Date pour la compatibilité.

Date.from(now)

Clock
#

Permet l’accès à l’Instant courant.

Instant now = Clock.system(ZoneId.of("Europe/Paris")).instant();
// 2014-04-21T19:36:37.786Z

long millis = Clock.systemDefaultZone().millis();
// 1398109144935

Duration
#

Représente une quantité de temps comme 42 secondes.

Duration twentySeconds = Duration.parse("PT20S");
assert twentySeconds.getSeconds() == 20;

Duration oneMinuteTwentySeconds = Duration.ofMinutes(1).plus(twentySeconds);
assert oneMinuteTwentySeconds.getSeconds() == 80;

LocalTime time1 = LocalTime.of(21, 30, 17);
LocalTime time2 = LocalTime.of(22, 40, 37);
Duration duration = Duration.between(time1, time2); // PT1H10M20S
assert duration.get(ChronoUnit.SECONDS) == 3600 + 600 + 20; 

Du sucre
#

StringJoiner
#

On peut enfin concaténer des String séparées par un délimiteur sans utiliser de librairies.

String join = new StringJoiner(",")
 .add("a")
 .add("b")
 .add("c")
 .toString();
assert join.equals("a,b,c");

String join = String.join(",", asList("a", "b", "c"));
assert join.equals("a,b,c");

Calendar.Builder
#

La mise en place du pattern Builder pour la classe Calendar.
Des exemples sont disponibles dans l’article http://marxsoftware.blogspot.fr/2013/05/jdk-8-calendar-builder.html.

Base64
#

Plus besoin non plus d’utiliser une librairie pour encoder des données en Base64.

Base64.getEncoder().encode("JC".getBytes()); //SkM=

Annotations
#

Les annotations peuvent être déclarées sur les utilisations des types.

Instantiation d’une classe :

new @Interned MyObject();

Cast :

myString = (@NonNull String) str;

Implémentation d’une interface :

class UnmodifiableList<T> implements
 @Readonly List<@Readonly T> { ... }

Déclaration des Exceptions:

void monitorTemperature() throws
 @Critical TemperatureException { ... }

Java 8 introduit la possibilité de rendre une annotation @Repeatable.

Vous avez déjà certainement vu le schéma d’utilisation suivant :

une annotation d’un certain type, au hasard @JoinColumn,
une seconde prenant comme paramètre un tableau d’éléments du premier type, @JoinColumns.

Et on écrivait ensuite

@JoinColumns({
 @JoinColumn(name="ADDR_ID", referencedColumnName="ID"),
 @JoinColumn(name="ADDR_ZIP", referencedColumnName="ZIP")
})
public Address getAddress() { return address; }

On peut maintenant se contenter de

@JoinColumn(name="ADDR_ID", referencedColumnName="ID"),
@JoinColumn(name="ADDR_ZIP", referencedColumnName="ZIP")
public Address getAddress() { return address; }


si l'annotation `@JoinColumn` est annotée avec `@Repeatable(JoinColumns.class)`.

Création
#

Il faut continuer de créer deux types.

public @interface Descriptions {
 Description[] value();
}

@Repeatable(Descriptions.class)
public @interface Description {
 String value();
}

@Description pourra être répétée dans utiliser @Descriptions.

@Description("toto")
@Description("tata")
public class Repeat {}

En fait c’est le compilateur qui utilisera @Descriptions de manière transparente pour l’utilisateur.

Lecture
#

Description[] byType = Repeat.class.getAnnotationsByType(Description.class);
assert byType.length == 2;

Description withoutType = Repeat.class.getAnnotation(Description.class);
assert withoutType == null;

Descriptions byContainer = Repeat.class.getAnnotation(Descriptions.class);
assert byContainer != null;
assert byContainer.value().length == 2;

On voit qu’il faut utiliser Class#getAnnotationsByType pour lire une annotation @Repeatable et que le compilateur a bien ajouté une annotation @Descriptions pour englober les @Description.

Nashorn
#

C’est un moteur Javascript executé au sein de la JVM ! Jusque là était disponible Rhino mais Nashorn est une nouvelle implémentation basée sur invokedynamic.

Il est possible d’interpréter du js en ligne de commande avec l’utilitaire jjs disponible dans le jdk.

jjs 
jjs> print("hello");
hello

Mais on peut surtout embarquer le moteur dans ses programmes Java.

ScriptEngineManager engineManager = new ScriptEngineManager();
ScriptEngine engine = engineManager.getEngineByName("nashorn");
engine.eval("function sum(a, b) { return a + b; }");

assert (int) engine.eval("sum(1, 2);") == 3;

Il existe de nombreuses possibilités d’intéraction entre votre code Java et le js évalué. L’article Oracle Nashorn: A next-generation JavaScript engine for the JVM présente toutes ces fonctionalités.

jdeps
#

Un analyseur de dépendances fait son apparition dans les outils du JDK.

jdeps -v Examples.class 
Examples.class -> /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/rt.jar
 fr.jcgay.example.java.Strings.Examples -> java.lang.AssertionError
 fr.jcgay.example.java.Strings.Examples -> java.lang.CharSequence
 fr.jcgay.example.java.Strings.Examples -> java.lang.Class
 fr.jcgay.example.java.Strings.Examples -> java.lang.Iterable
 fr.jcgay.example.java.Strings.Examples -> java.lang.Object
 fr.jcgay.example.java.Strings.Examples -> java.lang.String
 fr.jcgay.example.java.Strings.Examples -> java.util.Arrays
 fr.jcgay.example.java.Strings.Examples -> java.util.List
 fr.jcgay.example.java.Strings.Examples -> java.util.StringJoiner

Direction l’article http://marxsoftware.blogspot.fr/2014/03/jdeps.html pour en savoir plus.

Profils
#

Des sous-ensembles de l’API ont été définis et permettent de réduire la taille de la JVM : guide.

Javadoc
#

La section “Method Summary” a évoluée légèrement en regroupant maintenant les méthodes par type (Exemple).

Javadoc method summary

Un outil de validation a fait son apparition, doclint, malheureusement activé par défaut. Il y a peu de chance que votre documentation soit valide… Tout est très bien expliqué ici

Metaspace
#

La suppression de la Permanent Generation (PermGen) laisse place au Metaspace.
Java 8 from PermGen to Metaspace
Metaspace in Java 8

Sources, pour aller plus loin
#

Understanding Method References
Java 8 tutorial
10 features in Java 8 you haven’t heard of
Annotations Basics
50 nouvelles choses que l’on peut faire avec Java 8
Java time
Java 8 features

Les exceptions dans les tests unitaires

Tue, 18 Jun 2013 19:30:00 +0200

Il existe différentes solutions pour écrire des assertions sur les exceptions. Le choix de l’une ou l’autre se fait généralement selon les tests que l’on souhaite écrire… tour d’horizon des différents choix possibles.

@Test(expected) avec JUnit
#

@Test(expected = IndexOutOfBoundsException.class)
public void should_throw_exception() throws Exception {
 asList(0, 1).get(2);
}

Si le test échoue le message d’erreur est :

java.lang.AssertionError: Expected exception: java.lang.IndexOutOfBoundsException

C’est la méthode la plus simple, le code est compact et le but du test est clair. On ne peut pas effectuer d’autres assertions au sein du test (celui-ci s’arrête dès que l’exception attendue est levée), c’est un bien mais aussi un mal… Le message de l’exception n’est pas testable, ce qui est pourtant bien pratique.

@Rule ExpectedException avec JUnit
#

@Rule
public ExpectedException thrownException = ExpectedException.none();

@Test
public void should_throw_exception() throws Exception {
 thrownException.expect(IndexOutOfBoundsException.class);
 thrownException.expectMessage(containsString("2"));
 asList(0, 1).get(2);
}

Si le test échoue le message d’erreur est :

java.lang.AssertionError: Expected test to throw an instance of java.lang.IndexOutOfBoundsException

JUnit possède de nombreuses règles (@Rule) utilisables dans les tests. Celle-ci est dédiée aux exceptions. Cette solution permet, contrairement à la première, de réaliser des assertions plus précises sur l’exception levée. On peut vérifier le message, la présence ou non de cause, etc. En utilisant des matchers Hamcrest le message est testable de manière fine.

Je trouve dommage de devoir écrire ses assertions avant l’appel au code testé, l’ordre de lecture se retrouve inversé mais on s’en accommode assez bien.

@Test(expectedExceptions) avec TestNG
#

@Test(expectedExceptions = IndexOutOfBoundsException.class, expectedExceptionsMessageRegExp = "2")
public void should_throw_exception() throws Exception {
 asList(0, 1).get(2);
}

Si le test échoue le message d’erreur est :

Method TestNGExpectedTest.should_fail_because_no_exception_is_thrown()[...] should have thrown an exception of class java.lang.IndexOutOfBoundsException

Quand le message ne correspond pas :

org.testng.TestException: The exception was thrown with the wrong message: expected "2" but got "3"

Cette méthode avec TestNG ressemble beaucoup à celle de JUnit sauf que l’on peut tester le message ! Pratique et suffisant dans la majorité des cas. On utilise une expression régulière pour valider le message.

Etrangement expectedExceptions permet de renseigner un tableau d’Exception attendues, pas sûr que celà serve la lecture et la robustesse du test…

try / fail / catch
#

@Test
public void should_trow_exception() throws Exception {
 try {
 asList(0, 1).get(2);
 failBecauseExceptionWasNotThrown(IndexOutOfBoundsException.class);
 } catch (IndexOutOfBoundsException e) {
 assertThat(e).hasNoCause()
 .hasMessage("2");
 }
}

Si le test échoue le message d’erreur est :

java.lang.AssertionError: Expected IndexOutOfBoundsException to be thrown

Quand les autres solutions ne suffisent pas, par exemple pour tester un type personnalisé avec des données spécifiques ou pour vérifier la cause d’une exception, on peut toujours se reposer sur cette solution. Le test produit est assez verbeux mais le plus gros problème à mon sens est l’oubli du fail(). Si les tests sont écrits après le code de production, il est malheureusement assez facile de l’oublier au sein du bloc try.

catch-exception
#

@Test
public void should_throw_exception() throws Exception {

 catchException(asList(0, 1)).get(2);

 assertThat(caughtException())
 .isInstanceOf(IndexOutOfBoundsException.class)
 .hasMessage("2")
 .hasNoCause();
}

Si le test échoue le message d’erreur est :

java.lang.AssertionError: Expecting actual not to be null

catch-exception permet également de tester l’exception levée de manière très précise mais possède l’avantage de ne pas devoir écrire ses assertions dans le bloc catch. Plus de soucis d’oubli du fail() (caughtException() retourne null si aucune exception n’est levée). Le code est également moins verbeux que le try / catch / fail.

L’outil possède d’autres variantes d’écriture documentées sur son site. La forme présentée ici est celle que je préfère, puisque malheureusement la version BDD repose sur l’utilisation de FEST-assert 1.4.

Conclusion
#

Avec TestNG, j’utilise expectedExceptions quand le type de l’exception et son message sont suffisants pour mon test. Sinon avec JUnit ou pour des tests plus précis, j’utilise catch-exception avec AssertJ.

De la couleur dans les logs

Sat, 04 May 2013 18:22:00 +0200

Dans la quête de couleur, je me suis intéressé aux logs des applications Java. En fait il est très simple de configurer les différents frameworks de logs pour éclairer son quotidien.

Logback
#

L’implémentation ConsoleAppender expose une propriété withJansi qui permet d’activer la coloration des logs. Il suffit ensuite d’utiliser un des pattern disponibles dans PatternLayout (celui configuré par défaut) pour customiser ses logs :

%red, %boldRed, etc
%highlight

Ces mots clefs sont censés encapsuler d’autres expressions. La couleur sera appliquée sur l’expression contenue entre parenthèses.

[%thread] %highlight(%-5level) %cyan(%logger{15}) - %msg %n

%highlight est une conversion qui permet de séparer les différents niveaux de logs. Une erreur sera affichée en rouge et en gras, un warn en rouge et un info en bleu.

<configuration>
 <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
 <withJansi>true</withJansi>
 <encoder>
 <pattern>%d{HH:mm:ss.SSS} [%thread] %highlight(%-5level) %logger{36} - %msg%n</pattern>
 </encoder>
 </appender>

 <root level="trace">
 <appender-ref ref="STDOUT" />
 </root>
</configuration>

Sous Windows il est nécessaire d’ajouter la librairie Jansi à l’exécution de l’application.

<dependency>
 <groupId>org.fusesource.jansi</groupId>
 <artifactId>jansi</artifactId>
 <version>1.10</version>
 <scope>runtime</scope>
</dependency>

Documentation officielle : http://logback.qos.ch/manual/layouts.html#coloring

Log4j 2.0
#

Dans la nouvelle version de Log4j, le pattern %highlight est également disponible dans l’implémentation PatternLayout. Les couleurs par défaut sont différentes de celles de Logback mais il est possible de les surcharger :

%highlight{%d [%t] %-5level: %msg%n%throwable}{FATAL=white, ERROR=red, WARN=blue, INFO=black, DEBUG=green, TRACE=blue}

voir même d’utiliser les mêmes codes couleurs que Logback :

%highlight{%d [%t] %-5level: %msg%n%throwable}{STYLE=Logback}

Le deuxième pattern disponible est %style{pattern}{ANSI style}. Il permet de choisir une couleur pour une portion de texte. La liste complète des couleurs est disponible dans la documentation de Log4j 2.

<?xml version="1.0" encoding="UTF-8"?>
<configuration status="OFF">
 <appenders>
 <Console name="Console" target="SYSTEM_OUT">
 <PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %highlight{%-5level} %logger{36} - %msg%n"/>
 </Console>
 </appenders>
 <loggers>
 <root level="trace">
 <appender-ref ref="Console"/>
 </root>
 </loggers>
</configuration>

Sous Windows il est nécessaire d’ajouter la librairie Jansi à l’exécution de l’application.

<dependency>
 <groupId>org.fusesource.jansi</groupId>
 <artifactId>jansi</artifactId>
 <version>1.10</version>
 <scope>runtime</scope>
</dependency>

Log4j
#

Pas de solution officielle disponible pour le bon vieux Log4j… J’ai écrit un Appender et un Layout (logj4-color) qui permettent d’utiliser le pattern #highlight pour coloriser les logs. Les couleurs utilisées sont :

FATAL, rouge
ERROR, rouge
WARN, jaune
INFO, gras

L’appender AnsiConsoleAppender doit être utilisé sous Windows. Sinon le ConsoleAppender suffit.

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">
 <appender name="console" class="com.github.jcgay.log4j.color.appender.AnsiConsoleAppender">
 <param name="Target" value="System.out"/>
 <layout class="com.github.jcgay.log4j.color.layout.ColorEnhancedPatternLayout">
 <param name="ConversionPattern" value="#highlight(%-5p) %c{1} - %m%n"/>
 </layout>
 </appender>

 <root>
 <priority value ="trace" />
 <appender-ref ref="console" />
 </root>

</log4j:configuration>

Il suffit d’ajouter la librairie log4j-color à l’exécution de l’application.

<project>
 ...
 <repositories>
 <repository>
 <id>jcgay-releases</id>
 <url>https://repository-jcgay.forge.cloudbees.com/release/</url>
 </repository>
 </repositories>
 ...
 <dependencies>
 <dependency>
 <groupId>com.github.jcgay.log4j</groupId>
 <artifactId>log4j-color</artifactId>
 <version>0.1</version>
 <scope>runtime</scope>
 </dependency>
 </dependencies>
 ...
</project>

Plugins pour les IDE
#

Pour profiter de toutes ces couleurs dans son IDE préféré, il faudra utiliser des plugins pour améliorer les consoles disponibles : IntelliJ Idea : Grep Console Eclipse : Ansi Console

JRebel, le redéploiement c'est à chaud !

Sat, 02 Feb 2013 16:12:00 +0200

Quand on développe des applications web Java EE, on passe généralement son temps à redéployer son application et redémarrer son conteneur… Heureusement on peut compter depuis un moment sur JRebel pour grandement augmenter sa productivité lors des développements en permettant le rechargement à chaud des modifications de façon plus poussé que le Hot Swap intégré à la JVM.

Fonctionnement
#

JRebel est un agent java qui va surveiller les modifications de notre application et les appliquées au sein de la JVM à chaud. Pour celà, l’agent va scanner le classpath à la recherche de fichiers rebel.xml décrivant les ressources à surveiller.

Installation
#

La documentation de JRebel met l’accent sur l’intégration avec les IDE (Eclipse, IntelliJ Idea, Netbeans, MyEclipse) et est très bien faite : JRebel IDE Plugins Personnellement j’utilise rarement les fonctionnalités de déploiement intégrés dans les IDE (peut-être à cause de wtp dans Eclipse…) et préfère utilisé un serveur embedded (dans un plugin Maven par exemple) ou même directement le serveur d’application installé sur mon poste.

On a donc besoin de télécharger une archive de JRebel, disponible ici : Télécharger JRebel

Une fois dezippé, il faut exécuter la configuration de JRebel via bin/jrebel-config.{cmd|sh} et suivre les instructions de l’assistant. Pour ajouter l’agent JRebel à la JVM : -noverify -javaagent:$JREBEL_HOME/jrebel.jar

Configuration de votre application
#

Il faut maintenant s’intéresser à la génération des fichiers de configuration rebel.xml. Il existe un plugin Maven pour faire le travail à notre place : http://zeroturnaround.com/software/jrebel/maven/

<plugin>
 <groupId>org.zeroturnaround</groupId>
 <artifactId>jrebel-maven-plugin</artifactId>
 <version>1.1.3</version>
 <configuration>
 <classpath>
 <resources>
 <resource>
 <includes>
 <include>com/github/jcgay/**</include>
 </includes>
 </resource>
 <resource>
 <directory>src/main/resources</directory>
 </resource>
 </resources>
 </classpath>
 </configuration>
 <executions>
 <execution>
 <id>generate-rebel-xml</id>
 <phase>generate-resources</phase>
 <goals>
 <goal>generate</goal>
 </goals>
 </execution>
 </executions>
</plugin>

Le plugin se base sur le type de votre module pour générer la configuration par défaut (pour par exemple intégrer src/main/webapp aux ressources surveillées). Ce comportement peut-être surchargé si par exemple votre webapp utilise le type maven jar en utilisant war au sein de la configuration du plugin. Le plugin fonctionne très bien au sein des projets multi-module. On peut filtrer avec des include/exclude les ressources à intégrer dans le rechargement de JRebel.

Les chemins générés au sein de la configuration sont absolus par défaut (donc spécifique à votre environnement), il est possible de variabiliser les chemins générés pour les rendre relatifs. Je n’ai jamais utilisé la fonctionalité (je ne package pas la configuration JRebel dans mes artifacts finaux) mais c’est toujours bon à savoir.

Toutes les possibilités de configuration du rebel.xml sont décrites ici : documentation rebel.xml

Vérification du fonctionnement
#

Si l’agent est correctement configuré, on obtient au lancement de la JVM :

[2013-01-25 16:16:04] #############################################################
[2013-01-25 16:16:04] 
[2013-01-25 16:16:04] JRebel 5.1.1 (201211271929)
[2013-01-25 16:16:04] (c) Copyright ZeroTurnaround OU, Estonia, Tartu.
[2013-01-25 16:16:04] 
[2013-01-25 16:16:04] Over the last 30 days JRebel prevented 
[2013-01-25 16:16:04] at least 95 redeploys/restarts saving you about 3.9 hours.
[2013-01-25 16:16:04] 
[2013-01-25 16:16:04] This product is licensed to ******
[2013-01-25 16:16:04] 
[2013-01-25 16:16:04] The following plugins are disabled at the moment: 
[2013-01-25 16:16:04] * Click plugin (set -Drebel.click_plugin=true to enable)
[2013-01-25 16:16:04] * JRuby Plugin (set -Drebel.jruby_plugin=true to enable)
[2013-01-25 16:16:04] * Jersey plugin (set -Drebel.jersey_plugin=true to enable)
[2013-01-25 16:16:04] * Oracle ADF Core plugin (set -Drebel.adf_core_plugin=true to enable)
[2013-01-25 16:16:04] * Oracle ADF Faces plugin (set -Drebel.adf_faces_plugin=true to enable)
[2013-01-25 16:16:04] * RESTlet plugin (set -Drebel.restlet_plugin=true to enable)
[2013-01-25 16:16:04] * Seam-Wicket plugin (set -Drebel.seam_wicket_plugin=true to enable)
[2013-01-25 16:16:04] * Spring Data Plugin (set -Drebel.spring_data_plugin=true to enable)
[2013-01-25 16:16:04] * WebObjects plugin (set -Drebel.webobjects_plugin=true to enable)
[2013-01-25 16:16:04] 
[2013-01-25 16:16:04] #############################################################

Puis les ressources qui sont surveillées :

[2013-01-25 16:16:06] JRebel: Directory '/home/jcgay/dev/app/target/classes' will be monitored for changes.
[2013-01-25 16:16:06] JRebel: Directory '/home/jcgay/dev/app/src/main/webapp' will be monitored for changes.
[2013-01-25 16:16:06] JRebel: Directory '/home/jcgay/dev/app/src/main/resources will be monitored for changes.

Les classes seront maintenant rechargées dès qu’elles sont compilées depuis l’IDE (pour peu que celui ci soit bien configuré pour compiler les classes au même endroit que Maven).

Les ressources sont rechargées après un hit sur le serveur d’application. Pour chaque ressource rechargée, une entrée est loggée :

[2012-12-20 11:33:56] JRebel: Reloading class 'com.github.jcgay.app.Person'.

Notes
#

La génération de la configuration via le plugin Maven est liée à la phase “generate-resources”. Il est possible que le reste du build écrase cette configuration (par exemple de l’overlay de war, ou du tissage d’aspect à partir du build d’un war dans ses modules). Génaralement dans ce cas je change la phase d’exécution du plugin Maven pour une phase postérieure à celle qui pose problème…
Attention à bien cocher “I use Maven to build my application” dans l’assistant de configuration de JRebel, sinon vous verrez surement le monitoring de plugin JRebel correctement s’activé mais pas celui des ressources de l’application.
Dans IntelliJ Idea, pour que la compilation se fasse bien dans le même répertoire que Maven, il faut cocher “Use Maven output directories”.
Toujours dans Idea, si l’on utilise le debugger, celui si se retrouvera désynchronisé dès la prise en compte d’un rechargement à chaud. Dans ce cas il faut installer le plugin JRebel, et ajouter la propriété -Drebel.debugger_integration=true au lancement de la JVM.

Spring et les profils

Wed, 09 May 2012 19:55:00 +0200

Une des fonctionnalités apportées par la version 3.1 de Spring est la gestion des profils.

Récemment, pour une application web, j’ai eu besoin de définir des comportements spécifiques dans mon environnement de développement pour ne pas interroger des services externes, inaccessible depuis mon poste.

Le besoin est donc simple, charger des implémentations de service différentes selon l’environnement d’exécution de l’application. Et c’est là qu’entre en jeux les profils ! Ceux ci permettent de charger des beans différents dans le contexte Spring selon le(s) profil(s) configurés.

Configuration XML
#

Un fichier par profil
#

Il est possible de spécifier un profil dès la balise racine, celà implique que tout le contenu du fichier ne sera chargé que si le profil correspondant est activé.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.springframework.org/schema/beans
 http://www.springframework.org/schema/beans/spring-beans-3.1.xsd"
 profile="a">

 <bean class="com.github.jcgay.example.spring.BeanA" />

</beans>

Le bean n’est chargé que si le profile “a” est actif. Les beans définis en dehors de ce fichier de configuration seront accessibles dans tous les cas.

Blocs au sein d’un même fichier
#

On peut également définir des blocs de profils au sein d’un même fichier de configuration.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.springframework.org/schema/beans
 http://www.springframework.org/schema/beans/spring-beans-3.1.xsd">

 <bean class="com.github.jcgay.example.spring.BeanA" />

 <beans profile="b">
 <bean class="com.github.jcgay.example.spring.BeanB" />
 </beans>

</beans>

Le bean A est chargé dans tous les cas, le B seulement quand le profil “b” est actif.

Mutualisation de configuration pour plusieurs profils
#

Pour ne pas répéter la configuration de beans dans plusieurs profils, on peut déclarer des blocs valides pour ces différents profils.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.springframework.org/schema/beans
 http://www.springframework.org/schema/beans/spring-beans-3.1.xsd">

 <beans profile="a,b">
 <bean class="com.github.jcgay.example.spring.BeanA" />
 <bean class="com.github.jcgay.example.spring.BeanB" />
 </beans>

 <beans profile="a">
 <bean class="com.github.jcgay.example.spring.BeanC" />
 </beans>

 <beans profile="b">
 <bean class="com.github.jcgay.example.spring.BeanD" />
 </beans>

</beans>

Le profil “a” contient les beans A,B et C tandis que le profil “b” comprends les beans A,B et D. La déclaration de A et B est mutualisée.

Configuration par annotation
#

On peut également définir des profils via les annotations Spring. L’annotation @Profile peut être utilisé sur les différents stéréotypes disponibles (@Service, @Component, @Configuration, etc).

Au niveau @Configuration
#

@Configuration
@Profile("a")
public class ProfileA {

 @Bean
 public BeanA beanA() {
 return new BeanA();
 }
}

Tous les beans définis dans cette classe sont accessibles quand le profil “a” correspondant est actif.

Comme avec le modèle XML, il est possible de mutualiser la définition des profils.

@Configuration
@Profile({"a", "b"})
public class MultipleProfiles {

 @Bean
 public BeanA beanA() {
 return new BeanA();
 }

 @Bean
 public BeanB beanB() {
 return new BeanB();
 }
}

On peut annoter directement un composant Spring sans passer par des @Configuration.

@Component
@Profile("e")
public class BeanE {
}

Et enfin on peut utiliser @Profile comme meta-annotation et donc créer ses propres annotations au lieu de répeter le nom du profil un peu partout.

@Profile("a")
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface CustomProfile {
}

Et voilà on peut utiliser @CustomProfile pour construire le profil “a”.

Activation d’un profil
#

L’option -Dspring.profiles.active=a en ligne de commande active le profil “a”. Pour activer plusieurs profils il faut les séparer par des virgules.

Ou alors, en variable d’environnement : export spring.profiles.active=a

Dans le cadre d’une application web, le choix du profil peut être passé en paramètre de la servlet :

<servlet>
 <servlet-name>dispatcher</servlet-name>
 <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
 <init-param>
 <param-name>spring.profiles.active</param-name>
 <param-value>a</param-value>
 </init-param>
</servlet>

ou en paramètre du listener :

<context-param>
	<param-name>contextConfigLocation</param-name>
	<param-value>/WEB-INF/applicationContext*.xml</param-value>
</context-param>
<context-param>
	<param-name>spring.profiles.active</param-name>
	<param-value>a</param-value>
</context-param>

<listener>
	<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

Définir un profil par défaut
#

La clef spring.profiles.default permet de choisir un profil qui sera activé automatiquement si aucun autre n’a été défini. Pratique si par exemple on veut que l’application charge une configuration type “production” si aucun profil n’est spécifié.

Pour finir, pour les utilisateurs IntelliJ IDEA, il y a une fonctionnalité plutôt sympa qui permet de filtrer la configuration Spring selon le profil actif : http://blogs.jetbrains.com/idea/2011/04/new-in-105-spring-31-bean-definition-profiles/

Java on Jean-Christophe Gay

Tester son code Java avec Groovy et Spock

Mise en place #

Maven #

Gradle #

Spécification #

Squelette #

Blocs #

setup, given #

when, then #

expect #

cleanup #

where #

Assertions (conditions) #

Vérification des exceptions #

Mock #

Création #

interaction #

Définition retour des méthodes #

Stub, Spy, Partial mock #

Tests paramétrés #

Data Tables #

Data Pipes #

Test génératifs #

Extensions #

Documentation #

Conclusion #

Encore ? #

Ecrire une migration Liquibase en Java

Implémenter un CustomChange #

Configurer son changeset #

A la découverte de Java 8

Default methods sur les Interfaces #

Expressions Lambda #

Accès variable locale #

Membre et variable static #

Functional Interfaces #

Lambda #

Function, Predicate, etc #

Function #

BiFunction #

UnaryOperator #

BinaryOperator #

Predicate #

BiPredicate #

Supplier #

Consumer #

Comparator #

A retenir #

Surcharge de méthode #

Références de méthodes #

Fonctionnement #

statique #

instance #

instance arbitraire #

Optional #

Stream #

forEach #

filter #

sorted #

map #

allMatch, anyMatch, noneMatch #

count #

sum #

reduce #

collect #

concat #

findFirst, findAny #

flatMap #

limit, skip #

min, max #

peek #

Parallel Stream #

Map #

putIfAbsent #

forEach #

computeIf #

compute #

computeIfAbsent #

computeIfPresent #

Mise en place
#

Maven
#

Gradle
#

Spécification
#

Squelette
#

Blocs
#

setup, given
#

when, then
#

expect
#

cleanup
#

where
#

Assertions (conditions)
#

Vérification des exceptions
#

Mock
#

Création
#

interaction
#

Définition retour des méthodes
#

Stub, Spy, Partial mock
#

Tests paramétrés
#

Data Tables
#

Data Pipes
#

Test génératifs
#

Extensions
#

Documentation
#

Conclusion
#

Encore ?
#

Implémenter un CustomChange
#

Configurer son changeset
#

Default methods sur les Interfaces
#

Expressions Lambda
#

Accès variable locale
#

Membre et variable static
#

Functional Interfaces
#

Lambda
#

Function, Predicate, etc
#

Function
#

BiFunction
#

UnaryOperator
#

BinaryOperator
#

Predicate
#

BiPredicate
#

Supplier
#

Consumer
#

Comparator
#

A retenir
#

Surcharge de méthode
#

Références de méthodes
#

Fonctionnement
#

statique
#

instance
#

instance arbitraire
#

Optional
#

Stream
#

forEach
#

filter
#

sorted
#

map
#

allMatch, anyMatch, noneMatch
#

count
#

sum
#

reduce
#

collect
#

concat
#

findFirst, findAny
#

flatMap
#

limit, skip
#

min, max
#

peek
#

Parallel Stream
#

Map
#

putIfAbsent
#

forEach
#

computeIf
#

compute
#

computeIfAbsent
#

computeIfPresent
#

remove
#

getOrDefault
#

merge
#

replace, replaceAll
#