Eclipse - Impossible d'installer un point d'arrêt en raison d'attributs de numéro de ligne manquants

Question

Je reçois cette erreur étrange dans Eclipse en essayant de définir un point d'arrêt.

Unable to insert breakpoint Absent Line Number Information

J'ai coché la case des options du compilateur mais pas de chance.

Answer 1

J'ai eu le même message d'erreur dans Eclipse 3.4.1, Sun JVM1.6.0_07 connecté à Tomcat 6.0 (s'exécutant en mode débogage sur un autre ordinateur, Sun JVM1.6.0_16, la connexion de débogage fonctionnait correctement).

Fenêtre -> Préférences -> Java -> Compilateur -> Génération de fichier de classe: "ajoute des attributs de numéro de ligne au fichier de classe généré" a été vérifié. J'ai fait un nettoyage, recompiler. Je l'ai décoché, recompilé, coché, recompilé. Je me suis assuré que le projet utilisait les paramètres globaux. Toujours le même message.

Je suis passé à ant build, en utilisant

<javac srcdir="./src/Java" destdir="./bin" debug="true">

Toujours le même message.

Je n'ai pas trouvé la cause de ce message ni pourquoi il ne s'en allait pas. Bien que cela semble avoir quelque chose à voir avec la session de débogage Tomcat en cours d’exécution: lorsqu’il est déconnecté, la recompilation résout le problème. Mais lors de la connexion du débogueur à Tomcat ou de la définition de nouveaux points d'arrêt lors d'une session de débogage connectée, il est réapparu.

Cependant, il s’est avéré que le message était erroné: J'ai effectivement pu déboguer et définir des points d'arrêt, à la fois avant et pendant le débogage ( javap -l affiche également les numéros de ligne). Alors ignorez le :)

Answer 2

1. Dans le menu Eclipse, sélectionnez Fenêtre-> Préférences-> Java-> Compilateur
2. Décochez la case "Ajouter des attributs de numéro de ligne ..."
3. Cliquez sur Appliquer -> Oui
4. Cochez la case "Ajouter un attribut de numéro de ligne ..."
5. Appliquez à nouveau.
6. Allez le débogage heureux

Answer 3

Cela a résolu mon problème:

1. Fenêtre -> Préférences -> Serveur -> Environnements d'exécution
2. Apache Tomcat -> modifier
3. Sélectionnez un JDK au lieu de JRE

Answer 4

Pour , les problèmes liés à Spring considèrent que, dans certains cas, il génère des classes "sans numéros de ligne"; Par exemple, une classe annotée @Service sans interface, ajoutez-la et vous pourrez déboguer. voir ici pour un exemple complet.

@Service("SkillService")
public class TestServiceWithoutInterface {
   public void doSomething() {
      System.out.println("Hello TestServiceWithoutInterface");
   }
}

Le service ci-dessus aura une interface générée par spring causant des "numéros de ligne manquants". L'ajout d'une interface réelle résout le problème de génération:

public interface TestService {
    void doSomething();
}

@Service("SkillService")
public class TestServiceImpl implements TestService {
   public void doSomething() {
      System.out.println("Hello TestServiceImpl");
   }
}

Answer 5

J'ai la réponse à ce problème du côté du kit SDK BlackBerry: pour une raison quelconque, quel que soit le nombre de fois où j'ai modifié les options du compilateur, le fichier de paramètres sous-jacent réel n'a pas changé.

Recherchez dans le dossier .settings de votre projet un fichier nommé org.Eclipse.jdt.core.prefs.

Vous pouvez y modifier les paramètres manuellement:

org.Eclipse.jdt.core.compiler.debug.lineNumber=generate

edit: De plus, j'ai remarqué que je pouvais parfois ignorer l'alerte donnée par Eclipse et qu'elle s'arrêterait toujours à l'endroit souhaité ... curioser et curioser ... Je l'ai mis dans le seau des choses que nous apprenons à gérer quand on travaille comme dev.

Answer 6

Cela a fonctionné pour moi:

1. Sous Window --> Preferences --> Java --> Compiler --> Classfile Generation, toutes les options doivent être sur True.
2. Fait debug="true" dans la tâche build.xml <javac>.
3. Déployer l'application dans le Tomcat par la guerre générée par ant
4. Redémarrage du Tomcat en mode Debug

