Impossible d’obtenir le compilateur Java système. Veuillez utiliser un JDK, pas un JRE

Je ne parviens pas à obtenir le compilateur Java système. Veuillez utiliser un JDK, pas un JRE. lorsque le fichier jsp est dans le projet et que je le déploie dans Google App Engine. J’ai donc essayé ce qui suit pour résoudre le problème:

  1. Ajoutez -vm C: \ Program Files \ Java \ jdk1.6.0_43 \ bin \ javaw.exe à mon fichier eclipse.ini.
  2. Assurez-vous que le JDK se trouve dans le chemin de génération de mon projet et non dans jre.
  3. Ajoutez le fichier C: \ Program Files \ Java \ jdk1.6.0_43 \ bin \ à la variable PATH pour la variable d’environnement.

Mais aucun de ces problèmes n’a résolu le problème. Comment puis-je resoudre ceci?

    Lorsque vous ajoutez -vm C:\Program Files\Java\jdk1.6.0_43\bin\javaw.exe à -vm C:\Program Files\Java\jdk1.6.0_43\bin\javaw.exe , veillez à insérer -vm et C:\Program Files\Java\jdk1.6.0_43\bin\javaw.exe sur des lignes séparées

    Suivre 2 choses a fonctionné pour moi.

    1) Assurez-vous que votre chemin JAVA_HOME est défini sur JDK et que JAVA_HOME est inclus dans PATH.

    2) Ajoutez les deux premières lignes du code suivant dans eclipse.ini. Il devrait ressembler ci-dessous.

     -vm C:\Program Files\Java\jdk1.7.0_03\bin\javaw.exe -startup plugins/org.eclipse.equinox.launcher_1.3.0.v20130327-1440.jar --launcher.library plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.200.v20130807-1835-product org.eclipse.epp.package.standard.product --launcher.defaultAction openFile --launcher.XXMaxPermSize 256M -showsplash org.eclipse.platform --launcher.XXMaxPermSize 256m --launcher.defaultAction openFile --launcher.appendVmargs -vmargs -Dosgi.requiredJavaVersion=1.6 -Xms40m -Xmx512m 

    Pourriez-vous coller votre fichier eclipse.ini ici? Je viens d’append la ligne vm il y a quelques jours et ça a bien fonctionné.

    Rappelez-vous juste qu’il doit être mis avant la ligne -vmargs …

    J’ai eu le même problème et je suis arrivé à la conclusion:

    Si Eclipse est exécuté avec JRE, il utilisera JRE au lieu de JDK lors du déploiement sur App Engine, même si le paramètre Préférence est défini pour utiliser JDK.

    Solution: remplacez le chemin JAVA_HOME par JDK depuis JRE et assurez-vous que JAVA_HOME \ bin est inclus dans PATH. Ensuite, redémarrez Eclipse.

    J’ai rencontré la même erreur [“impossible d’obtenir le compilateur Java système”] lors du téléchargement de l’exemple de livre d’or de guerre. J’avais JDK installé et “java-version” pouvait imprimer les informations de version correctement. Alors, quelle partie a mal tourné?
    La cause du problème réside ici:

    Outre le répertoire% JAVA_HOME% / bin, java.exe / javaw.exe existe également dans le sous-répertoire C: \ Windows \.

    La commande de téléchargement a utilisé java.exe dans le sous-répertoire c: \ windows \ plutôt que dans le répertoire% JAVA_HOME%.
    Solution:
    Mettez “% JAVA_HOME% / bin” en tête de la définition de la variable d’environnement PATH. Cela devrait garantir que les éléments% JAVA_HOME% soient utilisés.

    Je résous ce problème en éditant le fichier appcfg.cmd sous le dossier SDK de Google App Engine.

    Le fichier appcfg.cmd est situé à

    {répertoire eclipse} \ plugins \ com.google.appengine.eclipse.sdkbundle_1.8.8 \ appengine-java-sdk-1.8.8 \ bin

    Modifiez la chaîne Java dans la commande à l’emplacement spécifique de java.exe sous le dossier jdk:

    Original:

    java -Xmx1100m -cp “% ~ dp0 .. \ lib \ appengine-tools-api.jar” com.google.appengine.tools.admin.AppCfg% *

    Après avoir changé:

    “C: \ Programmes \ Java \ jdk1.7.0_45 \ bin \ java.exe” -Xmx1100m -cp “% ~ dp0 .. \ lib \ appengine-tools-api.jar” com.google.appengine.tools.admin .AppCfg% *

    1. Editez le fichier eclipse ini et ajoutez -vm C: \ Program Files \ Java \ jdk1.7.0_65 \ bin \ javaw.exe comme suit (entre ces lignes):

      –launcher.defaultAction openFile -vm C: \ Program Files \ Java \ jdk1.7.0_65 \ bin \ javaw.exe –launcher.appendVmargs

    2. Configurez votre JAVA_HOME pour qu’il pointe vers le dossier jdk (C: \ Program Files \ Java \ jdk1.7.0_65)

    Cela a parfaitement fonctionné pour moi.

    Le dernier recours: une solution simple mais certes pas très élégante consiste à désinstaller tous les JRE .

    Allez dans Windows -> Preferences -> Java -> Installed JREs -> Add... et définissez le chemin vers votre dossier JDK en tant que JRE home . Les champs restants seront remplis automatiquement. Ensuite, dans la liste des Installed JREs assurez-vous que le JDK nouvellement ajouté est marqué par défaut.

    Assurez-vous que votre variable d’environnement JAVA_HOME fait référence au répertoire de base JDK, et non à JRE.

    Assez étrange, j’ai été confronté à ce problème soudainement, sans aucun changement (à part peut-être d’une mise à niveau de Windows 8 à la version 8.1).

    J’ai pu résoudre ce problème en plaçant -vm avant -vmargs dans le fichier eclipse.ini.

    J’ai fait tout ce que tout le monde a dit et rien n’a fonctionné. J’ai dû modifier le type de projet: Projet -> Propriétés-> Facettes de projet et vérifier le module Web dynamic. Après cela, j’ai pu déployer le projet.

    J’ai reçu cette erreur dans Android Studio lors de la création du projet. J’ai défini l’emplacement JDK dans les parameters (Fichier ==> Paramètres) et cela a résolu le problème pour moi.

    J’ai mis à jour tous les emplacements suggérés pour qu’ils pointent vers mon jdk1.8.0_111 plutôt que jre: Eclipse.ini, chemin système, JAVA_HOME. Également supprimé l’entrée Oracle de mon chemin: C: \ ProgramData \ Oracle \ Java \ javapath (qui pointait au jre). Finalement, j’ai trouvé un autre spot qui faisait référence au jre, qui l’a finalement corrigé:

    Dans Eclipse -> Propriétés de mon projet -> Chemin de construction Java -> La bibliothèque système JRE était toujours pointée sur mon jre. Supprimé, fait “Ajouter une bibliothèque” et l’a montré à mon jdk. Eclipse redémarré et je pourrais enfin déployer avec un jsp.

    Je suis retourné et j’ai supprimé JAVA_HOME et cela fonctionne toujours (JAVA_HOME interfère avec d’autres systèmes de compilation).

    Je suis impatient de trouver une bonne construction en ligne de commande afin d’éviter l’utilisation de compilateurs aléatoires.