Exile on Keyboard St. - Blog sur Linux et Debian

Aller au contenu | Aller au menu | Aller à la recherche

Tag - développement

Fil des billets - Fil des commentaires

samedi 25 mai 2019

Les versions d'OpenJDK du dépôt Debian

Dans les versions précédentes de Debian, Debian Jessie, Debian fournissait l'OpenJDK en version 6 et 7.

Maintenant qu'on est passé à Debian Stretch et que les versions 9 et 10 du JDK sont "remplacées" par les versions 11 et 12, Debian fournit les versions 8 et 11 de l'OpenJDK.

Donc, pourvu que l'on crée le fichier suivant:

root@324a074e5614:/# cat /etc/apt/sources.list.d/backports.list 
deb http://deb.debian.org/debian stretch-backports main

On dispose des paquets suivants:

root@324a074e5614:/# apt-cache search ^openjdk-
openjdk-8-dbg - Java runtime based on OpenJDK (debugging symbols)
openjdk-8-demo - Java runtime based on OpenJDK (demos and examples)
openjdk-8-doc - OpenJDK Development Kit (JDK) documentation
openjdk-8-jdk - OpenJDK Development Kit (JDK)
openjdk-8-jdk-headless - OpenJDK Development Kit (JDK) (headless)
openjdk-8-jre - OpenJDK Java runtime, using Hotspot JIT
openjdk-8-jre-headless - OpenJDK Java runtime, using Hotspot JIT (headless)
openjdk-8-jre-zero - Alternative JVM for OpenJDK, using Zero/Shark
openjdk-8-source - OpenJDK Development Kit (JDK) source files
openjdk-8-jre-dcevm - Alternative VM for OpenJDK 8 with enhanced class redefinition
openjdk-11-dbg - Java runtime based on OpenJDK (debugging symbols)
openjdk-11-demo - Java runtime based on OpenJDK (demos and examples)
openjdk-11-doc - OpenJDK Development Kit (JDK) documentation
openjdk-11-jdk - OpenJDK Development Kit (JDK)
openjdk-11-jdk-headless - OpenJDK Development Kit (JDK) (headless)
openjdk-11-jre - OpenJDK Java runtime, using Hotspot JIT
openjdk-11-jre-headless - OpenJDK Java runtime, using Hotspot JIT (headless)
openjdk-11-jre-zero - Alternative JVM for OpenJDK, using Zero
openjdk-11-source - OpenJDK Development Kit (JDK) source files
openjdk-11-jre-dcevm - Alternative VM for OpenJDK 11 with enhanced class redefinition

à savoir l'OpenJDK en version 8 et 11, décliné en JDK et JRE et pour chaque paquet, une version normale et une headless (sans GUI) ainsi que la doc et les paquets sources.

On peut donc installer l'OpenJDK avec une commande apt-get install .. et pourvu qu'on ait installé le paquet java-package on peut passer d'un JDK à l'autre avec la commande update-java-alternatives dont on a déjà parlé.

Pour ceux qui douteraient de la version que l'on peut installer:

root@8351575db5f2:/# java -version
openjdk version "1.8.0_212"
OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01)
OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode)

C'est donc bien la dernière version du JDK 8.

root@8351575db5f2:/# java -version
openjdk version "11.0.3" 2019-04-16
OpenJDK Runtime Environment (build 11.0.3+7-Debian-1bpo92)
OpenJDK 64-Bit Server VM (build 11.0.3+7-Debian-1bpo92, mixed mode, sharing)

Et il en est de même pour la version 11.

Je trouve que c'est un peu dommage de ne pas pouvoir installer le JDK 9 et 10, dans la mesure où Oracle précise bien que c'est plus compliqué de passer de Java 8 à Java 9 que de Java 9 aux versions 10, 11 et 12.

Et malheureusement, la version 12 n'est pas présente dans les dépots puisque sortie le 18 avril 2019.

On verra bien ce que ça donnera avec Debian Buster qui doit sortir prochainement, mais apparemment on n'aura "que" les versions 11 et 12. De quoi nous faire comprendre que si on est encore en Java 8 en 2019, on est à la traîne, comme si on ne le savait pas déjà !

mercredi 10 octobre 2018

Des logs claires et utiles en Java

L'utilisateur final d'un logiciel est toujours heureux lorsque ce logiciel produit des logs claires et utiles.

Malheureusement, les développeurs ne font pas toujours suffisamment le nécessaire pour:

  • Ajouter des logs et traces là ou c'est utile
  • Mettre ces logs dans le bon niveau de log
  • Les mettre à jour quand besoin est
  • Faire en sorte que ces logs ne pénalisent pas trop les performances du logiciel

Et pourtant, la deuxième plus grande catégorie d'utilisateurs d'un logicel, c'est .... l'équipe de développement de ce logiciel !!!

On va donc faire un tour des erreurs les plus communément faites en matière de logs, et ce dans le but de s'amélirorer !

1. Pas de logs du tout

La première erreur que je vois trop souvent, c'est l'absence complète de logs dans une méthode ou même dans un composant tout entier. Il est donc impossible en cas de doute(s) sur le fonctionnement de ce code, de savoir ce qu'il se passe, à part se connecter en debug sur le serveur, ce qui n'est évidemment pas possible chez un client.

2. Des logs uniquement en TRACE ou en FINEST

Deuxième erreur trop souvent commise, on a des logs mais seulement dans le niveau de log maximum !

Comme en pratique, il est déconseillé de configurer un logiciel avec un niveau de log maximum, il en résulte que ces logs ne sortiront la plupart du temps pas chez les clients.

Ce cas arrive souvent quand le développeur veut mettre des logs mais il n'est pas certain du niveau de logs qu'il faut choisir. Et comme il développe avec un niveau de log en TRACE, ses logs s'affichent et il est content !

3. Des logs sans suffisamment de contexte

C'est moins fréquent, mais j'ai aussi vu des logs qui ressemblent à ça:

LOGGER.log(Level.INFO, "Creating user");

ou

LOGGER.log(Level.INFO, "Entering method 'needsRestart'");

Des logs comme celles-cis ne donnant aucun contexte, elles ne sont pas vraiment utiles.

Il s'agit en fait de traces utilisées lors du développement ou plus précisément du debug et qui auraient dù être enlevées ensuite.

4. Des logs avec une chaîne de formatage fausse

Le cas le plus courant de chaîne de formatage fausse est l'erreur sur le nombre de paramètres, par exemple:

LOGGER.info("Computing user: {} identifier: {}", user.getName());

Manifestement, il va nous manquer une information dans la log ...

Si à la place on avait:

LOGGER.info("Computing user: {} identifier: {}", getParam("user"), getParam("identifier"), getParam("extra"));

La méthode getParam serait appelée trois fois alors que le troisième paramètre n'est pas utilisé. Cela nous amènera à utiliser un Supplier et les méthodes lambdas avec Java 8.

5. Des logs faites par des anciens développeurs C

Dans les logs en Java, on trouve aussi le résultat de la programmation en C: le développeur Java qui met des String.format(...) partout !

LOGGER.info(String.format("Computing user: %s identifier: %s", getParam("user"), getParam("identifier")));

Ce qui va formater la chaîne même si le niveau de log ne permet pas que le message s'affiche. On en revient aux Suppliers.

Ensuite il est inutile de recourir à String.format(....) puisque Log4j ou java.util.logging formattent très bien le message en convertissant tout en chaînes de caractères.

Parfois le String.format(...) est tout simplement oublié:

LOGGER.info("Computing user: %s identifier: %s", getParam("user"), getParam("identifier"));

Ce qui affiche quelque chose comme:

06:48:36.094 main INFO org.grumpyf0x48.test.Log4j2Test - Computing user: %s identifier: %s

ce qui n'était probablement pas souhaité !

6. Des logs avec des passages de paramètres .... illisibles

On voit aussi des développeurs qui veulent logger beaucoup de choses dans le même message, et qui ont la hantise du plantage, et qui donc non content de passer 8 paramètres au message de log (et ce tout sur la même ligne temps qu'à faire), font une vérification pour chacun (ou presque) comme: (name == null) ? "no name supplied" : name.

C'est parfaitement inutile puisque dans ce cas Log4J affichera simplement "null" sans se planter. En outre ce genre de message compliqué est difficile à lire et à maintenir, donc à bannir.

Voilà, j'imagine qu'il y a des cas d'erreurs que j'oublie, n'hésitez pas à faire un commentaire si c'est le cas.

dimanche 9 septembre 2018

Tester une API REST directement depuis le Swagger Hub

Les moyens de tester une API REST ne manquent pas.

Mais pendant que l'on définit celle-ci, si on le fait avec le Swagger Hub, il n'est vraiment pas besoin de se compliquer la vie.

En effet, le Swagger Hub qui permet de définir le fichier yaml ou json de l'API, mais aussi de générer les stubs clients et/ou serveur de l'API permet aussi de tester une installation de ladite API.

Il suffit pour cela de:

  1. Se rendre sur la page de votre API, par exemple: https://app.swaggerhub.com/apis/<user>/<api>/<api-version>
  2. Renseigner le nom du serveur de test qui "hoste" votre API
  3. Installer l'Add-On pour Firefox CORS Everywhere afin que le Swagger Hub puisse contacter votre serveur de test
  4. Sélectionner en bas à droite de l'écran l'option: "Routing requests via browser"
  5. Cliquer sur l'URL voulue puis sur "Try it out"
  6. Remplir les champs et enfin cliquer sur "Execute"

De cette façon, vous pouvez faire très facilement des tests manuels sur la permière version de votre API et éventuellement de corriger les problèmes. Et vous n'avez écrit ni généré aucun code pour ce faire !

- page 1 de 3