Discussion :

[Jb_One73]

Bonjour à tous,

Je rencontre un soucis que je n'arrive pas à résoudre et qui sera forcément très simple pour vous, j'essaie de récupérer une valeur d'une variable que j'ai créé dans une autre classe ... Problème !

Dans la classe où je veux récupérer cette valeur celle-ci se trouve à 0 au lieu de 2 en voici mon code :

Code de la classe contenant la valeur que je veux récupérer :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
 
public class A{
 
    /*
    * Les variables 
    */
    private static int R;     
 
    /*
    * Le constructeur
    */
    Coordinateur(){
        R = 0;
    }    
 
    /*
    * On démarre le coordinateur
    */
    public static void main(String[] args) {
 
        java.util.Scanner entree = new java.util.Scanner(System.in);
 
        /*
        * Les paramètres R
        */
        System.out.println("Veuillez saisir un nombre ");
	R = Integer.valueOf(entree.next());
      }
 
    public static int getR(){
        return R;
    }
}

Code de la classe dont je souhaire récupérer la valeur contenu dans la variable R de la classe A

Code :

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

1
2
3
4
5
6
7
8
9
10
 
public class B {
 
    public static void main(String[] args) {
 
        int r = A.getR();
        System.out.println(r);     // Ici j'ai 0 au lieu d'avoir la valeur qui a été saisie dans la classe A
 
    }    
}

Je vous remercie à tous d'avance pour votre aide

[Drowan]

Le fait que tu ais deux méthodes main n'est pas utile ici.

Ce que fait ton code :
Quand tu lances le main défini dans A :
- java crée un objet de type A
- cette objet possède donc l'attribut R qui vaut 0
- java lance la méthode main de l'objet
- tu saisi ton entier au clavier
- l'attribut R de ton objet prends la valeur saisie
- fin du code

Quand tu lances le main défini dans B :
- java crée un objet de type B
- java lance la méthode main de l'objet
- r prend le résultat de la méthode getR() qui est appliqué à aucun objet A, donc 0 (valeur par défaut défini dans la classe A)
- tu affiches r, donc 0
- fin

Et quand tu lances les deux en parallèles, il se passe c'est deux exécutions en parallèle et indépendamment.

[Drowan]

Il faut ne lancer que le main de ton objet de classe B.

Dans ce main, il faut créer un objet de type A.
Lancer une méthode sur cette objet qui réalise ce qui est écrit dans le main de la classe A. (Mais ne pas appeler cette méthode main)
Puis lancer la méthode getR() sur l'objet de type A.


PS : evite de définir un getter comme static, pour obliger à l'appeler sur un objet.

[Jb_One73]

Merci Drowan pour ta réponse, j'ai bien compris ce que tu m'as expliqué et je me rend compte que mon exemple n'est pas complet. Je vais essayer d'être plus précis car cet exemple était dérivé du code de mon projet.

Ma classe A doit s'exécuter en 1er est demandé à l'utilisateur de saisir des paramètres (des entiers), celles-ci une fois saisie vont servir d'information à d'autres classes notamment B. Lors de l'exécution, celle-ci va aller lire la valeur qui a été saisie dans A tout ça pour dire que je pense que je n'ai pas le choix que de mettre un main dans chaque classe.

Tu en penses quoi ?

Merci d'avance de ton aide.

[joel.drigo]

Salut,

Il faut voir chaque main() lancé séparément comme 2 programmes indépendants qui ne partagent pas les mêmes zones de mémoire : les variables créées par l'un ne sont pas accessibles par l'autre. Le fait qu'il s'agisse de la même variable dans le code n'a aucun rapport. Tout comme quand tu lances 2 fois le même programme : tu ne retrouves pas les valeurs de la précédente exécution dans les variables de la seconde.

Si tu lances les 2 classes à partir d'une troisième :

Code :

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

1
2
3
4
5
6
7
8
public class Launcher {
 
   public static void main(String[] args) {
       A.main(args);
       B.main(args);
   }
 
}

Alors, là, oui, en lançant Launcher (par sa méthode main() donc), tu ne lanceras qu'un seul programme, et toutes les instances créées auront accès les unes au autres.

Si les 2 programmes A et B doivent être lancé séparément, il faut utiliser un moyen de s'échanger les valeurs entre programmes : fichier, connexion UPD/TCP/RMI/HTTP/JNDI/Tout ce que tu veux... mais pas par la "mémoire" de chaque programme.

Si ce n'est pas le cas, la question à se poser est pourquoi des méthodes main() dans ces 2 classes...

[Jb_One73]

Bonsoir et merci joel.drigo,

Alors la solution correspondant à mon besoin est celle-ci que tu as noté

