Programmation fonctionnelle en Java

Version imprimable

Hello world!
J'aimerais votre avis sur le fait de faire de la programmation fonctionnelle en Java. Il existe depuis Java 8 des interfaces et des fonctions lambda mais je trouve leur utilisations un peu pénible.

En ayant suivi ce tuto sur ce site:
https://dzone.com/articles/functiona...ramming-java-8

J'en suis arrivé à expérimenter l'implémentation de quelques fonctions triviales.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 package univ.cours.sio; import java.util.function.BinaryOperator; import java.util.function.Function; import java.util.function.UnaryOperator; import univ.cours.utils.Utils; /** * fonctional skills in java */ public class App { public static void main( String[] args ) { Function<Integer, UnaryOperator<Integer>> makeAdder = Utils::adder; Function<Integer, UnaryOperator<Integer>> makeMultiplier = Utils::multiplier; UnaryOperator<Integer> add1 = makeAdder.apply(1); UnaryOperator<Integer> multiply5 = makeMultiplier.apply(5); BinaryOperator<UnaryOperator<Integer>> compose = (f, g) -> x -> g.apply(f.apply(x)); UnaryOperator<Integer> operation = compose.apply(add1, multiply5); Function<String, Integer> atoi = s -> Integer.valueOf(s); Integer result = operation.apply(10); System.out.println(result); } }
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 package univ.cours.utils; import java.util.function.UnaryOperator; public class Utils { public static UnaryOperator<Integer> adder(Integer y) { return x -> x + y; } public static UnaryOperator<Integer> multiplier(Integer y) { return x -> x * y; } }
Je sais que la programmation fonctionelle est un paradigme assez pratique. J'aime beaucoup le fait de respecter l'immutabilité des objets (philosophie adopté par certains framework comme React), de chainé les appels de méthodes (map, filter, reduce) et de déclarer des fonctions anonymes ect.
Je sais que le langage Scala est parfaitement adapté, mais j'aimerais tout de même pouvoir faire du fonctionnel en Java.

Faites-vous de la programmation fonctionnelle avec Java ou utilisez-vous plutôt un langage plus adapté comme Scala ?

Votre retour d'expérience m'intéresse. :)

04/09/2018, 21h22
adiGuba

Salut,

Mon plus gros problème avec la programmation fonctionnelle sous Java, c'est la gestion des exceptions.
Cela s'adapte assez mal avec la notion de "checked" exception de Java.

Du coup il fait parfois bidouiller pour simplement remonter l'exception.
10/09/2018, 13h30
deltree

Citation:

Envoyé par adiGuba

Salut,

Mon plus gros problème avec la programmation fonctionnelle sous Java, c'est la gestion des exceptions.
Cela s'adapte assez mal avec la notion de "checked" exception de Java.

Du coup il fait parfois bidouiller pour simplement remonter l'exception.

De plus en plus on programme en RuntimeException, en tout cas je l'ai vu sur certains frameworks, on peut wrapper simplement nos exception dans une ou plusieurs Runtime Custom (faire ses propres implem pour typer finement) en gardant la cause comme origine si c'est une checked. Même en programmation classique, se trainer la checked depuis toutes les couches d'interface DAO jusqu'au couches services ou écrans, c'est finalement assez inutile.
11/09/2018, 08h57
adiGuba

Oui mais si on doit utiliser une API qui utilise des checked-exceptions (et il y en a beaucoup) on se retrouve à devoir faire des try/catch dans tous les sens et encapsuler les exceptions.

C'edt particulièrement fastidieux, illisible, et encore moins facile de gérer les erreurs...
11/09/2018, 15h45
professeur shadoko

Citation:

Envoyé par deltree

. Même en programmation classique, se trainer la checked depuis toutes les couches d'interface DAO jusqu'au couches services ou écrans, c'est finalement assez inutile.

C'est une opinion assez répandue ... mais ce n'est pas la mienne (même sur le dernier gros projet, très complexe, sur lequel j'ai travaillé ça permettait au contraire de nous forcer à réfléchir à des dispositifs intermédiaires très propres - bon d'acc: il y avait très peu de code sous forme de "flow"-).

J'ai une préférence personnelle pour les unchecked-exceptions, mais les checked-exceptions n'avait jamais été un gros problème pour moi jusque là.

Avec les interfaces fonctionnelles cela s'avère souvent fastidieux.

Exemple tout bête : ce code là ne peut pas marcher car Files.lines() peut remonter une IOException.

Code:

1
2
3
4
5
6
7
8
9
10
	public Set<String> getAllWords(Path directory) throws IOException {
		Pattern separator = Pattern.compile("\\W+");
		return Files.walk(directory)  // On recherche tous les fichier du répertoire
			.filter(p -> p.getFileName().toString().endsWith(".java")) // Avec l'extension .java
			.flatMap(p -> Files.lines(p, StandardCharsets.UTF_8)) // Dont on lit toutes les lignes
			.map(String::trim) // On supprime les blancs
			.filter(s -> !s.isEmpty()) // On ignore les lignes vides
			.flatMap(line -> separator.splitAsStream(line)) // Et on y recherche toutes les mots
			.collect(Collectors.toSet()); // Que l'on rajoute dans un Set
	}

Il faut impérativement traiter l'exception, ce qui alourdit considérablement la chose :

Code:

.flatMap(p -> Files.lines(p, StandardCharsets.UTF_8)) // Dont on lit toutes les lignes

Devient :

Code:

1
2
3
4
5
6
7
.flatMap(p -> {
   try {
       return Files.lines(p, StandardCharsets.UTF_8);
   } catch (IOException e) {
       throw new UndeclaredThrowableException(e);
   }
}) // Dont on lit toutes les lignes

