Pseudo-Archive Java : 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.

Date sent:      	Thu, 10 May 2001 15:20:21 +0200
From:           	Remi Forax <forax@univ-mlv.fr>
To:             	java@u-strasbg.fr
Subject:        	Template en Java
Send reply to:  	java@u-strasbg.fr

La specif de Sun sur les templates est sortie,
ya du bon et du moins bon :)

http://java.sun.com/aboutJava/communityprocess/review/jsr014/

Remi

Date sent:      	Thu, 10 May 2001 06:35:04 -0700 (PDT)
From:           	Thierry Janaudy <janaudy@yahoo.com>
Send reply to:  	janaudy@jyperion.com
Subject:        	Re: Template en Java
To:             	java@u-strasbg.fr

Puis-je demander ton analyse de ce JSR?
Surtout ce que tu consideres comme etant "moins bon"
et pourquoi.

(Vu que tu connais tres bien le domaine, je desirerais
eclairer ma lanterne)

Merci

Thierry


--- Remi Forax <forax@univ-mlv.fr> wrote:
> La specif de Sun sur les templates est sortie,
> ya du bon et du moins bon :)
> 
>
http://java.sun.com/aboutJava/communityprocess/review/jsr014/
> 
> Remi


=====
________________________________________
Thierry Janaudy (Independent consultant)
+44 77 52 14 3001
[cv]            http://www.janaudy.com/
[company]       http://www.jyperion.com/
[search engine] http://pharos.inria.fr/Java/

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

Date sent:      	Thu, 10 May 2001 17:24:44 +0200
From:           	Remi Forax <forax@univ-mlv.fr>
To:             	java@u-strasbg.fr
Subject:        	Re: Template en Java
Send reply to:  	java@u-strasbg.fr

Thierry Janaudy wrote:
> 
> Puis-je demander ton analyse de ce JSR?
> Surtout ce que tu consideres comme etant "moins bon"
> et pourquoi.
> 
> (Vu que tu connais tres bien le domaine, je desirerais
> eclairer ma lanterne)

tres bien, j'irais pas jusque la, enfin bon, voila ce que
j'en pense :

En fait, le mot d'ordre chez SUN est compatibilite avec
l'existant, enfin, je trouve ca bien tant que ca vide pas
le concept de son sens, ce qui est a mon avis le cas, ici.

A propos des templates :

 1) les templates de Java marche que pour les types objets,
    pas de type primitif.

    Donc le Vector<int> c'est rate :(

 2) les parametres des templates sont typés, ca c'est cool,
    par rapport au C++, grosso-modo, les problemes sont
    detectés lors de la compil et pas lors de l'edition de lien
    (cette etape est effectuer lors de l'execution en Java)

 3) Compatibilite chez SUN veut dire qu'il n'y a pas de modif
    de la machine virtuelle.
    L'implementation correspond à un patch au niveau
    compilo, en fait, en considerer un Vector<String> comme
    un Vector normal et le compilo rajoute les casts qu'il fallait
    avant ecrire a la main. Donc utiliser ou non un template
    ne changera pas la vitesse d'execution :(

A propos de la covariance du type de retour

    Comme Java, ne permet pas d'avoir de covariance sur le
    type de retour en cas de redefinition
    et que l'on en a besoin lorsqu'on herite d'un template.

    class A {
      A clone() { ... }
    }

    class B extends A {
      B clone() { ... }
    }

    On utilise encore un patch au niveau du compilo pour
    faire semblant, on rajoute une methode intermediaire.

    class B extends A {
      B clone/* v1 */() { ... }
      // le compilo rajoute la methode ci dessous
      A clone/* v2 */() { return clone/* v1 */(); }
    }

    heu, ici, ca compile pas normalement, mais une JVM sera
    executer le code correspondant.

 Bref, comme pour les inner-classes, l'idee est d'avoir un compilo
 qui genere plein de trucs pour que ca marche avec des anciennes
 JVM.

 Donc je suis contre, principalement parce que je pense que
 l'on pourrait patcher de facon legere la JVM, dans le
 but d'obtenir des vrais templates, qui marche avec les types
 primitifs et qui evite de faire plein de casts.

 Enfin, j'ose esperer qu'il va y avoir un mouvement en
 deux phases :
   Maintenant, i.e JDK1.4 ou JDK1.5 :
     patch du compilo pour introduire les templates.
   Dans les JDKs suivants :
     patch de la JVM pour avoir des performances raisonnables.

 Enfin, pour l'instant, il n'y a qu'une phase, c'est bien, mais
 c'est pas top.

