Import récursif de classes

Version imprimable

20/09/2007, 12h41
Yannick_from_31

Import récursif de classes

Bonjour :D,

j'ai besoin de faire un import récursif de classes Java mais je ne sais pas comment faire.

Mon cas :
Je génère du code Java et donc les imports qui vont avec mais l'utilisateur peut modifier le code généré.

Donc, je voudrais éviter à l'utilisateur la lourdeur des imports en faisant un import global d'un package (l'utilisateur est amener à utiliser des classe d'un package et de ses sous-packages).

Par exemple, si on a :
A.aaa.class
A.bbb.class
A.B.cccc.class

Je veux ne pas avoir à faire :
import A.*;
import A.B.*;

mais seulement :
import A.*;

...mais ça ne fonctionne pas !

Une idée serait de lister les sous-packages récursivement et d'importer tout, package par package, mais il doit y avoir plus simple, non ?

Pour info, je peux créer un JAR du package père si besoin.

Merci d'avance pour votre aide.
20/09/2007, 14h43
Kh4iN3

Salut,

Déjà je te déconseille d'importer un package entier (com.package.*) mais uniquement la classe nécessaire, ça permet d'éviter les conflits de noms (ex: Date sql et Date util).
Si tu veux faire cela, il suffit de lister les classes nécessaires à la classe et des les importer (en ignorant le package java.lang).

a+
20/09/2007, 15h30
Yannick_from_31

Pour les conflits de noms : pas de risque => ce sont des packages persos prévus pour...

Et sinon, lister les classes nécessaires, c'est ce que je veux éviter car je n'ai pas spécialement le temps de le faire !

Merci quand même :D
20/09/2007, 15h51
CyberChouan

Normalement, tu n'as pas à "perdre le temps" que nécessite cette tâche.

Les IDE modernes (Eclipse & co) trouvent (presque tout seuls) les classes dont tu as besoin et créent les lignes d'import dont tu as besoin dans l'entête de ton fichier.
20/09/2007, 16h36
Yannick_from_31

Oui, mais je n'utilise pas d'IDE.

J'ai créé une appli qui permet de générer du code Java pour un truc particulier : l'appel de services décrits dans une interface X.

Donc je dois coder ce qu'est capable de faire Eclipse : générer les imports.

Je pensais faire un import récursif pour simplifier le tout :aie:
Mais peut-être qu'il va falloir que je parse le code généré pour n'importer que le strict nécessaire... :(

D'ailleurs je n'ai pas l'impression qu'il est possible de lister les packages d'un package connu... avec l'API Java de base...
20/09/2007, 17h29
Yannick_from_31

Je rajoute une question puisque ça évolue :

Savez-vous comment lister les packages d'un package connu depuis le code. J'ai essayé avec les classes "Package" et "ClassLoader" mais je n'y suis pas arrivé.

Avez-vous d'autres idées ?

Merci d'avance.
20/09/2007, 18h18
bulbo

Le seul moyen a ta disposition est de chercher dans le classpath:

Si c'est un repertoire, regarder si le package existe et si il a des sous-packages.
Si c'est un jar, ouvrir le jar et regarder si le package existe et si il a des sous-packages.

C'est couteux comme recherche, j'espere que tu fais ca a la generation ou en pre-compil et pas au runtime.

Bulbo ;)
20/09/2007, 18h54
Yannick_from_31

Merci pour l'aide, c'est ce à quoi j'ai du me résigner : chercher les répertoires...

Maintenant ça marche.

Cette recherche n'est faite qu'une fois à chaque fois que mon appli est lancée.
Pour l'instant, je fais un import massif d'un package et de ses sous packages !
C'est-à-dire des "import myPackage.*;"...

Je n'ai pas l'impression que ça ralenti mes scripts générés, mais je n'ai pas de script "costaud" pour l'instant pour faire des tests.

D'après-vous, un import massif peut-il plomber les performances ?
(pour info, je ne suis pas à 1 min. près par script qui peut durer 1 heure).
25/09/2007, 23h38
bouye

Citation:

Envoyé par Yannick_from_31

Pour l'instant, je fais un import massif d'un package et de ses sous packages !
C'est-à-dire des "import myPackage.*;"...

Je n'ai pas l'impression que ça ralenti mes scripts générés, mais je n'ai pas de script "costaud" pour l'instant pour faire des tests.

Dans quel sens ? Il s'agit la d'un raccourcit syntaxique et non pas d'une vraie inclusion comme le #include en C/C++. Il ne sert donc qu'a la compilation pour remplacer le nom court de la classe par son nom long partout dans le code ; le pseudo-code genere sera le meme que tu declares un import global, des imports detailles ou que tu mettes le nom complet de chaque classe a chaque appel dans le code. Donc a moins que tu n'ai 45.000 classes dans le code que tu compiles, et donc que le compilateur ne passe des lustres a resoudre les noms a la compilation, tu ne devrais pas voir de differences.

Pour le reste et hors conflits de nom (qui restent rare), la mode du moment est de declarer chaque classe importee separement, il en a ete autrement dans le passe, il en sera probablement autrement dans le futur quand les gens ont auront assez de lire du code source qui contient 4km d'import de classes triviales (cad des classes courrament utilisees dans la JVM ou chacun sait ou elles se trouvent) au debut (surtout quand on a pas une IDE capable d'effacer le bloc d'imports). D'un autre cote, ca a justement l'avantage de montrer aux debutants ou se trouve ce que tu utilises. Donc => fait comme tu veux.

Le listing de repertoire peut ne pas fonctionner car un package peut etre explose a plusieurs endroits sur le classpath. Bref, il faut parcourrir toutes les sources decrites dans le CLASSPATH, plus celles decrites dans le mecanisme des extensions plus les sources de base (rt.jar, etc...), etc... ce que fait le ClassLoader par defaut (sauf que lui il ne cherche pas a lister le contenu).

Citation:

Je veux ne pas avoir à faire :
import A.*;
import A.B.*;

mais seulement :
import A.*;

...mais ça ne fonctionne pas !

C'est normal, l'espace de nommage A.B n'appartient pas a l'espace de nommage A. En java, un espace de nommage (un package, une classe) ne gere/contient pas pas les sous-espaces de nommages qui sont declares dedans. Il faut donc les utiliser explicitement chacun.