Discussion :

[ChPr]

Bonjour à toutes et à tous,

Je travaille avec NetBeans, et à chaque fois que j'introduis une classe appartenant à une bibliothèque, je fais "Source/Fix Imports". Dès lors il me rajoute une ligne d'import spécifique à cette classe. C'est ainsi que je me retrouve avec ce type de déclaration :

Code :

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

1
2
3
4
import java.awt.Color;
import java.awt.Graphics;
import java.awt.GridLayout;
import java.awt.Image;

que je peux remplacer par :

Code :

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

import java.awt.*;

Quel est l'intérêt de cette méthode ?

Merci de votre aide.

Pierre

[mhamedbj]

quand tu fais un import ".*" tu importe toutes les classes de "awt" même celles que tu n'utilise pas

[n!co]

Puis t'es obligé de l'écrire ton import java.awt.*;
Imagines que ta classe fasse appele à 10 packages diférrents
Avec le Fix Import ou "Shift+Alt+F", tu n'écris rien du tout.

Cela marche aussi quand tu utilises l'autocomplétion, les classes non importées le sont automatiquement

n!co

[ChPr]

quand tu fais un import ".*" tu importe toutes les classes de "awt" même celles que tu n'utilise pas

Ca, j'ai bien compris. Mais quelle incidence cela a-t-il ?

Au niveau du fichier source, j'y vois l'avantage de ne pas avoir à faire de "Fix imports" à chaque fois que j'introduis une nouvelle classe de la bibliothèque importée,

Au niveau du fichier *.jar ????
Au niveau des temps de compilation ????

Merci de vos précisions.

Pierre

[afrikha]

Ca, j'ai bien compris. Mais quelle incidence cela a-t-il ?

Au niveau du fichier source, j'y vois l'avantage de ne pas avoir à faire de "Fix imports" à chaque fois que j'introduis une nouvelle classe de la bibliothèque importée,

Au niveau du fichier *.jar ????
Au niveau des temps de compilation ????

Merci de vos précisions.

Pierre

Bonjour,
à ma connaissance il n'y a strictement aucune incidence.

@+

[ChPr]

Imagines que ta classe fasse appele à 10 packages diférrents

Comment est-ce possible ? J'ai cru lire qu'il n'y avait pas de multi héritage. Est-ce dû aux "Interfaces" multiples ?

Pierre.

[afrikha]

Comment est-ce possible ? J'ai cru lire qu'il n'y avait pas de multi héritage. Est-ce dû aux "Interfaces" multiples ?

Pierre.

Mais non !! ça n'a rien à voir avec l'héritage !!!
Il veut dire que tu fais appels à plusieurs classes dans ta classe. Par exemple, dans la classe suivante :

Code :

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

1
2
3
4
5
 
public class Test {
  String mot="abc";
  Integer i=new Integer(5);
}

Dans la classe Test j'ai fait appel à deux autres classes à savoir java.lang.String et java.lang.Integer .

C'est clair maintenant ?

@+

[ChPr]

... C'est clair maintenant ?

J'ai compris.

Cependant, si vraiment "cela n'a aucune incidence", je préfère faire un import général que d'avoir un message d'erreur à chaque fois que j'utilise une nouvelle classe et que je corrige donc par un "Fix imports".

Merci pour vos éclaircissements.

N.B. : l'utilité que j'y vois pour l'instant est que c'est formateur (je suis un vrai débutant en Java, mais je manipule des classes en DELPHI depuis de nombreuses années).

Pierre

[mhamedbj]

je me souvien avoir lu quelque part qu'il vallait mieux fiar les import des classes que tu utilise seulement cad:
si tu utilise 10 classes de awt tu fait 10 import c'est pas grave de tout façon netbeans fait un import automatiquement et tu n'as pas a faire de fixe import si tu procéde ainsi:
si c'est netbeans qui a besoin de l'import, par ex si tu ajoute un jPanel il ajoute automatiquement le "import javax.swing.JPanel;"

si c'est toi qui a besion d'une classe (netbeans 5.5), ArrayList par ex, tu tape ArrayLi et il y a l'autocomplémentation qui apparait, il y a le ArrayList qui est en surbrillence, tu appuis sur entrée, alors, il fini ta phrase et donc il fini le ArrayLi en ArrayList et en plus il fait un "import java.util.ArrayList;"

donc si tu procède anisi tu n'as jamais des truc du genre "import ... .*"

et pour être sûr que c'est bon, une fois fini tu fais a ce moment là un fix import pour enlever tous les import qui ne sont PAS utiliser, si jamais en cours de route tu a fais appel une classe et que ensuite tu as changé d'avis et que tu as oublié de supprimé le import qui vas avec !!!!!



ouuufff....
c t mon avis... je suis mort !!!!

[n!co]

Cependant, si vraiment "cela n'a aucune incidence", je préfère faire un import général que d'avoir un message d'erreur à chaque fois que j'utilise une nouvelle classe et que je corrige donc par un "Fix imports".

Un "Shift+Alt+F" ca mange pas de pain tout de même, tu verras essayer c'est l'adopter

[vbrabant]

Imagine que tu utilises une classe du package java.util.
Tu fais

Code :

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

import java.util.*;

Ensuite, dans la même classe, tu utilises une classe du

Code :

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

package java.sql

, et tu fais donc

Code :

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

import java.sql.*;

Et maintenant, tu veux utiliser la classe Date qui se trouve dans le package java.util. Et bien, tu va devoir toujours l'utiliser de façon complete (

Code :

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

java.util.Date date = new java.util.Date()

) pour indiquer au compilateur que tu parles bien de

Code :

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

java.util.Date

et pas de

Code :

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

java.sql.Date

Si tu avais fait tes imports du style

Code :

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

1
2
3
4
import java.util.Date;
import java.util.UnAutreClasse;
import java.sql.Statement;
import java.sql.ResultSet;

...
Cela n'aurait pas été nécessaire de devoir spécifier tout le temps java.util.Date();
Maintenant, si tu utilises dans le même code java.util.Date et java.sql.Date, tu peux également faire la chose suivante

Code :

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

1
2
3
4
5
import java.util.Date;
...
Date currentDate = new Date();
...
java.sql.Date dbDate = new java.sql.Date();

Et cela est également vrai si tu as

Code :

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

1
2
3
4
5
6
import java.util.Date;
import java.sql.*;
...
Date currentDate = new Date();
...
java.sql.Date dbDate = new java.sql.Date();

le compilateur donne priorité à la classe qui est clairement spécifiée dans les import dans le cas où on ne précise rien.

Maintenant, si tu as

Code :

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

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

alors t'es obligé d'écrire dans ton code

Code :

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

1
2
3
4
 
java.util.Date currentDate = new java.util.Date();
...
java.sql.Date dbDate = new java.sql.Date();

Car le compilateur ne sait pas donner de priorité.

Personnellement, j'aime bien dire clairement ce que j'utilise et pas plus, donc, j'évite les import avec *.

Vincent

[ChPr]

Effectivement, Vincent, si des classes portant le même nom appartiennent à des packages différents, autant savoir à laquelle on a à faire.

Mais dans ce cas, je préfère écrire au plus près celle que j'utilise et donc utiliser ton dernier exemple de code :

Code :

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

1
2
3
java.util.Date currentDate = new java.util.Date();
...
java.sql.Date dbDate = new java.sql.Date();

Ce qui permet par ailleurs d'écrire simplement :

Code :

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

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

C'est une affaire de gout. Cependant, ton exemple pointe sur des problèmes sous-jacents qu'en tant que NewBy, je ne connais ni ne soupçonne.

Cordialement.

Pierre