Answer 7

Ne sais pas si cela est toujours d'actualité, peut-être qu'un autre marin trouvera cela utile.

Le message apparaît quand un fichier de classe est compilé et que les indicateurs de débogage sont désactivés.

Dans Eclipse, vous pouvez l’activer avec les options mentionnées ci-dessus,

Fenêtre -> Préférences -> Java -> Compilateur -> Génération de fichier de classe: "ajoute des attributs de numéro de ligne au fichier de classe généré"

Mais si vous avez un fichier JAR, vous obtiendrez la sortie compilée. Il n'y a pas de moyen facile de résoudre ce problème.

Si vous avez accès à la source et utilisez ant pour obtenir le fichier jar, vous pouvez modifier la tâche ant comme suit.

  <javac  destdir="${build.destDir}" srcdir="${build.srcDir}" source="1.6" fork="true" target="${javac.target}" debug="on" debuglevel="lines,vars,source" deprecation="on" memoryInitialSize="512m" memoryMaximumSize="1024m" optimize="true"   >

Bon débogage ..

ref: http://doc.sumy.ua/prog/Java/javanut/ch16_04.htm

Answer 8

Cela vous aiderait si vous indiquiez la version d'Eclipse que vous utilisez et la technologie (Java JDT, ou AJDT pour Aspect Java, ou C++ CDT par exemple), juste pour être sûr.

Du côté de Java, je suppose que votre "case à cocher parmi les options du compilateur" fait référence à this

Sous "Window --> Preferences --> Java --> Compiler --> Classfile Generation", toutes les options de génération 'Class file' 'sont définies sur True:

• (1) ajouter des attributs variables,
• (2) numéros de lignes,
• (3) ajouter le nom du fichier source,
• (4) préserver les variables locales non utilisées.

Votre projet a-t-il vérifié uniquement au niveau global (Préférences Windows) ou au niveau spécifique du projet?

Et êtes-vous sûr que la classe a ouvert (sur laquelle vous essayez de définir un point d'arrêt):

• est l'une de vos sources (et ne provient pas d'une bibliothèque tierce)
• est un .Java, pas un .class?

Essayez de tout nettoyer et de tout reconstruire, vérifiez le potentiel conflits de jar .

Answer 9

essayez de changer le jre que vous utilisez. Réglez le jre dans le dossier de JDK à la place.

Answer 10

Si rien ne fonctionne, ouvrez la perspective de débogage, effacez tous les points d'arrêt existants, puis rétablissez-les.

Answer 11

J'ai eu ce problème en essayant de démarrer Tomcat en mode débogage à partir d'Eclipse. J'avais un fichier de construction ANT prenant en charge la compilation et le déploiement. Après avoir défini le drapeau de débogage sur true (comme indiqué dans d'autres réponses) et redéployé l'application, cela a bien fonctionné:

<javac srcdir="./src/Java" destdir="./bin" debug="true">

NOTE: si vous venez d'ajouter l'indicateur de débogage et de le recompiler, vous devez toujours redéployer votre application sur le serveur car c'est là que Eclipse débogue les fichiers de classe. Très évident mais facile de passer une heure ou plus à vous gratter la tête et à vous demander pourquoi cela ne fonctionne pas (croyez-moi).

Answer 12

Étant donné que 6 versions différentes de Java sont installées, je devais modifier la conformité de mon JDK par défaut afin qu'elle corresponde à celle de la version Java que je souhaitais utiliser. Eclipse par défaut avait un niveau de conformité du compilateur défini sur Java 1.7 lorsque tout était construit/compilé à l'aide de Java 1.6.

Donc tout ce que j'ai fait était

1. Dans le menu Eclipse, sélectionnez Fenêtre-> Préférences-> Java-> Compilateur
2. Sous Conformité JDK, j'ai modifié le niveau de conformité du compilateur de 1.7 à 1.6.

Maintenant, Eclipse ne se plaint plus du "Impossible d'insérer un point d'arrêt Information de numéro de ligne absente" et les points d'arrêt de débogage fonctionnent réellement !!!

Answer 13

