Accueil -|- Visuel -|- Logistique -|- Applications réparties
| La pseudo-archive
Java est un service proposé par la SARL diaam informatique,
et il est hébergé par la
Sogid.
|
 |
| Pseudo-Archive Java : Accueil -|- Visuel -|- Logistique -|- Applications réparties |
|
||
|
|||
From: Olivier Dedieu <olivier.dedieu@inria.fr>
Date sent: Fri, 30 Nov 2001 09:34:56 +0100 (CET)
To: java@u-strasbg.fr
Subject: Heritage de methodes statiques
Send reply to: java@u-strasbg.fr
Bonjour,
J'ai un petit souci avec l'heritage de methode static car l'invocation des
methodes statiques est différente des methodes non-statique.
Mon probleme est de pouvoir invoquer une methode sm2 d'une classe B
via une methode sm1 définit dans une classe A, mère de B.
Voici un exemple:
class A {
public static void sm1() {
sm2();
}
public static void sm2() {
System.out.println("A.sm2");
}
}
class B extends A {
public static void sm2() {
System.out.println("B.sm2");
}
}
class TestStatic {
public static void main(String[] args) {
B.sm1();
}
}
A l'execution on obtient:
$ java test.TestStatic
A.sm2
Est-ce qu'il existe un contournement pour obtenir B.sm2 ?
a+
---------------------------------------------------------------
Olivier Dedieu - (INRIA - Bull / WebTools - Pharos)
Web: http://www-sor.inria.fr/~dedieu
JavaChannel: http://www.java-channel.org/
Pharos team: http://webtools.dyade.fr/pharos/
---------------------------------------------------------------
Date sent: Fri, 30 Nov 2001 09:47:00 +0100
To: java@u-strasbg.fr
From: Jean-Philippe Encausse <jphe@wanadoo.fr>
Subject: Re: Heritage de methodes statiques
Send reply to: java@u-strasbg.fr
Salut,
Les methodes static etant racroché aux classes et non pas aux instances je
ne crois pas que tu puisses les surcharger. Je crois que quand tu
surcharges une methode c'est forcement une methodes d'instance mais la
methodes surcharge est toujours dispo.
Donc je crois que logiquement il faudrais faire plutot un A.sm2() ou un
B.sm2(), c a d spécifier la class, mais c'est justement ce que tu ne veux
pas faire a mon avis.
Donc il faut peut etre passer par la reflexion en demandant la methode sm2
de la classe courrante, puis l'invoquer. C'est un peu lourd comme syntaxe.
Peut etre mais je n'ai pas testé qu'il est possible de spécifier un
this.sm2() mais j'y crois pas trop
Je n'apporte que peu de solution, mais enfin jsuis intéréssé qqun connais
une solution éléguante.
@+,
Jean-Philippe Encausse
jphe@wanadoo.fr - http://www.jphe.fr.st
ICQ: 109796741 - AOL: NextOne6666
Do it Once, Use it Twice ~ Do it Twice, Generalize It
At 09:34 30/11/2001 +0100, you wrote:
>Bonjour,
>
>J'ai un petit souci avec l'heritage de methode static car l'invocation
>des methodes statiques est différente des methodes non-statique.
>
>Mon probleme est de pouvoir invoquer une methode sm2 d'une classe B
>via une methode sm1 définit dans une classe A, mère de B.
>
>Voici un exemple:
>
>class A {
> public static void sm1() {
> sm2();
> }
>
> public static void sm2() {
> System.out.println("A.sm2");
> }
>}
>
>class B extends A {
> public static void sm2() {
> System.out.println("B.sm2");
> }
>}
>
>class TestStatic {
>
> public static void main(String[] args) {
> B.sm1();
> }
>}
>
>
>A l'execution on obtient:
>
>$ java test.TestStatic
>A.sm2
>
>
>Est-ce qu'il existe un contournement pour obtenir B.sm2 ?
>
>a+
>
>---------------------------------------------------------------
> Olivier Dedieu - (INRIA - Bull / WebTools - Pharos)
> Web: http://www-sor.inria.fr/~dedieu
> JavaChannel: http://www.java-channel.org/
> Pharos team: http://webtools.dyade.fr/pharos/
>---------------------------------------------------------------
To: java@u-strasbg.fr Subject: Re: Heritage de methodes statiques From: Jean-Yves Pere <toga.kiryu@free.fr> Organization: Ohtori Academy Date sent: Fri, 30 Nov 2001 10:18:52 +0100 Send reply to: java@u-strasbg.fr Jean-Philippe Encausse <jphe@wanadoo.fr> writes: > > Donc je crois que logiquement il faudrais faire plutot un A.sm2() ou un > B.sm2(), c a d spécifier la class, mais c'est justement ce que tu ne > veux pas faire a mon avis. > > Donc il faut peut etre passer par la reflexion en demandant la methode > sm2 de la classe courrante, puis l'invoquer. C'est un peu lourd comme > syntaxe. oui mais je pense que c'est la seule solution. > > Peut etre mais je n'ai pas testé qu'il est possible de spécifier un > this.sm2() mais j'y crois pas trop Ca ne sera pas possible avec this, il référence l'instance en cours de la classe et vu que là on est en static... -- Ce serait avec plaisir car je n'ai que ça à foutre en ce moment, mais encore faudrait-il que tu me passes la définition d'un déterminant cyclique, bicoze même dans mon bouquin de cours MP* je l'ai pas. -+- CS in NPC : Non chérie, pas ce soir, j'ai mal à ma sesquiélite -+-
Date sent: Fri, 30 Nov 2001 10:20:04 +0100
From: Guillaume Desnoix <guillaume@desnoix.com>
To: java@u-strasbg.fr
Subject: Re: Heritage de methodes statiques
Send reply to: java@u-strasbg.fr
Olivier Dedieu wrote:
> J'ai un petit souci avec l'heritage de methode static car l'invocation
> des methodes statiques est différente des methodes non-statique. Mon
> probleme est de pouvoir invoquer une methode sm2 d'une classe B via une
> methode sm1 définit dans une classe A, mère de B. Est-ce qu'il existe un
> contournement pour obtenir B.sm2 ?
A priori, non car la resolution des appels statiques est realisee a la
compilation. C'est d'ailleurs (imho) une erreur de conception de Java que
de pouvoir redefinir une methode statique de meme signature dans une
classe derivee.
Pour ton probleme, la solution est a mon avis de reintroduire l'heritage
classique via des singletons.
Guillaume
http://www.memoire.com/guillaume-desnoix/foo/
class A {
class WA {
final static SINGLETON=new WA();
sm1() { sm2(); }
sm2() { System.out.println("A.sm2"); }
public static void sm1() {
WA.SINGLETON.sm1();
}
public static void sm2() {
WA.SINGLETON.sm2();
}
}
class B extends A {
class WB extends WA {
final static SINGLETON=new WB();
sm2() { System.out.println("B.sm2"); }
}
public static void sm1() {
WB.SINGLETON.sm1();
}
public static void sm2() {
WB.SINGLETON.sm2();
}
}
Date sent: Fri, 30 Nov 2001 10:49:29 +0100 From: Remi Forax <forax@univ-mlv.fr> To: java@u-strasbg.fr Subject: Re: Heritage de methodes statiques Send reply to: java@u-strasbg.fr Jean-Yves Pere wrote: > Jean-Philippe Encausse <jphe@wanadoo.fr> writes: > > >>Donc je crois que logiquement il faudrais faire plutot un A.sm2() ou un >>B.sm2(), c a d spécifier la class, mais c'est justement ce que tu ne >>veux pas faire a mon avis. >> >>Donc il faut peut etre passer par la reflexion en demandant la methode >>sm2 de la classe courrante, puis l'invoquer. C'est un peu lourd comme >>syntaxe. >> > > oui mais je pense que c'est la seule solution. Euh, résoudre le problème par reflexion me semble ardu. En fait, je ne sais pas le faire avant le JDK1.4. Est-ce que j'aurais rate qquechose. > > >>Peut etre mais je n'ai pas testé qu'il est possible de spécifier un >>this.sm2() mais j'y crois pas trop >> > > Ca ne sera pas possible avec this, il référence l'instance en cours de > la classe et vu que là on est en static... > > Remi
From: Olivier Dedieu <olivier.dedieu@inria.fr> Date sent: Fri, 30 Nov 2001 11:15:23 +0100 (CET) To: java@u-strasbg.fr Subject: Re: Heritage de methodes statiques Send reply to: java@u-strasbg.fr > > Pour ton probleme, la solution est a mon avis de reintroduire > l'heritage > classique via des singletons. Oui c'est une bonne idée (mais m'oblige à revoir bcp de code ;-( ) Merci bcp, a+ --------------------------------------------------------------- Olivier Dedieu - (INRIA - Bull / WebTools - Pharos) Web: http://www-sor.inria.fr/~dedieu JavaChannel: http://www.java-channel.org/ Pharos team: http://webtools.dyade.fr/pharos/ ---------------------------------------------------------------
From: "Herve AGNOUX" <herve.agnoux@diaam-informatique.com> To: java@u-strasbg.fr Date sent: Fri, 30 Nov 2001 12:02:18 +0100 Subject: Re: Heritage de methodes statiques Send reply to: herve.agnoux@diaam-informatique.com Priority: normal Le 30 Nov 01, Olivier Dedieu a écrit : > > Oui c'est une bonne idée (mais m'oblige à revoir bcp de code ;-( ) > Moi, en Java, je trouve qu'il faut éviter au maximum les métodes statiques. (les singletons aussi, d'ailleurs, mais c'est un autre débat). Chaque fois que je me suis engagé dans des méthodes statiques, je l'ai regretté. Je ne sais pas si c'est parce que le support de Java est mauvais, ou si c'est parce que les méthodes statiques c'est pas vraiment de la POO, ou... Je préfère nettement l'approche "contexte". Chaque objet a un contexte (qu'il ne connait d'ailleurs en général pas), et ce contexte se transmet au fur et à mesure des besoins de proche en proche, et l'on agit sur ces objets à partir de leur contexte. Il n'est plus besoin de méthode statique, ni même de singleton. On arrive ainsi aux technologies JNDI, que je me félicite d'utiliser. Et j'ai vu que dans la jdk 1.3.1 il y avait de nouvelles merveilles telles que les BeanContext, les ThreadLocal, les AccessController, que je sais pas encore très bien comment tout cela fonctionne mais que je vais me dépêcher d'explorer à la première occasion ! A+. -- Sur le Web, tout de suite. Herve AGNOUX - diaam informatique http://www.diaam-informatique.com
From: Olivier Dedieu <olivier.dedieu@inria.fr>
Date sent: Fri, 30 Nov 2001 13:01:35 +0100 (CET)
To: herve.agnoux@diaam-informatique.com
Copies to: java@u-strasbg.fr
Subject: Re: Heritage de methodes statiques
Send reply to: java@u-strasbg.fr
> Moi, en Java, je trouve qu'il faut éviter au maximum les métodes
> statiques. (les singletons aussi, d'ailleurs, mais c'est un autre
> débat). Chaque fois que je me suis engagé dans des méthodes statiques,
> je l'ai regretté.
Je suis globalement d'accord. J'utilise très peu les méthodes
statique. Mais des fois ca permet d'encapsuler proprement des accès à des
resources statiques de la classe, comme par exemple des inner classe.
Juste pour info, voila plus précisement mon cas d'utilisation:
- J'ai une hierarchie de classes (eg: Data > Publication > Article)
- Chaque classe a des comparators (inner classes) qui lui sont propres
(en plus de ceux dont elle herite).
- J'ai besoin d'obtenir, pour une classe donnée, un comparateur
correspondant à une String (eg: "title" -> TitleComparator),
eventuellement géré par une classe ascendante:
Pour cela, j'ai definit une method statique à la classe qui me renvoit le
comparator en fonction de la String (evt en cherchant dans les classes
mere).
Comparator c = Article.getComparator("title");
Mon souci est d'arriver à quelque chose de concis, extensible et
maintenable.
a+
---------------------------------------------------------------
Olivier Dedieu - (INRIA - Bull / WebTools - Pharos)
Web: http://www-sor.inria.fr/~dedieu
JavaChannel: http://www.java-channel.org/
Pharos team: http://webtools.dyade.fr/pharos/
---------------------------------------------------------------
From: "Herve AGNOUX" <herve.agnoux@diaam-informatique.com>
To: java@u-strasbg.fr
Date sent: Fri, 30 Nov 2001 16:05:46 +0100
Subject: Re: Heritage de methodes statiques
Send reply to: java@u-strasbg.fr
Priority: normal
Le 30 Nov 01, Olivier Dedieu a écrit :
> [...]
> Pour cela, j'ai definit une method statique à la classe qui me renvoit
> le comparator en fonction de la String (evt en cherchant dans les
> classes mere).
>
C'est dans le "evt" qu'il y a un problème : depuis une méthode
statique tu n'as pas accés à "super", donc tu ne peux pas
facilement faire le traitement "éventuel".
Il y a bien sûr et heureusement 36 combines pour y arriver, mais je
ne suis pas sûr qu'elles soient très éleguantes.
La meilleure que je vois est de te donner un objet blanc de la
classe Article, mémorisé en attribut statique dans cette classe. La
méthode statique "getComparator" appellerait une méthode style
"articleBlanc.getComparatorFromInstance("title")", qui pourrait faire tous
les "super" qu'elle voudrait, et tu reprendrais contact avec l'éléguance
en rendant "getComparatorFromInstance" publique.
> Comparator c = Article.getComparator("title");
>
> Mon souci est d'arriver à quelque chose de concis, extensible et
> maintenable.
>
Je pense que la technique de l'objet blanc (copirit Hervé AGNOUX)
te le permet.
--
Sur le Web, tout de suite.
Herve AGNOUX - diaam informatique
http://www.diaam-informatique.com
To: java@u-strasbg.fr
Subject: Re: Heritage de methodes statiques
Date sent: Fri, 30 Nov 2001 16:32:13 +0100 (MET)
From: Nicolas Delsaux <nicolas.delsaux@free.fr>
Send reply to: java@u-strasbg.fr
----- Original Message -----
From: "Herve AGNOUX" <herve.agnoux@diaam-informatique.com>
To: <java@u-strasbg.fr>
Sent: Friday, November 30, 2001 4:05 PM
Subject: Re: Heritage de methodes statiques
>
> C'est dans le "evt" qu'il y a un problème : depuis une méthode
> statique tu n'as pas accés à "super", donc tu ne peux pas
> facilement faire le traitement "éventuel".
Bouaip, c'est le vrai problème des méthodes statiques : elles ne font pas
partie des objets d'une classe, et sont pourtant utilisées comme telles. >
> La meilleure que je vois est de te donner un objet blanc de la > classe
Article, mémorisé en attribut statique dans cette classe. La > méthode
statique "getComparator" appellerait une méthode style >
"articleBlanc.getComparatorFromInstance("title")", qui pourrait faire >
tous les "super" qu'elle voudrait, et tu reprendrais contact avec >
l'éléguance en rendant "getComparatorFromInstance" publique.
Est-ce que ça ne ressemblerait pas à l'instance "null" ? Je crois bien que
je vais dire des conneries, mais il me semble qu'il est possible en Java
de définir pour sa classe un objet "null". Cet objet est alors utilisé
lorsqu'on affecte null à un objet de la classe considérée. Je n'ai pas de
doc sous la main, mais il me semble que ça existe. Sinon, l'ojbet blanc
est effectivement une bonne solution, fourni éventuellement par une
méthode statique (la seule). En fait, il s'agit simplement d'intégrer un
singleton à la classe... > > Je pense que la technique de l'objet blanc
(copirit Hervé AGNOUX) > te le permet. > -- Nicolas Delsaux
http://nicolas.delsaux.free.fr/
From: Olivier Dedieu <olivier.dedieu@inria.fr>
Date sent: Fri, 30 Nov 2001 16:41:00 +0100 (CET)
To: java@u-strasbg.fr
Subject: Re: Heritage de methodes statiques
Send reply to: java@u-strasbg.fr
> La meilleure que je vois est de te donner un objet blanc de la
> classe Article, mémorisé en attribut statique dans cette classe.
C'est exactement le principe du singleton attaché à la classe que
citais Guillaume ce matin (désolé pour le copyright ;-)
class A {
class WA {
final static SINGLETON=new WA();
Mais ca complique un peu les chose. Pour m'a part j'ai fait plus
simple mais moins élégant. Comme le cas se présente peu, j'ai mis en
dur le nom de la classe mere pour invoque la method getComparator:
public static Comparator getComparator(String str) {
...
return ClasseMere.getComparator(str);
}
Comme je change peu (pour ne pas dire jamais) de classe mère pour ces
objets ca n'est pas tres génant.
a+
---------------------------------------------------------------
Olivier Dedieu - (INRIA - Bull / WebTools - Pharos)
Web: http://www-sor.inria.fr/~dedieu
JavaChannel: http://www.java-channel.org/
Pharos team: http://webtools.dyade.fr/pharos/
---------------------------------------------------------------
Date sent: Fri, 30 Nov 2001 19:32:28 +0100
From: Remi Forax <forax@univ-mlv.fr>
To: java@u-strasbg.fr
Subject: Re: Heritage de methodes statiques
Send reply to: java@u-strasbg.fr
Olivier Dedieu wrote:
> Je suis globalement d'accord. J'utilise très peu les méthodes
> statique. Mais des fois ca permet d'encapsuler proprement des accès à
> des resources statiques de la classe, comme par exemple des inner
> classe.
>
> Juste pour info, voila plus précisement mon cas d'utilisation:
>
> - J'ai une hierarchie de classes (eg: Data > Publication > Article)
>
> - Chaque classe a des comparators (inner classes) qui lui sont propres
> (en plus de ceux dont elle herite).
>
> - J'ai besoin d'obtenir, pour une classe donnée, un comparateur
> correspondant à une String (eg: "title" -> TitleComparator),
> eventuellement géré par une classe ascendante:
dit comme cela, ca ressemble franchement au cas rever d'utilisation
de reflection :)
Tu peux utiliser getDeclaredClasses() pour obtenir l'ensemble des
inner classes d'une classe. Le leger problème est que cela n'effectue pas
l'héritage, il faut le faire à la main.
Comparator getComparator(Class c,String name) {
if (c==null)
throw new ClassNotFoundException(name);
Class[] classes=c.getDeclaredClasses();
for(int i=0;i<classes.length;i++)
if (classes[i].getName().equals(name))
return (Comparator)c.newInstance();
return getComparator(c.getSuperclass(),name);
}
En appelant getComparator(Article,"TitleComparator").
Bien sur, ca serait mieux de simuler le mécanisme de VTable
en utilisant de inner-classe comme méthode.
>
> Pour cela, j'ai definit une method statique à la classe qui me renvoit
> le comparator en fonction de la String (evt en cherchant dans les
> classes mere).
>
> Comparator c = Article.getComparator("title");
>
> Mon souci est d'arriver à quelque chose de concis, extensible et
> maintenable.
>
> a+
Remi
From: "Herve AGNOUX" <herve.agnoux@diaam-informatique.com> To: java@u-strasbg.fr Date sent: Sat, 1 Dec 2001 11:27:32 +0100 Subject: Re: Heritage de methodes statiques Send reply to: herve.agnoux@diaam-informatique.com Priority: normal Le 30 Nov 01, Olivier Dedieu a écrit : > > C'est exactement le principe du singleton attaché à la classe que > citais Guillaume ce matin (désolé pour le copyright ;-) > A relire le message de Guillaume, oui effectivement. C'est le terme "singleton" qui m'avait trompé ; mais globalement, c'est la même idée... Bon, OK, OK, je retire mon copyright... -- Sur le Web, tout de suite. Herve AGNOUX - diaam informatique http://www.diaam-informatique.com
From: Olivier Dedieu <olivier.dedieu@inria.fr> Date sent: Mon, 3 Dec 2001 09:35:54 +0100 (CET) To: java@u-strasbg.fr Subject: Re: Heritage de methodes statiques Send reply to: java@u-strasbg.fr > dit comme cela, ca ressemble franchement au cas rever d'utilisation de > reflection :) Oui mais c'est du code appeler tres souvent, donc j'ai besoins qu'il soit performant. Or, dans mes derniers test la reflexion n'est pas très performante. a+ --------------------------------------------------------------- Olivier Dedieu - (INRIA - Bull / WebTools - Pharos) Web: http://www-sor.inria.fr/~dedieu JavaChannel: http://www.java-channel.org/ Pharos team: http://webtools.dyade.fr/pharos/ ---------------------------------------------------------------
From: "D T" <dtaye@hotmail.com> To: java@u-strasbg.fr Subject: Re: Heritage de methodes statiques Date sent: Mon, 03 Dec 2001 09:12:08 +0000 Send reply to: java@u-strasbg.fr > > > dit comme cela, ca ressemble franchement au cas rever d'utilisation > > de reflection :) > >Oui mais c'est du code appeler tres souvent, donc j'ai besoins qu'il soit >performant. Or, dans mes derniers test la reflexion n'est pas trs >performante. > meme sur 1.4? _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
Date sent: Mon, 03 Dec 2001 10:30:49 +0100 To: java@u-strasbg.fr From: Jean-Philippe Encausse <jphe@wanadoo.fr> Subject: Re: Heritage de methodes statiques Send reply to: java@u-strasbg.fr At 09:35 03/12/2001 +0100, you wrote: > > dit comme cela, ca ressemble franchement au cas rever d'utilisation > > de reflection :) > >Oui mais c'est du code appeler tres souvent, donc j'ai besoins qu'il soit >performant. Or, dans mes derniers test la reflexion n'est pas très >performante. Normalement la reflection devrait etre beaucoup accéléré avec le JDK 1.4 Actuellement sur le 1.3 une action faite par reflection est 80 fois plus lente. Avec le JDK 1.4 ce sera corrigé, on ne peux pas vraiment le tester en ce moment car les version beta sont tres lentes mais il faut l'esperer. Jean-Philippe Encausse jphe@wanadoo.fr - http://www.jphe.fr.st ICQ: 109796741 - AOL: NextOne6666 - Tel: 06.63.47.93.13 Do it Once, Use it Twice ~ Do it Twice, Generalize It
From: Olivier Dedieu <olivier.dedieu@inria.fr> Date sent: Mon, 3 Dec 2001 10:32:19 +0100 (CET) To: java@u-strasbg.fr Subject: Re: Heritage de methodes statiques Send reply to: java@u-strasbg.fr > > > > > > dit comme cela, ca ressemble franchement au cas rever > > > d'utilisation de reflection :) > > > >Oui mais c'est du code appeler tres souvent, donc j'ai besoins qu'il > >soit performant. Or, dans mes derniers test la reflexion n'est pas trs > >performante. > > > > meme sur 1.4? j'ai pas testé et 1.4 n'est pas encore très déployé, en particulier comme on fait du J2EE que l'on souhaite portable, on est contraint par la version du JDK supporté les principales versions des AppServer (souvent du 1.2) a+ --------------------------------------------------------------- Olivier Dedieu - (INRIA - Bull / WebTools - Pharos) Web: http://www-sor.inria.fr/~dedieu JavaChannel: http://www.java-channel.org/ Pharos team: http://webtools.dyade.fr/pharos/ ---------------------------------------------------------------
Date sent: Mon, 03 Dec 2001 10:58:43 +0100 From: Yann SECQ <Yann.Secq@lifl.fr> Organization: SMAC To: java@u-strasbg.fr Subject: Re: Heritage de methodes statiques Send reply to: java@u-strasbg.fr Jean-Philippe Encausse wrote: > Normalement la reflection devrait etre beaucoup accéléré > avec le JDK 1.4. Actuellement sur le 1.3 une action faite > par reflection est 80 fois plus lente. > Avec le JDK 1.4 ce sera corrigé, on ne peux pas vraiment le > tester en ce moment car les version beta sont tres lentes > mais il faut l'esperer. Un petit programme de test en attachement pour illustrer les propos de Jean-Philippe : En 1.3.1 : (-g:none -O) Normal call : 14 Lookup+argument's building+reflection call : 5374 argument's building+Reflective call : 689 Reflective call only : 666 En 1.4.0b2 : (-g:none -O) Normal call : 21 Lookup+argument's building+reflection call : 2063 argument's building+Reflective call : 611 Reflective call only : 611 Malgré une amélioration sensible (notamment sur le lookup!), le cout n'est pas négligeable ! En passant, on remarquera le cout quasi-nul de création d'un tableau d'objets (pour le passage d'arguments). Il n'y a plus qu'à attendre la Release Consumer en 1.4 ;) a+, yann. -- / Yann SECQ Equipe SMAC secq@lifl.fr \ | Multi-Agent Systems Modeling & Agent Oriented Programming | \ http://www.lifl.fr/SMAC http://www.lifl.fr/~secq /
From: Olivier Dedieu <olivier.dedieu@inria.fr> Date sent: Mon, 3 Dec 2001 11:00:59 +0100 (CET) To: java@u-strasbg.fr Subject: Re: Heritage de methodes statiques Send reply to: java@u-strasbg.fr > At 09:35 03/12/2001 +0100, you wrote: > > > > dit comme cela, ca ressemble franchement au cas rever > > > d'utilisation de reflection :) > > > >Oui mais c'est du code appeler tres souvent, donc j'ai besoins qu'il > >soit performant. Or, dans mes derniers test la reflexion n'est pas > >très performante. > > > Normalement la reflection devrait etre beaucoup accéléré avec le > JDK 1.4 Actuellement sur le 1.3 une action faite par reflection est 80 > fois plus lente. Avec le JDK 1.4 ce sera corrigé, on ne peux pas > vraiment le tester en ce moment car les version beta sont tres lentes > mais il faut l'esperer. 80 fois ca me parait beaucoup (j'avais plutot constaté un rapport inférieur à 10). Mais c'est qd meme très couteux. C'est pour ca que j'évite la reflexion au Runtime. Je ne l'utilise actuellement que pour générer dynamiquement du code statique. Comme ca je beneficie des avantages (simplicité et généricité) et pas des inconvenients (lenteur actuelle) Il y a recemment eu un article sur le sujet dans JavaWorld http://pharos.inria.fr/Java/annotations.jsp?id=s1:17740 a+ --------------------------------------------------------------- Olivier Dedieu - (INRIA - Bull / WebTools - Pharos) Web: http://www-sor.inria.fr/~dedieu JavaChannel: http://www.java-channel.org/ Pharos team: http://webtools.dyade.fr/pharos/ ---------------------------------------------------------------
Date sent: Mon, 03 Dec 2001 11:22:23 +0100 From: Remi Forax <forax@univ-mlv.fr> To: java@u-strasbg.fr Subject: Re: Heritage de methodes statiques Send reply to: java@u-strasbg.fr Olivier Dedieu wrote: > 80 fois ca me parait beaucoup (j'avais plutot constaté un rapport > inférieur à 10). > > Mais c'est qd meme très couteux. C'est pour ca que j'évite la > reflexion au Runtime. Je ne l'utilise actuellement que pour générer > dynamiquement du code statique. Comme ca je beneficie des avantages > (simplicité et généricité) et pas des inconvenients (lenteur actuelle) Justement, en 1.4, un appel reflexif est transformer en un appel normal en utilisant un mécanisme de proxy (byte-code généré lors de la première utilisation). > > Il y a recemment eu un article sur le sujet dans JavaWorld > http://pharos.inria.fr/Java/annotations.jsp?id=s1:17740 > > a+ > Remi
From: Olivier Dedieu <olivier.dedieu@inria.fr> Date sent: Mon, 3 Dec 2001 11:38:18 +0100 (CET) To: java@u-strasbg.fr Subject: Re: Heritage de methodes statiques Send reply to: java@u-strasbg.fr > Olivier Dedieu wrote: > > > > 80 fois ca me parait beaucoup (j'avais plutot constaté un rapport > > inférieur à 10). > > > > Mais c'est qd meme très couteux. C'est pour ca que j'évite la > > reflexion au Runtime. Je ne l'utilise actuellement que pour générer > > dynamiquement du code statique. Comme ca je beneficie des avantages > > (simplicité et généricité) et pas des inconvenients (lenteur > > actuelle) > > > Justement, en 1.4, un appel reflexif est transformer en un appel > normal en utilisant un mécanisme de proxy (byte-code généré lors > de la première utilisation). Ah, très bonne approche. Ce mecanisme est expliqué dans les doc du 1.4 ? a+ --------------------------------------------------------------- Olivier Dedieu - (INRIA - Bull / WebTools - Pharos) Web: http://www-sor.inria.fr/~dedieu JavaChannel: http://www.java-channel.org/ Pharos team: http://webtools.dyade.fr/pharos/ ---------------------------------------------------------------
From: DELGRANCHE David <ddelgranche@sogitec.fr> To: "'java@u-strasbg.fr'" <java@u-strasbg.fr> Subject: RE: Heritage de methodes statiques Date sent: Mon, 3 Dec 2001 11:43:05 +0100 Send reply to: java@u-strasbg.fr Bonjour, Au risque de passer pour un idiot, qu'est-ce que la réflexion?? Merci. > -----Message d'origine----- > De: Olivier Dedieu [SMTP:olivier.dedieu@inria.fr] > Date: lundi 3 décembre 2001 11.38 > À: java@u-strasbg.fr > Objet: Re: Heritage de methodes statiques > > > > Olivier Dedieu wrote: > > > > > > > 80 fois ca me parait beaucoup (j'avais plutot constaté un rapport > > > inférieur à 10). > > > > > > Mais c'est qd meme très couteux. C'est pour ca que j'évite la > > > reflexion au Runtime. Je ne l'utilise actuellement que pour générer > > > dynamiquement du code statique. Comme ca je beneficie des avantages > > > (simplicité et généricité) et pas des inconvenients (lenteur > actuelle) > > > > > > Justement, en 1.4, un appel reflexif est transformer en un appel > > normal en utilisant un mécanisme de proxy (byte-code généré lors de > > la première utilisation). > > Ah, très bonne approche. Ce mecanisme est expliqué dans les doc du > 1.4 ? > > a+ > > --------------------------------------------------------------- > Olivier Dedieu - (INRIA - Bull / WebTools - Pharos) > Web: http://www-sor.inria.fr/~dedieu > JavaChannel: http://www.java-channel.org/ > Pharos team: http://webtools.dyade.fr/pharos/ > --------------------------------------------------------------- > > > >
Date sent: Mon, 03 Dec 2001 11:52:01 +0100
From: Yann SECQ <Yann.Secq@lifl.fr>
Organization: SMAC
To: java@u-strasbg.fr
Subject: Re: Heritage de methodes statiques
Send reply to: java@u-strasbg.fr
DELGRANCHE David wrote:
> Bonjour,
> Au risque de passer pour un idiot, qu'est-ce que la réflexion??
Si j'étais taquin je dirai que c'est un processus permettant
à l'être humain de penser à sa condition ;))
Mais concernant Java c'est beaucoup plus pragmatique : ce sont
les capacités que fourni un language pour se décrire lui même.
Ex: je récupère une référence d'objet sortant d'un Vector et
je dois l'utiliser. Pour cela je peux utiliser la reflection
pour l'interroger.
Object o = monVecteur.get(0);
Class c = o.getClass(); // me retourne la classe de l'objet
Method[] m = c.getDeclaredMethods[]; // me retourne les méthodes
// définies dans cette classe.
et l'on peut une fois que l'on a sélectionné la méthode nous intéressant
l'invoquer :
m.invoque(<l'objet cible>, <un tableau d'objets contenant les paramètres
de la méthode invoquée>);
Voilà, en gros c'est une couche de description et de manipulation
du langage par lui-même (attention une fois que l'on y a goûté, on
a du mal à s'en passer ;)
yann.
--
/ Yann SECQ Equipe SMAC secq@lifl.fr \
| Multi-Agent Systems Modeling & Agent Oriented Programming |
\ http://www.lifl.fr/SMAC http://www.lifl.fr/~secq /
Date sent: Mon, 03 Dec 2001 12:04:08 +0100
To: java@u-strasbg.fr
From: Jean-Philippe Encausse <jphe@wanadoo.fr>
Subject: RE: Heritage de methodes statiques
Send reply to: java@u-strasbg.fr
En faite on utilise ce mot abusivement pour désigner
l'utilisation des concept du package java.lang.reflect (plus quelques
autres)
La grande puissance de Java est que c'est un langage completement Objet
donc les objets sont composés d'objet et manipulable par des objets
par exemple:
- Un int est un Objet (Integer.Type)
- Une methode est un objet
- Un pointeur sur Objet (une réference sur un objet) est un objet
- ...
Donc il est possible en Java de manipuler des objets
soit directement :
Point p = new Point(5,5)
p.getSize();
soit par la reflexion :
java.lang.reflect.Method m = f.getClass().getDeclaredMethod("getSize", new
Class[]{}); m.invoke(f, new Object[]{});
Quel est l'interet ?
*********************
Vu de loin c'est pas super car il faut ecrire plus de code,
il faut utiliser des try catch, c'est plus lent pour l'instant ...
Mais ce qui est génial c'est la possibilité de penser completement
générique Tu as un objet X tu lui demande de se décrire , ce qu'il a
comme methode, ce qu'elles retournent ... A partir de la tu peux abstraire
un concept sans te préocuper de ce que tu manipule.
Par exemple si tu veux ecrire un Serializer d'objet en XML c'est une des
techniques, tu travailles avec n'importe qu'elle objet en regardant
comment il se présente, tu sauvegarde cette presentation puis tu
reconstruit l'objet.
Il faut juste noter que ce n'est pas tout rose et que pour des raisons de
sécurité et de packaging il y a parfois certaines contraintes imposés. Je
pense par exemple au faite que la JVM transforme à la volée les int en
Integer ou que certaines methodes pour pouvoir etre invoquées doivent etre
public ...
@+,
Jp
At 11:43 03/12/2001 +0100, you wrote:
> Bonjour,
>
> Au risque de passer pour un idiot, qu'est-ce que la réflexion??
>
> Merci.
>
> > -----Message d'origine-----
> > De: Olivier Dedieu [SMTP:olivier.dedieu@inria.fr]
> > Date: lundi 3 décembre 2001 11.38
> > À: java@u-strasbg.fr
> > Objet: Re: Heritage de methodes statiques
> >
> >
> > > Olivier Dedieu wrote:
> > >
> > >
> > > > 80 fois ca me parait beaucoup (j'avais plutot constaté un rapport
> > > > inférieur à 10).
> > > >
> > > > Mais c'est qd meme très couteux. C'est pour ca que j'évite la
> > > > reflexion au Runtime. Je ne l'utilise actuellement que pour
> > > > générer dynamiquement du code statique. Comme ca je beneficie des
> > > > avantages (simplicité et généricité) et pas des inconvenients
> > > > (lenteur
> > actuelle)
> > >
> > >
> > > Justement, en 1.4, un appel reflexif est transformer en un appel
> > > normal en utilisant un mécanisme de proxy (byte-code généré lors de
> > > la première utilisation).
> >
> > Ah, très bonne approche. Ce mecanisme est expliqué dans les doc du 1.4
> > ?
> >
> > a+
> >
> > ---------------------------------------------------------------
> > Olivier Dedieu - (INRIA - Bull / WebTools - Pharos)
> > Web: http://www-sor.inria.fr/~dedieu
> > JavaChannel: http://www.java-channel.org/
> > Pharos team: http://webtools.dyade.fr/pharos/
> > ---------------------------------------------------------------
> >
> >
> >
> > --------------Interscan------------- (on the network)
>
>email-body was scanned and no virus found
>------------------------------Traite par ISVW---------------
Jean-Philippe Encausse
jphe@wanadoo.fr - http://www.jphe.fr.st
ICQ: 109796741 - AOL: NextOne6666 - Tel: 06.63.47.93.13
Do it Once, Use it Twice ~ Do it Twice, Generalize It
Date sent: Mon, 03 Dec 2001 12:15:04 +0100 From: Remi Forax <forax@univ-mlv.fr> To: java@u-strasbg.fr Subject: Re: Heritage de methodes statiques Send reply to: java@u-strasbg.fr Olivier Dedieu wrote: >> Olivier Dedieu wrote: >> >> >> > 80 fois ca me parait beaucoup (j'avais plutot constaté un rapport >> > inférieur à 10). >> > >> > Mais c'est qd meme très couteux. C'est pour ca que j'évite la >> > reflexion au Runtime. Je ne l'utilise actuellement que pour générer >> > dynamiquement du code statique. Comme ca je beneficie des avantages >> > (simplicité et généricité) et pas des inconvenients (lenteur >> > actuelle) >> >> >> Justement, en 1.4, un appel reflexif est transformer en un appel >> normal en utilisant un mécanisme de proxy (byte-code généré lors >> de la première utilisation). >> > > Ah, très bonne approche. Ce mecanisme est expliqué dans les doc du > 1.4 ? Heu, moi, ma doc c'est le src.zip :) Je ne crois pas que cela soit expliquer qqpart. A ce que j'ai compris, c'est juste une optimisation qui consiste si méthode est accessible (public) et si les droits ont déjà été teste (ReflectionPermission) à générer le proxy puis à l'appeler. Ca va plus vite que de transiter par le VM, c'est tout. > > a+ > > --------------------------------------------------------------- > Olivier Dedieu - (INRIA - Bull / WebTools - Pharos) > Web: http://www-sor.inria.fr/~dedieu > JavaChannel: http://www.java-channel.org/ > Pharos team: http://webtools.dyade.fr/pharos/ > --------------------------------------------------------------- > Remi
Date sent: Mon, 3 Dec 2001 14:09:21 +0100 (CET) From: Alain AITOULHA <aitoulha@yahoo.fr> Subject: Re: Heritage de methodes statiques To: java@u-strasbg.fr Send reply to: java@u-strasbg.fr --- Yann SECQ <Yann.Secq@lifl.fr> a écrit : > DELGRANCHE David wrote: > > > Bonjour, > > Au risque de passer pour un idiot, qu'est-ce que > la réflexion?? > > Si j'étais taquin je dirai que c'est un processus > permettant > à l'être humain de penser à sa condition ;)) > > Mais concernant Java c'est beaucoup plus pragmatique > : ce sont > les capacités que fourni un language pour se décrire > lui même. > > Ex: je récupère une référence d'objet sortant d'un > Vector et > je dois l'utiliser. Pour cela je peux utiliser la > reflection > pour l'interroger. > > Object o = monVecteur.get(0); > Class c = o.getClass(); // me retourne la classe de > l'objet > Method[] m = c.getDeclaredMethods[]; // me retourne > les méthodes > // définies dans cette classe. > > et l'on peut une fois que l'on a sélectionné la > méthode nous intéressant > l'invoquer : > > m.invoque(<l'objet cible>, <un tableau d'objets > contenant les paramètres > de la méthode invoquée>); Très bien mais peux-tu expliquer l'intérêt de cette mécanique ? avec ton exemple (par exemple) t'aurais pu faire le choix bien classsique o.m(<params>) en supposant que o soit casté. Donc il y a un intérêt caché derrière ta mécanique ... Alain > > Voilà, en gros c'est une couche de description et de > manipulation > du langage par lui-même (attention une fois que l'on > y a goûté, on > a du mal à s'en passer ;) > > yann. > > -- > / Yann SECQ Equipe SMAC > secq@lifl.fr \ > | Multi-Agent Systems Modeling & Agent Oriented > Programming | > \ http://www.lifl.fr/SMAC > http://www.lifl.fr/~secq / > ___________________________________________________________ Nokia 5510 Drole de look et quel son. Cliquez sur http://fr.promotions.yahoo.com/nokia/ découvrez le et tentez votre chance pour en gagner un! Fin de concours le 16 décembre.
Date sent: Mon, 03 Dec 2001 14:49:29 +0100 From: Yann SECQ <Yann.Secq@lifl.fr> Organization: SMAC To: java@u-strasbg.fr Subject: Re: Heritage de methodes statiques Send reply to: java@u-strasbg.fr Alain AITOULHA wrote: > Très bien mais peux-tu expliquer l'intérêt de cette > mécanique ? avec ton exemple (par exemple) t'aurais pu > faire le choix bien classsique o.m(<params>) en > supposant que o soit casté. Donc il y a un intérêt > caché derrière ta mécanique ... Je n'ai pas d'exemple concret en tête si ce n'est l'utilisation que nous en faisons dans l'équipe. Nous avons écris un système permettant de réifier la notion d'invocation (i.e. se libérer de la syntaxe objet.methode(arguments), en la remplaçant par methode(arguments) l'objet étant déterminé dynamiquement. Pour cela, on introduit des méthodes appelées par l'utilisateur (perform, ask, askNow) qui introduise la réification, et l'on se sert ensuite de la reflection pour trouver les objets possédants la méthode. Je n'ai pas regardé les sources, mais je suppose que c'est grâce à la réfléxivité que les DynamicProxy peuvent être implémentés en 1.3. yann. PS: Dans les outils cela sert évidemment : un browser de classes peut ainsi être facilement écrit. -- / Yann SECQ Equipe SMAC secq@lifl.fr \ | Multi-Agent Systems Modeling & Agent Oriented Programming | \ http://www.lifl.fr/SMAC http://www.lifl.fr/~secq /
