Surcharger les librairies Java

Bonjour,

je cherche une solution pour surcharger des fonctions de l'API Java, tout en faisant en sorte que les classes qui utilisent les fonctions pensent qu'il s'agit des vraies fonctions de l'API Java.

Par exemple, je veux surcharger le comportement de java.io.InputStream, sans avoir à modifier les fichiers source qui font appel à cela et dans lesquels on a:

import java.io.*;
et
InputStream myStream = ...

J'ai appris que la librairie org.objectweb.asm permettait de faire cela au runtime avec un class loader.
Mais je me demandais si c'était possible autrement (notamment à la compilation, en remplaçant les références à InputStream par autre chose).

Merci pour vos suggestions.

Sans modifier les sources ça va étre difficile. Il faut savoir que "java.*" et "javax.*" pour les noms de packages sont résérvés pour Sun.
Je ne vois aucune manière de faire mais ça ne veut pas dire qu'il y en a pas.

Salut,

je ne crois pas que ce soit possible, la seule façon que je voie est de faire hériter une classe fille de ta création et de surcharger à la main...

bien à toi !

mavina

Salut,

Pour faire ce que tu veux je vois 3 possibilités :
-> Soit tu écrit une applie qui modifie le byte code de tes classes après compilation et qui remplace les occurences des classes java(celles que tu veux surcharger), par des classes à toi. Le plus simple je pense c'est de remplacer les new ClasseJava par new TaClasse avec Taclasse qui hérite de ClasseJava. La théorie à l'air simple mais je pense que c'est assez compliqué à faire.
-> Sinon l'autre moyen comme tu l'indique c'est en écrivant ton propre ClassLoader. Jette un coup d'oeil sur la librarie http://www.csg.is.titech.ac.jp/~chiba/javassist/.
Elle te permet de modifier du code dynamiquement. Tu peux au choix soit modifier le comportement des classes java (pas évident et surtout je ne pense pas que celà soit très légal), soit modifier dynamiquement tes classes en remplacent les occurences des classes java par tes classes.
-> Soit écrire des classes portant le même nom(package compris) que les classes java que tu souhaite remplacer et les mettres au début de ton bootclasspath. Je pense aussi que cette solution n'est pas très légal.

hydraland, merci pour ta 3eme proposition qui est la plus intéressante dans mon cas.

-> Soit écrire des classes portant le même nom(package compris) que les classes java que tu souhaite remplacer et les mettres au début de ton bootclasspath. Je pense aussi que cette solution n'est pas très légal.

Ça marche bien pour remplacer une classe du jre par une autre. Mais par contre, je ne vois pas comment faire pour hériter du code déjà existant pour cette classe.

Par exemple, j'ai remplacé java.math.BigInteger par ma propre classe, mais je ne veux pas réécrire toute cette classe.
Et je ne vois pas comment faire cela.

Merci pour vos suggestions.

Par curiosité, c'est quoi le but ? Parce que ça semble quand même risqué étant donné que les classes du jdk s'utilisent les unes les autres...

Pourquoi comme cela a été proposé plus haut ne pas utiliser l'héritage ?

Xavinou, le but c'est de simuler le comportement d'une autre machine virtuelle qui est un peu différent, en particulier pour la classe InputStream.

En ce qui concerne l'héritage, c'est vrai que je pourrais créer une classe qui hérite de InputStream et utiliser cette classe dans le code.
Mais en fait je dois faire tourner des appli déjà écrites, sans en changer le code.

Commentaire

Il y a la possibilité de définir la propriété java.system.class.loader.

Tu lances ton programmme de cette manière

Code:

---

java -classpath ./bin -Djava.system.class.loader=mypackage.MyLoader mypackage.MyClass

---

Je te renvois à la documentaion de ClassLoad
et à un article de ONJava.com. L'ami Google t'aidera volontiers pour trouver d'autres informations.

Bah c simple, il suffit de modifier ce que tu veux dans le sources du sdk et de le compiler. Tu as donc créé une nouvelle version du SDK ! Félicitation.... enfin non c'est nimp mais bon passons... ensuite pour dire à ton appli d'utiliser ton sdk plutot que celui de java par défaut, il faut redéfinir le class path pour l'appli. Après ça dépend si tu utilise la ligne de commande, une applet, ou encore java webstart.

Perso je pense que c'est très débile, et que tu devrai plutôt te créer une Lib bien à toi qui fait pile poil ce que tu veux et basta fini terminado on en parle plus et c plus léger.

jowo:
dans la solution que j'évoquais dans mon 1er message, on utilise en effet un classloader, mais il faut de plus une librairie comme org.objectweb.asm, ou probablement http://www.csg.is.titech.ac.jp/~chiba/javassist/ comme le disait hydraland.
C'est nécessaire pour changer uniquement des partices des classes que l'on load. C'est ce que j'utilise pour faire une classe qui a le même nom que InputStream, qui possède le comportement de InputStream mais qui a quelques différences dans ses fonctionnalités.
Je ne vois pas comment faire ça sans ce type de librairie.

ypicman:
Recompiler la classe InputStream du sdk serait en effet une solution (qui a tout de même des inconvénients au niveau du déploiement).
Est-ce que les sources de l'API Java fournie avec la machine virtuelle sun sont publiques ?
Pour ce qui est de tes commentaires sur l'utilité et la débilité de faire ça, le forum n'est pas fait pour ça. Donc si ça ne te plait pas, ne réponds pas.

Comme je l'ai déjà dit précédemment, je dois simuler une autre machine virtuelle dont le comportement est un peu différent. Pour autant, je ne dois pas modifier le source des classes executées, donc je ne peux pas remplacer les références à java.io.InputStream par une classe que j'aurais créée moi même.

La modification de la JVM n'est pas autorisée selon la license binaire qui l'accompagne.

Seules les classes décrites ici peuvent être redéfinies par une autre implémentation:
http://java.sun.com/j2se/1.4.2/docs/guide/standards/

Le bootclasspath est à mon avis la solution la plus simple et la plus pratique. Je ne crois pas qu'elle entraîne quelconque problème légal mais je ne peux le dire avec certitude. Alexis, si tu as une info là desssus... :)

Note : Nous utilisons le bootclasspath chez Sun lorsque nous travaillons sur les API du JDK. Si vous voulez corriger des bugs du JDK au sein du projet Peabody (cf http://mustang.dev.java.net) c'est la solution la plus simple pour ne pas avoir à recompiler tout le JDK.

No problemo avec le bootclasspath.