J'ai essayé presque toutes les solutions ici et pas de chance. Avez-vous essayé de cliquer sur "Ne plus me dire"? Après cela, j'ai redémarré mon programme et tout allait bien. Eclipse a frappé mon point d'arrêt comme si de rien n'était.

Eclipse essayait de configurer le débogage pour les objets proxy Spring CGLIB générés automatiquement. À moins que vous ne deviez déboguer quelque chose à ce niveau, vous devriez ignorer le problème.

Answer 14

J'ai eu le même problème lorsque je me suis rendu sur le serveur Jetty et que j'ai compilé le nouveau fichier .war d'ANT. Vous devez créer la même version du compilateur jdk/jre et du chemin de compilation (par exemple, jdk 1.6v33, jdk 1.7, ....) après avoir défini Java Compiler comme il était écrit auparavant.

J'ai tout fait et je ne travaille toujours pas. La solution consistait à supprimer les fichiers .class compilés et la cible du fichier war généré. Elle fonctionne maintenant :)

Answer 15

J'ai trouvé encore une autre raison pour ce message. Je programmais Scala. La solution était:

1. Ouvrez Exécuter -> Configurations de débogage
2. Dans l'onglet Principal, en bas, à côté des boutons "Appliquer" et "Rétablir", il y a un texte indiquant le lanceur que vous utilisez et à côté, un hyperlien indiquant "Sélectionnez un autre". C'est un élément étrange de l'interface utilisateur, qui ne semble pas être exploitable à première vue.
3. Utilisez le lien "Sélectionnez un autre" et choisissez "Lanceur d’application Scala (nouveau débogueur)". L'autre ne semble pas fonctionner avec Scala.

Le débogage devrait maintenant fonctionner. Notez que j'ai installé le plugin Scala IDE, cette option peut ne pas être disponible si vous ne l'avez pas.

Answer 16

J'ai reçu ce message avec Spring AOP (semble provenir de la bibliothèque CGLIB). Cliquer sur Ignorer semble fonctionner correctement, je peux toujours déboguer.

Answer 17

Ma situation était similaire:

• Je déboguais un test JUnit
• J'utilisais Mockito pour créer un espion, comme dans spyTask = spy(new Task())
• Je mets le point d'arrêt à l'intérieur de la classe que j'espionnais (à l'intérieur de Task.Java)

Ce point d'arrêt génère l'erreur en question à chaque fois que j'exécute Debug As... > JUnit Test

Pour résoudre le problème, j'ai déplacé le point d'arrêt "vers le haut" dans le test réel (à l'intérieur de TaskTest.Java). Une fois l'exécution arrêtée, j'ai ajouté le point d'arrêt à son emplacement d'origine (à l'intérieur de Task.Java).

J'ai toujours la même erreur mais après avoir cliqué sur "ok", le point d'arrêt a très bien fonctionné.

J'espère que ça aide quelqu'un,

-gmale

Answer 18

J'ai eu la même erreur avec JBoss 7.1 .. Et j'ai fait la même chose que Zefiro. Juste ignoré l'erreur et j'ai pu placer des points d'arrêt normalement. Dans mon cas, je construisais une construction de fourmis et voici ma tâche javac:

