Enlever la méthode main

**Alain Defrance** · 05/10/2009, 21h57

Bonjour,

J'ai vu sur le net une implémentation un peu spéciale, qui marche sans le moindre doute, mais je trouve ça affreux.

Je voulais avoir vos avis, la voici :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
class Sample {
    static {
        System.out.println("Hello Word !!");
    }
}

source : http://browntips.com/trick-java-program-with-out-main/

**adiGuba** · 05/10/2009, 22h01

Salut,

Envoyé par Alain Defrance

mais je trouve ça affreux.

Pas mieux !

Envoyé par Alain Defrance

qui marche sans le moindre doute,

Cela remonte quand même une exception (main() not found)

a++

**Alain Defrance** · 05/10/2009, 22h06

Envoyé par adiGuba

Cela remonte quand même une exception (main() not found)

En effet, mais c'est encore pire, ca remonte une error : Exception in thread "main" java.lang.NoSuchMethodError: main

Pour utiliser cette classe ca va être chaud, va vraiment falloir faire tous les appels dans le bloc static :p

**professeur shadoko** · 06/10/2009, 08h45

plus fumant: un jour un stagiaire m'a demandé s'il était possible de lancer une application Java autrement que par la méthode magique "main"...
C'est possible en modifiant le code C du lanceur, mais je me suis toujours demandé pourquoi il voulait faire ça ...

**Patriarch24** · 06/10/2009, 09h18

Je vois pas vraiment l'intérêt. Vraiment pas. Mais alors pas du tout.
Bref, après cette contribution du tonnerre, ...

**Alain Defrance** · 06/10/2009, 10h06

Envoyé par professeur shadoko

plus fumant: un jour un stagiaire m'a demandé s'il était possible de lancer une application Java autrement que par la méthode magique "main"...
C'est possible en modifiant le code C du lanceur, mais je me suis toujours demandé pourquoi il voulait faire ça ...

Autant créer un nouveau langage basé sur la JVM :p, ca sera encore plus simple

.

Invité · 06/10/2009, 10h45

Juste pour apporter ma pierre a l'édifice, je ne pense pas que cette manière de faire soit plus horrible qu'une autre.

Certes elle n'est pas du tout adaptée au langage Java, mais elle a l'avantage d'enlever ce vieil héritage venant de la programmation procédurale.

Pourquoi diable devons nous passer par une méthode nommée "main" pour lancer notre application ?

Une simple modification du langage pourrait nous donner quelque chose de bien plus orienté objet, et bien moins procédural.

En poussant dans les extrêmes, on pourrait aller jusqu'à dire que l'orienté objet devrait pouvoir fonctionner sans aucune méthode.

Donc encore une fois, la façon de procéder ici n'est pas appropriée, mais elle n'est pas si inesthétique pour autant.

Etant donné que ce sujet a donné lieu a une petite session débat (très légère) entre Alain et moi-même voici un argument que j'ai avancé, non pas en faveur du bloc statique, mais plutôt en défaveur du main().

Premier point, pourquoi "main", pourquoi pas quelque chose de plus souple ?
Pourquoi toute une méthode avec des arguments bien précis, une visibilité, une valeur de retours fixés ? D'ailleurs a ce compte, pourquoi une méthode ?

Il est certain qu'il y a quelques années lorsque l'on voulait convertir des développeurs C au java il était plus simple de leur proposer une méthode principale nommée main, prenant en paramètre les paramètres de l'application.

Alors quitte à faire, j'apporte une possible solution.

Pourquoi ne pas avoir au même titre qu'un bloc statique un bloc main{}.
Faire de ce fameux main un mot clef dans des cas précis. Et si ce n'est main, autre chose ?
Evidemment pour ce qui est du Java c'est beaucoup trop tard, mais l'idée est là.

Ainsi avec un main{} nous pourrions avoir un point d'entrée qui ne serait pas une méthode.

Quant aux arguments, il pourraient être disponibles depuis la classe System.
Enfin point sur le quel je n'ai que trop peu réfléchis, serait la possibilité de mettre ce bloc en dehors d'une classe.

