L'objectif de ce tutoriel est de regrouper mes meilleurs pratiques d'installation d'un environnement de développement dédié Java sous Linux. Et ce en tentant d'être le plus large spectre possible, de l'utilisation « simple » d'Eclipse à la mise en place d'une plate-forme dédiée à un client, en passant par la création, maintenant possible avec un Java GPL, d'application Linux qui se lancent sans tracas.

Installation du JDK

Pendant longtemps la seule méthode pour installer le JDK était d'aller sur le site de SUN et de l'installer à la main. Mais lorsque que Sun c'est (enfin) décidé à placer Java sous licence GPL, la situation de la machine virtuelle au sein des distributions linux a très rapidement évoluée, jusqu'à sa mise à disposition en standard dans les dépôts, comme c'est depuis longtemps le cas pour .Net avec Mono, d'une version complète et officielle de l'environnement d'exécution Java. Avec le temps, la majorité des JDK sont ainsi devenus disponibles sous la forme de simple paquets, y compris les versions officielles de SUN.

Sur une mandriva de base les JDK suivants sont disponibles :

java-1.5.0-sun

Il s'agit de la dernière version 1.5 du JDK de SUN. A utiliser pour une compatibilité maximale avec le JDK 1.5.x

java-1.6.0-sun

Il s'agit de la dernière version 1.6 du JDK de SUN. A utiliser pour une compatibilité maximale avec le JDK 1.6.x

java-1.6.0-openjdk

La nous sommes en présences avec une version semi-libre du JDK de SUN, issue du projet OpenJDK. Semi-libre car il y a encore des éléments binaires propriétaires dans cette version.

java-1.5.0-gcj

Il s'agit d'un JDK un peu spécial basée sur GCC pour la compilation et le projet classpath pour les librairies. ClassPath est un projet GNU qui vise à développer une version totalement libre de l'ensemble du JDK. A n'utiliser que si vous cherchez à produire du code natif ou des choses très particulières.

java-1.7.0-icedtea

Issu du projet icedtea initié par RedHat, il s'agit cette fois d'un JDK totalement libre. Les éléments non-libre d'OpenJDK y ont été remplacés par leur équivalent du projet GNU CLasspath.

L'installation de chacun de ses JDK se fait de manière totalement classique selon votre distribution (urpmi, apt, etc). A ce stade se pose la question du choix d'un JDK par défaut lorsque nous en avons installés plusieurs. La réponse à ce "problème" s'appelle les alternatives.

Les alternatives sont un puissant concept, introduit par debian, permettant d'avoir sur la même machine, plusieurs version d'un même outil et de pouvoir basculer à un moment donné de l'une à l'autre de manière transparente. L'idée sous-jacente est celle d'un utilitaire update-alternatives qui va créer des liens symboliques entre une version donnée (ex. /usr/local/java/jdk1.5.0_14/bin/java) et la commande standard invoquée pour l'utiliser (ex. /usr/bin/java).

Nous pouvons ainsi lister les alternatives qui sont associées à la commande java de la manière suivante :

root#update-alternatives --list java

/usr/lib/jvm/jre-1.6.0-sun/bin/java

/usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java

/usr/lib/jvm/jre-1.5.0-sun/bin/java

liste des alternatives

Ceci indique que nous avons bien trois JDK d'installés. Pour connaître le JDK utilisé en ce moment, et aussi pouvoir en changer, nous procédons de la sorte :

root#update-alternatives --config java

There are 3 programs which provide `java'.

 

Selection Command

-----------------------------------------------

1 /usr/lib/jvm/jre-1.6.0-sun/bin/java

*+ 2 /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java

3 /usr/lib/jvm/jre-1.5.0-sun/bin/java

 

Enter to keep the default[*], or type selection number:1

Using `/usr/lib/jvm/jre-1.6.0-sun/bin/java' to provide `java'.

root#

sélection d'un JDK

Le JDK par défaut était l'openJDK 1.6, nous utilisons maintenant le JDK de SUN.

Et effectivement, si l'on regarde ce qu'est en réalité la commande /usr/bin/java : ## readlink -f /usr/bin/java /usr/lib/jvm/java-1.6.0-sun-1.6.0.10/jre/bin/java

