Probleme Calendar

Version imprimable

10/05/2006, 10h45
warwink

Probleme Calendar

Voila, j'expose un petit probleme bizarre, ou en tout cas pour moi.

J'ai un petit programme qui utilise la classe Calendar. (d'ailleur au passage, je suis prenneur pour une meilleure initialisation de mon 'lastcheck' car je sais pas si c'est comme ca qu'il faut s'y prendre)

Citation:

private Calendar lastCheck;
lastCheck = Calendar.getInstance();
lastCheck.set(2000,1,1);

Et ensuite je le passe en argument pour l'appelle d'une methode.
Et c'est donc la que le probleme arrive. Quand je lance le programme, il me sort une erreur (dans la méthode, lastCheck devient null :( ) mais que sur les premieres executions du programme. En insistant, au bout du 4eme ou 5eme lancement, ca le fait plus et puis ca marche nickel.

Voici l'erreur:

Citation:

Exception in thread "Thread-3" java.lang.NullPointerException
at java.util.Calendar.getMillisOf(Unknown Source)
at java.util.Calendar.compareTo(Unknown Source)

Autre petite indication, j'execute le programme avec Eclipse. Quabd je quitte Eclipse et que je le relance, le probleme revient.

Merci.
10/05/2006, 11h02
KiLVaiDeN

Je ne pense pas que ça ait un rapport avec Eclipse ( que j'apprécie enormément pour ma part :P )

Pourquoi n'utilises-tu pas un objet Date() plutot ? Je pense que c'est plus adapté. L'objet Calendar n'est pas à passer en argument comme tu le fais, il faut faire un getInstance dans chaque méthode; il s'agit d'un singleton.

A+
10/05/2006, 11h07
KiLVaiDeN

L'avantage de l'objet Date est que tu peux le passer en paramètre, lui :)
Donc si c'est le besoin initial, c'est le meilleur moyen.
En plus l'objet Date colle bien avec des champs de type Date en base de données.
Puis finalement, tu peux avoir un objet Date pour chaque instant souhaité, sans écraser le précedent; Calendar te retourne l'instant T, mais ne te permet pas de stocker l'instant t-1 :)

A+
10/05/2006, 11h17
warwink

Merci pour vos réponses.

Je vais essayé de me pencher un peu plus sur Date alors. Car, dans un premier temps, c'est celui-ci que j'avais utilisé mais pour une raison que là, maintenant, tout de suite, je me rappelle plus, j'avais changé car je ne pouvais pas faire un truc :?.
10/05/2006, 11h26
adiGuba

Salut,

Citation:

Envoyé par KiLVaiDeN

Pourquoi n'utilises-tu pas un objet Date() plutot ? Je pense que c'est plus adapté.

L'objet Calendar n'est pas à passer en argument comme tu le fais, il faut faire un getInstance dans chaque méthode; il s'agit d'un singleton.

Non l'objet Calendar est bien adapté au traitement sur les dates... et il n'est en aucun cas un Singleton : chaque appel à getInstance() te renvoit un nouvel objet Calendar selon ton timezone et ta locale... Pour la plupart des pays cela revient à créer un GregorianCalendar...

Le problème semble plutôt venir de ta gestion des threads : dans certains car tu te retrouves avec un attribut mal-initialisé...
Est-ce que le stacktrace de l'erreur est complet ? Si ce n'est pas le cas donne le nous avec le code correspondant à ton codes sources...

a++
10/05/2006, 11h27
adiGuba

Citation:

Envoyé par warwink

Je vais essayé de me pencher un peu plus sur Date alors. Car, dans un premier temps, c'est celui-ci que j'avais utilisé mais pour une raison que là, maintenant, tout de suite, je me rappelle plus, j'avais changé car je ne pouvais pas faire un truc :?.

C'est surement parce que la plupart des méthodes de Date sont déprécié et qu'il ne vaut mieux pas les utiliser...
10/05/2006, 11h30
warwink

