Est ce qu'il vaut mieux indiquer le chemin complet lors d'un import, par
exemple si j'ai besoin de java.util.Date, si je fais un import sur
java.util.* mon programme va bouffer plus de mémoire?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Olivier Thomann
Est ce qu'il vaut mieux indiquer le chemin complet lors d'un import, par exemple si j'ai besoin de java.util.Date, si je fais un import sur java.util.* mon programme va bouffer plus de mémoire? Le .class résultant sera exactement le même. Temps en temps tu n'as
pas le choix de passer par un import simple (java.util.Date) dans le cas où tu utilises des classes de même nom situées dans deux packages différents. Cela peut avoir un impact sur le temps de compilation, mais dans la plupart des cas tu ne verras pas la différence. En terme de style, il est plus clair d'utiliser des imports simples. Ils permettent de savoir exactement quelle classes sont utilisées dans ton programme. Si tu utilises un outil comme Eclipse, il te gère les imports comme tu le souhaites avec l'opération "Organize imports...". Le compilateur Eclipse peut également te dire quel import n'est pas utilisé. -- Olivier
Est ce qu'il vaut mieux indiquer le chemin complet lors d'un import, par
exemple si j'ai besoin de java.util.Date, si je fais un import sur
java.util.* mon programme va bouffer plus de mémoire?
Le .class résultant sera exactement le même. Temps en temps tu n'as
pas le choix de passer par un import simple (java.util.Date) dans le
cas où tu utilises des classes de même nom situées dans deux packages
différents.
Cela peut avoir un impact sur le temps de compilation, mais dans la
plupart des cas tu ne verras pas la différence.
En terme de style, il est plus clair d'utiliser des imports simples.
Ils permettent de savoir exactement quelle classes sont utilisées dans
ton programme. Si tu utilises un outil comme Eclipse, il te gère les
imports comme tu le souhaites avec l'opération "Organize imports...".
Le compilateur Eclipse peut également te dire quel import n'est pas
utilisé.
--
Olivier
Est ce qu'il vaut mieux indiquer le chemin complet lors d'un import, par exemple si j'ai besoin de java.util.Date, si je fais un import sur java.util.* mon programme va bouffer plus de mémoire? Le .class résultant sera exactement le même. Temps en temps tu n'as
pas le choix de passer par un import simple (java.util.Date) dans le cas où tu utilises des classes de même nom situées dans deux packages différents. Cela peut avoir un impact sur le temps de compilation, mais dans la plupart des cas tu ne verras pas la différence. En terme de style, il est plus clair d'utiliser des imports simples. Ils permettent de savoir exactement quelle classes sont utilisées dans ton programme. Si tu utilises un outil comme Eclipse, il te gère les imports comme tu le souhaites avec l'opération "Organize imports...". Le compilateur Eclipse peut également te dire quel import n'est pas utilisé. -- Olivier
Julien Arlandis
Est ce qu'il vaut mieux indiquer le chemin complet lors d'un import, par exemple si j'ai besoin de java.util.Date, si je fais un import sur java.util.* mon programme va bouffer plus de mémoire?
Le .class résultant sera exactement le même. Temps en temps tu n'as pas le choix de passer par un import simple (java.util.Date) dans le cas où tu utilises des classes de même nom situées dans deux packages différents. Cela peut avoir un impact sur le temps de compilation, mais dans la plupart des cas tu ne verras pas la différence. En terme de style, il est plus clair d'utiliser des imports simples. Ils permettent de savoir exactement quelle classes sont utilisées dans ton programme. Si tu utilises un outil comme Eclipse, il te gère les imports comme tu le souhaites avec l'opération "Organize imports...". Le compilateur Eclipse peut également te dire quel import n'est pas utilisé. -- Olivier
Dans certains cas je suis obligé d'utiliser le même import dans des classes différentes, j'espère que la class sera chargée qu'une seule fois?
Est ce qu'il vaut mieux indiquer le chemin complet lors d'un import, par
exemple si j'ai besoin de java.util.Date, si je fais un import sur
java.util.* mon programme va bouffer plus de mémoire?
Le .class résultant sera exactement le même. Temps en temps tu n'as
pas le choix de passer par un import simple (java.util.Date) dans le
cas où tu utilises des classes de même nom situées dans deux packages
différents.
Cela peut avoir un impact sur le temps de compilation, mais dans la
plupart des cas tu ne verras pas la différence.
En terme de style, il est plus clair d'utiliser des imports simples.
Ils permettent de savoir exactement quelle classes sont utilisées dans
ton programme. Si tu utilises un outil comme Eclipse, il te gère les
imports comme tu le souhaites avec l'opération "Organize imports...".
Le compilateur Eclipse peut également te dire quel import n'est pas
utilisé.
--
Olivier
Dans certains cas je suis obligé d'utiliser le même import dans des
classes différentes, j'espère que la class sera chargée qu'une seule fois?
Est ce qu'il vaut mieux indiquer le chemin complet lors d'un import, par exemple si j'ai besoin de java.util.Date, si je fais un import sur java.util.* mon programme va bouffer plus de mémoire?
Le .class résultant sera exactement le même. Temps en temps tu n'as pas le choix de passer par un import simple (java.util.Date) dans le cas où tu utilises des classes de même nom situées dans deux packages différents. Cela peut avoir un impact sur le temps de compilation, mais dans la plupart des cas tu ne verras pas la différence. En terme de style, il est plus clair d'utiliser des imports simples. Ils permettent de savoir exactement quelle classes sont utilisées dans ton programme. Si tu utilises un outil comme Eclipse, il te gère les imports comme tu le souhaites avec l'opération "Organize imports...". Le compilateur Eclipse peut également te dire quel import n'est pas utilisé. -- Olivier
Dans certains cas je suis obligé d'utiliser le même import dans des classes différentes, j'espère que la class sera chargée qu'une seule fois?
jerome moliere
Dans certains cas je suis obligé d'utiliser le même import dans des classes différentes, j'espère que la class sera chargée qu'une seule fois?
specs de la VM... oui, une seule fois par classloader
Jerome -- Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003 http://www.eyrolles.com/php.informatique/Ouvrages/ouvrage.php3?ouv_ean1382212111941
Dans certains cas je suis obligé d'utiliser le même import dans des
classes différentes, j'espère que la class sera chargée qu'une seule fois?
specs de la VM...
oui, une seule fois par classloader
Jerome
--
Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003
http://www.eyrolles.com/php.informatique/Ouvrages/ouvrage.php3?ouv_ean1382212111941
Dans certains cas je suis obligé d'utiliser le même import dans des classes différentes, j'espère que la class sera chargée qu'une seule fois?
specs de la VM... oui, une seule fois par classloader
Jerome -- Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003 http://www.eyrolles.com/php.informatique/Ouvrages/ouvrage.php3?ouv_ean1382212111941
Julien Arlandis
Est ce qu'il vaut mieux indiquer le chemin complet lors d'un import, par exemple si j'ai besoin de java.util.Date, si je fais un import sur java.util.* mon programme va bouffer plus de mémoire?
Le .class résultant sera exactement le même.
Mais comment il sait quelle class utiliser lors d'un java.util.* ?
Est ce qu'il vaut mieux indiquer le chemin complet lors d'un import, par
exemple si j'ai besoin de java.util.Date, si je fais un import sur
java.util.* mon programme va bouffer plus de mémoire?
Le .class résultant sera exactement le même.
Mais comment il sait quelle class utiliser lors d'un java.util.* ?
Est ce qu'il vaut mieux indiquer le chemin complet lors d'un import, par exemple si j'ai besoin de java.util.Date, si je fais un import sur java.util.* mon programme va bouffer plus de mémoire?
Le .class résultant sera exactement le même.
Mais comment il sait quelle class utiliser lors d'un java.util.* ?
jerome moliere
Julien Arlandis wrote:
Est ce qu'il vaut mieux indiquer le chemin complet lors d'un import, par exemple si j'ai besoin de java.util.Date, si je fais un import sur java.util.* mon programme va bouffer plus de mémoire?
Le .class résultant sera exactement le même.
Mais comment il sait quelle class utiliser lors d'un java.util.* ?
regardes les specs de la VM et la description d'un .class Java
Jerome
-- Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003 http://www.eyrolles.com/php.informatique/Ouvrages/ouvrage.php3?ouv_ean1382212111941
Julien Arlandis wrote:
Est ce qu'il vaut mieux indiquer le chemin complet lors d'un import,
par exemple si j'ai besoin de java.util.Date, si je fais un import
sur java.util.* mon programme va bouffer plus de mémoire?
Le .class résultant sera exactement le même.
Mais comment il sait quelle class utiliser lors d'un java.util.* ?
regardes les specs de la VM et la description d'un .class Java
Jerome
--
Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003
http://www.eyrolles.com/php.informatique/Ouvrages/ouvrage.php3?ouv_ean1382212111941
Est ce qu'il vaut mieux indiquer le chemin complet lors d'un import, par exemple si j'ai besoin de java.util.Date, si je fais un import sur java.util.* mon programme va bouffer plus de mémoire?
Le .class résultant sera exactement le même.
Mais comment il sait quelle class utiliser lors d'un java.util.* ?
regardes les specs de la VM et la description d'un .class Java
Jerome
-- Auteur cahier du programmeur Java tome 2 - Eyrolles 10/2003 http://www.eyrolles.com/php.informatique/Ouvrages/ouvrage.php3?ouv_ean1382212111941
Olivier Thomann
Le Wed, 18 Feb 2004 11:09:47 +0100, Julien Arlandis
Mais comment il sait quelle class utiliser lors d'un java.util.* ? Toutes les classes publiques de ce package sont potentiellement
"visibles". -- Olivier
Le Wed, 18 Feb 2004 11:09:47 +0100, Julien Arlandis
Mais comment il sait quelle class utiliser lors d'un java.util.* ?
Toutes les classes publiques de ce package sont potentiellement
Le Wed, 18 Feb 2004 11:09:47 +0100, Julien Arlandis
Mais comment il sait quelle class utiliser lors d'un java.util.* ? Toutes les classes publiques de ce package sont potentiellement
"visibles". -- Olivier
Yves Martin
Olivier Thomann writes:
Le Wed, 18 Feb 2004 11:09:47 +0100, Julien Arlandis
Mais comment il sait quelle class utiliser lors d'un java.util.* ? Toutes les classes publiques de ce package sont potentiellement
"visibles".
C'est le compilateur qui fait le boulot de détermination du nom de classe et du package correspondant.
Petit jeu: comment utiliser à la fois java.util.Date et java.sql.Date ?
Deux imports ne sont pas possibles. Il faut ne faire qu'un import de la classe qui est la plus utilisée - et utiliser l'autre classe avec un nommage complet dans le code:
import java.util.Date;
Date d = new Date(); // c'est du java.util.Date
java.sql.Date sqlDate = new java.sql.Date(); // j'crois qu'c'est clair ?
Le Wed, 18 Feb 2004 11:09:47 +0100, Julien Arlandis
Mais comment il sait quelle class utiliser lors d'un java.util.* ?
Toutes les classes publiques de ce package sont potentiellement
"visibles".
C'est le compilateur qui fait le boulot de détermination du nom de
classe et du package correspondant.
Petit jeu: comment utiliser à la fois java.util.Date et java.sql.Date ?
Deux imports ne sont pas possibles. Il faut ne faire qu'un import de
la classe qui est la plus utilisée - et utiliser l'autre classe avec
un nommage complet dans le code:
import java.util.Date;
Date d = new Date(); // c'est du java.util.Date
java.sql.Date sqlDate = new java.sql.Date(); // j'crois qu'c'est clair ?
Le Wed, 18 Feb 2004 11:09:47 +0100, Julien Arlandis
Mais comment il sait quelle class utiliser lors d'un java.util.* ? Toutes les classes publiques de ce package sont potentiellement
"visibles".
C'est le compilateur qui fait le boulot de détermination du nom de classe et du package correspondant.
Petit jeu: comment utiliser à la fois java.util.Date et java.sql.Date ?
Deux imports ne sont pas possibles. Il faut ne faire qu'un import de la classe qui est la plus utilisée - et utiliser l'autre classe avec un nommage complet dans le code:
import java.util.Date;
Date d = new Date(); // c'est du java.util.Date
java.sql.Date sqlDate = new java.sql.Date(); // j'crois qu'c'est clair ?
