Probleme Calendar

**warwink** · 10/05/2006, 10h45

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)

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:

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.

**KiLVaiDeN** · 10/05/2006, 11h02

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

)

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+

**KiLVaiDeN** · 10/05/2006, 11h07

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+

**warwink** · 10/05/2006, 11h17

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

.

**adiGuba** · 10/05/2006, 11h26

Salut,

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

**adiGuba** · 10/05/2006, 11h27

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

**warwink** · 10/05/2006, 11h30

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

**warwink** · 10/05/2006, 11h33

Voila le complet :

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)

**KiLVaiDeN** · 10/05/2006, 11h46

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

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

**thewho** · 10/05/2006, 12h01

Bonjour,

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.

**KiLVaiDeN** · 10/05/2006, 12h17

Voici un article interessant trouvé sur la toile au sujet de Date et Calendar : http://www.xmission.com/~goodhill/da...eprecation.htm

**jowo** · 10/05/2006, 12h23

Bonjour,

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

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

**adiGuba** · 10/05/2006, 12h30

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 :

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

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

**KiLVaiDeN** · 10/05/2006, 12h40

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+

**adiGuba** · 10/05/2006, 12h50

Tout à fat d'accord sur ce point. Je parlais essentiellement du travail sur les dates

**warwink** · 10/05/2006, 14h12

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.