<javac
        srcdir="${src.dir}"
        destdir="${build.classes.dir}" 
        includeantruntime="false" 
        debug="${debug}"
        verbose="false"
        debuglevel="lines,vars,source"
        source="1.6"
        target="1.6">

        <!-- Sppressing warning for setting an older source without bootclasspath
             (see: https://blogs.Oracle.com/darcy/entry/bootclasspath_older_source) -->
        <compilerarg value="-Xlint:-options"/>

        <classpath>
            <fileset dir="${lib.dir}" includes="*.jar" />
            <fileset dir="${jboss.lib.dir}" includes="**/*.jar" />
        </classpath>

    </javac>

Answer 19

Ceci est expliqué en détail ici:

https://github.com/spring-projects/spring-ide/issues/78

Juste pour référence future, voici la partie pertinente de la réponse (ignorez le fait qui fait référence à une application Spring Boot, le comportement est le même pour beaucoup d'autres cas):

Chaque fois que vous définissez un point d'arrêt dans Eclipse/STS, le IDE tente de définir le point d'arrêt dans le VM si vous lancez une application. C'est ce qui se produit dans votre cas lorsque vous exécutez l'application de démarrage en mode débogage.

Pour chaque classe chargée dans la machine virtuelle Java, le IDE vérifie si elle doit définir un point d'arrêt ou non. S'il décide de définir le point d'arrêt, il essaie de le faire (en utilisant les informations de la définition de point d'arrêt dans l'EDI, y compris son numéro de ligne, car vous définissez généralement des points d'arrêt de ligne sur un fichier source sur une ligne donnée).

Cette décision (de définir le point d'arrêt sur une classe chargée donnée ou non) vérifie les types sur lesquels vous définissez le point d'arrêt, les types englobants et les classes internes. Cela garantit que les points d'arrêt des classes internes (même les classes internes anonymes) sont définis sur la machine virtuelle Java (et ne sont pas ignorés).

Spring Boot génère une classe interne pour votre contrôleur au moment de l'exécution (il s'agit de la classe interne générée par CGLIB qui apparaît dans le message d'erreur). Lorsque la machine virtuelle Java charge cette classe, elle tente de définir le point d'arrêt du numéro de ligne du type englobant (pour cette classe interne). Étant donné que la classe interne générée ne contient aucune information sur le numéro de ligne (elle n'a pas besoin d'informations de numéro de ligne), la définition du point d'arrêt échoue pour cette classe interne avec le message d'erreur mentionné.

Lorsque IDE charge le type englobant (votre classe de contrôleur elle-même), il essaie également de définir le point d'arrêt de la ligne et y parvient. Ceci est visualisé avec le marqueur de contrôle sur le marqueur de point d'arrêt.

Par conséquent, vous pouvez ignorer en toute sécurité le message d'erreur qui s'affiche. Pour éviter que ce message d'erreur ne s'affiche, vous pouvez vous rendre dans les préférences (Java -> Déboguer) et désactiver "Avertir en cas d'impossibilité d'installer un point d'arrêt en raison d'attributs de numéro de ligne manquants".

Answer 20

Une fois que j'ai rencontré la même erreur lorsque j'ai utilisé Junit et Mockito, j'ai oublié d'ajouter @PrepareForTest pour une classe statique.

Ajouter ci-dessous le code corrigé mon problème.

@PrepareForTest({XXXXX.class})

_{Pas sûr que c'était le même cas.}

Answer 21

J'ai eu le même problème lors du débogage d'un fichier WAR (construit à partir de plusieurs artefacts de projet Eclipse) déployé sur Tomcat.

Je construis tout en utilisant un script de construction ANT. Si c'est ce que vous faites, assurez-vous que le drapeau debug = true est défini sur chaque tâche javac que vous avez. C'était mon seul problème - j'espère que cela aidera votre problème!

Answer 22

J'ai eu le même problème, j'ai passé beaucoup de temps à chercher une solution mais ces solutions sont inutiles, donc j'étudie moi-même tous les cas, enfin j'ai découvert que le problème est un conflit entre les versions de JDK. Vous trouverez ci-dessous les étapes à suivre pour résoudre le problème: 1. Supprimez toutes les versions de JDK et JRE, ne conservez qu'une version. 2. Définissez le système Java_HOME et le compilateur Java dans Eclipse identique. Dans certains cas, l'erreur ci-dessus ne disparaîtra pas, mais nous pourrons exécuter le modèle de débogage.

Answer 23

Mon problème était que j'avais deux fichiers JAR et que j'essayais d'en remplacer un en fonction de son ordre dans l'onglet Java Build Path => Order & Export dans Eclipse, car l'un était destiné au débogage et l'autre non (le fichier JAR de débogage étant le premier dans la liste). ordre). Quand je l'ai fait de cette façon, je devais attacher manuellement une source.

J'ai essayé de supprimer le fichier JAR non débogué et de le placer dans mon répertoire\WEB-INF\lib \, de nettoyage, de construction, etc., et cela a fonctionné. Cette fois (après avoir supprimé la source attachée), cela me laisserait automatiquement naviguer à travers le code de débogage, sans avoir à attacher une source manuellement. Les points d'arrêt et le débogage ont également fonctionné.

---

Au cas où quelqu'un aurait encore des problèmes, j'ai aussi essayé toutes les solutions particulières mentionnées dans les autres réponses:

• Décochez, appliquez et revérifiez Add line number attributes...
• Édition manuelle de org.Eclipse.jdt.core.prefs comme indiqué dans une autre réponse: https://stackoverflow.com/a/31588700/1599699
• S'assurer que le fichier JAR a été généré avec le débogage activé.
• Modification du niveau de conformité du JDK de 1,6 à 1,7 (correspondant ainsi au JDK que j'utilisais).

J'ai également procédé à l'arrêt habituel du serveur (en m'assurant que Java.exe est bien fermé ...), en supprimant les répertoires\build\des deux projets, en redémarrant Eclipse avec le paramètre -clean, en recréant le fichier JAR de débogage, en actualisant, le nettoyage et la construction du projet avec le fichier JAR de débogage, le démarrage du serveur en mode débogage, la publication/le nettoyage et le point d'arrêt.

Answer 24

J'ai eu le même problème avec un projet spécifique et j'ai continué à essayer de réinitialiser les attributs de numéro de ligne dans Fenêtre-> Préférences ... Ensuite, j'ai réalisé que chaque projet avait ses propres paramètres pour les attributs de numéro de ligne. Faites un clic droit sur le projet, allez dans les propriétés, choisissez JavaCompiler, puis cochez la case "Ajouter des attributs de numéro de ligne ..."

Answer 25

J'avais un problème similaire sur le projet Spring MVC + Maven; et passé 2 heures à essayer de comprendre pourquoi le dossier cible n'est pas mis à jour avec des classes contenant des informations sur les lignes.

Je vous suggère de tout nettoyer et de vous assurer que toutes les classes sont supprimées du dossier avant de procéder à la construction.

1. Assurez-vous que, dans les propriétés du projet> Java, le compilateur a "Ajouter des attributs de numéro de ligne aux fichiers générés (utilisés par le débogueur)".
2. Nettoyer tout le projet. . (Menu> Projet> Nettoyer ...) Assurez-vous que le dossier cible est vide.
3. Projet de construction (Menu> Projet> Projet de construction)
4. Assurez-vous que de nouvelles classes sont générées dans votre répertoire cible.
5. Exécuter le débogage; si vous utilisez un serveur Web, assurez-vous d’exécuter votre serveur Web en mode "Débogage".

En cas de doute - que les fichiers .class compilés contiennent des numéros de ligne ou non - ouvrez les fichiers .class dans Eclipse. L'Eclipse décompilera les fichiers et vous indiquera si les numéros de ligne existent ou non.

Answer 26

J'ai fait tout ce qui est énuméré ci-dessus lors de la compilation/construction des bocaux - j'avais toujours le même problème.

Finalement, les changements de jvmarg listés ci-dessous lors du démarrage du serveur sont finalement ce qui a fonctionné pour moi:

1) Supprimé/commenté un tas d'arguments jvm concernant javaagent et bootclasspath.

2) Activer/désactiver la ligne suivante:

Ensuite, lorsque je démarre le serveur, je peux atteindre mes points d'arrêt. Je soupçonne que le javaagent interférait d'une manière ou d'une autre avec la capacité d'Eclipse à détecter les numéros de ligne.

Answer 27

Nous avons déjà des informations très utiles pour résoudre ce problème, mais dans mon cas particulier, le problème était que, lors de la mise à jour de mon projet à partir du référentiel, de nouvelles classes étaient générées avec la source compilée à partir du code le plus récent. Le problème est que j’ai oublié de changer les versions des projets dans mes fichiers POM et que, comme les points d’arrêt étaient définis sur le nouveau code et que les fichiers POM pointaient toujours vers d’anciennes versions disponibles sur les fichiers JAR d’une compilation précédente, les classes des fichiers JAR ont été choisies et non les classes du nouveau code.

En résumé, pour résoudre ce problème, il me suffisait de mettre à jour les versions du fichier POM du projet principal, de nettoyer et de recompiler le code source et enfin d'actualiser l'environnement. J'espère que cela pourra être utile à quelqu'un d'autre.

Answer 28

J'ai vu ce problème lorsque j'ai annoté une classe avec @ManagedBean (javax.annotation.ManagedBean). Le message d'avertissement est apparu lors de l'exécution de l'application nouvellement conforme sur JBoss EAP 6.2.0. L'ignorer et courir de toute façon n'a pas aidé - le point d'arrêt n'a jamais été atteint.

J'appelais ce haricot en utilisant EL dans une page JSF. Maintenant ... il est possible que @ManagedBean ne soit pas bon pour cela (je suis nouveau sur CDI). Lorsque j'ai modifié mon annotation en @Model, mon bean s'est exécuté, mais l'avertissement relatif au point d'arrêt a également disparu et j'ai atteint le point d'arrêt comme prévu.

En résumé, il semblerait que l'annotation @ManagedBean ait gâché les numéros de lignes, qu'il s'agisse ou non de la mauvaise annotation à utiliser.

Answer 29

Si quelqu'un essaie de déboguer le code source de Java, c'est la seule solution qui fonctionne pour moi. La plupart des réponses ci-dessus parlent de la définition de l'option du compilateur pour générer des numéros de ligne. Toutefois, si vous souhaitez déboguer le code source de Java (par exemple, Java.util.HashMap), les options ci-dessus risquent de ne pas fonctionner pour vous. En effet, le projet à partir duquel vous souhaitez déboguer le code source a le Java Build Path --> Library --> JRE System Library pointant vers le jre jar au lieu du jdk jar. Les classes regroupées dans jre jar ont déjà été précompilées avec une option spécifique, qui ne respectera pas les paramètres de l'option Compiler. La solution consiste à reconfigurer votre projet pour que le JRE System Library pointe sur le fichier jdk. Les classes à l'intérieur de votre jar jdk respectent les paramètres de l'option Compiler. Ainsi, une fois que vous aurez mis à jour le JRE System Library de votre projet pour qu'il pointe vers le fichier jar jdk, le débogage sur le code source Java commencera à fonctionner.

Answer 30

Assurez-vous que le projet dans lequel classe principale du moteur d'exécution est le même projet que celui dans lequel la classe dans laquelle vous avez des points d'arrêt. Sinon, assurez-vous que les deux projets sont dans le chemin de classe de la configuration d'exécution et apparaissent avant tous les fichiers JAR et les dossiers de classe.

Answer 31

J'ai rencontré ce problème aussi. J'utilise un script de construction de fourmi. Je travaille sur une ancienne application et j'utilise donc jdk version 1.4.2. Cela fonctionnait alors j'ai commencé à regarder autour de moi. J'ai remarqué que dans la configuration de débogage de l'onglet JRE, la version de Java avait été définie sur 1.7. Une fois que je suis revenu à la version 1.4, cela a fonctionné.

J'espère que ça aide.

Answer 32

J'essayais de déboguer le gestionnaire de journalisation et devais changer le jre en un jdk, puis sélectionner ce jdk dans l'onglet "principal", "Environnement d'exécution Java" | "JRE d'exécution" de la configuration de débogage alors tout allait bien.

Answer 33

Vérifiez/procédez comme suit:

1) Sous "Fenêtre -> Préférences -> Java -> Compilateur -> Génération de fichier de classe", toutes les options doivent être sur True:

(1) Add variable attributes...
(2) Add line number attributes...
(3) Add source file name...
(4) Preserve unused (never read) local variables

2) Dans le dossier .settings de votre projet, recherchez un fichier appelé org.Eclipse.jdt.core.prefs. Vérifier ou définir org.Eclipse.jdt.core.compiler.debug.lineNumber = générer