Quoi qu'il en soit, sans défendre corps et âme cette idée de bloc static{} pour démarrer l'application, je trouve que c'est osé, et pourquoi pas, vu sous un certain angle, intéressant comme approche. Et peut-être, comme je disais plus tôt, élégant comme solution, bien qu'inadapté.

Je sens d'ici les personnes qui ne vont pas se privé de me traiter d'hérétique mais bon, main() ne m'a pas l'air d'être une solution parfaite.

**adiGuba** · 06/10/2009, 11h10

Envoyé par Makkhdyn

Pourquoi diable devons nous passer par une méthode nommée "main" pour lancer notre application ?

Et pourquoi diable utilisé un bloc static ? En quoi est-ce mieux ???

Envoyé par Makkhdyn

Donc encore une fois, la façon de procéder ici n'est pas appropriée, mais elle n'est pas si inesthétique pour autant.

Cela a un second gros défaut : le bloc static est exécuté au chargement de la classe. Du coup cela peut être exécuté involontairement en cas d'une simple utilisation de la classe...

Envoyé par Makkhdyn

Pourquoi ne pas avoir au même titre qu'un bloc statique un bloc main{}.
Faire de ce fameux main un mot clef dans des cas précis. Et si ce n'est main, autre chose ?
Evidemment pour ce qui est du Java c'est beaucoup trop tard, mais l'idée est là.

Ainsi avec un main{} nous pourrions avoir un point d'entrée qui ne serait pas une méthode.

Donc si je comprend bien on remplacerais une méthode static par une bloc static...

On y gagne quoi en fait ?

a++

Invité · 06/10/2009, 11h22

Envoyé par adiGuba

Et pourquoi diable utilisé un bloc static ? En quoi est-ce mieux ???

Attention, comme je l'ai dis, ce n'est pas tant le bloc static qui est intéressant à voir, mais plutôt le bloc "point d'entrée" remplaçant la méthode point d'entrée.

Envoyé par adiGuba

Cela a un second gros défaut : le bloc static est exécuté au chargement de la classe. Du coup cela peut être exécuté involontairement en cas d'une simple utilisation de la classe...

Encore une fois, je ne défend pas le bloc static qui est totalement inadapté. Je dis simplement que l'approche mérite le coup d'oeil.

Envoyé par adiGuba

Donc si je comprend bien on remplacerais une méthode static par une bloc static...

On y gagne quoi en fait ?

Question d'esthétique. Niveau fonctionnel c'est strictement la même chose. Niveau sémantique c'est plus logique (à mon goût).

EDIT:
Et non je ne préconise pas la solution du bloc static. Comme il a été dit judicieusement auparavant, c'est plus dangereux et cause de bugs qu'autre chose.

**Torg666** · 07/10/2009, 14h55

Envoyé par Makkhdyn

Pourquoi diable devons nous passer par une méthode nommée "main" pour lancer notre application ?

Essaie d'ouvrir le .class du .java qui contient ton main avec un editeur hexa et lit la premiere ligne... tu vas comprendre pourquoi... Après on nous dis que les developpeur n'ont pas d'humour...

**Alain Defrance** · 07/10/2009, 17h50

Envoyé par Torg666

Essaie d'ouvrir le .class du .java qui contient ton main avec un editeur hexa et lit la premiere ligne... tu vas comprendre pourquoi... Après on nous dis que les developpeur n'ont pas d'humour...

Si tu fais référence au "cafe babe", il n'y est pas que là ou il y a la class main, et je ne vois pas le rapport

**dingoth** · 08/10/2009, 09h47

Bonne chance pour jouer avec plusieurs threads en utilisant cette (hum) astuce (hum)

**Torg666** · 08/10/2009, 10h48

Envoyé par Alain Defrance

Si tu fais référence au "cafe babe", il n'y est pas que là ou il y a la class main, et je ne vois pas le rapport

Tu as tout a fait raison... je sais pas où je suis allé chercher ça tiens... melaculpa

