Suite aux premières annonces de distanciation sociale ( avant que le confinement soit effectif ) j’ai acheté en catastrophe un PC portable. Les critères étaient : 8Go de RAM, un disque SSD … et la compatibilité GNU/LINUX :).

N’ayant pas trop de temps pour chercher la bonne affaire ( technologique et financière ), j’ ai acheté un Dell Inspiron 14-3493.

Je n’ai pas pris trop de risques. Bien que livré avec Windows 10, ce modèle est déjà certifié compatible Ubuntu.
L’installation d’Ubuntu se passe très bien. C’est plié en moins de 30mn. Du coup, je ne la détaillerai pas dans cet article – si vous êtes intéressé, vous pouvez consulter cet article. Pour les pré-requis, c’est une autre paire de manches …

Java 8 est encore largement utilisé dans les entreprises aujourd’hui. Il y a même certains frameworks qui n’ont pas encore sauté le pas.
Je vais essayer d’exposer dans cette article les étapes à réaliser pour migrer (simplement) votre application JAVA8 en JAVA 11.

Dans cet article, je prendrai comme postulat que l’application se construit avec Maven.

1 Pré-requis

Tout d’abord vérifiez votre environnement d’exécution cible! Faites un tour du coté de la documentation et regardez le support de JAVA.

Depuis quelques temps je me mets à Gradle. Après de (trop?) nombreuses années à utiliser Maven (depuis la version 0.9…), je me risque à modifier mon environnement de build. Du moins sur des projets démo.

Quand on a fait pas mal de Maven, on est un peu dérouté au début. On a d’un coté, la plupart des actions qui sont configurées de manière implicite et de l’autre on peut tout coder/étendre ou presque.

Je suis en train de mettre en œuvre des tests de performance avec Gatling. Un des principaux outils libres de tests de performance.

J’ai eu récemment à résoudre un « petit » soucis : je souhaitai partager des variables entre plusieurs scénarios. Il existe pas mal de solutions sur stackoverflow. J’ai condensé certaines d’entre elles pour les adapter à mon besoin.
Ces variables sont issues de exécution d’une seule requête et sont automatiquement injectées dans les scénarios suivants. Ce mécanisme permet par exemple de récupérer un jeton d’un serveur d’identification et de l’injecter pour le scénario que l’on souhaite tester.

Une fois n’est pas coutume, voici un article qui reprend des basiques de la programmation. J’aborde une stack JAVA, mais c’est applicable à d’autres langages.

Il existe une fonctionnalité très intéressante dans Spring (et dans J(akarta)EE) que l’on oublie assez souvent : l’AOP ou encore la programmation par aspect. Cette manière de programmer permet notamment de séparer le code fonctionnel et technique.
Si vous faites du JAVA, vous utilisez déjà l’AOP. En effet, quand vous faites une insertion en base via JPA dans un EJB ou un bean annoté @Transactional, une transaction est initiée au début de la méthode et fermée à la fin.

Après avoir soumis mon article sur le coaching des développeurs, je me suis rendu compte que j’ai oublié pas mal de points qui, à bien y réfléchir, me paraissent essentiels.
Dans mon précédent article ( the first blood pour le coup ) je me suis attardé sur le « quoi » : toutes les actions que j’ai testé dans l’encadrement des jeunes développeurs et des développeurs en général.

Maintenant, je vais essayer de m’attarder sur le « comment » : ma démarche, la posture que l’on doit adopter ( ce n’est que mon ressenti ) etc.

Auparavant, dans nos tests, quand on voulait mocker des méthodes « final » ou statiques, on devait passer par PowerMock.

Depuis peu, si on utilise Mockito ( >2.1) , on n’a plus besoin d’ajouter PowerMock pour mocker des méthodes « final ».

Bon il reste toujours la gestion des méthodes statiques à gérer autrement qu’avec Mockito, mais cela va dans le bon sens.

Voici comment activer en quelques commandes le mocking des méthodes « final ».