Les alternatives permettent non seulement de sélectionner le JDK actif, mais aussi permettent d'ajouter des JDK "non-standard" de manière trés simple.

Imaginons par exemple que vous ayez un projet nécessitant un JDK 1.4 qui n'est évidement pas dans les dépôts. Vous allez le télécharger sur le site de SUN, puis le placer dans un dossier local, par exemple /usr/local/java/jdk1.4.

Ceci fait, vous pouvez ajouter une nouvelle alternative de la manière suivante

root#update-alternatives --install /usr/bin/java java /usr/local/java/jdk1.4/bin/java 5 \

--slave /usr/bin/javac javac /usr/local/java/jdk1.4/bin/javac

Avec l'option --install nous avons donc crée une alternative supplémentaire pour le groupe java pour la commande java du 1.4. Le dernier argument est la priorité par rapport aux autres alternatives.

L'option --slave permet quant à elle de créer des sous-alternative liées au choix de l'alternative principale. Ainsi si l'on sélectionne le java 1.4, le compilateur javac 1.4 sera lui aussi sélectionné.

Du coup, pour basculer de l'un à l'autre, c'est ultra-simple :

root#java -version

java version "1.6.0_10"

Java(TM) SE Runtime Environment (build 1.6.0_10-b33)

Java HotSpot(TM) 64-Bit Server VM (build 11.0-b15, mixed mode)

 

 

root#update-alternatives --config java

There are 3 programs which provide `java'.

 

Selection Command

-----------------------------------------------

1 /usr/lib/jvm/jre-1.6.0-sun/bin/java

*+ 2 /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java

3 /usr/lib/jvm/jre-1.5.0-sun/bin/java

4 /usr/local/java/jdk1.4/bin/java

 

Enter to keep the default[*], or type selection number:4

Using `/usr/local/java/jdk1.4/bin/java' to provide `java'.

root#javac -version

javac 1.4.0_6

Notez pour finir que le paramétrage de l'alternative par défaut de la commande Java n'a d'intérêt que pour lancer des applications java, comme eclipse lui-même. Cela n'a heureusement aucun impact sur le JDK utilisé pour développer une application. Ne paramétrez donc pas un poussif JDK 1.3 à ce niveau et ce même si votre projet le nécessite. Vous ferrez cela au sein même du projet eclipse en passant par le menu Windows/Preferences/Java/Installed JRE.

Installation d'eclipse, ANT et MAVEN2

Ces trois choses sont aujourd'hui intégrées elles aussi dans les distributions. Le seul problème est que, pour un développeur JAVA, autant le JDK ne bouge pas trop, autant nous passons notre vie à mettre à jour Eclipse, Ant, des librairies pour ANT, etc. La méthode "par paquets" est donc bien trop rigide. De plus, il suffit d'installer eclipse une fois en mode "paquet" pour se rendre compte des impacts sur les ressources au vue du nombre de dépendance que cela engendre. Une simple version adaptée à PHP (Eclipse+PDT) génère une cinquantaine d'installations annexes qui ne nous servent à rien (un serveur apache, tomcat, etc.).

A partir de maintenant donc, la « règle » est que l'ensemble des outils Java sont regroupés au même endroit, en /usr/local/java. C'est un bon usage car lorsque l'on a 10 machines de développement à installer ou à mettre à jour, il est du coup facile de dupliquer ce dossier, par rsync.

Pour éclipse, vous allez pouvoir télécharger sur le site eclipse.org la version Linux d'eclipse (attention à prendre une version 64 bits si tel est votre architecture). Les choses s'améliorant dans ce domaine, cette page vous propose plusieurs version d'eclipse. Là cela dépends de ce que vous avez à faire et vous pouvez cliquer sur le lien compare packages pour savoir à ce qu'il y a de présent dans chacune des distributions. Personnellement je vous conseille la version Eclipse IDE for Java EE Developers qui est la plus complète pour développer en Java.

Enfin pour un environnement complet, il nous faut deux indispensable, ant et maven. En effet, il est pratique d'avoir ces deux outils en ligne de commande plutôt que seulement intégrés comme plugin dans eclipse.

