Discussion :

[ngmsky]

Bonjour,

J'aimerais développé des applications en Java 7.
Par contre, j'ai appris que les premières versions de java 7 soufraient de sérieux problèmes de sécurité 29 failles dont deux très graves).

En fait, depuis peu une nouvelle version de Java7 update 7 (du 31 août 2012) contenant des correctifs est désormais disponible en téléchargement. Je l'ai donc téléchargé puis installé avec succès.

Ensuite, j'ai téléchargé la version Eclipse Classic 4.2 et l'ai lancé sans problème. Cette version à une date de build du 08/06/2012. Ce qui signifie qu'elle n'intègre pas le JDK corrigé.
Donc, j'aimerais qu'Eclipse se base sur ce "JDK 7u7" pour compiler mes programmes et non sur son compilateur interne.

Voici les détails détails qui m'inquiètent concernant cette version d'Eclipse :

org.eclipse.jdt (3.8.0.v20120525-1249-8-8nFqlFNOfwKDRGz-pXLdGxEM83) "Eclipse Java Development Tools"
(v20120525 = 25 Mai 2012 ?)

et
org.eclipse.sdk (4.2.0.v20120528-1648-7T7oDFDPz-3FepgRqG6kkFFY0UF4_otgmt0XcoU3Zh27X) "Eclipse Project SDK"
(v20120528 = 28 Mai 2012 ?)

Si le JDT et le SDK (inclus dans Eclipse) date de Mai 2012, alors les programmes Java qui seront compilés avec cet Eclipse seront toujours exposés aux 29 failles de sécurité. C'est pour cela que je tiens vraiment à ce qu'Eclipse utilise obligatoirement le "dernier" JDK de Java "7u7".

Voici une autre partie de la configuration d'Eclipse avec des liens importants.

*** Platform Details:

*** System properties:
applicationXMI=org.eclipse.ui.workbench/LegacyIDE.e4xmi
awt.toolkit=sun.awt.windows.WToolkit
eclipse.application=org.eclipse.ui.ide.workbench
eclipse.buildId=I20120608-1400
eclipse.commands=-os
win32
-ws
win32
-arch
x86
-showsplash
C:\eclipse-SDK-4.2\\plugins\org.eclipse.platform_4.2.0.v201206081400\splash.bmp
-launcher
C:\eclipse-SDK-4.2\eclipse.exe
-name
Eclipse
--launcher.library
C:\eclipse-SDK-4.2\\plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.200.v20120522-1813\eclipse_1503.dll
-startup
C:\eclipse-SDK-4.2\\plugins/org.eclipse.equinox.launcher_1.3.0.v20120522-1813.jar
--launcher.overrideVmargs
-vm
C:\Program Files\Java\jre7\bin\client\jvm.dll
eclipse.home.location=file:/C:/eclipse-SDK-4.2/
eclipse.launcher=C:\eclipse-SDK-4.2\eclipse.exe
eclipse.launcher.name=Eclipse
eclipse.p2.data.area=@config.dir/../p2
eclipse.p2.profile=SDKProfile
eclipse.product=org.eclipse.sdk.ide
eclipse.startTime=1348312390609
eclipse.vm=C:\Program Files\Java\jre7\bin\client\jvm.dll
eclipse.vmargs=-Xms40m
-Xmx512m
-XX:MaxPermSize=256m
-Djava.class.path=C:\eclipse-SDK-4.2\\plugins/org.eclipse.equinox.launcher_1.3.0.v20120522-1813.jar
equinox.use.ds=true
file.encoding=Cp1252
file.encoding.pkg=sun.io
file.separator=\
gosh.args=--nointeractive
java.awt.graphicsenv=sun.awt.Win32GraphicsEnvironment
java.awt.printerjob=sun.awt.windows.WPrinterJob
java.class.path=C:\eclipse-SDK-4.2\\plugins/org.eclipse.equinox.launcher_1.3.0.v20120522-1813.jar
java.class.version=51.0
java.endorsed.dirs=C:\Program Files\Java\jre7\lib\endorsed
java.ext.dirs=C:\Program Files\Java\jre7\lib\ext;C:\WINDOWS\Sun\Java\lib\ext
java.home=C:\Program Files\Java\jre7
java.io.tmpdir=C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\
java.library.path=C:\eclipse-SDK-4.2;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32;C:\WINDOWS;C:/Program Files/Java/jre7/bin/client;C:/Program Files/Java/jre7/bin;C:/Program Files/Java/jre7/lib/i386;C:\Program Files\Fichiers communs\Microsoft Shared\Windows Live;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Fichiers communs\HP\Digital Imaging\bin;C:\Program Files\HP\Digital Imaging\bin\;C:\Program Files\HP\Digital Imaging\bin\Qt\Qt 4.3.3;C:\Program Files\QuickTime\QTSystem\;C:\Program Files\Fichiers communs\Microsoft Shared\Windows Live;C:\Program Files\Fichiers communs\Microsoft Shared\Windows Live;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Fichiers communs\HP\Digital Imaging\bin;C:\Program Files\HP\Digital Imaging\bin\;C:\Program Files\HP\Digital Imaging\bin\Qt\Qt 4.3.3;C:\Program Files\QuickTime\QTSystem\;C:\Program Files\Microsoft eMbedded Tools\EVC\WCE300\BIN;C:\Program Files\IDM Computer Solutions\UltraEdit\;C:\eclipse-SDK-4.2;;.
java.runtime.name=Java(TM) SE Runtime Environment
java.runtime.version=1.7.0_07-b11
java.specification.name=Java Platform API Specification
java.specification.vendor=Oracle Corporation
java.specification.version=1.7
java.vendor=Oracle Corporation
java.vendor.url=http://java.oracle.com/
java.vendor.url.bug=http://bugreport.sun.com/bugreport/
java.version=1.7.0_07
java.vm.info=mixed mode
java.vm.name=Java HotSpot(TM) Client VM
java.vm.specification.name=Java Virtual Machine Specification
java.vm.specification.vendor=Oracle Corporation
java.vm.specification.version=1.7
java.vm.vendor=Oracle Corporation
java.vm.version=23.3-b01
line.separator=
.
.
.
Plus loin, j'ai :