> 
> Merci
> 
> Thierry

de rien

Remi

From:           	"Cedric Beust" <cedric@beust.com>
To:             	<java@u-strasbg.fr>
Subject:        	RE: Template en Java
Date sent:      	Thu, 10 May 2001 08:28:55 -0700
Send reply to:  	java@u-strasbg.fr

> From: Remi Forax [mailto:forax@univ-mlv.fr]

> La specif de Sun sur les templates est sortie,
> ya du bon et du moins bon :)

Oui.  J'espere que cette spec ne verra jamais le jour.  Rien a voir avec
cette proposition particuliere, c'est juste que je ne vois pas ce que Java
aurait a gagner avec des templates.

Et:  oui, cette remarque vient d'un fan de C++ :-)

--
Cedric

From:           	Gilli Julien <darktigrou@bigfoot.com>
To:             	java@u-strasbg.fr
Subject:        	Re: Template en Java
Date sent:      	Thu, 10 May 2001 20:36:17 +0200
Send reply to:  	java@u-strasbg.fr

On Thursday 10 May 2001 17:24, Remi Forax wrote:
> Thierry Janaudy wrote:
>     l'edition de lien
>     (cette etape est effectuer lors de l'execution en Java)

L'édition de liens n'est elle pas faite aussi à l'exécution pour des
librairies partagées en C, C++, ou tout autre langage compilé ? Corrigez
moi si je me trompe :-). Peut-être aussi ai-je mal interprété ta phrase,
en croyant que tu voulais dire "il n'y a qu'en Java que l'édition de liens
se fait à l'exécution" ?

A bientôt.

Julien GIlli. 


-- 
darktigrou@bigfoot.com
http://www.darktigrou.free.fr/                                     

Date sent:      	Thu, 10 May 2001 23:02:41 +0200
From:           	Nicolas Hognon <nicolash@virtools.com>
Organization:   	Virtools
To:             	java@u-strasbg.fr
Subject:        	[HS] Re: Template en Java
Send reply to:  	java@u-strasbg.fr


> L'édition de liens n'est elle pas faite aussi à l'exécution pour des
> librairies partagées en C, C++, ou tout autre langage compilé ? Corrigez
> moi si je me trompe :-). Peut-être aussi ai-je mal interprété ta phrase,
> en croyant que tu voulais dire "il n'y a qu'en Java que l'édition de
> liens se fait à l'exécution" ?
> 

heuuu
c'est un truc dont je pensais etre sur mais tu me mets le doute :))
l'edition de liens en C/C++ est fait a la compilation
d'abord ton compilo cree les objets associes a tes fichiers
puis il y a une edition de liens pour creer ta librairie
statique/dynamique ou ton executable.

ce qui est fait a l'execution c'est le fait de rechercher
les librairies dynamique.

enfin il me semble

> A bientôt.
> 
> Julien GIlli. 

From:           	"Gilli Julien" <darktigrou@bigfoot.com>
To:             	<java@u-strasbg.fr>
Subject:        	Re: [HS] Re: Template en Java
Date sent:      	Fri, 11 May 2001 09:06:45 +0200
Send reply to:  	java@u-strasbg.fr

> L'édition de liens n'est elle pas faite aussi à l'exécution pour des
> librairies partagées en C, C++, ou tout autre langage compilé ? Corrigez
> moi si je me trompe :-). Peut-être aussi ai-je mal interprété ta phrase,
> en croyant que tu voulais dire "il n'y a qu'en Java que l'édition de
> liens se fait à l'exécution" ?
>