Voila, moi j'initialise avec ces champs la :

int year, int month, int date, int hrs, int min, int sec

Et le constructeur de Date est "deprecated". Et dans la bible, ils disent qu'il faut utiliser Calendar :?

Edit: Voila comme tu viens de dire adiGuba ;)
10/05/2006, 11h33
warwink

Voila le complet :

Citation:

Exception in thread "Thread-3" java.lang.NullPointerException
at java.util.Calendar.getMillisOf(Unknown Source)
at java.util.Calendar.compareTo(Unknown Source)
at NetworkEagleUI.parser.alert.AlertHandler.element(AlertHandler.java:20)
at NetworkEagleUI.parser.alert.AlertParser.parse(AlertParser.java:47)
at NetworkEagleUI.parser.alert.AlertParser.<init>(AlertParser.java:33)
at NetworkEagleUI.ui.AppletUI.run(AppletUI.java:113)
at java.lang.Thread.run(Unknown Source)
10/05/2006, 11h46
KiLVaiDeN

Je me sers très souvent des objets Date sans aucun souci, peut-être vais-je en avoir un jour :roll:

J'étais persuadé que Calendar était un singleton, avec sa méthode getInstance, je suis trop habitué à cette corrélation on dirait..

Merci pour l'info en tout cas adiGuba, je vais utiliser des GregorianCalendar de partout maintenant ;)
10/05/2006, 12h01
thewho

Bonjour,

Citation:

Envoyé par KiLVaiDeN

Je me sers très souvent des objets Date sans aucun souci, peut-être vais-je en avoir un jour

Personne ne dit que ça ne marche pas (moi même je m'en sers de temps en temps).
C'est seulement déprécié, ce qui signifie que rien ne garantit son maintien dans les versions futures de Java, ce qui posera problème aux logiciels qui l'utilisent.
10/05/2006, 12h17
KiLVaiDeN

Voici un article interessant trouvé sur la toile au sujet de Date et Calendar : http://www.xmission.com/~goodhill/da...eprecation.htm
10/05/2006, 12h23
jowo

Bonjour,

Tu utilises la méthode compareTo(Object o) .

As-tu contrôlé que l'argument passé à compareTo n'est pas null?

KiLVaiDen >> Date peut renvoyer des valeurs incorrects pour certain timezone et/ou locale. Calendar gère cela beaucoup mieux et est nettement plus complet...

warwink >> L'origine de ton problème doit surement venir d'une de ces lignes :
Code:

1 2 3 4 at NetworkEagleUI.parser.alert.AlertHandler.element(AlertHandler.java:20) at NetworkEagleUI.parser.alert.AlertParser.parse(AlertParser.java:47) at NetworkEagleUI.parser.alert.AlertParser.<init>(AlertParser.java:33) at NetworkEagleUI.ui.AppletUI.run(AppletUI.java:113)
Vérifie donc le code de ces méthodes...

10/05/2006, 12h40
KiLVaiDeN

adiGuba : en fait il ne faut se servir de l'objet Date que comme un conteneur, et ne pas utiliser les méthodes qui retournent des informations autre que le long de type timestamp. Comme il est dit dans l'article que j'ai mit en lien, c'est un peu le même principe qu'un objet Integer pour les int.

Pour récuperer les éléments indépendamment, en effet tu peux alors utiliser un calendar, qui lui connait les Timezone, et te retournera les bonnes valeurs, mais je pense qu'étant donné que l'objet Date est plus compacte que l'objet Calendar, il convient peut-être mieux quand on s'en sert de "conteneur" tout simplement.

Je ne me rappellais pas trop pourquoi j'utilisais Date dans mes programmes alors que je connaissais Calendar et le fait que les méthodes de Date étaient dépréciées; en fait la seule chose que je ne savais pas, c'est que Calendar n'était pas un singleton, mais vu que dans mon utilisation je me sers de Calendar plus comme d'une classe statique ( bien que ce ne soit pas le cas.. ) qui me retournerait des éléments correctes par rapport à un objet Date donné, la confusion était facile :)