:arrow: En plus d'être bien lourd, je trouve le code moins propre puisqu'il ne remonte plus directement une IOException.
Si je veux que ce soit bien propre et que ca me remonte une IOException, je dois retraiter l'exception :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
	public Set<String> getAllWords(Path directory) throws IOException {
		Pattern separator = Pattern.compile("\\W+");
		try {
			return Files.walk(directory)  // On recherche tous les fichier du répertoire
				.filter(p -> p.getFileName().toString().endsWith(".java")) // Avec l'extension .java
				.flatMap(p -> {
					try {
						return Files.lines(p, StandardCharsets.UTF_8);
					} catch (IOException e) {
						throw new UneUncheckedExceptionPerso(e);
					}
				}) // Dont on lit toutes les lignes
				.map(String::trim) // On supprime les blancs
				.filter(s -> !s.isEmpty()) // On ignore les lignes vides
				.flatMap(line -> separator.splitAsStream(line)) // Et on y recherche toutes les mots
				.collect(Collectors.toSet()); // Que l'on rajoute dans un Set
		} catch (UneUncheckedExceptionPerso e) {
			throw e.getOriginalIOException();
		}
	}

Pour peu qu'il y ait plusieurs unchecked-exception ca devient atroce !

Il existe sur le Net plusieurs versions de classes qui servent à relancer des exceptions sans devoir les déclarer :
Par exemple
http://www-sop.inria.fr/oasis/proact...ower.java.html
basée sur javassist,

mais on peut le faire aussi avec ByteBuddy

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
 
interface Thrower {
    public void throwException(final Throwable t);
}
 
public class ExceptionThrower {
    private static final Logger LOGGER = LoggerFactory.getLogger(MethodHandles.lookup().lookupClass());
 
    enum ThrowThrowable implements StackManipulation {
 
        INSTANCE; // singleton
 
        @Override
        public boolean isValid() {
            return true;
        }
 
        @Override
        public Size apply(MethodVisitor methodVisitor, Implementation.Context implementationContext) {
            methodVisitor.visitVarInsn(Opcodes.ALOAD, 1);
            methodVisitor.visitInsn(Opcodes.ATHROW);
            return new Size(1, 2);
        }
    }
 
    static enum ThrowExceptionMethod implements ByteCodeAppender {
        INSTANCE;
 
        @Override
        public Size apply(MethodVisitor methodVisitor, Context implementationContext, MethodDescription instrumentedMethod) {
            StackManipulation.Size operandStackSize = new StackManipulation.Compound(
                    ThrowThrowable.INSTANCE).apply(methodVisitor, implementationContext);
 
            return new Size(operandStackSize.getMaximalSize(), instrumentedMethod.getStackSize());
        }
 
    }
 
    static enum ThrowExceptionImpl implements Implementation {
        INSTANCE;
 
        @Override
        public InstrumentedType prepare(InstrumentedType instrumentedType) {
            return instrumentedType;
        }
 
        @Override
        public ByteCodeAppender appender(Target implementationTarget) {
            return ThrowExceptionMethod.INSTANCE;
        }
    }
 
    private static Thrower thrower = null;
 
    private static void loadClassByteBuddy() {
        try {
            @SuppressWarnings("unchecked")
            Class<Thrower> dynamicType = (Class<Thrower>) new ByteBuddy().with(new NamingStrategy.AbstractBase() {
 
                @Override
                protected String name(TypeDescription superClass) {
 
                    return ExceptionThrower.class.getPackage().getName() + ".TheActualExceptionThrower";
                }
            })
                    .subclass(Thrower.class, ConstructorStrategy.Default.DEFAULT_CONSTRUCTOR)
                    .method(ElementMatchers.named("throwException"))
                    .intercept(ThrowExceptionImpl.INSTANCE)
                    .make().load(ExceptionThrower.class.getClassLoader())
                    .getLoaded();
 
            thrower = dynamicType.newInstance();
        }
        catch (final Exception e) {
            LOGGER.error("Internal error initializing Thrower with ByteBuddy");
        }
    }
 
    /* The first time the mechanism is used, it has to initialize the thrower */
    private static void activate() {
        loadClassByteBuddy();
    }
 
    public synchronized static void throwException(final Throwable t) {
        if (thrower == null) {
            activate();
        }
 
        if (thrower != null) {
            thrower.throwException(t);
        }
    }
}

Avec ce genre de classe vous ne devez pas envelopper l'exception originale pour la relancer :

Code:

1
2
3
4
5

catch (IOException e) {
    ExceptionThrower.throwException(e);
}

18/09/2018, 22h14
adiGuba
C'est quand même sortir l'artillerie lourde... 😕

Au passage il existe aussi des solutions plus simple basé sur les Générics en jouant avec l'erasure..

Mais c'est pas forcément mieux de mon point de vue :
- Il faut quand même utiliser un try/catch pour intercepter l'exception et appeller cette méthode de rethrow...
- Le rethrow de l'exception n'est pas visible par le compilateur, ce qui fait qu'il faut parfois bidouiller en rajoutant un return ou un throw bidon...
- On ne peut plus catcher l'exception facilement. Le compilateur refusera de nous laisser utiliser un try/catch avec une checked-exception si elle n'est déclarée dans aucune des méthodes...

Et le code utilisant les generics est :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
 
public final class ExceptionThrower{
    private ExceptionThrower(){}
 
    public static void throwException(final Throwable ex){
        ExceptionThrower.<RuntimeException>throwsUnchecked(ex);
    }
 
    private static <T extends Throwable> void throwsUnchecked(final Throwable toThrow) throws T {
        throw (T) toThrow;
    }
}