3) Si la fenêtre d'erreur apparaît toujours, cochez la case pour ne pas afficher le message d'erreur.

4) Nettoyer et construire le projet. Commencez le débogage.

Normalement, la fenêtre d'erreur ne s'affiche plus et les informations de débogage sont affichées correctement.

Answer 34

Si la solution ci-dessus ne fonctionne pas et que vous rencontrez ce problème après une injection de haricots printaniers, le problème peut être que vous n'avez pas utilisé l'interface pour la classe injectée. Essayer de faire une injection avec la classe qui implémente une interface résoudrait le problème. Pour un exemple, suivez le lien: Impossible d'installer le problème de point d'arrêt pour la création de bean

Answer 35

J'ai essayé la plupart des solutions précédentes, et j'avais toujours le problème. C'est ce que j'ai fait ensuite:

• Suppression de l'application d'Eclipse
• Arrêté le serveur
• Supprimer le dossier de l'application de webapps
• Supprimer le contenu du dossier temporaire sur le serveur
• Supprimer le contenu du dossier de travail sur le serveur
• Rouvrez l'application sur Eclipse
• Démarrer le serveur

Peut-être que certaines de ces étapes ne sont pas nécessaires, mais "au cas où".

Donc, si les solutions précédentes ne fonctionnent toujours pas pour vous. Essaye ça. J'espère que ça aide ;-)

