J'ai créer un classloader qui permet de recompiler les sources d'une class,
si les dates des class et des sources sont differentes.
Je voudrais maintenant pouvoir réinitialisé la liste des class déja lu à fin
que la class soit toujours recontruite à partir du .class du disque.
C'est à dire que la fonction "findLoadedClass" du classloader retournerait
toujours null. Je voudrais par exemple le code d'une fonction qui
s'appelerait "removeLoadedClass".
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
jerome moliere
9OnLine wrote:
Bonjour,
J'ai créer un classloader qui permet de recompiler les sources d'une class, si les dates des class et des sources sont differentes.
Je voudrais maintenant pouvoir réinitialisé la liste des class déja lu à fin que la class soit toujours recontruite à partir du .class du disque.
C'est à dire que la fonction "findLoadedClass" du classloader retournerait toujours null. Je voudrais par exemple le code d'une fonction qui s'appelerait "removeLoadedClass". ouep mais le probleme est qu'il n'y a pas moyen de supprimer une classe
deja chargee... pour recharger une classe, il faut charger la nouvelle version avec un 'nouveau' classloader
Jerome
9OnLine wrote:
Bonjour,
J'ai créer un classloader qui permet de recompiler les sources d'une class,
si les dates des class et des sources sont differentes.
Je voudrais maintenant pouvoir réinitialisé la liste des class déja lu à fin
que la class soit toujours recontruite à partir du .class du disque.
C'est à dire que la fonction "findLoadedClass" du classloader retournerait
toujours null. Je voudrais par exemple le code d'une fonction qui
s'appelerait "removeLoadedClass".
ouep mais le probleme est qu'il n'y a pas moyen de supprimer une classe
deja chargee...
pour recharger une classe, il faut charger la nouvelle version avec un
'nouveau' classloader
J'ai créer un classloader qui permet de recompiler les sources d'une class, si les dates des class et des sources sont differentes.
Je voudrais maintenant pouvoir réinitialisé la liste des class déja lu à fin que la class soit toujours recontruite à partir du .class du disque.
C'est à dire que la fonction "findLoadedClass" du classloader retournerait toujours null. Je voudrais par exemple le code d'une fonction qui s'appelerait "removeLoadedClass". ouep mais le probleme est qu'il n'y a pas moyen de supprimer une classe
deja chargee... pour recharger une classe, il faut charger la nouvelle version avec un 'nouveau' classloader
Jerome
9OnLine
Je suis d'accord avec toi mais c'est ce que j'ai fait pour l'instant. Mais je trouve que ça gonfle conciderablement la memoire de la JVM. Et en plus j'ai vu une javadoc dispo avec un classloader qui peut le faire. Mais il y avait pas les sources. :(
Donc je me demandais si quelqu'un n'aurait pas la solution ????
Et si quelqu'un pouvait me confirmer que ça confle bien DANGEREUSEMENT la memoire de la JVM ???
Merci d'avance.
"jerome moliere" a écrit dans le message news: bnm1nr$eb$
9OnLine wrote:
Bonjour,
J'ai créer un classloader qui permet de recompiler les sources d'une class,
si les dates des class et des sources sont differentes.
Je voudrais maintenant pouvoir réinitialisé la liste des class déja lu à fin
que la class soit toujours recontruite à partir du .class du disque.
C'est à dire que la fonction "findLoadedClass" du classloader retournerait
toujours null. Je voudrais par exemple le code d'une fonction qui s'appelerait "removeLoadedClass". ouep mais le probleme est qu'il n'y a pas moyen de supprimer une classe
deja chargee... pour recharger une classe, il faut charger la nouvelle version avec un 'nouveau' classloader
Jerome
Je suis d'accord avec toi mais c'est ce que j'ai fait pour l'instant. Mais
je trouve que ça gonfle conciderablement la memoire de la JVM. Et en plus
j'ai vu une javadoc dispo avec un classloader qui peut le faire. Mais il y
avait pas les sources. :(
Donc je me demandais si quelqu'un n'aurait pas la solution ????
Et si quelqu'un pouvait me confirmer que ça confle bien DANGEREUSEMENT la
memoire de la JVM ???
Merci d'avance.
"jerome moliere" <jmoliere@nerim.net> a écrit dans le message news:
bnm1nr$eb$1@biggoron.nerim.net...
9OnLine wrote:
Bonjour,
J'ai créer un classloader qui permet de recompiler les sources d'une
class,
si les dates des class et des sources sont differentes.
Je voudrais maintenant pouvoir réinitialisé la liste des class déja lu à
fin
que la class soit toujours recontruite à partir du .class du disque.
C'est à dire que la fonction "findLoadedClass" du classloader
retournerait
toujours null. Je voudrais par exemple le code d'une fonction qui
s'appelerait "removeLoadedClass".
ouep mais le probleme est qu'il n'y a pas moyen de supprimer une classe
deja chargee...
pour recharger une classe, il faut charger la nouvelle version avec un
'nouveau' classloader
Je suis d'accord avec toi mais c'est ce que j'ai fait pour l'instant. Mais je trouve que ça gonfle conciderablement la memoire de la JVM. Et en plus j'ai vu une javadoc dispo avec un classloader qui peut le faire. Mais il y avait pas les sources. :(
Donc je me demandais si quelqu'un n'aurait pas la solution ????
Et si quelqu'un pouvait me confirmer que ça confle bien DANGEREUSEMENT la memoire de la JVM ???
Merci d'avance.
"jerome moliere" a écrit dans le message news: bnm1nr$eb$
9OnLine wrote:
Bonjour,
J'ai créer un classloader qui permet de recompiler les sources d'une class,
si les dates des class et des sources sont differentes.
Je voudrais maintenant pouvoir réinitialisé la liste des class déja lu à fin
que la class soit toujours recontruite à partir du .class du disque.
C'est à dire que la fonction "findLoadedClass" du classloader retournerait
toujours null. Je voudrais par exemple le code d'une fonction qui s'appelerait "removeLoadedClass". ouep mais le probleme est qu'il n'y a pas moyen de supprimer une classe
deja chargee... pour recharger une classe, il faut charger la nouvelle version avec un 'nouveau' classloader
Jerome
9OnLine
ok, merci pour tes explications.
Pour ce qui est du classloader que j'ai trouvé pour supprimer une class déja chargé voici 2 URL: http://www.omegahat.org/api/org/omegahat/Environment/System/DynamicClassLoad er.html http://jakarta.apache.org/bcel/apidocs/org/apache/bcel/util/ClassLoaderRepos itory.html Mais je ne pense pas que ca va t'avancé beaucoup, car il n'y a pas les sources
Et pour ta remarque:
Au fait, tu quotes comme un goret (selon l'expression usuelle). Lis donc http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
J'ai lu le doc du lien et je ne vois pas ce que tu veux dire.....
@+
"Nicolas Delsaux" a écrit dans le message news:
Le Tue, 28 Oct 2003 16:42:41 +0100, 9OnLine s'est levé est s'est dit : "tiens, si j'écrivais aux mecs de fr.comp.lang.java :
Je suis d'accord avec toi mais c'est ce que j'ai fait pour l'instant. Mais
je trouve que ça gonfle conciderablement la memoire de la JVM.
Oui, c'est normal : si tu disposes de plusieurs instances de ton ClassLoader, chacune de ces instances dispose d'un ensemble de classes chargées.
Et en plus j'ai vu une javadoc dispo avec un classloader qui peut le faire. Mais il y
avait pas les sources. :(
J'aimerais bien voir l'URL, mais je suis prêt à parier qu'il s'agit en fait
d'un singleton bien caché (ou d'un autre cas beaucoup plus balaize).
Explication ... On va dire que tu crées un ReloaderClassLoader. Celui-ci est en fait une facade vers un PersonnalClassLoader. Ce PersonnalClassLoader permet le chargement et la compilation à la volée de tes classes. Toutefois, comme tu sembles le savoir, le PersonnalClassLoader est incapable de décharger les classes chargées (c'est dans les "spécifs" du JDK). Lorsqu'une des classes qu'il a chargé est modifiée, il existe deux possibilités pour recharger la nouvelle version de la classe : - instancier ton PersonnalClassLoader sous forme d'une variable d'instance
de ton ReloaderClassLoader. Lorsqu'une classe est modifiée, le ReloaderClassLoader recrée une nouvelle instance de PersonnalClassLoader qui recharge toutes les classes. L'ancienne instance (et donc toutes les classes et instances chargées) peut être garbage collectée si tous les threads qu'elle contient sont tués. Le gros incovnénient est un ralentissement notable de ton appli pendant ce temps là, mais aussi la perte de tous les calculs effectués au moment du rechargement. - instancier ton PersonnalClassLoader sous forme d'une collection et y implémenter un chaînage : lorsqu'une nouvelle classe est modifiée, un nouveau PersonnalClassLoader est créé en queue de cette collection. Pour charger une classe, on prend le premier PersonnalClassLoader, on lui demande si la classe qu'il contient n'est pas osbolète et, si c'est le cas,
on passe au suivant. Sinon, on la charge. Ca a l'avantage de ne recharger que les classes nécessaires, avec de gros inconvénients : il y a un risque non négligeable d'incohérence entre les classes mais, surtout, la notion d'espace de nommage fait qu'il faut mémoriser les graphes de chargement de classes. Il est en effet impossible à deux instances d'une classe chargées par deux ClassLoaders différents de communiquer sereinement ensemble. Il faut impérativement passer par une interface dans leur ClassLoader primitif. Bref, tu risques de te battre. Enfin, cette méthode risque fort de charger ta JVM.
Et si quelqu'un pouvait me confirmer que ça confle bien DANGEREUSEMENT la
memoire de la JVM ???
N'exagérons rien. Les objets Class ne sont pas les plus gros. Ce qui va charger ta JVM, ce sont toutes ces instances de classes, dont tu auras intérêt à te débarasser au plus vite.
Merci d'avance.
Au fait, tu quotes comme un goret (selon l'expression usuelle). Lis donc
-- Nicolas Delsaux AN > Le rire est le propre de l'homme. AN > C'est aussi le sale de la hyène. in fras, rigolade et savane
ok, merci pour tes explications.
Pour ce qui est du classloader que j'ai trouvé pour supprimer une class déja
chargé voici 2 URL:
http://www.omegahat.org/api/org/omegahat/Environment/System/DynamicClassLoad
er.html
http://jakarta.apache.org/bcel/apidocs/org/apache/bcel/util/ClassLoaderRepos
itory.html
Mais je ne pense pas que ca va t'avancé beaucoup, car il n'y a pas les
sources
Et pour ta remarque:
Au fait, tu quotes comme un goret (selon l'expression usuelle). Lis donc
http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
J'ai lu le doc du lien et je ne vois pas ce que tu veux dire.....
@+
"Nicolas Delsaux" <nicolas.delsaux@online.fr.invalid> a écrit dans le
message news: 69y0hjkvv6lk.1amgszsybv5ue.dlg@40tude.net...
Le Tue, 28 Oct 2003 16:42:41 +0100, 9OnLine s'est levé est s'est dit :
"tiens, si j'écrivais aux mecs de fr.comp.lang.java :
Je suis d'accord avec toi mais c'est ce que j'ai fait pour l'instant.
Mais
je trouve que ça gonfle conciderablement la memoire de la JVM.
Oui, c'est normal : si tu disposes de plusieurs instances de ton
ClassLoader, chacune de ces instances dispose d'un ensemble de classes
chargées.
Et en plus
j'ai vu une javadoc dispo avec un classloader qui peut le faire. Mais il
y
avait pas les sources. :(
J'aimerais bien voir l'URL, mais je suis prêt à parier qu'il s'agit en
fait
d'un singleton bien caché (ou d'un autre cas beaucoup plus balaize).
Explication ...
On va dire que tu crées un ReloaderClassLoader. Celui-ci est en fait une
facade vers un PersonnalClassLoader. Ce PersonnalClassLoader permet le
chargement et la compilation à la volée de tes classes.
Toutefois, comme tu sembles le savoir, le PersonnalClassLoader est
incapable de décharger les classes chargées (c'est dans les "spécifs" du
JDK). Lorsqu'une des classes qu'il a chargé est modifiée, il existe deux
possibilités pour recharger la nouvelle version de la classe :
- instancier ton PersonnalClassLoader sous forme d'une variable
d'instance
de ton ReloaderClassLoader. Lorsqu'une classe est modifiée, le
ReloaderClassLoader recrée une nouvelle instance de PersonnalClassLoader
qui recharge toutes les classes. L'ancienne instance (et donc toutes les
classes et instances chargées) peut être garbage collectée si tous les
threads qu'elle contient sont tués. Le gros incovnénient est un
ralentissement notable de ton appli pendant ce temps là, mais aussi la
perte de tous les calculs effectués au moment du rechargement.
- instancier ton PersonnalClassLoader sous forme d'une collection et y
implémenter un chaînage : lorsqu'une nouvelle classe est modifiée, un
nouveau PersonnalClassLoader est créé en queue de cette collection. Pour
charger une classe, on prend le premier PersonnalClassLoader, on lui
demande si la classe qu'il contient n'est pas osbolète et, si c'est le
cas,
on passe au suivant. Sinon, on la charge. Ca a l'avantage de ne recharger
que les classes nécessaires, avec de gros inconvénients : il y a un risque
non négligeable d'incohérence entre les classes mais, surtout, la notion
d'espace de nommage fait qu'il faut mémoriser les graphes de chargement de
classes. Il est en effet impossible à deux instances d'une classe chargées
par deux ClassLoaders différents de communiquer sereinement ensemble. Il
faut impérativement passer par une interface dans leur ClassLoader
primitif. Bref, tu risques de te battre. Enfin, cette méthode risque fort
de charger ta JVM.
Et si quelqu'un pouvait me confirmer que ça confle bien DANGEREUSEMENT
la
memoire de la JVM ???
N'exagérons rien. Les objets Class ne sont pas les plus gros. Ce qui va
charger ta JVM, ce sont toutes ces instances de classes, dont tu auras
intérêt à te débarasser au plus vite.
Merci d'avance.
Au fait, tu quotes comme un goret (selon l'expression usuelle). Lis donc
Pour ce qui est du classloader que j'ai trouvé pour supprimer une class déja chargé voici 2 URL: http://www.omegahat.org/api/org/omegahat/Environment/System/DynamicClassLoad er.html http://jakarta.apache.org/bcel/apidocs/org/apache/bcel/util/ClassLoaderRepos itory.html Mais je ne pense pas que ca va t'avancé beaucoup, car il n'y a pas les sources
Et pour ta remarque:
Au fait, tu quotes comme un goret (selon l'expression usuelle). Lis donc http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html
J'ai lu le doc du lien et je ne vois pas ce que tu veux dire.....
@+
"Nicolas Delsaux" a écrit dans le message news:
Le Tue, 28 Oct 2003 16:42:41 +0100, 9OnLine s'est levé est s'est dit : "tiens, si j'écrivais aux mecs de fr.comp.lang.java :
Je suis d'accord avec toi mais c'est ce que j'ai fait pour l'instant. Mais
je trouve que ça gonfle conciderablement la memoire de la JVM.
Oui, c'est normal : si tu disposes de plusieurs instances de ton ClassLoader, chacune de ces instances dispose d'un ensemble de classes chargées.
Et en plus j'ai vu une javadoc dispo avec un classloader qui peut le faire. Mais il y
avait pas les sources. :(
J'aimerais bien voir l'URL, mais je suis prêt à parier qu'il s'agit en fait
d'un singleton bien caché (ou d'un autre cas beaucoup plus balaize).
Explication ... On va dire que tu crées un ReloaderClassLoader. Celui-ci est en fait une facade vers un PersonnalClassLoader. Ce PersonnalClassLoader permet le chargement et la compilation à la volée de tes classes. Toutefois, comme tu sembles le savoir, le PersonnalClassLoader est incapable de décharger les classes chargées (c'est dans les "spécifs" du JDK). Lorsqu'une des classes qu'il a chargé est modifiée, il existe deux possibilités pour recharger la nouvelle version de la classe : - instancier ton PersonnalClassLoader sous forme d'une variable d'instance
de ton ReloaderClassLoader. Lorsqu'une classe est modifiée, le ReloaderClassLoader recrée une nouvelle instance de PersonnalClassLoader qui recharge toutes les classes. L'ancienne instance (et donc toutes les classes et instances chargées) peut être garbage collectée si tous les threads qu'elle contient sont tués. Le gros incovnénient est un ralentissement notable de ton appli pendant ce temps là, mais aussi la perte de tous les calculs effectués au moment du rechargement. - instancier ton PersonnalClassLoader sous forme d'une collection et y implémenter un chaînage : lorsqu'une nouvelle classe est modifiée, un nouveau PersonnalClassLoader est créé en queue de cette collection. Pour charger une classe, on prend le premier PersonnalClassLoader, on lui demande si la classe qu'il contient n'est pas osbolète et, si c'est le cas,
on passe au suivant. Sinon, on la charge. Ca a l'avantage de ne recharger que les classes nécessaires, avec de gros inconvénients : il y a un risque non négligeable d'incohérence entre les classes mais, surtout, la notion d'espace de nommage fait qu'il faut mémoriser les graphes de chargement de classes. Il est en effet impossible à deux instances d'une classe chargées par deux ClassLoaders différents de communiquer sereinement ensemble. Il faut impérativement passer par une interface dans leur ClassLoader primitif. Bref, tu risques de te battre. Enfin, cette méthode risque fort de charger ta JVM.
Et si quelqu'un pouvait me confirmer que ça confle bien DANGEREUSEMENT la
memoire de la JVM ???
N'exagérons rien. Les objets Class ne sont pas les plus gros. Ce qui va charger ta JVM, ce sont toutes ces instances de classes, dont tu auras intérêt à te débarasser au plus vite.
Merci d'avance.
Au fait, tu quotes comme un goret (selon l'expression usuelle). Lis donc
-- Nicolas Delsaux AN > Le rire est le propre de l'homme. AN > C'est aussi le sale de la hyène. in fras, rigolade et savane
Nicolas Delsaux
Le Wed, 29 Oct 2003 10:18:03 +0100, 9OnLine s'est levé est s'est dit : "tiens, si j'écrivais aux mecs de fr.comp.lang.java :
ok, merci pour tes explications.
http://jakarta.apache.org/bcel/apidocs/org/apache/bcel/util/ClassLoaderRepos itory.html Mais je ne pense pas que ca va t'avancé beaucoup, car il n'y a pas les sources
Tu as mal cherché : http://jakarta.apache.org/bcel/xref/org/apache/bcel/util/ClassLoaderRepository.html
J'ai lu le doc du lien et je ne vois pas ce que tu veux dire.....
C'est peut-être que tu ne veux pas comprendre : quand on répond à quelqu'un, on répond *sous* de petites parties du message précédent qu'on cite à bon escient. Ce qui n'est clairement pas ton cas, puisque tu recopies intégralement sous ton message le mien, sans en enlever quoi que ce soit. Je ne sais pas si tu utilises un modem, mais je peux te garantir qu'avec ça, tu augmentes considérablement la taille du message envoyé.
@+
-- Nicolas Delsaux "Etre un humain était bien, j'y ai même pris du plaisir. Mais être un cyborg a tellement plus à offrir" Kevin Warwick
Le Wed, 29 Oct 2003 10:18:03 +0100, 9OnLine s'est levé est s'est dit :
"tiens, si j'écrivais aux mecs de fr.comp.lang.java :
ok, merci pour tes explications.
http://jakarta.apache.org/bcel/apidocs/org/apache/bcel/util/ClassLoaderRepos
itory.html
Mais je ne pense pas que ca va t'avancé beaucoup, car il n'y a pas les
sources
Tu as mal cherché :
http://jakarta.apache.org/bcel/xref/org/apache/bcel/util/ClassLoaderRepository.html
J'ai lu le doc du lien et je ne vois pas ce que tu veux dire.....
C'est peut-être que tu ne veux pas comprendre : quand on répond à
quelqu'un, on répond *sous* de petites parties du message précédent qu'on
cite à bon escient. Ce qui n'est clairement pas ton cas, puisque tu
recopies intégralement sous ton message le mien, sans en enlever quoi que
ce soit. Je ne sais pas si tu utilises un modem, mais je peux te garantir
qu'avec ça, tu augmentes considérablement la taille du message envoyé.
@+
--
Nicolas Delsaux
"Etre un humain était bien, j'y ai même pris du plaisir. Mais être un
cyborg a tellement plus à offrir"
Kevin Warwick
Le Wed, 29 Oct 2003 10:18:03 +0100, 9OnLine s'est levé est s'est dit : "tiens, si j'écrivais aux mecs de fr.comp.lang.java :
ok, merci pour tes explications.
http://jakarta.apache.org/bcel/apidocs/org/apache/bcel/util/ClassLoaderRepos itory.html Mais je ne pense pas que ca va t'avancé beaucoup, car il n'y a pas les sources
Tu as mal cherché : http://jakarta.apache.org/bcel/xref/org/apache/bcel/util/ClassLoaderRepository.html
J'ai lu le doc du lien et je ne vois pas ce que tu veux dire.....
C'est peut-être que tu ne veux pas comprendre : quand on répond à quelqu'un, on répond *sous* de petites parties du message précédent qu'on cite à bon escient. Ce qui n'est clairement pas ton cas, puisque tu recopies intégralement sous ton message le mien, sans en enlever quoi que ce soit. Je ne sais pas si tu utilises un modem, mais je peux te garantir qu'avec ça, tu augmentes considérablement la taille du message envoyé.
@+
-- Nicolas Delsaux "Etre un humain était bien, j'y ai même pris du plaisir. Mais être un cyborg a tellement plus à offrir" Kevin Warwick
9OnLine
Thanks
"Nicolas Delsaux" a écrit dans le message news: 19htkwjts66zh$
Le Wed, 29 Oct 2003 10:18:03 +0100, 9OnLine s'est levé est s'est dit : "tiens, si j'écrivais aux mecs de fr.comp.lang.java :
J'ai lu le doc du lien et je ne vois pas ce que tu veux dire.....
C'est peut-être que tu ne veux pas comprendre : quand on répond à quelqu'un, on répond *sous* de petites parties du message précédent qu'on cite à bon escient. Ce qui n'est clairement pas ton cas, puisque tu recopies intégralement sous ton message le mien, sans en enlever quoi que ce soit. Je ne sais pas si tu utilises un modem, mais je peux te garantir qu'avec ça, tu augmentes considérablement la taille du message envoyé.
@+
-- Nicolas Delsaux "Etre un humain était bien, j'y ai même pris du plaisir. Mais être un cyborg a tellement plus à offrir" Kevin Warwick
Thanks
"Nicolas Delsaux" <nicolas.delsaux@online.fr.invalid> a écrit dans le
message news: 19htkwjts66zh$.ae9w60vf6e9b.dlg@40tude.net...
Le Wed, 29 Oct 2003 10:18:03 +0100, 9OnLine s'est levé est s'est dit :
"tiens, si j'écrivais aux mecs de fr.comp.lang.java :
J'ai lu le doc du lien et je ne vois pas ce que tu veux dire.....
C'est peut-être que tu ne veux pas comprendre : quand on répond à
quelqu'un, on répond *sous* de petites parties du message précédent qu'on
cite à bon escient. Ce qui n'est clairement pas ton cas, puisque tu
recopies intégralement sous ton message le mien, sans en enlever quoi que
ce soit. Je ne sais pas si tu utilises un modem, mais je peux te garantir
qu'avec ça, tu augmentes considérablement la taille du message envoyé.
@+
--
Nicolas Delsaux
"Etre un humain était bien, j'y ai même pris du plaisir. Mais être un
cyborg a tellement plus à offrir"
Kevin Warwick
J'ai lu le doc du lien et je ne vois pas ce que tu veux dire.....
C'est peut-être que tu ne veux pas comprendre : quand on répond à quelqu'un, on répond *sous* de petites parties du message précédent qu'on cite à bon escient. Ce qui n'est clairement pas ton cas, puisque tu recopies intégralement sous ton message le mien, sans en enlever quoi que ce soit. Je ne sais pas si tu utilises un modem, mais je peux te garantir qu'avec ça, tu augmentes considérablement la taille du message envoyé.
@+
-- Nicolas Delsaux "Etre un humain était bien, j'y ai même pris du plaisir. Mais être un cyborg a tellement plus à offrir" Kevin Warwick
