Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1970 connectés 

  FORUM HardWare.fr
  Programmation
  Java

  JVM comment ça marche en fait...

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

JVM comment ça marche en fait...

n°1666567
twif
Posté le 05-01-2008 à 21:58:15  profilanswer
 

Bonjour a tous !
Je suis tombé sur un problème au boulot...
En gros si quelqu'un pourrait m'expliquer comment fonctionne la JVM, chargement des classes. etc..  pour ma culture perso, ce serait gentil :)
 
J'ai 2 classes, une mere et une fille avec leur prope bloc static, et une autre pour le Main
exemple

Code :
  1. public class ClassMere {
  2. static String var = "aa";
  3. static{
  4.  System.out.println("bloc static mere " + var);
  5. }
  6. public static void methode(){
  7.  System.out.println("passage dans methode" );
  8. }
  9. }
  10. public class ClassFille extends ClassMere {
  11. static String var = "aa";
  12. static{
  13.  System.out.println("bloc static fille " + var);
  14. }
  15. }
  16. public class Main {
  17. public static void main(String[] args){
  18.  ClassFille.methode();
  19. }
  20. }


 
Deja a votre avis qu'affiche ce bout de code ? (sans l'executer ;) ) et pourquoi ce resultat ?
 
Merci d'avance :)

mood
Publicité
Posté le 05-01-2008 à 21:58:15  profilanswer
 

n°1666904
Kragorn
Posté le 06-01-2008 à 22:13:49  profilanswer
 

bloc static mere aa
 
bloc static fille aa
 
passage methode
 
La JVM va charger main et puis elle va se rendre compte qu'elle a besoin de ClasseFille mais en même temps de ClasseMere, alors elle va charger ClasseMere dans classe mere elle va utiliser le bloc static d'initialisation au moment du chargement de celle-ci et imprimer le code, ensuite la même chose pour ClasseFille et ensuite executer la methode.
 
Je crois que c'est ca ^^

n°1666905
twif
Posté le 06-01-2008 à 22:34:40  profilanswer
 

ah enfin quelqu'un se jette a l'eau ^^
en théorie j'aurais répondu la même chose que toi, avec la meme logique que tu as apportée dans ta réponse, execute le code juste pour voir tu verras le resultat...

n°1666914
Kragorn
Posté le 06-01-2008 à 22:56:15  profilanswer
 

Je sais pourquoi, lors de la compilation, le compilateur fait le lien entre la méthode statique et de ce fait se rend compte qu'il n'a pas besoin de ClasseFille et remplace donc ton code ClasseFille.methode() par ClasseMere.methode() tout simplement.
 
D'où l'importance de bien faire attention au mot 'static', tout cela est fait au moment de la compilation. Si on avait enlevé le mot clé static, il y aurait bien eu chargement de ClassFille (moyennant quelques adaptations). Bref, sale piège le static :p


Message édité par Kragorn le 06-01-2008 à 23:08:26
n°1667362
twif
Posté le 07-01-2008 à 20:25:21  profilanswer
 

j'trouve ça dingue comme comportement, tant qu'une méthode static (de la classe fille) ou que l'objet n'est pas instancié, le bloc static n'est pas appelé donc... pourquoi ou pourquoi pas.. !

n°1671240
BifaceMcLe​OD
The HighGlandeur
Posté le 15-01-2008 à 00:00:03  profilanswer
 

Une méthode statique ne peut pas être redéfinie dans une sous-classe. Autrement dit (même si cela peut faire bizarre), les méthodes statiques ne sont pas héritées, même si elles sont accessibles dans les sous-classes.
 
Donc la seule méthode "methode()" qui est définie ici est celle de "ClassMere", et "ClassFille" n'a pas de méthode "methode()". Ce qui explique le comportement du code ci-dessus.
 