Answer 36

Pour les projets Web avec serveur Tomcat, je l’ai résolu en procédant comme suit.

1. Fenêtre ouverte -> Afficher la vue -> Autre -> Serveurs.
2. Double-cliquez sur le serveur Tomcat en cours d'exécution. (La vue d'ensemble du serveur Tomcat sera ouverte)
3. Maintenant, cliquez sur le lien Lancer la configuration.
4. Cliquez sur l'onglet sources.
5. Cliquez sur Ajouter.
6. Choisissez le projet Java
7. Tous vos projets seront affichés.
8. Sélectionnez le sur vous voulez déboguer.
9. Enregistrez la configuration et redémarrez ou générez à nouveau l'application.

Answer 37

Les choses ci-dessus n'ont pas fonctionné pour moi. Les solutions ci-dessous ont finalement fonctionné. Configurations de débogage -> Classpath -> Entrées utilisateur -> (Ajoutez le dossier src du projet que vous souhaitez déboguer.)

Answer 38

Je faisais face au même problème dans mon IDE Eclipse. J'ai lu toutes les réponses à cette question et essayé presque tous les paramètres mentionnés, mais pas de chance.

J'ai donc essayé de modifier la bibliothèque d'exécution du projet. Auparavant, il s'agissait de JRE - Java SE 1.8