Si les 2 programmes A et B doivent être lancé séparément, il faut utiliser un moyen de s'échanger les valeurs entre programmes : fichier, connexion UPD/TCP/RMI/HTTP/JNDI/Tout ce que tu veux... mais pas par la "mémoire" de chaque programme.

C'est tout à fait cela, cependant, ça m'a l'air plus compliqué que je ne le pensais, si je dois utiliser un fichier pour récupérer mes valeurs c'est un peu contraignant, en UDP c'est à dire ? Je dois utiliser RMI dans mon développement aucune utilité pour faire cet échange ?

Merci d'avance.

[joel.drigo]

Si tu dois utiliser RMI dans ton développement, c'est probablement justement pour ça. RMI permet de partager des objets entre applications.

NB: quand je parlais d'UDP, je citais juste un protocole réseau comme n'importe quel autre, qui permet d'échanger des informations entre 2 applications, donc d'une certaine manière de partager des objets. Bien sûr plus l'objet est complexe, plus c'est complexe de le faire avec UDP. Mais s'il s'agit de partager juste un nombre, initialisé une fois pour toute une session de serveur, ça peut suffire, et ce sera plus simple que de le faire avec RMI.

[Jb_One73]

Ok ! Merci Joël !

Pour faire simple je dois développer une messagerie réparti qui dois obligatoirement utiliser RMI et UDP, j'ai réussi à faire la partie client en utilisant les sockets mais maintenant j'attaque la partie la plus dur:
J'ai 3 applications (un client, un routeur, un coordinateur), le coordinateur est l'appli qui se lance en 1er, celui-ci sert à déterminé le schéma de nommage basé sur le protocole ZigBee d'où la saisie des paramètres.
Ensuite vient le routeur ou client qui eux doivent justement récupérer ses valeurs car lorsqu'un client ou routeur veut se connecter sur le système il doit obligatoirement passer par le coordinateur (j'ai créé un post sur mon projet pour avoir un peu d'aide pour concevoir ce projet de fin d'étude moi qui pensais mettre débarrassé de java ....), le post se trouve ici http://www.developpez.net/forums/d15...erie-repartie/

Merci Joël de m'apporter une nouvelle fois tes conseils et idées.

Cordialement

[joel.drigo]

Je ne suis pas très au fait de ZigBee, mais je ne vois pas trop ce que ça vient faire ici (tout ce que j'en sais (ou je crois savoir) c'est que c'est un protocole d'échange entre dispositifs électroniques de communication (radio) dédié aux petites surfaces : genre pour faire un système d'interphone sans fil dans un immeuble, ou un réseau radio local pour une équipe de surveillance d'un musée, des trucs comme ça...), mais bon peut-être y a t il un spécification de "nommage" particulier et qu'il s'agit à priori de l'adapter dans le cadre de ta messagerie. M'enfin, j'ai l'impression qu'il s'agit de simuler en quelque sorte JNDI mais sans utiliser JNDI, et sans se baser sur JNDI. A moins qu'il ne s'agisse tout simplement de simuler logiquement un réseau ZigBee.

Regarde ce tutoriel. Mais avant, tu peux déjà penser sans RMI : quelles sont les informations que tu vas devoir manipuler pour faire ce système de nommage à la ZigBee.

[Jb_One73]

Concernant ZigBee, alors tout d'abord ta définition est tout à fait correct, c'est bien un protocole de communication utilisé dans les systèmes réparti mais on va pas faire un cours là-dessus. ZigBee dans mon projet sert juste à créer le schéma de nommage (cf. image ci-dessous)


Les seules variables que je vais avoir besoin de manipuler sont : R = Nombre max de routeur, D = Nombre max de client, P = Profondeur de l'arbre et une autre qui contient le routeur racine (IP + Port), toutes ses variables dépendent du coordinateur c'est lui en gros qui le chef d'orchestre.

Le routeur ou le client vont demander au coordinateur ses variables et à la suite de ça chacun va pouvoir connaître sa position dans le schéma ZigBee (un routeur vert qui il est associé père ou fils et le client à quel routeur).
Les valeurs R, D, P permettent de calculer la plage d'adressage totale donc après il y a des calculs à faire mais ça c'est bon je les ai fait.