Et si on définissait une méthode "methode()" dans "ClassFille", celle-ci serait une autre méthode que celle de "ClassMere" (qui masquerait cette dernière), et non une redéfinition de la même méthode (comme c'est le cas pour les méthodes non statiques).
Meilleure preuve : on ne pourrait pas écrire "super.methode()" dans le code de "ClassFille.methode()", mais pas contre, on pourrait y écrire sans souci "ClassMere.methode()" (essayez ça dans une méthode non statique, vous vous retrouverez avec un dépassement de pile par appel récursif sans fin : ce qui prouve que c'est bien la même méthode dans "ClassMere" et "ClassFille" ).
 

n°1676443
twif
Posté le 24-01-2008 à 20:22:54  profilanswer
 

J'comprends bien la théorie, mais c'est assez étrange que l'appel à "methode()"  via la classe fille (ClasseFille.methode dans le main) ne charge pas la classe fille dans la JVM, pour preuve le code dans le bloc statique de fille n'est pas exécuter, (system.out "bloc static fille aa " ).  Comme si la JVM sait par avance que methode() n'est que dans ClassMere et que ClassFille en hérite donc la JVM fait le raccourci d'elle meme, donc pas beson de charger ClassFille, et quand on a des variables qu'on pense etre initialisées dans le bloc statique de la fille on se retrouve avec un joli nullPonterException, j'trouve que c'est pas très instinctif :p
C'est quand meme un exemple tordu que j'ai donné, quand on est tombé dessus on a remanié le code ^^

n°1680555
verdy_p
Posté le 01-02-2008 à 16:12:25  profilanswer
 

Tout écrire en statique en Java c'est comme programmer du vieux BASIC ou du Fortran d'il y a 20 ans. Où est la programmation objet? Nulle-part c'est du traitement procédural. twif, il va falloir te faire à l'idée qu'on ne programme plus aujourd'hui comme ça. Le mot clé "static" est même interdit dans pas mal de projets (ou dans les langages fonctionnels purs) à cause des risques qu'ils posent (sécurité...) et la difficulté de faire évoluer le logiciel et le maintenir. Même en Javascript on connait les problèmes que ça pose de tout mettre dans des variables du même objet "document" dans une page: les relations entre scripts sont trop compliquées à maintenir car cela augmente fortement les dépendances et incompatibilités. Le principe de l'objet est d'isoler le comportement en rendant les objets le plus indépendants possible et donc plus facilement réutilisables.


Message édité par verdy_p le 01-02-2008 à 16:15:44
n°1681133
BifaceMcLe​OD
The HighGlandeur
Posté le 03-02-2008 à 19:20:36  profilanswer
 

twif a écrit :

[...]Comme si la JVM sait par avance que methode() n'est que dans ClassMere et que ClassFille en hérite donc la JVM fait le raccourci d'elle meme, donc [...]


Encore une fois, tu fais une erreur de raisonnement : ClassFille ne hérite pas de methode(). La méthode appartient à ClassMere et seulement à ClassMere. Le fait de pouvoir écrire ClassFille.methode() est une facilité d'écriture, mais cela n'indique pas un héritage de la méthode, seulement une différence de visibilité de methode() par rapport à une classe lambda qui n'hériterait pas de ClassMere.

n°1694831
twif
Posté le 29-02-2008 à 00:53:17  profilanswer
 

BifaceMcLeOD a écrit :


Encore une fois,...


 
Ok j'ai bien compris la différence maintenant. Merci de ta réponse :) Cette facilité d'écriture prête quand même à confusion. bref j'vais pas revenir dessus.
 
Par contre verdy_p faut pas non plus me prendre pour un âne,  penser en java c'est mon métier et personne ne m'a encore reproché mes façons de faire dans mon boulot, même si j'ai pas x années d'expériences encore derrière moi.  
Comme tu le dis "faire évoluer le logiciel et le maintenir".. bah oui souvent on tombe sur du code qu'on a pas écrit, donc faut le lire, le comprendre, le débuguer, le remanier etc.  
 
ça arrive de ne pas savoir ou comprendre, encore heureux! sinon j'm'ennuierais à mourir dans mon boulot  
Quant a interdire totalement le mot clef static dans un projet c'est une idée de "génie" ça.

mood
Publicité
Posté le 29-02-2008 à 00:53:17  profilanswer
 

n°1694863
el muchach​o
Comfortably Numb
Posté le 29-02-2008 à 04:39:18  profilanswer
 

N'empêche qu'il a raison. Strictement aucun intérêt de mettre tout ce code en static.

n°1695459
twif
Posté le 01-03-2008 à 00:05:45  profilanswer
 

Aucun intérêt, oui tu as peut être raison, le code d"origine est quand même plus compliqué que l'exemple que j'ai donné :)  
mais quand tu tombes dessus et que tu dois travailler dessus pour telles ou telles raisons faut quand même essayer de comprendre pourquoi telle personne l'a fait comme ça (de plus quand aucun commentaire n'est présent :| ), pourquoi cela a été fait comme ça, dans quel but.. Et souvent cette personne n'est plus là pour t'expliquer ..!  
A "nous" de savoir remanier le truc pour que ce soit plus clair pour tout le monde quand faut faire une évolution ou une correction de bug.
 
bref j'pense que beaucoup de gens ici se sont déjà poser des questions en lisant du code qui ne nous appartient pas, parfois a avoir des crises, de rire, cardiaques, de nerfs, d'angoisses :) mais bon le temps qui nous est donné pour ces taches est souvent limité... va expliquer a ton chef de projet que cette partie de code c'est de la merde qu'il y a x jours / homme pour la recoder, alors que celle ci marche telle qu'elle! ça passe moyen. j'exagère un poil, j'ai la chance d'avoir un peu de ce temps donc quand j'vois des trucs aberrants je fais en sorte que ça se passe mieux pour la prochaine personne qui travaillera dessus.. voila voila


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  Java

  JVM comment ça marche en fait...

 

Sujets relatifs
XMLHttpRequest qui marche en local, mais pas en ligne...[VB.NET 05] - Appli console marche sous XP, pas sous Vista ?
[Résolu][StringTokenizer - Urgent] Comment ça marche ?[Résolu][Html/CSS]"a:active" ne marche qu'à l'instant du clic..
Ma caltoche ne marche pas !Menu JS qui ne marche pas avec IE
CSS: pourquoi ça marche pas ?swf en boucle | loop="false" ne marche pas
[XSLT]Récursivitésoucis pour remettre en marche site web
Plus de sujets relatifs à : JVM comment ça marche en fait...


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR