Je ne trouve aucune erreur dans cette classe, mais NetBeans montrant en permanence le symbole rouge sur cette classe. La classe est la compilation est la compilation mais obtient une erreur d'exécution. P> dans une autre classe, où une classe individuelle est utilisée: P> Individual temp = new Individual(STRING_SIZE);
pop.add(temp);
5 Réponses :
Ce n'est probablement pas le problème, mais votre méthode puis l'appelez comme ceci: copie () est totalement gâchée ... au lieu de copier quoi que ce soit, cela réinitialise simplement l'objet d'origine et renvoie un nouveau vide. Si vous le souhaitez de créer des copies de l'objet, vous devriez faire quelque chose comme ceci:
Heureux d'aider, mais si cela corrige votre problème, c'est par hasard: p Vérifiez que les licks chauds répondent à une meilleure explication.
Vous devriez Le vérificateur JVM nécessite que tout constructeur (autre que pour l'objet, bien sûr) invoquer (éventuellement indirectement via un autre constructeur) C'est le constructeur de Superclass. Normalement, le compilateur insère automatiquement un appel au constructeur de Superclass si vous ne le faites pas, mais il est possible que cela puisse être confondu sans le faire dans certaines circonstances (bien que le code présenté ne semble pas ce complexe).
(et oui, vous avez Javap le fichier .class et vérifier si le compilateur a généré un appel à Super () près du début de votre constructeur.
ceci et ind échangé dans la plupart des endroits de copier .)
Bonjour, j'ai la même expérience avec Netbeans. J'étais assez en colère à ce sujet, mais la solution est assez facile. Vous devez copier créer de nouveaux projets et les mêmes classes que dans le non-fonctionnel. Ensuite, copiez tous les textes des classes dans l'ancien projet vers un nouveau projet et n'oubliez pas de modifier le nom du package si ce n'est pas le même. Votre travail sera alors exécuté :)
J'ai eu le même problème chez Netbeans. Nettoyer puis construire le projet à nouveau résolu pour moi.
java.lang.verifyError peut être le résultat lorsque vous avez compilé sur une autre bibliothèque que vous utilisez au moment de l'exécution.
Par exemple, cela m'est arrivé lors de la tentative d'exécution d'un programme compilé contre Xerces 1, mais Xerces 2 a été trouvé sur la classe de classe. Les classes requises (dans ORG.APACHE. * Espace de noms) ont été trouvées au moment de l'exécution, donc la clastonnelle de classeNotFoundException n'était pas le résultat. Il y avait eu des modifications aux classes et aux méthodes, de sorte que les signatures de méthode trouvées à l'exécution ne correspondaient pas à ce qui était là à la compilation.
Normalement, le compilateur signalera des problèmes lorsque les signatures de méthode ne correspondent pas. La JVM vérifiera à nouveau le bytecode lorsque la classe est chargée et jette VerifyError lorsque le bytecode tente de faire quelque chose qui ne devrait pas être autorisé - par exemple. Appeler une méthode qui renvoie la chaîne, puis stocke la valeur de retour dans un champ détenant une liste. C'est ce que j'ai eu, mais je suis toujours incapable de le corriger ..
Stackoverflow.com/questions/100107 / ...
Le code actuel semble correct, le problème pourrait être dans l'utilisation de la classe individuelle. Comment créez-vous une instance de celui-ci?
@Staquette: Je n'ai pas compris un peu. Je suis e novice
Je ne vois aucune erreur dans Eclipse lorsque je crée un projet avec cette classe.
Ouais, pourriez-vous ajouter le code que vous utilisez pour créer l'instance? Quelque chose comme
individu indov1 = nouvelle personne (5); ?Vous devez expliquer ce que vous avez fait depuis le début.
Cela semble être un quirk spécifique des NetBeans lors de la double signature de la même signature de différents forfaits: Stackoverflow.com/Questtions/6560988/... Vous avez probablement renommé de vieilles classes manuellement par fichier explorateur au lieu d'utiliser des fonctions de refactoring IDE. Cleansweep votre projet.
Ma solution la plus simple consiste à sauvegarder, supprimez le fichier Java incrusté et copiez-le. Voir code source inabiletable après copie en double