Date est juste un conteneur, c'est tout ce que je voulais dire, donc il est plus efficace d'avoir un objet Date en tant que membre d'un objet, plutot qu'un objet Calendar plus complexe.

A+
10/05/2006, 12h50
adiGuba

Tout à fat d'accord sur ce point. Je parlais essentiellement du travail sur les dates ;)
10/05/2006, 14h12
warwink

Citation:

Envoyé par jowo

Bonjour,

Tu utilises la méthode compareTo(Object o) .

As-tu contrôlé que l'argument passé à compareTo n'est pas null?

L'erreur c'est bien ca, c'est que dans une méthode ou je passe un Calendar, celui ci est null donc dans le compareTo ca déconne.

Mais je disais dans mon premier poste qu'en faite cela se produit que pour les premières execution. En mode debug, quand je passe de l'appel de la méthode à la méthode elle-même, ma variable passe à null. Et donc j'arrete et je relance le programme 3 ou 4 fois et puis après ca passe bien.
10/05/2006, 14h31
KiLVaiDeN

Salut,

Après cette ligne :

Code:

lastCheck.set(2000,1,1);

Essaie de faire un :

Code:

lastCheck.complete();

Pour voir si ça ne te débloque pas.
10/05/2006, 14h38
warwink

Citation:

Envoyé par KiLVaiDeN

Code:

lastCheck.complete();

euuuh, cette méthode n'existe pas.
10/05/2006, 14h44
KiLVaiDeN

alors computeTime();
10/05/2006, 15h31
warwink

ca non plus ca n'existe pas XD
10/05/2006, 15h55
KiLVaiDeN

Ton objet il est de quelle classe ??

computeTime() existe pour Calendar et GregorianCalendar
10/05/2006, 16h03
warwink

Ta méthode, elle est "protected".
10/05/2006, 16h08
adiGuba

Si tu as un null c'est qu'il y a une erreur dans ton code... cela ne sert à rien de rechercher des "méthodes magiques" dans Calendar...

Vérifie bien ton code, ou poste le code indiqué dans ton stacktrace...

a++
10/05/2006, 16h14
KiLVaiDeN
Je pense que ton set ne met pas à jour ton Calendar comme il faut.

En effet les méthodes dont je parle sont protected, donc tu ne peux pas les déclencher à la main, peut être que tu peux t'en sortir comme ceci :
Code:

1 2 3 private Calendar lastCheck; lastCheck = Calendar.getInstance(); lastCheck.setTime( new Date(2000,1,1) );
10/05/2006, 16h15
KiLVaiDeN

Citation:

Envoyé par adiGuba

Si tu as un null c'est qu'il y a une erreur dans ton code... cela ne sert à rien de rechercher des "méthodes magiques" dans Calendar...

Vérifie bien ton code, ou poste le code indiqué dans ton stacktrace...

a++

Calendar me rappelle de mauvais souvenir, je me souviens par exemple que dans l'implémentation d'IBM, les champs n'étaient pas mis à jour si tu ne faisais pas un toString() !

Il y a un problème à mon avis au niveau du recalcul de la vrai date... enfin peut-être que je me trompe, mais le problème que je cite un peu plus haut est réel, ça faisait planter une appli quand on changeait de fuseau horaire !

Attention les yeux ca pique :p

at NetworkEagleUI.ui.AppletUI.run(AppletUI.java:116)

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
         while (true) {
                try {
                    System.out.println("Refresh");
                    new AlertParser("E:\\Day5.log", company, lastCheck);
                    lastCheck = Calendar.getInstance();
 
                } catch (AlertException e1) {
                    //TODO
                    e1.printStackTrace();
                }
            try {
                Thread.sleep(10000);
            } catch(InterruptedException e){
                //TODO
                e.printStackTrace();
            }
        }

Aprés :
at NetworkEagleUI.parser.alert.AlertParser.<init>(AlertParser.java:32)

