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

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

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 ^^

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...

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

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.. !

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" ).
 

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
C'est quand meme un exemple tordu que j'ai donné, quand on est tombé dessus on a remanié le code ^^

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.

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.

 
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.

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

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