Exile on Keyboard St. - Blog sur Linux et Debian

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

samedi 21 décembre 2019

Gérer plusieurs versions de Java avec jEnv

Depuis la sortie de la version 9 de Java en 2017 et la nouvelle cadence de sortie des versions de Java décidée par Oracle, il devient de plus en plus difficile de ne travailler que sur une version de Java à la fois.

Se pose alors pour le développeur la question de comment passer d'une version à l'autre de Java, et si possible de façon simple.

Sur Debian, on a longtemps utilisé la commande update-java-alternatives mais elle présente plusieurs inconvénients:

  • L'utilisation d'une version de Java est globale à tout le système (liens symboliques dans /etc/alternatives)
  • Elle ne fonctionne qu'avec les JDK installés depuis les dépôts du système (utilisation des fichiers de métadonnées .jinfo)
  • Elle est spécifique à Debian (A vérifier mais il me semble que oui)

Heureusement, le projet jEnv vient à notre secours, et permet de passer très facilement d'un JDK à un autre.

1. Installation de jEnv

Pour installer jEnv, rien de plus simple:

On clone le repository Git:

git clone https://github.com/gcuisinier/jenv.git ~/.jenv

Puis on ajoute quelques lignes à la fin de notre fichier ~/.bash_profile ou ~/.bashrc

echo 'export PATH="$HOME/.jenv/bin:$PATH"' >> ~/.bash_profile
echo 'eval "$(jenv init -)"' >> ~/.bash_profile

Personnellement, j'ai déplacé ces lignes dans un fichier ~/.jenvrc pour les référencer ensuite dans ~/.bashrc:

if [ -f ~/.jenvrc ]; then
    . ~/.jenvrc
fi

mais ce n'est pas une obligation.

2. Configuration de jEnv

Une fois jEnv installé, on va lui indiquer quelles sont les versions de Java que l'on veux utiliser.

Au départ, aucune version de Java n'est connue de jEnv:

jenv versions

Si on ajoute un Java 9:

jenv add $HOME/jdk/jdk9/jdk-9.0.4/
openjdk64-9.0.4 added
9.0.4 added
9.0 added
9 added

Puis un Java 11:

jenv add $HOME/jdk/jdk11/jdk-11.0.2/
openjdk64-11.0.2 added
11.0.2 added
11.0 added
11 added

Les versions disponibles sont maintenant:

jenv versions
  11
  11.0
  11.0.2
  9
  9.0
  9.0.4
  openjdk64-11.0.2
  openjdk64-9.0.4

On voit que Jenv crée plusieurs tags vers le JDK ajouté.

3. Utilisation de jEnv

On a donc installé deux versions de Java, mais aucune n'est encore disponible.

Si on fait:

which java
/home/user/.jenv/shims/java

On voit que jEnv a "wrappé" la commande Java dans un script Shell.

3.1. Une version de Java globale

Définissons maintenant le Java 9 comme Java global au système:

jenv global 9

La commande précédente donne maintenant:

java -version
openjdk version "9.0.4"
OpenJDK Runtime Environment (build 9.0.4+11)
OpenJDK 64-Bit Server VM (build 9.0.4+11, mixed mode)

Et tout nouveau terminal utilisera donc Java 9.

3.2. Une version de Java locale

Si maintenant, pour un projet particulier, j'ai besoin de Java 11, je peux le définir comme la version de Java à utiliser dans un répertoire particulier:

mkdir my-project
cd my-project
jenv local 11

Et le résultat est:

java -version
openjdk version "11.0.2" 2019-01-15
OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)

Si je relance la commande pour connaître les versions disponibles:

jenv versions
* 11 (set by /home/user/my-project/.java-version)
  11.0
  11.0.2
  9
  9.0
  9.0.4
  openjdk64-11.0.2
  openjdk64-9.0.4

Et si je quitte ce projet, je reviens en Java 9:

cd
java -version
openjdk version "9.0.4"
OpenJDK Runtime Environment (build 9.0.4+11)
OpenJDK 64-Bit Server VM (build 9.0.4+11, mixed mode)

Et j'ai donc:

jenv version
9 (set by /home/user/.jenv/version)

qui est la version globale:

jenv global
9

3.3. Une version de Java locale au Shell courant

On peut également changer la version de Java utilisée localement au Shell courant comme suit:

jenv shell 11

Par exemple, pour tester rapidement quelques lignes de Java grâce à au JShell de Java 9:

jenv shell 9 && jshell
|  Welcome to JShell -- Version 9.0.4
|  For an introduction type: /help intro

Comme on vient de le voir, jEnv est un outil très simple à utiliser pour passer d'une version de Java à une autre, et il ne dépend pas de la façon dont ont été installés les JDK pour être utilisé.

jEnv fait donc partie des outils que le développeur Java va adopter rapidement !

mardi 5 septembre 2017

Refaire fonctionner Enigmail avec Icedove / Thunderbird sur Debian 8.9

Depuis la dernière mise à jour du paquet Icedove sur Debian 8.9, ce dernier m'a signalé que mon Add-On Enigmail était désactivé et qu'il fallait passer désormais par un autre Add-On dont j'ai oublié le nom. Ce jour là, j'ai laché l'affaire en me disant que je regarderai cela plus tard.