>heuuu
>c'est un truc dont je pensais etre sur mais tu me mets le doute :))
>l'edition de liens en C/C++ est fait a la compilation
>d'abord ton compilo cree les objets associes a tes fichiers
>puis il y a une edition de liens pour creer ta librairie
>statique/dynamique ou ton executable.
>
>ce qui est fait a l'execution c'est le fait de rechercher
>les librairies dynamique.

Le document suivant : http://www.suse.de/~bastian/Export/linking.txt ne
semble pas dire la même chose, c'est ce qui me fait douter aussi. Pour
info, il traite de la raison de la lenteur du lancement des applications
de KDE. Apparemment, il est dit, à la section 2 :

"The task of the runtime linker is to link an application to the shared
libraries it needs. There are several steps involved in this process.
These steps involve:

1) Finding the shared libraries that are needed
2) Loading the shared libraries into the address space of the process. 3)
Relocating addresses in the library to reflect the location in the address
space the library was loaded to. 4) Resolving undefined symbols in a
library and/or the executable by searching for these symbols in the other
libraries."

Donc effectivement la majeure partie du travail semble être de la
recherche et du chargement de librairie, mais l'étape 3 effectue bien la
traduction d'adresses à l'exécution.

 A bientôt.

Julien GIlli.

From:           	"Cedric Beust" <cedric@beust.com>
To:             	<java@u-strasbg.fr>
Subject:        	RE: Template en Java
Date sent:      	Fri, 11 May 2001 00:11:26 -0700
Send reply to:  	java@u-strasbg.fr

> From: Gilli Julien [mailto:darktigrou@bigfoot.com]

> L'édition de liens n'est elle pas faite aussi à l'exécution pour des
> librairies partagées en C, C++, ou tout autre langage compilé ? Corrigez
> moi si je me trompe :-). Peut-être aussi ai-je mal interprété ta phrase,
> en croyant que tu voulais dire "il n'y a qu'en Java que l'édition de
> liens se fait à l'exécution" ?

Je pense qu'il y a confusion sur les termes.

L'edition de lien (link en anglais) est l'operation qui consiste a
parcourir les fichiers objets, reperer les symboles manquants et aller les
chercher dans les bibliotheques.  Quand elles sont statiques, cette
resolution est faite avant la production de l'executable.  Quand elles
sont dynamiques, cette phase est repoussee a l'execution.

Il n'y a donc pas qu'en Java que l'edition de liens se fait a l'execution,
C et C++ font ca aussi quand ils utilisent des bibliotheques dynamiques.

La resolution des templates est une operation qui n'a rien a voir avec ca:
aucun symbole a aller chercher mais beaucoup de code a generer en fonction
des instantiations demandees.  Apres ca, il y a aussi les differentes
strategies pour gerer ces bouts de codes generes, mais c'est un peu
hors-sujet alors j'en reste la.

--
Cedric

From:           	"Herve AGNOUX" <hagnoux@mail.club-internet.fr>
To:             	java@u-strasbg.fr
Date sent:      	Fri, 11 May 2001 10:26:45 +0200
Subject:        	RE: Template en Java
Priority:       	normal
Send reply to:  	java@u-strasbg.fr

Le 10 May 01, Cedric Beust a écrit :

> 
> Oui.  J'espere que cette spec ne verra jamais le jour.  Rien a voir avec
> cette proposition particuliere, c'est juste que je ne vois pas ce que
> Java aurait a gagner avec des templates.
> 

Je suis assez d'accord. Il me semble qu'il vaudrait mieux que le 
langage évolue de façon à se rapprocher des us et coutumes du 
génie logiciel, comme les liens entre objets, ou même les 
"template" au sens de modèle de programmation, et non de 
modèle d'objet, au lieu de s'enquiquiner avec des trucs dont on se 
passe très bien.



--
Hervé AGNOUX  hagnoux@mail.club-internet.fr
Faites vos sites avec des formulaires électroniques :
http://www.diaam.com

Date sent:      	Fri, 11 May 2001 10:47:13 +0200
From:           	Remi Forax <forax@univ-mlv.fr>
To:             	java@u-strasbg.fr
Subject:        	Re: Template en Java
Send reply to:  	java@u-strasbg.fr