J'ai essayé de changer le JRE en JDK et cela a fonctionné pour moi:

Voici les étapes à suivre pour passer de JRE à JDK:

• Clic droit sur le projet
• Cliquez sur Propriétés -> Java Chemin de construction
• Sélectionnez l'onglet "Bibliothèques"
• Cliquez sur le bouton "Ajouter une bibliothèque". La fenêtre "Ajouter une bibliothèque" s'ouvre
• Sélectionnez "Bibliothèque système JRE" -> Cliquez sur le bouton Suivant
• Sélectionnez "Alterner JRE"
• Cliquez sur le bouton JRE installé
• Dans une nouvelle fenêtre, cliquez sur "Ajouter". Cela ouvrira une autre fenêtre "Ajouter JRE".
• Sélectionnez "VM standard". Cliquez sur Suivant.
• Cliquez sur le bouton Répertoire.
• Choisissez le chemin de votre répertoire d'installation "JDK" et cliquez sur OK. Puis cliquez sur Terminer.

• Maintenant, vérifiez sur "JDK" nouvellement ajouté

• Supprimer tous les autres JRE installés de la liste (facultatif)

• Appliquer-> OK
• Sélectionnez "JDK à partir d'un autre menu déroulant JRE et cliquez sur" Terminer "
• Maintenant, dans la liste ci-dessous, supprimez l’instance JRE
• Cliquez sur Appliquer -> OK

Et vous avez terminé !!

Answer 39

Comment corriger une erreur de point d'arrêt lors du débogage dans Eclipse? Remplacez ce que vous avez par cette ligne uniquement.

    Eclipse.preferences.version=1
org.Eclipse.jdt.core.compiler.codegen.inlineJsrBytecode=enabled
org.Eclipse.jdt.core.compiler.codegen.targetPlatform=1.8
org.Eclipse.jdt.core.compiler.codegen.unusedLocal=preserve
org.Eclipse.jdt.core.compiler.compliance=1.8
org.Eclipse.jdt.core.compiler.debug.lineNumber=generate
org.Eclipse.jdt.core.compiler.debug.localVariable=generate
org.Eclipse.jdt.core.compiler.debug.sourceFile=generate
org.Eclipse.jdt.core.compiler.problem.assertIdentifier=error
org.Eclipse.jdt.core.compiler.problem.enumIdentifier=error
org.Eclipse.jdt.core.compiler.source=1.8