Discussion :

[Mr.Azerty]

Salut a tous,

Je pense que cette question a déjà dû être posée, mais je n'ai rien trouvé qui correspondait à mes attentes, surement parce que je ne cherche pas avec les bons termes.

Si j'ai bien tout saisi, quand je fais un import de type

Code :

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

import java.util.*;

Java va chercher les classes correspondant au package util quelque part c'est ca ?
Où est ce quelque part ? Dans quel dossier et quel type de fichier sont stockées ces classes ? M'est il possible d'en voir le code source pour regarder comment c'est fichu ?

Merci beaucoup.

[gwinyam]

Hello!

Beaucoup de questions à la fois...

Code java :

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

import java.util.*;

va importer toutes les classes appartenant au package java.util, mêmes celles qui ne te servent à rien. Je ne pense pas que je serais les seul si je te déconseillais fortement cette notation. Vire l'étoile et complète par les classes dont tu as besoin.

java.util fait partie du jdk de Java mais je ne sais pas comment trouver le fichier d'un point de vue système. En revanche, je suis pas convaincu que tu puisses en trouver directement le code source, peut-être en fouillant plus en profondeur.

bon courage pour tes recherches

[professeur shadoko]

que veux dire "importer"? rien de bien grave!
quand le compilateur trouvera le type "ArrayList" il le remplacera par "java.util.ArrayList".
ensuite il ira consulter uniquement le code binaire de cette classe (dans le jar du runtime).
tout ça c'est du compile-time.
Bien sur tu peux aller lire le code source de la classe java.util.ArrayList : dans le jdk à la racine tu trouveras "src.zip" qui contient les sources.

[adiGuba]

Salut,


Il est préférable d'utiliser un import complet, c'est à dire avec le nom complet de la classe. En particulier lorsqu'on utilise un EDI qui peut faire cela automatiquement...

L'import * est juste une facilité qui évite de nommer explicitement toutes les classes. Toutefois cela peut amener des ambiguïtés :

Code :

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

1
2
3
4
5
6
7
8
import java.awt.*;
import java.util.*;
 
public class Main {
 
	private List list; /* java.awt.List ou java.util.List ??? */
 
}

Et même s'il n'y a pas d'ambiguïté, elles pourraient survenir dans le futur en cas d'évolutions des APIs. Donc cette syntaxe est à déconseiller lorsque c'est possible...

Par contre il n'y a aucune différence une fois le code compilé...

java.util fait partie du jdk de Java mais je ne sais pas comment trouver le fichier d'un point de vue système. En revanche, je suis pas convaincu que tu puisses en trouver directement le code source, peut-être en fouillant plus en profondeur.

La JVM recherche les classes dans le CLASSPATH, dont chaque élément correspond à une racine à partir de laquelle on recherchera les classes.

Par exemple si notre package comporte 3 éléments comme ceci : "/un_repertoire/sous_rep/:/une_archive1.jar:.

Lorsqu'on charge la classe monpackage.util.MaClasse, la JVM recherchera dans l'ordre :

• Le fichier /un_repertoire/sous_rep/monpackage/util/MaClasse.class
• Le fichier /monpackage/util/MaClasse.class à l'intérieur de l'archive /une_archive1.jar
• Le fichier ./monpackage/util/MaClasse.class (par rapport au répertoire courant donc.

La JVM retournera donc la première classe correspondante.


Ce classpath possède un "booclasspath" qui comporte automatiquement les archives de l'API de Java, afin qu'elle soit retrouvé en priorité.



Quand aux sources, si l'installation est bien complète, ils sont disponibles dans le fichier src.zip du JDK...


a++

[Mr.Azerty]

Compris, merci à tous.

[bouye]

Hello!

Code java :

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

import java.util.*;

va importer toutes les classes appartenant au package java.util, mêmes celles qui ne te servent à rien. Je ne pense pas que je serais les seul si je te déconseillais fortement cette notation. Vire l'étoile et complète par les classes dont tu as besoin.

On est pas en C !

L'import n'inclue rien, il permet juste d'utiliser le nom court des classes au lieu du nom long.
Le nom court est remplace par le nom long au moment de la compilation par le compilateur.

En theorie, certes, utiliser uniquement les imports dont on a besoin devrait permetre d'avoir une compilation plus rapide (car le compilateur va passer moins de temps a chercher le nom long d'une classe ecrite avec son nom court) mais en pratique ce n'etait deja discernable au niveau perfs il y a a 12 ans, alors de nos jours...

En pratique, la seule utilite a utiliser ou pas l'import * ou des imports distincts c'est :

• La lisibilite du code : certains prefere l'un et d'autres l'autre.
• Eviter ou pas les collisions quand deux ou plus classes ont des noms courts identiques (cad classes avec le meme nom mais dans des packages differents). Quelques soit celle des deux solutions choisies quand on utilise java.util.Date et java.sql.Date ou java.awt.Color et javafx.scene.paint.Color au meme endroit dans le code on sera toujours ammene a ecrire au moins l'une des deux avec son nom long.

Donc => c'est plus une question de gout qu'autre chose.
Actuellement la mode est aux imports distincts... principalement car les imports sont automatiquement generes par les IDE et qu'on peut de nos jours cacher/replier facilement ces blocs de code.
La mode dans le codage c'est comme la mode dans les vetements, ca part et ca revient...

Seules les parties sous license Sun et/ou libres sont visibles dans les sources. Une partie des classes publiques reposent sur des implementations internes en C (ex: les operations I/O de base) ou en Java (ex: les Look'n Feel utilises par Swing) pour lesquelles Sun ne publie pas le source code pour X raison : technologie proprietaire Sun/vendeur du JDK (Apple, IBM, etc.), technologie sous license (codec supportant des formats bitmap, codec sonores et video) ou pour eviter leur distributions sur des platformes non-autorisees (il n'est pas permis -par Apple et Microsoft- d'utiliser les LnF Aqua, Luna/Aero sur d'autres platformes que les leurs respectives).