Cedric Beust wrote:
> 
> > From: Gilli Julien [mailto:darktigrou@bigfoot.com]
> 
> > L'édition de liens n'est elle pas faite aussi à l'exécution pour des
> > librairies partagées en C, C++, ou tout autre langage compilé ?
> > Corrigez moi si je me trompe :-). Peut-être aussi ai-je mal interprété
> > ta phrase, en croyant que tu voulais dire "il n'y a qu'en Java que
> > l'édition de liens se fait à l'exécution" ?
> 
> Je pense qu'il y a confusion sur les termes.
> 
> L'edition de lien (link en anglais) est l'operation qui consiste a
> parcourir les fichiers objets, reperer les symboles manquants et aller
> les chercher dans les bibliotheques.  Quand elles sont statiques, cette
> resolution est faite avant la production de l'executable.  Quand elles
> sont dynamiques, cette phase est repoussee a l'execution.
> 
> Il n'y a donc pas qu'en Java que l'edition de liens se fait a
> l'execution, C et C++ font ca aussi quand ils utilisent des
> bibliotheques dynamiques.

Complement d'accord, en fait, ici, le terme edition de lien est mal
choisi,
j'aurais peut-être du parler de reification quoique suivant les
personnes
ce concept a des sens differents.

Ce que je voulais dire, c'est qu'une classe Java ne contient pas
dans sa forme binaire toutes les méthodes et attributs utilisables
sur cette classe mais seulement les membres déclaréees dans cette
classe.
Lors du chargement de la classe, il y a une étape qui va chercher dans les
super-classes tous les membres d'une classe. Entre autre, cette étape
calcul les offsets pour chacun des attributs, remplace les appels statique
par un branchement direct, etc... 

C'est de cette etape dont je parlais. 

> 
> La resolution des templates est une operation qui n'a rien a voir avec
> ca: aucun symbole a aller chercher mais beaucoup de code a generer en
> fonction des instantiations demandees.  Apres ca, il y a aussi les
> differentes strategies pour gerer ces bouts de codes generes, mais c'est
> un peu hors-sujet alors j'en reste la.
> 
> --
> Cedric

Remi

From:           	"Gilli Julien" <darktigrou@bigfoot.com>
To:             	<java@u-strasbg.fr>
Subject:        	Re: [HS] Re: Template en Java
Date sent:      	Fri, 11 May 2001 09:06:45 +0200
Send reply to:  	java@u-strasbg.fr

> L'édition de liens n'est elle pas faite aussi à l'exécution pour des
> librairies partagées en C, C++, ou tout autre langage compilé ? Corrigez
> moi si je me trompe :-). Peut-être aussi ai-je mal interprété ta phrase,
> en croyant que tu voulais dire "il n'y a qu'en Java que l'édition de
> liens se fait à l'exécution" ?
>

>heuuu
>c'est un truc dont je pensais etre sur mais tu me mets le doute :))
>l'edition de liens en C/C++ est fait a la compilation
>d'abord ton compilo cree les objets associes a tes fichiers
>puis il y a une edition de liens pour creer ta librairie
>statique/dynamique ou ton executable.
>
>ce qui est fait a l'execution c'est le fait de rechercher
>les librairies dynamique.

Le document suivant : http://www.suse.de/~bastian/Export/linking.txt ne
semble pas dire la même chose, c'est ce qui me fait douter aussi. Pour
info, il traite de la raison de la lenteur du lancement des applications
de KDE. Apparemment, il est dit, à la section 2 :

"The task of the runtime linker is to link an application to the shared
libraries it needs. There are several steps involved in this process.
These steps involve:

1) Finding the shared libraries that are needed
2) Loading the shared libraries into the address space of the process. 3)
Relocating addresses in the library to reflect the location in the address
space the library was loaded to. 4) Resolving undefined symbols in a
library and/or the executable by searching for these symbols in the other
libraries."

Donc effectivement la majeure partie du travail semble être de la
recherche et du chargement de librairie, mais l'étape 3 effectue bien la
traduction d'adresses à l'exécution.

 A bientôt.

Julien GIlli.