sun.arch.data.model=32
sun.boot.class.path=C:\Program Files\Java\jre7\lib\resources.jar;C:\Program Files\Java\jre7\lib\rt.jar;C:\Program Files\Java\jre7\lib\sunrsasign.jar;C:\Program Files\Java\jre7\lib\jsse.jar;C:\Program Files\Java\jre7\lib\jce.jar;C:\Program Files\Java\jre7\lib\charsets.jar;C:\Program Files\Java\jre7\lib\jfr.jar;C:\Program Files\Java\jre7\classes
sun.boot.library.path=C:\Program Files\Java\jre7\bin

Je constate qu'il n'y a aucun lien entre Eclipse et le JDK-7u7 (C:\Program Files\Java\jdk1.7.0_07) que j'ai installé mais plutôt vers le dossier Jre7 (C:\Program Files\Java\jre7).

Remarque :
Après installation du JDK 7u7, il y avait 2 nouveaux sous-dossiers crées dans "C:\Program Files\Java\".
Il s'agit des dossiers :
- jre7 (122Mo - 649 fichiers et 33 dossiers )
et
- jdk1.7.0_07 contenant un autre dossier jre. (ce jre fait 136Mo - 653 fichiers et 34 dossiers)

Mes questions :

- Pourquoi y a-t-il 2 JRE (un interne, l'autre externe au JDK) ?
- Pourquoi Eclipse pointe vers le JRE externe au JDK alors qu'il semble contenir moins de fichiers et dossiers que celui interne au dossier JDK ?

De toutes les façons, je me dis que peu importe le JRE (interne ou externe), cela n'aura aucun impact sur le fichiers .class puisque le JRE sert simplement à exécuter (interpréter) les .class qui sont produits par le compilateur javac (.java vers .class). Et le compilateur javac est inclu dans le dossier JDK.

Le fait qu'Eclipse ne pointe aucun chemin vers le JDK installé, cela signifie que mes .java seront compilés par le compilateur interne (par défaut) d'Eclipse ?

- Si oui, cela veut dire que j'aurai des .class non protégés contre les 29 dernières failles de sécurité Java ?

Comment lancer ou configurer ou forcer Eclipse à utiliser le JDK Oracle au lieu de son propre JDK (JDT) interne ?

Merci d'avance pour votre aide.

[Laurent.B]

Bonjour,

Concernant la faille de sécurité récente de Java 7, celle-ci concerne les applets, c'est-à-dire les applications qui s'exécutent dans un navigateur web...
Comme tu n'indiques pas quel type d'application tu veux développer, il est déjà possible que tu t'inquiètes pour rien.

D'autre part, même si c'est bien une applet que tu veux développer, le problème de sécurité n'est pas franchement de ton ressort car il concerne le JRE et non le compilateur ! Pour que les utilisateurs risquent quelque chose, il faudrait que tu exploites toi-même cette faille...

De surcroit, d'autres failles similaires à celle-ci ont été identifiées après coup et donc ne sont pas encore corrigées...

J'ignore quelles sont les 28 autres failles mais a priori cela ne concerne en rien le compilateur.

Sinon, même si tout ça n'a rien à voir avec ce que tu pensais être un problème, regarde ceci http://eclipse.developpez.com/faq/?p...eform#autreJDK, ainsi tu sauras comment paramétrer Eclipse pour qu'il démarre sur tel ou tel JRE.
Voir aussi dans les cours et tutoriels pour apprendre Eclipse.

[ngmsky]

Bonjour,

Merci infiniment pour ces précisions.
Effectivement je ne suis pas concerné puisque je veux faire du Swing et non du web (applet).

Déjà je suis soulagé.

Merci aussi pour le lien sur comment démarrer Eclipse avec tel JRE ou tel JDK, je l'avais bien vu avant de poster mais je ne savais pas à quel moment, ni pour quelle raison doit-on décider de préférer de le lancer avec un JRE plutôt qu'avec un JDK ?

C'est tout mon problème.

D'autre part, d'après ce que j'ai compris de Java :
- Le JRE sert à exécuter (interpréter) les programmes Java déjà précompilés en .class
- Le JDK (contenant aussi un JRE) fournissant tous les outils nécessaires au développement d'applications Java : librairies, compilateur, débugger, etc.

Ma question est donc de savoir pourquoi aucun lien de configuration d'Eclipse ne pointe vers mon dossier d'installation du JDK (... Program Files/Java/jdk), cela signifie-t-il qu'Eclipse ignore les librairies installées par le JDK ?

Si oui, je pense qu'il est alors préférable de faire pointer Eclipse vers le JDK en le spécifiant (dans eclipse.ini):

-vm
C:/Program Files/Java/jdk1.7.0_7/bin/javaw.exe

Et même là, j'ai l'impression que ce paramètre indique à Eclipse l’interpréteur à utilisé : la VM (virtual Machine) donc le JRE.

N'y a-t-il pas moyen d'indiquer le compilateur à utiliser ?
Je pensais plutôt trouver quelque chose du genre :

-compiler
C:/Program Files/Java/jdk1.7.0_7/bin/javac.exe

En fait, je me dis que si Eclipse utilise son compilateur interne, celui-ci devrait surement utiliser les librairies livrées avec Eclipse pour compiler les .java. Or je voudrais qu'il utilise les librairies du JDK.

Excusez-moi d'insister un peu. En effet, avant que je n'installe ce JDK 7u7, j’utilisais déjà Eclipse pour Java. Par contre, je n'avais pas de JDK installé sur mon PC. Seul le JRE 6 était disponible pour exécuter les applications Java telles qu'Eclipse.

Cela me laisse donc penser que malgré le fait d'avoir installé ce JDK 7u7, Eclipse n'en tire pas profit puisqu'il se contente du JDT et SDK qui est intégré à Eclipse.

Même si cette faille ne concerne pas les programmes Swing, j'aimerais quand même savoir, par curiosité, comment obliger ou indiquer à Eclipse d'utiliser le JDK (donc le plus à jour) ?

Merci d'avance pour votre aide.

[Laurent.B]

Eclipse est la plupart du temps indépendant du JDK installé et se contente des outils nécessaires à la compilation et autres, parmi ceux qu'il embarque lui-même.

Néanmoins, comme expliqué dans la FAQ, il peut s'avérer utile de paramétrer Eclipse pour qu'il démarre avec le javaw.exe d'un JDK. Ceci a le double avantage de donner d'office accès aux sources/javadocs de la version ciblée (à partir du moment où l'on code en Java dans cette même version) mais aussi parce que certaines opérations nécessitent des outils particuliers du JDK pour pouvoir être exécutées. Dans le cas général, ce n'est pas primordial et si jamais tu tombes dans ce cas-là, Eclipse devrait te l'indiquer plutôt clairement, en réclamant un JDK.
Autrement dit, paramétrer la -vm, en pointant sur le javaw.exe d'un JDK, suffit à Eclipse pour qu'il puisse retrouver et utiliser, le cas échéant, les outils du JDK qu'il n'embarque pas lui-même.

Une fois de plus, je pense que tu t'inquiètes un peu pour rien. Si jamais Eclipse devait pouvoir disposer d'un compilateur plus à jour que celui qu'il embarque, je pense qu'une mise à jour de son plug-in serait rapidement déployée. Personnellement, je n'ai pas connaissance d'un paramètre qui indique à Eclipse quel compilateur utiliser.

Une dernière chose, ce n'est pas Eclipse Classic que tu aurais dû prendre, surtout pour faire de l'IHM en Swing, mais Eclipse IDE for Java Developers.

[ngmsky]

Merci pour votre réponse rapide et claire.

Ok, finalement je pointerai le -vm vers le javaw.exe du JDK d'Oracle.
Et une fois le projet fini, avant la livraison, je le compilerai manuellement en ligne de commande avec javac, voire même en utilisant Ant ou Maven pour générer le .jar et également.
Comme ça au moins je suis sûr que le projet sera compilé avec les outils du JDK (compilateur + librairies) officiels et les plus à jour possible.

Merci encore pour votre aide.

[Laurent.B]

Et une fois le projet fini, avant la livraison, je le compilerai manuellement en ligne de commande avec javac, voire même en utilisant Ant ou Maven pour générer le .jar et également.

Je pense que tu t'embêtes pour rien mais bon c'est toi qui vois...
Par contre, l'idée d'utiliser Maven ou même Ant est très bien mais il vaut mieux s'en préoccuper dès le départ. Avec Maven, il est absurde de l'utiliser à la fin, puisqu'il sert justement à initier les projets...