Discussion :

[balistick]

Bonjour,

L'objectif des langages managés, et de java en particulier, est de permettre une grande portabilité de l'application grâce à l'utilisation de bytecode, compilé à la volée par une machine virtuelle. Lorsqu'une JVM est installée sur un système, celui ne va plus changé. Pourquoi dans ces conditions ne compile t-on pas l'ensemble des librairies java une bonne fois pour toute en code natif sur le système ? Pourquoi ne fait-on pas pareil avec l'installation d'un programme java, c'est à dire qu'on compile l'ensemble du code en code natif au moment de l'installation sur un système donné ?

Merci pour vos réponses,

PS : si ce message se trouve dans la mauvaise catégorie merci de le déplacer.

[supersnail]

Bonjour,
effectivement ta question est intéressante,mais:

Le langage java est conçu pour justement être portable,et donc on doit pouvoir transférer un programme java d'un ordinateur à un autre sans problème de compatibilité.

Or,qui dit compilation dit dépendant de l'O.S,et ce n'est pas le but de java...

De toute façon,les APIs java reposent sur du code natif pour l'affichage,etc...

[T`lash]

Si je ne m'abuse, la JVM compile automatiquement une partie du bytecode lors de la première exécution pour que les suivantes soient plus rapides.

[tchize_]

tu t'abuse Compilation uniquement en mémoire vive.

La compilation JIT est complexe. Tout ton code java n'est pas compilé en natif. La jvm garde une trace des bouts de codes les plus réutilisés de ton programme, et au dela d'un certaine limite d'utilisation, estime qu'il est rentable de convertir cette méthode ou bout de code en code natif. On ne le fait pas sur fichier parce que ca n'a jamais été jugé utile. Les parties sur lequelles il y a gain notable sont déjà compilées à la volée. De plus ce code natif est visiblement très dépendant de l'état de la jvm, d'une exécution à l'autre il pourrait etre différent.
Enfin, mettre un fichier natif serait spécifique à l'OS (on pourrait toujours argumenter qu'il ne changera pas, mais ce n'est pas vrai dans tous les cas!) mais aussi spécifique à la version de la jvm utilisée -> bonjour les dégat si tu change de jvm sans réinstaller ton programme.

[T`lash]

Donc, je m'abuse, ou alors j'ai abusé...

N'empêche que Java est souvent considéré à tord comme un langage menant à des applications très lentes à l'exécution. D'accord, en tant que langage semi-compilé il est plus lent que du code natif, mais c'est négligeable par rapport aux nombreuses erreurs de conception des IHMs.
Si on jongle bien avec les Threads et qu'on n'utilise pas des méthodes synchronisées lorsque c'est totalement inutile le gain en perfs est impressionnant.

[tchize_]

tout a fait d'accord, la perte de perfs du à l'interprété deviens minime, par rapport au gain en temps de développement et debuggage par rapport à des language comme le C++. La plus grosse différence de perfs viens de ce que les gens comparent des choses non comparable, comme les méthode object C++ qui sont plsu rapide car finale par défaut alors que les méthode java sont surchargeables par défaut. Et personellement, c'est plus propre et rapide de programmer dans le deuxième cas

[hibour]

... La plus grosse différence de perfs viens de ce que les gens comparent des choses non comparable, comme les méthode object C++ qui sont plsu rapide car finale par défaut alors que les méthode java sont surchargeables par défaut. Et personellement, c'est plus propre et rapide de programmer dans le deuxième cas

Je ne suis pas d'accord avec toi, La preuve C# reprend la même philosophie de C++ càd une méthode n'est surchargeable que si on le veut bien

[tchize_]

ben moi je trouve normal que ce ne soit pas a l'objet parent de savoir si oui ou non il sera étendu et dans quel mesure, c'est à l'objet fils de savoir ce qu'il veux ou pas étendre. Combien de fois je me suis pas retrouvé à surcharger des objets d'une api pour leur donner des comportements supplémentaire, sans pour autant que l'api ai pu avoir la moindre idée que ce serait nécessaire (après tout c'est mon code qui a besoin de cette surcharge, pas l'api). Décider ca dans le parent, c'est bon quand quand t'as la maitrise de toute la chaine et que tu peux aller quand tu veux changer les code du parent pour lui faire passer des méthodes en virtual.

