Debian: Utiliser java-package pour créer des packages natifs depuis les JDK et JRE de Sun

Installer java sous Linux consiste trop souvent:

• à décompresser un fichier .tar.gz ou .zip,
• à lancer un fichier .bin qui extrait son contenu dans le répertoire courant

Sur Debian, le package java-package de la section contrib permet de convertir une archive du JDK ou du JRE livrée par Sun (en fait Oracle maintenant) en package natif Debian (un fichier .deb), ce qui est bien plus commode et plus propre pour l'installation qu'un .tar.gz ou un fichier binaire.

Sur Debian Wheezy, après avoir ajouté contrib au fichier /etc/apt/sources.list puis lancé apt-get update, on installe java-package comme suit:

apt-get install java-package

Le paquet java-package installe la commande make-jpkg (make java package) qui convertit une archive .bin ou .tar.gz en provenance d'Oracle en paquet Debian.

Par exemple:

fakeroot make-jpkg /home/myuser/Downloads/jre-6u38-linux-x64.bin

On obtient alors dans le répertoire courant le fichier:

oracle-j2re1.6_1.6.0+update38_amd64.deb

Qu'il suffit d'installer comme suit:

sudo dpkg -l oracle-j2re1.6_1.6.0+update38_amd64.deb

On peut vérifier le contenu du package généré par:

sudo dpkg -c oracle-j2re1.6_1.6.0+update38_amd64.deb

En utilisant java-package, les JRE et JDK Java s'installent comme les autres logiciels sous Debian, et Java est accessible pour tous les utilisateurs du système et pas seulement pour un utilisateur donné.

Note: Si vous voulez convertir une archive de Java 7, il se peut que vous obteniez l'erreur suivante "No matching plugin was found".

En fait l'update 10 (et ceux d'après) de Java 7 n'est pas encore prévue dans java-package (qui ne prévoit qu'un digit de 0 à 9 !).

Il suffit alors de modifier le fichier /usr/share/java-package/oracle-j2re.sh (ou /usr/share/java-package/oracle-j2sdk.sh) pour ajouter [0-9] à la regexp du nom de l'archive.

Par exemple pour un JDK 7 sous Linux 64 bits:

        "jdk-7u"[0-9][0-9]"-linux-x64.tar.gz") # SUPPORTED
            j2se_version=1.7.0+update${archive_name:6:1}${revision}
            j2se_expected_min_size=180 #Mb
            j2se_priority=317
            found=true
            ;;

Pourquoi les paquets sun-java* ont été retirés des dépots Debian & Ubuntu

Depuis 2006 et le changement de license par Sun du JDK et du JRE pour une license DLJ (Distro License for Java) , les systèmes d'exploitation libres comme Debian et Ubuntu pouvaient proposer dans leurs dépôts les JVM et JRE publiés par Sun.

Maintenant, suite au rachat de Sun par Oracle, on revient à la case départ, à savoir que Sun n'autorise désormais plus la redistribution de sa machine virtuelle Java (non libre).

Les acteurs du libre, Debian, Ubuntu, ... ont donc supprimé de leurs dépots les paquets sun-java*, et c'est pour cela qu'au mois de décembre 2011 suite à une mise à jour sur Debian ou Ubuntu, on pouvait se retrouver avec openjdk à la place de la JVM de Sun sans trop comprendre pourquoi.

Ceux qui comme moi n'ont pas installé Java avec Synaptic mais à la main dans un répertoire utilisateur n'auront pas de soucis !

Heure d'été, Classe Date, JDK 1.5 et TimeZone

Alors que l'on est passé à l'heure d'été ce week-end, soit UTC+0200 au lieu d'UTC+0100, je me suis aperçu ce matin que le JDK 1.5 de Sun ne me donnait pas (plus en fait !) l'heure correcte ... alors que la machine elle avait bien changé d'heure, comme le confirmait Gnome et la commande date.

En fait, la classe Date de Java était restée à l'ancienne heure, contrairement à moi qui ai vu mon week-end écourté, mais bref.

En effet, Java tient compte du TimeZone, et un simple

new Date();

doit vous donner la date courante et tenir compte du TimeZone, et non vous donner la date GMT définie par nos amis Anglais.

La raison de ce problème est que le JDK 1.5 ne me donnait pas le TimeZone me correspondant. Au lieu d' "Europe/Paris" j'obtenais GMT+0100 soit le TimeZone de la semaine dernière.

TimeZone.getDefault().getID()=GMT+01:00

Pour remédier à ce problème, il suffit soit d'utiliser un JDK plus récent, c'est à dire un JDK 1.6, soit de modifier le TimeZone par programme comme suit:

TimeZone tz = TimeZone.getTimeZone("Europe/Paris");
TimeZone.setDefault(tz);

On peut également modifier la propriété "user.timezone" et lui affecter la valeur "Europe/Paris", par exemple sur la ligne de commande Java, via un -D.

Je n'ai pas testé toutes les versions de JDK 1.5, mais les dernières versions du JDK 1.5 (jdk1.5.0_14 et jdk1.5.0_15) ont toutes deux ce bug sous Linux.

Autres posts liés à Développement / Logiciel / Java / Shell / C:

Erreurs de débutant en Java: fermer les fichiers !
Un très ancien bug non découvert jusque là
pop3/tcp server failing (looping), service terminated
De l’usage des programmes d’exemple
JavaMail en IMAP avec un serveur Exchange

Java 1.5: Utilisation des imports avec JMS

La facilité en Java consiste à utiliser des imports "génériques" du genre:

import java.util.*;

ou

import javax.jms.*;

.
Autre méthode possible, laisser Eclipse réorganiser les imports du fichier source Java.

Lorsqu'on utilise Java 1.5 sur du code Java écrit pour la version 1.4 voire 1.3 du JDK, on peut rencontrer l'erreur suivante à la compilation:

reference to Queue is ambiguous, both class java.util.Queue in java.util and class javax.jms.Queue in javax.jms match

En effet, les classes java.util.Queue et javax.jms.Queue existent toutes les deux ... dans le JDK et comme j'ai mis les deux imports, j'obtiens une ambiguité et la compilation échoue (ce n'est pas un warning).

Personnellement, je préfère de loin spécifier au début du fichier source Java l'intégralité des imports dont j'ai besoin. Par exemple, dans un programme d'envoi et de réception de messages JMS:

import javax.jms.QueueConnectionFactory;
import javax.jms.QueueConnection;
import javax.jms.Session;
import javax.jms.QueueSession;
import javax.jms.Queue;
import javax.jms.QueueReceiver;
import javax.jms.QueueSender;
import javax.jms.MessageListener;

import javax.jms.Message;
import javax.jms.MapMessage;

import javax.jms.JMSException;

Comme cela, non seulement je sais exactement quelles classes Java j'utilise mais je vois également en un coup d'oeil que telle classe qui pourrait me poser un problème n'est pas utilisée dans mon implémentation.

Pour une fois, incitons les développeurs à être un peu moins "lazy" que d'habitude :-)

Note: L'erreur "reference to Queue is ambiguous, both class java.util.Queue in java.util and class javax.jms.Queue in javax.jms match" survient sur le programme d'exemple JMS de Sun TransactedExample.java, qui avait été écrit avant Java 1.5 évidemment.

 Autres posts liés à Développement / Logiciel / Java / Shell / C:

Erreurs de débutant en Java: fermer les fichiers !
Heure d'été, Classe Date, JDK 1.5 et TimeZone
Un très ancien bug non découvert jusque là
pop3/tcp server failing (looping), service terminated
De l’usage des programmes d’exemple
JavaMail en IMAP avec un serveur Exchange