Discussion :

[Ayana]

Bonjour,

Dans mes jolis petits programmes, il m'arrive fréquemment de faire appel à de nombreuses classes via des import.

En voici un exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.Reader;
import java.util.Locale;
 
import org.apache.log4j.Logger;
import org.apache.log4j.PropertyConfigurator;
 
import test_logging.MathException;

J'aimerais savoir s'il est préférable de garder le code tel quel, ou s'il vaut mieux simplifier en mettant ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
import java.io.*;
 
import org.apache.log4j.*;
 
import test_logging.MathException;

Y-a-t-il des contraintes qui m'échappent ??
Je ne sais pas si, quand je mets une *, cela me charge quelque chose en mémoire ou pas, ou si cela met plus de temps pour rechercher la classe adéquate lors de l'instanciation.

Quelqu'un aurait-il quelques éléments à ce sujet ? Je suis preneuse de toute littérature .

Merci d'avance.

[adiGuba]

Salut,


Cela n'a aucune incidence sur le code généré : en fait lorsque tu utilises un import * c'est le compilateur qui se chargera de "générer" les bons imports selon les classes que tu utilises dans ton code.

Le résultat final sera strictement identique. La compilation pourrait peut-être être légèrement plus longue mais cela ne doit pas être visible pour un humain.

Par contre les import * ont deux défauts :

1. Ils peuvent apporter de l'ambigüité, par exemple si tu utilises le type Date et que tu as les imports suivant :
   

   Code :

   Sélectionner tout - Visualiser dans une fenêtre à part

   1
   2
   import java.util.*;
   import java.sql.*;

   Le compilateur ne saura pas si tu veux utiliser java.util.Date ou java.sql.Date et il te génèrera une erreur. Tu devras alors utiliser un import spécifique pour indiquer la classe que tu souhaites utiliser.
   
   
   
2. Indirectement ce problème d'ambigüité peut amener un problème de compatibilité du code source.
   Même si ton programme compile parfaitement avec ses import *, cela ne veut pas dire qu'il en sera de même avec les versions futures de Java ou en utilisant les nouvelles versions des librairies que tu utilises. En effet si une nouvelle classe est introduite et utilise le même nom qu'une des classes que tu utilises, tu retrouveras la même erreur et le code devra être modifié...

Bref les imports complets sont bien plus sûr car il n'apporte aucune ambigüité. De plus la plupart des EDI actuelles permettent de les générer/corriger simplement donc pourquoi s'en priver

a++

[Ayana]

Rholala, merci beaucoup beaucoup pour cette réponse très rapide et complète .

Je vais donc garder mes imports écrits en entier.


Sinon une dernière petite question, par rapport à ta 1e remarque (je vais demander la lune là ) :
Existe-t-il un site qui recense les classes qui posent problème, comme celle que tu évoques, "Date" ?

[adiGuba]

Existe-t-il un site qui recense les classes qui posent problème, comme celle que tu évoques, "Date" ?

javac... en compilant avec les import * il te génèrera des erreurs

Sinon tu peux utiliser JavaSearch et rechercher les classes par nom....

Mais j'ai du mal à voir l'intérêt de faire cela

a++

[Ayana]

Pour faire une documentation convaincante pour la non utilité du .*

Et voir s'il y a beaucoup de cas qui posent problème .

[bouye]

Le compilateur ne saura pas si tu veux utiliser java.util.Date ou java.sql.Date et il te génèrera une erreur. Tu devras alors utiliser un import spécifique pour indiquer la classe que tu souhaites utiliser.

Ou utiliser le nom long de la classe a l'endroit qui pose probleme ce qui evite devoir re-generer une longue liste d'import qui va rajouter 25.000 lignes au code source.

Bref les imports complets sont bien plus sûr car il n'apporte aucune ambigüité. De plus la plupart des EDI actuelles permettent de les générer/corriger simplement donc pourquoi s'en priver

Generalement, les EDI peuvent faire l'un comme l'autre, c'est juste la configuration par defaut qui a tendance a ecrire tous ces imports a rallonge. C'est "a la mode".

Les conflits se reparent d'une maniere ou d'une autre. Les EDI peuvent ou generer une liste d'import separes ou les simplifier en un .*. Avoir des .* evite une tres (parfois TRES TRES) longue liste d'import en tout genre, cependant quand on utilise un EDI, il est souvent possible de cacher ces memes imports... Globalement c'est plus une question de gout qu'autre chose. L'important c'est surtout qu'une fois specifiee, quelle qu'elle soit, tous les membres du projet suivent la meme regle de codage.

Utilisant principalement des imports .*, je ne vois qu'un seul et unique avantage aux imports separes : montrer aux personnes qui ne connaissent pas le code ou qui debutent (et qui donc peuvent ne pas connaitre meme l'API Java fondamentale) quelles classes on utilise. Pour le reste, ils m'ennuient plus qu'autre chose.

[adiGuba]

Perso j'utilise eclipse et il me rajoute automatiquement les import via la complétion (Ctrl+espace) ou il me les vérifie tous via Ctrl+Shift+O (en supprimant ceux qui sont devenu inutile). Et lorsqu'il y a un conflit il me propose gentiment de choisir...

Sans oublier que les lignes d'import sont "caché" et regroupé sur une seule ligne...

Bref dans ce cas là je ne vois pas l'intérêt de lui demander d'utiliser des import * qui pourrait être problématique dans le futur



Maintenant lorsqu'on utilise un EDI qui ne gère pas les import il est nettement plus simple de passer par les import * c'est sûr car c'est vraiment très fastidieux de le faire à la main...

a++

PS : Et je suis 100% d'accord sur le fait que les imports n'ont en général aucun intérêt pour le développeur

[Ayana]

Hihi, merci pour ce complément d'information.

Moi qui suis débutante en Java, je vais garder mes classes quelques temps écrites en entier, au moins le temps de bien tout assimiler. Ensuite je pense que je ferai en fonction de mes collègues de projet.
Mais vu que là je ne fais qu'une "auto-formation", je suis seule maître de mes exercices, donc la seule personne que ça pourrait déranger .

[bouye]

Bref dans ce cas là je ne vois pas l'intérêt de lui demander d'utiliser des import * qui pourrait être problématique dans le futur

C'est totalement vrai. MAIS a mon sens c'est exactement le meme probleme qu'esperer que le meme code fonctionnera/compilera a l'identique toujours tout le temps dans les versions futures de la JVM (ou de celle d'autre vendeur) en croisant les doigts tres (mais alors tres) fort pour que les APIs/classes/methode (meme celles de base) qu'on utilise ne deviennent jamais deprecated (cf certains changement un peu trop radicaux de la 1.4 concernant les variables d'envirronnement). Il y a du bon sens et de la bonne volonte mais sur le long terme c'est une perte d'energie (d'ou effectivement l'interret de laisser l'IDE* s'en charger via un CTRL+SPACE ) : il faudra toujours revenir modifier le code a un moment ou a un autre.

Cependant je dois avouer que le code-folding/repli de paragraphe dans l'interface graphique m'ennervais deja dans les vieilles versions de Visual Studio, donc j'ai peut l'habitude de l'utiliser dans les IDE plus recentes (j'ai probablement passe trop de temps sur Emacs a la fac ).

*Tiens en parlant d'IDE, etant donne que c'etait le comportement par defaut de JBuilder X, 2005 et 2006, c'est la premiere chose que j'ai ete changer dans la configuration JBuilder 2007/Eclipse. Donc mon CRTL+SPACE a moi fait totalement l'inverse du tien.