Discussion :

[Chatbour]

bonjour à tous et à toutes


Supposons que j'ai besoin, dans mon code, d'utiliser la class File..

Pour l'inclure, quelle est la différence entre faire import java.io.File; ou import java.io.*; ?
est-ce que le fait de faire import java.io.*; va inclure toutes les classes ?
est-ce qu'il y a un gain en performance en faisant import java.io.File; ?


Merci d'avance..

[danimo]

Bonjour,

est-ce que le fait de faire import java.io.*; va inclure toutes les classes ?

je dirais oui.

est-ce qu'il y a un gain en performance en faisant import java.io.File; ?

encore oui, mais si peu ...

Nous saurons demain ce qu'en pensent les experts !

Cordialememt.

Dan

[dinobogan]

Les imports sont utilisés uniquement par le compilateur. Il n'y a strictement aucune différence de performance entre ".*" ou ".File" lors de l'exécution.
c'est uniquement une question de lisibilité pour le programmeur. Certains détestent le ".*", d'autres l'adorent, à toi de voir.

[Uther]

Le * équivaut effectivement à importer toutes les classes. Mais les classes non utilisées sont bien évidement ignorées. Il n'y a donc pas de différences en temps d'exécution ou taille des fichier class.
La différence serait théoriquement en temps de compilation, mais en pratique il n'y en à aucune.


L'intérêt de * est évident : ne pas se farcir 60 ligne d'import si on utilise beaucoup de classe d'un même package (typiquement awt,swing,io,util,...).
L'intérêt de l'import individuel est d'éviter les collisions de nom. Par exemple dans:

Code :

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

1
2
3
4
5
6
import java.util.*;
import java.sql.*;
 
public class Main {
    Date d = new Date();
}

Vu qu'il y a deux objets Date différents définis dans java.util et java.sql, ce code ne compilera pas. Il te faudra rajouter un import individuel de la classe Date souhaitée, ou utiliser le nom de classe complet dans le code.

Les IDE comme Eclipse ou Netbeans ajoutent automatiquement des import individuel et les rassemblent en une seule ligne pour ne pas surcharger la vue du code de lignes d'import. Il vaut mieux donc les laisser gérer ça.
Mais c'est sur que si tu ne programmes pas avec un outil qui gère les import automatiquement, alors le * te simplifie la vie et ça serait dommage de t'en passer.

[adiGuba]

Salut,

Les imports sont utilisés uniquement par le compilateur. Il n'y a strictement aucune différence de performance entre ".*" ou ".File" lors de l'exécution.

+1

S'il y a une différence de performance, ce serait lors de la compilation uniquement... mais je ne pense pas que ce soit sensible...

c'est uniquement une question de lisibilité pour le programmeur. Certains détestent le ".*", d'autres l'adorent, à toi de voir.

C'est surtout que c'est source d'ambiguïté puisqu'on ne précise jamais le type exacte de la classe que l'on veut utiliser...

Par exemple si on fait :

Code :

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

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

Et qu'on utilise le type Date, le compilateur sera perdu et génèrera une erreur, puisque il existe à la fois java.util.Date et java.sql.Date...


De ce fait, l'utilisation des import * peut produire un code non-compatible avec les futurs JDK... Car en multipliant les import * on augmente le risque de conflit. Et on ne peut pas être sûr que les JDKs futurs n'introduiront pas une classe du même nom dans un autre package...

Pour info cela a été le cas avec les classes java.lang.reflect.Proxy (Java 1.3) et java.net.Proxy (Java 1.5).


C'est quand même des cas bien particulier, mais il est quand même préférable de limiter au maximum l'utilisation du import *, en particulier lorsqu'on utilise un EDI (qui permet de générer des imports propres).


a++

[edit] Grillé par Uther
Faut dire que j'ai mis une plombe à taper cela

[Chatbour]

Merci beaucoup à vous

je propose que vous ajoutez cette information dans la FAQ..