**tchize_** · 08/10/2009, 11h34

hooo la belle crasse

alors pourquoi main()? Parce que objet ou pas objet, il faut bien un point de départ. Quand on me dit que ce n'est pas orienté objet une "méthode", je m'insurge. Les méthodes font partie du language objet. Un objet, ce sont des propriété et des méthodes. On pourrait effectivement arguer du fait que la méthode soit statique. Une interface "Program" a implémenter avec des méthodes précises (setArguments(String[] argv), run() ) aurait peut-être été plus objet. Mais ce n'est pas ce qui a été choisi et, en informatique comme dans tous le reste d'ailleurs, l'héritage historique, ca a un poids énorme (après tout, la taille des réservoirs de la navette spatiale est fonction de la largeur de l'arrière train d'un cheval moyen de l'époque romaine....).

PS: si tu veux pousser le vice de pas utiliser main, tu peux coder tout ton programme dans un Agent.

....
Ou implémenter une applet :p

Invité · 08/10/2009, 14h46

Envoyé par tchize_

hooo la belle crasse

alors pourquoi main()? Parce que objet ou pas objet, il faut bien un point de départ. Quand on me dit que ce n'est pas orienté objet une "méthode", je m'insurge. Les méthodes font partie du language objet. Un objet, ce sont des propriété et des méthodes. On pourrait effectivement arguer du fait que la méthode soit statique. Une interface "Program" a implémenter avec des méthodes précises (setArguments(String[] argv), run() ) aurait peut-être été plus objet. Mais ce n'est pas ce qui a été choisi et, en informatique comme dans tous le reste d'ailleurs, l'héritage historique, ca a un poids énorme (après tout, la taille des réservoirs de la navette spatiale est fonction de la largeur de l'arrière train d'un cheval moyen de l'époque romaine....).

PS: si tu veux pousser le vice de pas utiliser main, tu peux coder tout ton programme dans un Agent.

....
Ou implémenter une applet :p

Effectivement j'aurais du plus détailler mon désagrément concernant la méthode _statique_ main.

Mais comme tu(vous) le dis(tes), c'est ce qui a été choisi. Je ne questionne pas le fonctionnement actuel, je ne propose même pas de changer quoi que ce soit dans Java pour ce point. Je dis juste qu'une méthode main "magique" bien que venant de l'héritage et de l'histoire de la programmation, n'est pas forcement ce qui est plus adapté.

Cependant les choses étant ce qu'elles sont, essayer de contourner le fonctionnement normal ne mènera pas bien loin.

Donc encore une fois:
Oui le bloc static est moche, et non ce n'est pas une solution envisageable. Le seul point que je tentais de soulever ici était le fait qu'un bloc d'initialisation de l'application pourrait-être plus adapté qu'une méthode d'initialisation.

**dingoth** · 08/10/2009, 16h52

Dans ce cas, on conceptualise un peu et on crée une classe point d'entrée, avec une méthode (statique, soit) point d'entrée.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
public class Main {
  public static void main (String... args) {
    MyApplication application = new MyApplication();
    application.start();
  }
}

Enfin, ne dit-on pas qu'"avec des 'si', on met Paris en bouteille" ?

Et puis, il y aura toujours un main quelque part... Ne fut-ce que celui écrit en C pour démarrer la JVM.

**tchize_** · 08/10/2009, 17h01

avantage de la méthode statique, on peux avoir plusieurs main. J'ai vu ce concept utilisé parfois pour des tests unitaire. Certaines classes possédaient un main en plus de leurs méthode normale, avant de s'auto tester

(enfin je préfère quand meme avoir des tests a part)

**Alain Defrance** · 08/10/2009, 17h07

Envoyé par tchize_

J'ai vu ce concept utilisé parfois pour des tests unitaire. Certaines classes possédaient un main en plus de leurs méthode normale, avant de s'auto tester

(enfin je préfère quand meme avoir des tests a part)

Sur le projet que j'ai récupéré, ils font ca. Ca pique un peu mais pourquoi pas