Les chargeurs de classes, c'est vraiment excellent.
 
Du genre,  
 
Class maclasse=aClassLoader.loadClass("java.lang.String" );
Object ob=maclasse.newInstance();

c'est bien sympathique.
 
Mais
 
N'existe t-il pas un chargeur qui cherche tout seul dans tous les packages
s'il n'y a pas une classe String (qui lancerait une exception s'il y en plusieurs ou qui prendrait la première.)
Finalement, ceci pour ne pas avoir à se préoccuper des packages :
Class maclasse=aClassLoader.loadClass("java.lang.String" );
Object ob=maclasse.newInstance();
 
Sinon j'ai un problème quand je fais une nouvelle instance de la classe Integer : java.lang.InstantiationException: java.lang.Integer. Je ne sais pas trop comment résoudre le problème proprement ...    
 
Un lecteur pourrait-il m'aider ?
 

Integer prend un argument, newInstance() ne peut pas marcher sans.
 
http://java.sun.com/j2se/1.4.2/doc [...] teger.html
 
sur la classe, utilise getConstructor(Class[] types)
 
http://java.sun.com/j2se/1.4.2/doc [...] Class.html
 

Merci pour le deuxieme point.  
Je viens de le faire.
OKI d'ac ca marche.  
 
Et pour le premier point ... quelqu'un aurait-il une idée ?

 
Je suis pas sur d'avoir compris : tu voudrais un class loader qui permet de ne pas préciser les packages ? J'en vois pas trop l'intéret : c'est pas  plus compliqué d'écrire "java.lang.String" que "String". Et puis, les packages, ça à un intéret quand même, que t'évoques d'ailleurs : les conflits de noms de classes.

non.
 
le nom simple d'une classe (sans les package) est une simplification pour l'écriture du code (qui se base sur la recherche séquantiel parmis les import). Quand tu demande à charger une classe, tu dois utiliser le nom réel de la classe. Le nom court n'a pas de sens dans ce cas ... Il n'y a d'ailleur pas de notion équivalent au import qui permettrait celà ... Pour imiter ce comportement, ce serait à toi de boucler sur une suite de package dans laquelle la classe pourrait se trouver ...

+1, et je ne vois pas le gain recherché.

J'ai bien entendu ce que vous dites et je suis d'accord.
 
Mais en quoi quelqu'un n'aurait-il pas pu programmer une API qui va chercher dans tous les packages un nom de classe, qui montre les packages qui la contiennent, et en charge une instance selon des informations supplémentaires données par l'utilisateur(comme justement le bon package par exemple).
 
Reste que, pour faire simple, le but recherché étais de proposer à l'utilisateur des noms de classes communes dans les packages standards, sans qu'il n'ai à écrire par exemple le "java.lang." ou le "java.util.".
Le but étant de spécifier un attribut dans un petit fichier XML qui revient assez souvent.
Et donc d'éviter d'avoir attr=java.lang.Integer à la place de Integer dans les balises
 
 
Du coup, j'ai changé ma vision : je vais faire un adaptateur qui traduit Integer en java.lang.Integer,Float en java.lang.Float, etc...

* commons-discovery fait qqch de semblable: il cherche les implementations d'une interface donnée
* ctrl-n dans intellij-idea fait exactement ce que tu demandes, donc en effet ça a déjà été codé

Aaaah ouais ! J'avais pas pensé à ça  

je te conseille de te limiter au java.lang ...

Espèrons simplement que qqn n'aura pas la bonne idée de créer mypack.Integer extends java.lang.Integer, car là tu pourrais regretter ton geste.

je vois pas bien pourquoi ...

Moi non plus d'ailleurs    
 
Ca poserait vraiment un problème si on avait Integer extends java.lang.Integer, mais ce serait déjà vachement pas malin à la base, hein.

java.lang.Integer est final  

 
Non je n'ai pas été clair apparemment.
Je vais faire un fichier de correspondance entre la valeur de mes attributs dans mon fichier XML et sa classe java associée.
Excusez-moi pour le manque de clareté de mes propos.

 
commons-discovery : c a l'air de ce que cherchais , je le testerais
intellij-idea : sans l'interface graphique et avec le code source c'est ça en gros
Merci

j'ai bien compris (enfin je crois), mais qu'est ce qui t'embete dans le fait de mettre le nom de classe complet ?

Il est effectivement possible d'implémenter ton propre class loader qui scan dans tous les jars ou dans les directory que tu auras spécifiées, les classes que tu recherches.
Tout comme il est possible de modifier dynamiquement une class sans avoir à redémarrer la JVM.

 
Ba en fait, plus rien maintenant. Donc plus rien ne m'empêche de mettre le nom complet et ça ne m'embête pas non plus. Par contre, ça aurait embêté les utilisateurs de taper à chaque fois le chemin complet.  
 
Les utilisateurs n'ont pas à savoir de quels packages il s'agit et ne connaissent à priori rien au java. C'est pour ça que finalement je finis par créer un fichier d'adaptation entre ce que veux l'utilisateur comme type (entier, float) et la classe associée en java (avec le chemin complet)
 
En plus, vu que ces types se retrouvent assez fréquemment dans un fichier XML, il vaut mieux qu'ils soit assez courts...

 
Premier point. Oui c'est ça et je cherchais les implémentations existantes ce que m'a donné the real moins moins.
Le deuxième point est intéressant mais peut être trop complexe pour ce que je veux faire.