Et combien de fois j'ai pas ralé sur certaines api java parce qu'un *%£$£ avait la magnifique idée de créer des méthode final là ou j'avais besoin de surcharger!

Le fait que c# reprenne la philosohpie de c++ n'en fait pas nécessairement une bonne pratique. Ca restreint, au contraire, l'aspect objet du language, puisque la surcharge et l'héritage font partie des bases d'un language objet.

[hibour]

Au fait surchargeable veut dire redéfinissable Quand on crée un code réutilisable alors qui mieux que le concepteur lui même sait le mieux comment réutiliser son code. redéfinir une méthode malencontreusement peut avoir des effet néfaste si la classe de base n'a pas prévu de gérer ça! Je pense qu'on a deux points de vues différents de l'OO, la multitude des langages OO le prouve

[tchize_]

je suis toujours pas d'accord, quand tu crée un api, tu ne sais pas nécessairement comment elle va etre utilisée. Et je préfère avoir une api qui me laisse surcharger ses méthodes sans poser de question qu'un autre qui ne me laisse rien faire parce que le codeur y a jamais pensé. Extrèmement rare son les cas ou je suis tombé sur du code ou un surcharge avait un effet de bord ennuyeux. Dans 99% des cas, l'effet de bord était voulu par celui qui étant mais non prévu par le codeur de l'api.

J'ai déjà vu pas mal de code type C++ (en elcture uniquement) j'ai rarement vu des codeurs de ce genre de classe qui envisagerais qu'on pourrait, ne serait-ce que avoir "envie" d'hériter de leur classe. Les 3/4 de leurs classes n'avaient aucune méthode virtuelle. Hors pour des design pattern comme le wrapper, il est nécessaire de pouvoir surcharger toutes les méthodes publiques et protégées.

pour moi le concepteur de la classe parent est justement, la dernière personne qui a a se soucier de savoir qu'est-ce qu'on va faire de sa classe. Il a une classe, qui répond à un ou plusieurs besoins, un comportement documenté et son boulot s'arrete là! C'est pas a lui de décider si on va hériter ou non de sa classe pour y ajouter ou non des comportement sur les méthodes existante. Quand tu crée une classe Vecteur, tu sais d'office à quoi elle va servir dans tous les cas?

[hibour]

je suis toujours pas d'accord, quand tu crée un api, tu ne sais pas nécessairement comment elle va etre utilisée. Et je préfère avoir une api qui me laisse surcharger ses méthodes sans poser de question qu'un autre qui ne me laisse rien faire parce que le codeur y a jamais pensé. Extrèmement rare son les cas ou je suis tombé sur du code ou un surcharge avait un effet de bord ennuyeux. Dans 99% des cas, l'effet de bord était voulu par celui qui étant mais non prévu par le codeur de l'api.

J'ai déjà vu pas mal de code type C++ (en elcture uniquement) j'ai rarement vu des codeurs de ce genre de classe qui envisagerais qu'on pourrait, ne serait-ce que avoir "envie" d'hériter de leur classe. Les 3/4 de leurs classes n'avaient aucune méthode virtuelle. Hors pour des design pattern comme le wrapper, il est nécessaire de pouvoir surcharger toutes les méthodes publiques et protégées.

pour moi le concepteur de la classe parent est justement, la dernière personne qui a a se soucier de savoir qu'est-ce qu'on va faire de sa classe. Il a une classe, qui répond à un ou plusieurs besoins, un comportement documenté et son boulot s'arrete là! C'est pas a lui de décider si on va hériter ou non de sa classe pour y ajouter ou non des comportement sur les méthodes existante. Quand tu crée une classe Vecteur, tu sais d'office à quoi elle va servir dans tous les cas?

Alors explique moi pourquoi StringBuffer est finale ?
Quand tu crée une API tu vois vraiment les choses de loin!
Quand tu met des truc en protected tu sais très bien que tu peux redéfinir ce comportement à volenté a moins de le rendre final, enfin il y aune différence entre un programmeur qui utilise une API et celui qui l'a crée et ça c'est toute une discussion à part..

[professeur shadoko]