La version compilée de Ant est disponible sur le site Apache Ant. Quant à Maven, c'est ici que cela se passe. Dans les deux cas prendre la version tar.bz2.

Une fois vos téléchargement effectués, vous allez devoir décompresser tout ce beau monde dans /usr/local/java. Tout devrait se faire sans problèmes.

Vous devez maintenant avoir dans votre dossier quelque chose comme :

root#ls

apache-ant-1.7.1/ eclipse/ installs/ maven-2.0.7/

eclipse étant le seul qui n'ait pas son numéro de version, il faut changer cela pour s'y retrouver :

root#mv eclipse eclipse-3.4.0

Ceci fait, un des problèmes classique d'eclipse est qu'un utilisateur standard se retrouve généralement dans l'impossibilité de rajouter un nouveau plugins car il n'a pas les droit d'écriture sur le dossier /usr/local/java/eclipse. Si vous désirez changer cela, la bonne solution est de créer un groupe, par exemple du nom du produit (ici eclipse) par groupadd eclipse, et d'associer ce groupe au développeur propriétaire du compte (moi je modifie directement /etc/group pour rajouter à la fin de la ligne "eclipse", la liste des logins autorisés. La commande id login permet de voir si la modification a bien prise (le groupe "eclipse" devrait apparaître). Ensuite, je n'ai plus qu'à autoriser l'écriture à ce groupe pour tout le dossier :

root#chown :eclipse /usr/local/java/eclipse* -R

root#chmod gu+rwX /usr/local/java/eclipse* -R

Comme nous l'allons pas utiliser des alternatives pour eclipse, ant et maven, nous allons définir des liens symboliques de sorte à nous abstraire un peu des versions :

root#cd /usr/local/java

root#ln -s apache-ant-1.7.1 ant

root#ln -s eclipse-3.4.0 eclipse

root#ln -s maven-2.0.7 maven

Java nécessite un certain nombre de variables d'environnement pour fonctionner correctement, variables qui ne sont pas prise en charge par la simple installation de paquets. Pour régler cela, vous pouvez créer un simple script qui s'exécute à chaque connection. Cela se fait très simplement en ajoutant ce script dans le dossier /etc/profile.d/java.sh :

#! /bin/sh

export JAVA_HOME=$(dirname $(dirname $(readlink -f /usr/bin/java)))
export JRE_HOME=$JAVA_HOME
export JAVA_BASE=/usr/local/java
export ANT_HOME=/usr/local/java/ant
export MAVEN_HOME=/usr/local/java/maven
export ECLIPSE_HOME=/usr/local/java/eclipse

export PATH=$PATH:$JAVA_HOME/bin:$MAVEN_HOME/bin:$JAVA_INSTAL/bin:$ANT_HOME/bin:$ECLIPSE_HOME

ajout d'un profil JAVA

Comme vous le constatez, nous utilisons ici les chemins "symboliques". Ainsi si vous changez de version d'eclipse par exemple, il suffit de changer le lien pour que cela continue de fonctionner.

Une fois le script enregistré, n'oubliez pas de faire un chmod +x /etc/profile.d/java.sh. Maintenant il ne nous reste qu'a ouvrir une console, ce qui provoquera le chargement de notre script, et de tester que tout se lance correctement.

Applications Java pour Linux

Lorsqu'il s'agit de développer une application pour Linux, il est important de se baser sur les librairies fournies avec la distribution plutôt que d'utiliser par exemple maven. Cela commence donc par ajouter et sélectionner dans votre projet le JDK iced-tea plutôt que celui de SUN.

Ensuite, si par exemple vous avez besoin des librairies DBUS, vous allez d'abord, en tant que root, l'installer :

urpmi dbus-java

Puis dans les propriétés de votre projet, dans Java Build Path/Librairies, ajouter la librairie /usr/share/java/dbus.jar. Dans la mesure où l'installation du paquet a déjà placé les librairies natives aux bons endroits, il n'y a rien d'autre à faire.

Conclusion

J'espère que ce petit tour vous aura plu et que l'utilisation de java sous linux ne sera plus un problème. Linux et Java, nous l'avons vu, fonctionne très bien ensemble, et pour peu que l'on s'y prenne bien, la souplesse de Linux s'accorde à merveille avec celle de Java.