Code:

private Calendar lastCheck;

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
public AlertParser(String fileName, Company company, Calendar lastCheck) throws AlertException{
        try{
            this.company = company;
            this.lastCheck = lastCheck;
            this.reader = new BufferedReader(new FileReader(fileName));
            this.handler = new AlertHandler();
            this.lineNumber = 0;
            this.parse();
        }catch(IOException e){
            //TODO
            e.printStackTrace();
        }
    }

c'est ici que lastCheck devient null donc ca sert a rien que je mette la suite. Je regarde la variable dans le constructeur (et non pas méthode mais bon je pense passe que ca change grand chose) AlertParser, elle est null

Code:

1
2
                    new AlertParser("E:\\Day5.log", company, lastCheck);
                    lastCheck = Calendar.getInstance();

Tu instancies ton Calendar après l'appel au constructeur, normal ?

10/05/2006, 16h32
warwink
Ouai pour avoir l'heure de ma derniere MAJ.

C'est vrai que sur le coup j'ai fais ca comme un porc car normalement j'aurais du faire un truc du style:
Code:

1 2 3 4 Calendar tmpCheck = (Calendar)lastCheck.clone(); lastCheck = Calendar.getInstance(); new AlertParser("E:\\Day5.log", company, tmpCheck);
Comme ca je sauvegarde l'heure puis je fais les MAJ par rapport à l'ancienne. Puis 10s plus tard idem ....
10/05/2006, 16h52
warwink

De toute facon,le fait deja que ca marche certaines fois et pas d'autres je sentais le problème à la con. Mais alors là, je viens de faire la modif du message d'avant et les résultats sont que :

En exectution normale, ca fait toujours la même chose. Au début ca marche pas puis aprés ca marche.

En mode pas à pas: ca marche tout le temps :aie:

Alors je sais pas si c'est du à mon PC ou à Eclipse, mais ca c'est vraiment bizarre.
10/05/2006, 16h57
KiLVaiDeN

Ben oui, mais si tu le mets à jour après ton premier appel à ton constructeur, au premier passage, il sera = null non ?
10/05/2006, 17h05
warwink
C'est vrai que je ne l'ai pas ré-écrit, mais dans mon tout premier post j'avais que je fesait d'abord une initialisation de lastCheck :
Code:

1 2 lastCheck = Calendar.getInstance(); lastCheck.set(2000,1,1);

mais tu le mets où ce code ?
directement en dessous de la déclaration des attributs ?

Il faut plutot le mettre dans le constructeur je pense, si ce n'est pas le cas.
Sinon il y a des chances que ce ne soit pas executé, peut-être que ton erreur est là.

Quand tu appelles ton constructeur
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 public AlertParser(String fileName, Company company, Calendar lastCheck) throws AlertException{ try{ this.company = company; this.lastCheck = lastCheck; this.reader = new BufferedReader(new FileReader(fileName)); this.handler = new AlertHandler(); this.lineNumber = 0; this.parse(); }catch(IOException e){ //TODO e.printStackTrace(); } }
Tu lui fournis bien une valeur pour lastCheck ?

10/05/2006, 17h38
warwink

J'initialise dans la méthode init() car c'est un applet.

Sinon je peux plus vraiment te dire que je lui fourni vraiment une valeur car en mode pas a pas ca marche tout le temps. Et bon d'après mon code, ca serait oui la réponse.

Moi j'ai vraiment l'impression que c'est un problème d'execution mais bon dans la logique c'est pas possible.
10/05/2006, 18h11
KiLVaiDeN

Essaie de donner la main au constructeur pour initialiser lastCheck, et qu'il fasse lui même la mise à jour via le Calendar.getInstance(). Ainsi tu enlèves le paramètre de la liste dans ton constructeur.

Peut-être que ça marchera mieux... Bien que comme tu dis je ne vois pas pourquoi :?

Fuseau horaire GMT +2. Il est actuellement 10h09.