update-alternatives
Hier, j’ai voulu installé Eclipse sous Xubuntu avec le nouvel installateur Oomph. Au lancement de l’installateur, j’ai eu un message d’erreur car je ne disposais que de Java 7 et que l’installateur avait besoin de Java 8. Je me suis alors dit qu’il était temps de mettre en oeuvre la technique des update-alternatives dont m’avait parlé mon administrateur système préféré.
État des lieux de Java
Tout d’abord, commençons par regarder ce vers quoi pointe la commande java :
$ ls -la $(which java) lrwxrwxrwx 1 root root 22 sept. 20 19:05 /usr/bin/java -> /etc/alternatives/java
Le principe d’update-alternatives est de ne pas faire de lien direct vers la vraie implémentation mais un lien vers une alternative, qui est dans /etc/alternatives qui pointe à son tour vers le programme réellement chargé de la commande. Regardons les alternatives connues du système des alternatives pour java :
$ update-alternatives --list java /usr/lib/jvm/java-7-openjdk-i386/jre/bin/java
Il n’y a pour l’instant qu’un seul programme connu pour la commande java et c’est sans surprise un Java 7.
Installation d’une nouvelle alternative pour Java
Personnellement, j’ai choisi d’utiliser le JDK 8 d’Oracle et j’ai récupéré la dernière version disponible sur le site officiel. J’ai décompressé l’archive tar.gz dans /usr/local :
$ ls bin/ etc/ games/ include/ jdk1.8.0_60/ lib/ man@ sbin/ share/ src/
Pour installer une nouvelle alternative, il faut utiliser une ligne de commande de la forme suivante :
update-alternatives --install <link> <name> <path> <priority>
<link> est l’endroit où placer le lien qui pointera vers /etc/alternatives, <name> est la commande pour laquelle on installe une alternative et <path> est le chemin vers le programme concret. <priority> sert pour les groupes de liens et quand le mode automatique est utilisé. Plus la priorité est élevée, plus l’alternative aura une priorité forte. Pour installer une nouvelle alternative vers mon JDK 8, j’ai utilisé la commande suivante :
$ sudo update-alternatives --install /usr/bin/java java
/usr/local/jdk1.8.0_60/bin/java 3000
update-alternatives: using /usr/local/jdk1.8.0_60/bin/java
to provide /usr/bin/java (java) in auto mode
C’est maintenant Java 8 qui est utilisé par défaut car la nouvelle alternative a une priorité plus forte que l’alternative déjà disponible :
$ which java /usr/bin/java pgradot@pgradot-xubuntu:~$ java -version java version "1.8.0_60" Java(TM) SE Runtime Environment (build 1.8.0_60-b27) Java HotSpot(TM) Client VM (build 25.60-b23, mixed mode)
A titre d’exemple, voici ce qui se passe pour une installation avec une priorité à 1000 au lieu de 3000 :
$ sudo update-alternatives --install /usr/bin/java java
/usr/local/jdk1.8.0_60/bin/java 1000
pgradot@pgradot-xubuntu:~/Documents/git/PyTweet$ java -version
java version "1.7.0_79"
OpenJDK Runtime Environment (IcedTea 2.5.6) (7u79-2.5.6-0ubuntu1.14.04.1)
OpenJDK Client VM (build 24.79-b02, mixed mode, sharing)
Changer d’alternative
Il est simple de passer d’une alternative à une autre et il est donc pratique de garder plusieurs versions installées sur le système et de changer la cible concrète de la commande au besoin. Cela est utile quand un projet particulier réclame une version différente que la version utilisée généralement, que ce soit Java ou autre.
On commence par lister les alternatives pour la commande souhaitée :
$ sudo update-alternatives --list java [sudo] password for pgradot: /usr/lib/jvm/java-7-openjdk-i386/jre/bin/java /usr/local/jdk1.8.0_60/bin/java
Il suffit ensuite d’utiliser la commande --set :
$ sudo update-alternatives --set java
/usr/lib/jvm/java-7-openjdk-i386/jre/bin/java
update-alternatives: using /usr/lib/jvm/java-7-openjdk-i386/jre/bin/java
to provide /usr/bin/java (java) in manual mode
$ java -version
java version "1.7.0_79"
OpenJDK Runtime Environment (IcedTea 2.5.6) (7u79-2.5.6-0ubuntu1.14.04.1)
OpenJDK Client VM (build 24.79-b02, mixed mode, sharing)
Il est pratique de lister les alternatives avant d’utiliser --set pour pouvoir copier-coller le chemin souhaité. Il n’est pas possible d’utiliser un programme qui n’a pas encore été ajouté comme alternative :
$ sudo update-alternatives --set java /usr/local/jdk1.8.0_60/bin/jav
update-alternatives: error: alternative /usr/local/jdk1.8.0_60/bin/jav
for java not registered; not setting
L’erreur dit bien que l’alternative n’est pas connue et non que le programme n’existe pas.
Supprimer une alternative
Rien de bien compliqué pour supprimer une alternative. Si c’est l’alternative est actuellement utilisé, le gestionnaire des alternatives se rabat sur une autre alternative en se basant sur les priorités :
$ sudo update-alternatives --remove java /usr/local/jdk1.8.0_60/bin/java
update-alternatives: removing manually selected
alternative - switching java to auto mode
update-alternatives: using /usr/lib/jvm/java-7-openjdk-i386/jre/bin/java
to provide /usr/bin/java (java) in auto mode
C’est aussi l’un des avantages du système des alternatives. Il sera charge de mettre à jour les différents liens quand des alternatives sont modifiées.
Things every Java developer must know about Exception handling
Je n’avais encore jamais reblogué, mais cet article est tellement bien écrit, il me semble être le candidat idéal pour un premier reblog !
Exceptions are one of the most misunderstood (and misused) features of the Java programming language. This article describes the absolute minimum every Java developer must know about exceptions. It assumes that the reader is somewhat familiar with Java.
Historical Perspective
Back in the heyday of the « C » programming language, it was customary to return values such as -1 or NULL from functions to indicate errors. You can easily see why this isn’t a great idea – developers had to check and track possible return values and their meanings: a return value of 2 might indicate « host is down » error in library A, whereas in library B, it could mean « illegal filename ».
Attempts were made to standardize error checking by expecting functions to set a global variable with a defined value.
James Gosling and other designers of the language felt that this approach would go against the design goals of Java. They wanted:
- a cleaner, robust and portable approach
- built in language support for error checking…
Voir l’article original 1 470 mots de plus
Merci Oracle
Ce matin, j’arrive au travail, je démarre mes PC et l’un d’eux me propose une mise à jour de Java. J’utilise Eclipse, plein d’Eclipses, et donc Java, tous les jours. Je dis oui. Tout se passe bien, rien de spécial à dire. Un peu plus tard, je double-clique sur mon raccourci pour lancer MicroEJ, l’IDE basé sur Eclipse de mon entreprise, et bim !
Quoi ? Comment ? Tout marchait très bien hier soir ! Un petit tour dans l’explorateur de fichiers. Ah ok : le dossier C:\Program Files (x86)\jre7 n’existe plus, la mise à jour de Java l’a supprimé ! Les utilisateurs avertis d’Eclipse savent qu’à côté de eclipse.exe, il y a un fichier eclipse.ini qui donne le chemin vers le JRE à utiliser. Pour régler le problème ci-dessus, il suffit d’éditer ce fichier pour pointer vers un JRE qui existe. J’ai choisi mon JDK 7 qui, contrairement au JRE 7, n’avait pas été supprimé (logique, non ?). Maintenant, cet Eclipse marche, il n’y plus qu’à réparer les autres…
Merci Oracle.
Tableau en paramètre d’une méthode en Java
J’avance lentement mais sûrement dans mon apprentissage de Java (ouais, je préfère coder que de lire un bouquin, c’est comme ça ^^). Hier, je me suis demandé comment on pouvait modifier un tableau passé en paramètre à l’intérieur d’une méthode. Petit article avec code démonstratif pour me souvenir de tout ça.
Comme avec un descendant d’Object, on passe non pas l’objet tableau (qui se trouve quelque part dans le tas) mais une référence vers ce tableau. Grâce à cette référence, on peut modifier les éléments du tableau ; en revanche, on ne peut pas échanger cet objet par un autre. Si on tente d’affecter un nouveau tableau au paramètre à l’intérieur de la méthode, cela n’a pas d’effet en dehors de cette méthode. L’appelant possède toujours une référence sur le « bon » objet, la méthode travaille elle sur la nouvelle référence et donc le nouvel objet.
package tests;
public class Main {
private static void content(byte[] array) {
array[0] = 42;
System.out.println("Content :" + array);
}
private static void object(byte[] array) {
array = new byte[] { 0, 0, 0 };
System.out.println("Object : " + array);
}
private static void print(byte[] array) {
System.out.println("Print: " + array);
for (byte b : array) {
System.out.print(b);
System.out.print('\t');
}
System.out.println("\n");
}
public static void main(String[] args) {
byte[] array = new byte[] { 1, 2, 3 };
print(array);
content(array);
print(array);
object(array);
print(array);
}
}
Sortie console :
Print: [B@1888759 1 2 3 Content :[B@1888759 Print: [B@1888759 42 2 3 Object : [B@6e1408 Print: [B@1888759 42 2 3
Mes débuts avec Maven
J’avais déjà entendu parler de Maven mais pas eu l’occasion de m’en servir. Pour ceux qui ne connaissent pas Maven, vous pouvez lire l’article Wikipédia à son sujet. En bref, Maven (en version longue Apache Maven, puisque c’est un outil de l’Apache Software Foundation) est un outil pour la gestion et la construction de projets Java. On m’avait surtout vanté ses mérites pour la gestion des dépendances. J’ai voulu cette semaine tester une bibliothèque Java et le tutoriel donnait les dépendances Maven pour récupérer les JAR nécessaires. Je me suis dit que c’était le moment de débuter et cet article retrace mes étapes de prise en main.
Pour être honnête, ce n’est pas très compliqué. Il suffit de vous rendre ici : http://maven.apache.org/guides/. Il y a deux getting started with Maven. J’ai commencé par celui qui dure 5 minutes. Il explique de manière claire et détaillée comment l’installer puis comment créer son projet et le construire. J’ai ensuite lu celui qui dure 30 minutes. Je me suis en particulier intéressé à la section How do I use external dependencies?. J’ai édité mon fichier pom.xml pour y ajouter mes dépendances.
Quand est venu le moment de coder, je n’avais pas vraiment envie de faire ça avec Notepad++ et la ligne de commande, alors j’ai tapé dans mon terminal :
mvn eclipse:eclipse
J’ai ouvert Eclipse, j’ai fait Import / Existing project into workspace. Mon projet était là ! Il restait un petit détail à régler : Maven avait ajouter des classpath variables au Java build path de mon projet mais en utilisant une variable M2_REPO qui n’était pas positionnée dans mon Eclipse. Cette variable pointe vers le dépôt local de Maven, là où il télécharge les JAR des dépendances. Un petit tour sur Google pour savoir où est le dépôt Maven sur mon disque dur et savoir comment rajouter la variable dans Eclipse. Le build path était réparé et le projet compilait.
Le plus simple était fait, j’ai alors testé la bibliothèque 😉
Pierre Gradot 