Ce matin, j'ai jeté un oeil, n'ai pas trouvé d'Add-On de remplacement pour Enigmail mais par contre en suivant la procédure suivante, j'ai rétabli ma configuration Mail+Encryption:

  • Installation de Thunderbird
  • Démarrage de Thunderbird + Migration des données issues d'Icedove (se fait tout seul)
  • Installation d'Enigmail afin de le réactiver (cette possibilité n'étant pas proposée)
  • Suppression du paquet iceowl-extension

Donc, je suis passé d'Icedove à Thunderbird (comma avant sur Debian quoi !) et ça fonctionne comme avant. Enfin presque ...

Maintenant, le déchiffrement des messages ne se fait pas de manière automatique et j'ai une erreur qui dit: GnuPG a rapporté une erreur de communication avec gpg-agent (un composant de GnuPG).

Capture-Alerte_Enigmail.png

Les solutions proposées dans le billet cité n'ont malheureusement pas fonctionné chez moi.

J'ai trouvé la solution dans le billet gnome-keyring gpg2 and enigmail clash.

Le script en question a été enregistré en .gpgrc et appelé dans .bashrc. Ensuite, j'appele Thunderbird de la façon suivante:

bash -i -c '/usr/bin/thunderbird %u'

Et j'ai bien:

env| grep GPG
GPG_AGENT_INFO=/tmp/gpg-63XK4k/S.gpg-agent:3002:1

C'est donc bien le gpg-agent qui est utilisé et non le Gnome Keyring.

Avec cette façon de faire, tout fonctionne, y compris le cache sur la saisie du mot de passe de ma clé privée !

Enfin, j'ai remarqué une aberration dans la configuration par défaut de Thunderbird, le moteur de recherche par défaut est Bing, moteur de recherche d'une célèbre (plus que son moteur en tous cas !) société américaine dont je ne citerai pas le nom. Je me demande bien ce qui a pû dicter ce choix malheureux dans un logiciel open source ...

Capture-Preferences_de_Thunderbird.png

mardi 15 août 2017

Utilisation des alias Bash en mode interactif ou non

Avec Bash, les alias sont définis dans le fichier .bashrc ou plus proprement dans le fichier .bash_aliases qui normalement est chargé depuis .bashrc comme suit:

# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

Si j'ai défini:

alias ll='ls -l

Alias en mode interactif

La commande ll donnera le résultat suivant:

user@machine:~$ ll
total 60
drwxr-xr-x 2 user user  4096 juil. 23 17:03 bin
drwxr-xr-x 2 user user  4096 août   3 21:41 Bureau
drwxr-xr-x 6 user user  4096 juil.  9 18:00 Documents
drwxr-xr-x 2 user user  4096 avril 29 14:20 Enregistrements
drwxr-xr-x 4 user user  4096 juin  14 07:39 Images
drwxr-xr-x 2 user user  4096 nov.   9  2016 Modèles
drwxr-xr-x 2 user user  4096 nov.  23  2016 Musique
drwxr-xr-x 9 user user  4096 juin  13 08:51 Programs
drwxr-xr-x 2 user user  4096 nov.   9  2016 Public
drwxr-xr-x 8 user user  4096 juin   4 07:25 Sources
drwxr-xr-x 6 user user 12288 août   2 07:59 Téléchargements
drwxr-xr-x 7 user user  4096 juin   5 06:31 Vidéos
drwxr-xr-x 9 user user  4096 juin  30 19:32 VirtualBox VMs

Expansion des alias

C'est normal me direz-vous. En fait, l'alias ll qui a été défini est utilisable parce que je suis dans un Shell interactif et que par défaut Bash autorise l'expansion des alias dans un Shell interactif.

On peut s'en convaincre en désactivant cette option:

user@machine:~$ shopt -u expand_aliases
user@machine:~$ ll
bash: ll : commande introuvable
user@machine:~$ alias
alias l='ls -CF'
alias la='ls -A'
alias ll='ls -l'
alias ls='ls --color=auto'
alias rm='rm -i'

Les alias sont définis, ils existent mais ne sont pas utilisables pour autant !

Alias en mode non interactif

En mode non interactif, c'est à dire dans un script Shell lançé sans l'option -i, les choses sont différentes.

Première différence, le script .bash_aliases n'est pas chargé puisque .bashrc ne l'est pas. Ah bon ?

Il suffit de regarder le début du fichier .bashrc pour s'en convaincre:

user@machine:~$ more .bashrc 
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

Vos alias habituels ne seront donc pas connus dans les scripts.

C'est en fait assez heureux si l'on considère les alias couramment définis sur les commandes rm et cp avec une demande de confirmation: dans un script mieux vaut ne pas avoir à répondre à des questions !

Deuxième différence, l'expansion des alias n'est pas activée par défaut dans un Shell non interactif.

Considérons le script suivant:

#!/bin/bash

alias ll='ls -l'
alias
ll
user@machine:~$ alias.sh
alias ll='ls -l'
/home/user/alias.sh: ligne 5: ll : commande introuvable

L'alias défini dans le script lui même n'est pas utilisable !!!

En revanche si j'ajoute en début de script la ligne suivante:

shopt -s expand_aliases

mon alias est connu depuis le script. On pensera donc à ajouter cette commande, avant ou après la définition des alias, dans les scripts les utilisant.

Et pour afficher toutes les options actives de Bash:

shopt -s

- page 1 de 3