Installation d'un nouveau java sans toucher à l'actuelle vers...
Résolu/Fermé
Xeny351
Messages postés
33
Date d'inscription
dimanche 13 décembre 2009
Statut
Membre
Dernière intervention
6 septembre 2016
-
30 août 2016 à 14:06
Xeny351 Messages postés 33 Date d'inscription dimanche 13 décembre 2009 Statut Membre Dernière intervention 6 septembre 2016 - 6 sept. 2016 à 16:29
Xeny351 Messages postés 33 Date d'inscription dimanche 13 décembre 2009 Statut Membre Dernière intervention 6 septembre 2016 - 6 sept. 2016 à 16:29
A voir également:
- Installation d'un nouveau java sans toucher à l'actuelle vers...
- Nouveau outlook - Guide
- Waptrick java football - Télécharger - Jeux vidéo
- Installation chromecast - Guide
- Java apk - Télécharger - Langages
- Waptrick java - Forum Mobile
1 réponse
KX
Messages postés
16733
Date d'inscription
samedi 31 mai 2008
Statut
Modérateur
Dernière intervention
31 janvier 2024
3 015
Modifié par KX le 30/08/2016 à 23:50
Modifié par KX le 30/08/2016 à 23:50
Bonjour,
Version courte : tout à fait possible, sans aucun problème !
Version longue :
Lorsqu'un programme Java est lancé c'est fait grâce au programme java.exe (ou équivalent pour Solaris) qui est installé dans le répertoire "bin" du dossier d'installation de Java et qui est configuré dans le PATH, généralement grâce à une variable intermédiaire JAVA_HOME qui pointe vers ce répertoire d'installation.
Ce que je peux te proposer c'est d'installer un nouveau Java ("l'installation" consiste à dézipper un tar.gz, car Java est toujours portable !), de configurer une variable d'environnement pour chaque version majeure de Java (par exemple JAVA_HOME_5 pour Java 5, JAVA_HOME_8 pour Java 8...)
Tu laisses le PATH par défaut (avec JAVA_HOME_5) tel qu'il est configuré aujourd'hui pour les scripts, et soit tu construis un PATH alternatif (via des users différents lorsqu'ils accèdent au serveur), soit les développeurs modifient à la volée le PATH utilisé par leurs programmes afin d'utiliser le JAVA_HOME de la version dont ils ont besoin.
Remarque : Java 5 est dépassé depuis 10 ans, aujourd'hui on est à la version 8, la 9 sortira l'an prochain, donc ce genre de problèmes peuvent commencer à se multiplier au fur et à mesure, vous ne pouvez pas indéfiniment rester sur une vieille version, c'est d'ailleurs dangereux car il y a des failles de sécurités qui ne sont mises à jour que sur les versions les plus récentes.
Il serait donc pertinent que les programmes qui le peuvent passent sur une nouvelle version de Java, pour la plupart cela devraient continuer à fonctionner sans problème grâce à la rétrocompatibilité des versions.
Pour les autres, il faudra peut-être faire quelques (petits) développements pour migrer de version et au pire on pourra laisser le Java 5 historique disponible (même si en terme de développement Java, c'est des dinosaures...)
Généralement ces migrations se font en deux temps afin de détecter tout problème éventuel. Exemple pour une migration de Java 5 vers Java 8 :
compilation J5/exécution J5 → compil J5/exec J8 → compil J8/exec J8
La confiance n'exclut pas le contrôle
Version courte : tout à fait possible, sans aucun problème !
Version longue :
Lorsqu'un programme Java est lancé c'est fait grâce au programme java.exe (ou équivalent pour Solaris) qui est installé dans le répertoire "bin" du dossier d'installation de Java et qui est configuré dans le PATH, généralement grâce à une variable intermédiaire JAVA_HOME qui pointe vers ce répertoire d'installation.
Ce que je peux te proposer c'est d'installer un nouveau Java ("l'installation" consiste à dézipper un tar.gz, car Java est toujours portable !), de configurer une variable d'environnement pour chaque version majeure de Java (par exemple JAVA_HOME_5 pour Java 5, JAVA_HOME_8 pour Java 8...)
Tu laisses le PATH par défaut (avec JAVA_HOME_5) tel qu'il est configuré aujourd'hui pour les scripts, et soit tu construis un PATH alternatif (via des users différents lorsqu'ils accèdent au serveur), soit les développeurs modifient à la volée le PATH utilisé par leurs programmes afin d'utiliser le JAVA_HOME de la version dont ils ont besoin.
Remarque : Java 5 est dépassé depuis 10 ans, aujourd'hui on est à la version 8, la 9 sortira l'an prochain, donc ce genre de problèmes peuvent commencer à se multiplier au fur et à mesure, vous ne pouvez pas indéfiniment rester sur une vieille version, c'est d'ailleurs dangereux car il y a des failles de sécurités qui ne sont mises à jour que sur les versions les plus récentes.
Il serait donc pertinent que les programmes qui le peuvent passent sur une nouvelle version de Java, pour la plupart cela devraient continuer à fonctionner sans problème grâce à la rétrocompatibilité des versions.
Pour les autres, il faudra peut-être faire quelques (petits) développements pour migrer de version et au pire on pourra laisser le Java 5 historique disponible (même si en terme de développement Java, c'est des dinosaures...)
Généralement ces migrations se font en deux temps afin de détecter tout problème éventuel. Exemple pour une migration de Java 5 vers Java 8 :
compilation J5/exécution J5 → compil J5/exec J8 → compil J8/exec J8
La confiance n'exclut pas le contrôle
Modifié par Xeny351 le 6/09/2016 à 16:30
Merci pour ta réponse!
C'est en effet un peu ce que j'avais imaginé, avec un peu moins de précision, notamment je n’avais pas pensé à l'astuce des variables qui est toute bête mais bien utile!
Cependant, nous allons finalement en profiter pour migrer notre serveur qui lui aussi est globalement obsolète...
Encore merci et bonne journée!