Merci pour le lien du tuto sur RMI (je l'ai déjà étudié hier), grâce à celui-ci j'ai réussi à partager mes objets mais ce qui m’intéresse c'est ce que tu as noté dans un de tes posts, tu m'as indiqué que je pouvais partager ses fameuses valeurs, est ce que tu pourrais m'en dire plus ?

Merci d'avance.

[joel.drigo]

Tout est dit dans le tutoriel.

En résumé, tu as un programme (serveur) qui instancie un objet et un programme (ou plusieurs) client qui utilise cet objet. RMI permet de facilement manipuler l'objet dans le client, alors que celui-ci a été créé dans une autre application (le serveur). Cette manipulation se fait par le biais d'une interface (public interface Truc {...}. Cette interface sera à la fois dans les bibliothèques du client et celles du serveur. Le serveur créer une instance (d'une classe locale qui implémente l'interface), et le publie via un annuaire : le client recherche dans les annuaires auquel il a accès l'objet publié et le récupère, et le manipule via l'interface.

L'interface doit donc présenter comme accesseurs tout ce que le client à besoin d'obtenir d'un objet créé par un serveur (le coordonnateur (ou coordinateur si tu préfères - j'évite pour ma part les néologismes d'origine anglo-saxonne, comme solutionner aussi) dans ton cas). Donc à priori, il va y avoir trois accesseurs pour récupérer les données produites par le coordonnateur, R, D et P. RMI va te rendre plus ou moins transparente la communication entre le serveur et le client (tu n'auras pas à lire des flux d'octets, a t'occuper de connexion, etc), comme le ferait n'importe quel protocole de type RPC : tu demandes simplement à un annuaire un objet, qu'un serveur a placé dans cet annuaire. L'identification de l'objet se fait sur un nom commun.

[Jb_One73]

Ok ! Merci Joël, donc si je comprend bien je vais avoir une Interface Coordinateur et une Classe Coordinateur, dans l'interface j'indiquerai ce que le client via RMI (implémentation de l'interface Coordinateur) pourra récupérer notamment R, D et P.
Si tel est le cas, je vais donc maintenir les main et lorsqu'un client va se connecter, il va utiliser les méthodes de l'interface Coordinateur (ex : getD()) qui contiendra la valeur souhaitée. Au niveau de la Classe Coordinateur, j'aurai donc une méthode getD() qui sera chargée de contenir la valeur de D, alors je sais pas si j'ai réussi à expliquer correctement ce que je voulais dire ou peut être que j'ai tout compris à l'envers.

Merci d'avance.

[joel.drigo]

Donc, en gros :

Code :

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

1
2
3
4
5
6
public interface Coordinator extends Remote {
 
   int getD();
   /*...*/
 
}

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class CoordinatorImpl extends UnicastRemoteObject implment Coordinator {
 
   private final int D; //!
   //...
 
   public CoordinatorImpl(int D/*...*/) {
        this.D=D;
   }
 
   public int getD() {
       return D;
   }
 
   /*...*/
 
}

Code :

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

1
2
3
4
5
6
7
8
9
10
11
public class CoordinatorMain {
 
   public static void main(String[] args) {
          saisir R...
          CoordinatorImpl impl = new CoordonatorImpl(R/*...*/);
 
          placer dans l'annuaire RMI l'instance impl sous le nom de xxx...
 
   }
 
}

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
public class ClientMain {
 
   public static void main(String[] args) {
 
           Coordinator coordinator = demande objet appelé xxx dans l'annuaire RMI
 
 
          int D = coordinator.getD(); // je peux appeler la méthode, et j'obtiens la valeur écrite par le serveur           
 
 
   }
 
}

[Jb_One73]

Merci Joël ! C'est très claire ! Petite question est après c'est bon. On est obligé de créer la Classe CoordinatorImpl () on peut pas tout intégrer dans la CLasse CoordinatorMain() ?

[joel.drigo]

Si bien sûr on peut faire une seule classe qui implémente l'interface avec la méthode main dans cette classe. Normalement, on préfère découper les classes de manière à dédier à chacune elle ce qu'elles sont censées faire, leur dédier un rôle unique, au lieu de tout fourguer dans la même classe. En particulier, la saisie des paramètres au clavier devraient être découpler de la classe à partager elle-même. La méthode de récupération des paramètres devraient pouvoir être indépendante. Mais après tout tu fais ce que tu veux.

[Jb_One73]

Bonjour Joël et désolé pour cette réponse aussi tardive.

J'ai suivi tes conseils et j'ai donc dissocié chaque classe et attribué le rôle de chacun. Je viens de commencer mes essais, pour le RMI c'est Ok ! Interface Ok ! Coordinateur Ok ! En revanche le client j'ai un tout petit soucis concernant la ligne que tu as noté :

Coordinator coordinator = demande objet appelé xxx dans l'annuaire RMI

Est ce que tu pourrais m'apporter une petite précision sur "demande objet appelé xxx dans l'annuaire RMI" ?

Je t'en remercie d'avance.

Cordialement

[joel.drigo]

Cela se fait par l'appel de java.rmi.Naming.lookup()...

[Jb_One73]

Super ! Merci Joël ! Ça fonctionne à merveille et encore merci !

Cordialement.