-
Une histoire de temps et de tests
Le temps, c’est compliqué, ça change tout le temps. Et je ne parle pas de météo, mais bien du temps qui passe. Et c’est justement parce qu’il passe que ça change.
Bon, je vais m’arrêter là avec les pensées profondes. Je n’ai pas prévu de marquer l’histoire de la philosophie avec ce billet. Ce qui m’intéresse ici, c’est de pouvoir tester des méthodes qui utilisent des objets temporels, et plus précisément des objets du package récent
java.time:Instant.now(),LocalDateTime.now(),ZonedDateTime.now(),…Partons sur ce petit exemple, dans lequel on choisit une activité distincte en fonction de l’heure de la journée.
public class ActivityService { private final Action action; public ActivityService(Action action) { this.action = action; } public void chooseActivity() { if (LocalDateTime.now().get(ChronoField.AMPM_OF_DAY) == 0) { action.doSleep(); } else { action.doPlay(); } } }En utilisant le code tel quel,
action.doSleep()est appelé si le test est exécuté le matin etaction.doPlay()si le code est appelé l’après-midi. Voyons comment adapter le code pour qu’on puisse développer tester de façon reproductible. -
Quand est-ce qu'on change d'heure ?
C’est assez facile à retrouver. Nous passerons à l’heure d’été le dernier dimanche de mars, à 2h00, puis nous repasserons à l’heure d’hiver le dernier dimanche d’octobre, à 3h00.
Ce qui m’intéresse c’est que mon code puisse connaitre cette information. Et comme je veux gérer ça dans mon backend en Java, voyons voir ce que les APIs du JDK proposent.
TLDR Toutes les informations sont disponibles via des méthodes publiques depuis le JDK 8, dans le package
java.time. -
WildFly 25, la promotion d'elytron
Depuis la version 11, WildFly est livré avec 2 sous-systèmes de sécurité, PicketBox et Elytron. PicketBox était actif par défaut, et un script jboss-cli permettait de passer sous Elytron. Depuis WildFly 25, Elytron a été promu au rang de sous-système de sécurité par défaut.
Ce billet était initialement publié sur le site de Sewatech. Il a migré ici suite à l’abandon de la section Articles. -
Passer des arguments au build de Docker
Depuis quelques années, je gère un repository sur GitHub pour que chacun puisse faire un build à partir du code source de JBoss EAP. Récemment, j’ai voulu automatiser ce build avec Docker, sur plusieurs systèmes (Debian, CentOS, Alpine), pour plusieurs versions du JDK (8 et 11) et pour plusieurs versions de JBoss EAP.
C’est là que j’ai découvert la possibilité d’utiliser des arguments dans
Dockerfileet de les passer en option dedocker build. Ainsi, je peux choisir les versions du JDK et de JBoss EAP au lancement du build :~# docker build --build-arg JDK_VERSION=8 --build-arg EAP_VERSION=7.2.3 \ --tag hasalex/eap:7.2.3_jdk8 .Voyons pourquoi et comment j’en suis arrivé à ce résultat…
-
Sortie du JDK 17
Maintenant que la sortie d’une nouvelle version du JDK est devenu une routine, l’événement est l’arrivée d’une version LTS.
Voyons ce que cette version 17 nous apporte au niveau du langage, du runtime et des API.
Ce billet était initialement publié sur le site de Sewatech. Il a migré ici suite à l’abandon de la section Articles.
Alexis Hassler
J'ai créé la société Sewatech en 2005, pour y exercer mon métier de développeur full stack, à dominante back end.
Vous pouvez me contacter si vous cherchez un développeur indépendant expérimenté (plus de 25 ans d'expérience) pour intégrer votre équipe de projet. Je peux aussi intervenir pour un audit ou une mission de conseil.
Enfin, je donne des formations sur Spring, Vert.x, WildFly,... en intra sur site ou à distance.