<détournement du sujet>
pour la facilité de la discussion est ce qu'on pourrait se mettre d'accord sur le vocabulaire? soit en gardant la terminologie de la norme:
- surcharge (overloading) devrait être reservé en Java au fait d'avoir une même méthode avec des arguments différents
- spécialisation ou autre trad. (overriding) pour la redéfinition d'une méthode dans une sous-classe.

(c'était la minute "être pédant ne coute pas cher")
</détournement>

pour revenir au sujet: les optimisations à chaud de JVM comme "hotSpot" sont capables de faire des optimisations qu'une simple compilation statique ne sait pas faire.
On a donc des curiosités comme des codes de calcul très optimum .... mais aussi des applications qui se trainent.
Là ça m'interpelle: pourquoi tant d'applications Java se trainent? vos experiences? merci

[hibour]

Pour revenir aussi à la discussion y a le compilateur gcc java qui permet de compiler directement en code natif. mais les performances ne sont pas toujours meilleurs forcément (j'ai déjà vu un comparatif)..

[thelvin]

Là ça m'interpelle: pourquoi tant d'applications Java se trainent? vos experiences? merci

Parce que Java est un langage qui fut, et est encore dans une moindre mesure, à la mode, très enseigné, assez facile à mettre en œuvre et déployer si on le compare à ses anciens "supposés concurrents" comme C ou C++.

Il y a donc beaucoup de programmes qui se font en Java par des gens qui ne comprennent pas que la rapidité d'un programme dépend de comment il est programmé et pas seulement de son effet final.

Ce genre de choses se voient moins avec d'autres langages pour une collection de raisons :
- Le déploiement de ces autres langages est moins pratique, et ils sont donc moins adoptés, bref on ne les voit pas.
- La barre d'entrée de ces langages est haute, et avant de réussir à produire un programme bien déployable, on a généralement rejoint une équipe qui contient des gens qui s'y connaissent en algorithmique.
- Soyons honnêtes : pour moins stables, propres ou puissantes que soient les APIs graphiques proposées par ces autres langages, au moins elles permettent de faire rapidement et simplement une UI qui va vite. Franchement, SWT ça va bien, mais Swing par contre oblige à se casser beaucoup les dents pour être à peu près efficace.

[tchize_]

Alors explique moi pourquoi StringBuffer est finale ?

Parce qu'elle est au centre de la manipulation des string en java (dès que tu fais un + entre strings) et qu'elle se doit donc d'être la plus rapide possible. On en reviens à mon message d'origine, comparer ce qui est comparable coté perfs. Si tu met un algo en C++ et que tu veux le comparer à un algo en java, met toutes tes méthodes et tes classes java final, puisque c'est ce que fait c++, ou alors met tout ton code c++ en virtual. J'ai jamais dit que final ne servait à rien, juste que j'estime anormal en language objet de considérer que "par défaut" une classe ne peut pas être étendue et un méthode ne peut pas être overridée (c'est bon j'ai le bon terme?). On peut pas prévoir comment l'api sera utilisée, alors restreindre son utilisation doit être fait pour des raison bien précie. En C++ c'est restreint juste parce que le programmeur a pas pendé à mettre virtual devant le nom de la méthode, et en tout logique il devrait le faire devant la plupart de ses méthodes...

[hibour]

Je donne des cas d'API éprouvé et pas de code d'une personne lambda!
Les classes STL C++ (équivalent de java.lang.*, java.util.*) ne sont pas héritable correctement (fonctions non virtual) car les auteurs de la STL ont préféré la performance à la réutilisabilité du code.. Les gourou de la POO préfère l'encapsulation à l'héritage. Il faut choisir son camps dès le départ car malheureusement on ne peut pas avoir tout (Généricité VS Performance)

[adiGuba]

Salut,


Il n'y a rien de mal à ce que le concepteur d'une classe puisse interdire de redéfinir ses méthodes voir même d'hériter tout court.

La seule différence qu'il y a entre Java et C++/C# sur ce point là, c'est que le choix "par défaut" est différent... Comme tu le dis c'est un choix qui est fait.


Concernant les performances des méthodes virtuelles, la JVM peut optimiser cela selon le contexte d'exécution justement. En clair une méthode virtuelle sera considéré comme non-virtuelle tant qu'aucune classe fille ne la redéfinissant n'a pas été chargée...

a++