2010-05-04 6 views
0

[J'ai décidé de donner un autre coup à IntelliJ (pour remplacer Eclipse), car son support Groovy est censé être le meilleur. Mais revenons à Java ...]IntelliJ ne remarque pas les changements dans l'interface?

J'ai une interface qui définit une constante

public static final int CHANNEL_IN = 1; 

et environ 20 classes dans mon module qui mettent en œuvre cette interface. J'ai décidé que cette constante était une mauvaise idée, donc j'ai fait ce que je fais dans Eclipse: j'ai supprimé toute la ligne. Cela devrait faire que l'arborescence du projet s'allume comme un arbre de Noël et toutes les classes qui implémentent cette interface et utilisent cette constante pour rompre. Au lieu de cela, cela n'arrive pas. Si je ne double pas réellement sur les classes concernées - que je trouve en utilisant grep - le module se construit même correctement (en utilisant Build -> Make Module). Si je double-clique sur une classe pertinente, l'erreur est affichée à la fois dans l'arborescence du projet et dans l'éditeur.

Je ne parviens pas à répliquer ce comportement lors de petits tests, mais dans les modules volumineux, cela fonctionne (de façon incorrecte) de cette façon. Y a-t-il un paramètre pertinent dans IntelliJ pour cela?

+0

N'avez pas rencontré ce problème avant, mais vous pourriez en discuter dans leurs forums de support: http://www.jetbrains.net/devnet/community/idea/ideacommunity – Behrang

+0

Merci @Bytecode Ninja, pourrait le faire si rien ne se passe ici, merci. –

Répondre

2

Vous avez ici une interaction entre un problème java standard et un comportement IDEA standard. Les expressions constantes de ce type sont intégrées dans la compilation de classe (selon la spécification de langage Java), donc la classe référençant cette constante n'a pas changé juste parce que vous avez supprimé la ligne (évidemment) et il n'y a aucune dépendance enregistrée entre la constante et la classe plus depuis qu'il était en ligne. Cela provoque l'échec de la compilation (la classe n'échouerait pas au moment de l'exécution si c'était le seul changement - elle n'échouera que lorsque vous faites une compilation propre). Un moyen de contourner cela dans IDEA est de faire un projet Build-> Rebuild lorsque vous avez un tel changement. L'autre est dans Paramètres-> Compilateur il y a un Honor Dependencies on "Compile" command. Cela peut affecter négativement les performances dans les grands projets (par conséquent, il est désactivé par défaut), mais est censé résoudre ce genre de problème.

L'autre partie de ce problème est que IDEA ne recalcule pas automatiquement toutes les inspections sur un changement comme celui-là. Il recalcule lorsque vous ouvrez un fichier. Je ne suis pas au courant d'un paramètre qui fait IDEA faire cela. Lorsque vous reconstruisez, les problèmes détectés sont mis en surbrillance (jusqu'à l'endroit où le compilateur a abandonné), mais la surbrillance ne disparaîtra pas tant que vous n'aurez pas ouvert la classe ou recompilé.

+0

Des trucs informatifs et intéressants, +1. Je ne comprends toujours pas pourquoi Eclipse remarque ce changement et le fait rapidement. Pour ce problème, de toute façon, la réponse est de réduire les projets à un seul module chacun, car il n'y a pas de "module de reconstruction". Merci encore pour votre réponse. –

+0

@yar, si vous reconstruisez le projet, il reconstruit tous les modules, donc vous pouvez avoir autant de modules que vous voulez, vous ne pouvez pas reconstruire à partir d'un seul module (il peut y avoir des cas de bords qui rendraient cela problématique). En ce qui concerne Eclipse, je ne suis pas très familier avec Eclipse, mais ce que je soupçonne, c'est qu'il ne fait pas toutes ses inspections de code en un seul groupe et les divise probablement en problèmes de compilation et d'autres problèmes et ne réévalue que problèmes de compilation, ou il exploite le fait qu'il a son propre compilateur construit sur mesure. – Yishai

Questions connexes