eclipse collision package 3.4 (Ganymede de) avec le type

StackOverflow https://stackoverflow.com/questions/2674325

Question

Nous avons un paquet qui se termine par exception par exemple 

package a.b.c.exception;

Notre base de code avait aucun problème jusqu'à éclipse 3.3, cependant, quand nous sommes passés à éclipser 3.4, il a commencé à donner des erreurs liées à ce paquet: 

"The package a.b.c.exception collides with a type"

Quand je Refactor le nom du paquet à a.b.c.exceptions, il n'y a aucun problème. Est-ce en raison d'un bogue dans Eclipse 3.4 ou est-il un paramètre pour corriger ce comportement?

Était-ce utile?

La solution 5

J'ai changé l'une des options de compilation dans Eclipse et le problème a disparu. Sous Propriétés de l'espace de travail: Compilateur Java -> Erreurs / avertissements ->     Change « importation non » de « Attention » à « Ignorer ».

Autres conseils

Il est parce que vous avez un exception de classe nommée (avec une minuscule « e ») dans le package a.b.c et un package nommé a.b.c.exception.

Il provoque une collision de nom parce que si vous avez le code a.b.c.exception.doSomething(); - ce que cela signifie que vous voulez appeler la méthode doSomething() de statique dans la classe a.b.c.exception? Ou est-ce que cela signifie qu'il ya une classe appelée a.b.c.exception.doSomething que vous essayez d'invoquer le constructeur de?

Memory Stick avec les conventions de nommage Java - packages tout en minuscules, des classes commençant par une majuscule et le chameau cas après -. Et vous ne verrez jamais ce problème

========== ========== EDIT

Ceci est la seule légitime raison de cette erreur devrait faire preuve jusqu'à ...

Il ne doit pas être dans votre projet directement, il pourrait être dans un autre projet ou d'une bibliothèque que votre projet dépend. Cela devrait vous montrer toutes les occurrences du partout classe sur le chemin de construction ou votre projet: Cliquez sur le bouton recherche lampe de poche dans la barre d'outils Eclipse -> Choisissez « Java Recherche » -> entrez abcexception dans le champ de recherche -> sélectionnez « Sensible à la casse » - > sélectionnez « type » dans « Rechercher » -.> assurez-vous que toutes les options sont sélectionnées pour « Recherche dans »

Utilisez-vous des outils qui génèrent des classes? Pourraient-ils être de les mettre dans le répertoire de construction de votre projet? Quand vous voyez l'erreur, si vous allez dans le répertoire de construction du projet, et descendre dans le a / b / c / répertoire ne voyez-vous un fichier .class pour « exception »?

Bien sûr Eclipse en général pourrait avoir un bug (mais je pense qu'il y aurait un rapport de bogue dans Eclipse 3.4 et que vous pourrez trouver plus de plaintes si elle était ...), votre Eclipse installation pourrait être brisé d'une certaine façon (quelqu'un d'autre peut ouvrir votre projet dans Eclipse 3.4? Pouvez-vous faire Eclipse propre 3.4 installer dans un autre répertoire? est-ce que l'erreur apparaît là?), ou votre projet pourrait être sali d'une certaine façon (Créer un nouveau projet sans dépendance autre que le JDK, créer le package abcexception dans votre nouveau projet, créer une classe dans votre projet import a.b.c.exception.*; et voir si l'erreur se produit.).

En Java vous ne pouvez pas avoir un nom de classe qui est le même que le nom du package.

Cela signifie que le paquet JDT doit avoir appliqué cette règle que dans 3.4

Voir bug 63668 par exemple.

Comme commentaires Nate:

  

Une classe nommée Exception ne vous empêchera pas de créer exception paquet .
   Cas compte .

     

Souvenez-vous également le nom complet d'une classe comprend le paquet il se trouve.
  Alors a.b.SomeClass (nom de la classe) est différent de x.y.SomeClass (nom du package).
  Il n'y aurait pas de collision nom ici.

     

Le nom de la classe et le nom du package doivent correspondre dans les deux cas et l'emballage pour provoquer cette erreur.

Voir sa réponse plus précise .

a rencontré un problème similaire dans une énorme base de code que je hérité. Il se trouve que le choc a été causé par un nom de classe partiellement qualifié dans un lien JavaDoc.

Pour paraphraser, Eclipse me disait que j'avais un affrontement paquet / type pour a.b.c.d. lors de la compilation a.b.c.d.London. Faire une recherche java sur le code de a.b.c.d a révélé que Eclipse a pensé qu'un commentaire Javadoc dans a.b.c.Paris était un match. Le commentaire JavaDoc contenu {@} lien d.NewYork. Quand je l'ai changé pour le lire {} @link a.b.c.d.NewYork l'erreur de compilation a été résolue.

Il convient également de noter que NewYork n'a pas été importé dans la classe Paris comme il est seulement apparu dans le commentaire JavaDoc. Cela a également rendu non résolu sous sa forme abrégée et en cliquant sur le lien dans le commentaire n'a pas fonctionné. Ce qui en fait une référence absolue fait également le travail de liaison JavaDoc.

Je sais que cela paraître stupide, et peut-être trop simple pour être vrai, mais je résolu ce problème exactement le même message d'erreur par:

  • Suppression de la ligne entière du nom du package provoquant le message d'erreur.
  • Enregistrer le fichier .java (ce qui déclenche une nouvelle erreur sur la même ligne indiquant « Le paquet a déclaré « » ne correspond pas à l'emballage prévu »), qu'il devrait faire.
  • retapant le nom du package original sur la même ligne.
  • Enregistrer le fichier .java.

Impossible de vous dire pourquoi cela a fonctionné, mais il l'a fait, et Eclipse arrêté jeter une crise de colère sur place.

Saisie sûre et le codage rapide.

-Goodge

Si vous avez une classe Foo, vous ne pouvez pas avoir un paquet qui se termine par Foo, comme com.my.Foo.
Aussi, si vous utilisez le style maven, vous avez des ressources dans votre projet en quelque chose comme src / principales ressources /
Les dossiers de vos ressources ont également un style de package et là aussi, vous ne pouvez pas avoir un dossier qui contient le nom de votre classe.

vous rencontrerez certainement ce problème lors de l'élaboration d'un plug-in Jenkins selon les conventions recommandées.
si vous suivez les conventions Jenkins, et vous créez un constructeur dans une classe nommée MyBuilder dans le paquet x.y alors vous êtes également censé placer votre .jelly dans un dossier de ressource nommée x.y.MyBuilder. Cela se traduira par le problème ci-dessus.
Toutefois, si vous nommez votre ressource dossier x.y.myBuilder (avis minuscule « m » en myBuilder), contrairement à la convention recommandée, le plugin fonctionne toujours à vous l'intention

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top