Bonjour la liste,

J'ai l'habitude, lorsque je développe une application, de 
mettre un certain nombre de constantes (oops : de variables 
statiques - voire final) dans un Config.java.

Ceci me permet, par exemple, d'écrire des trucs du style :
if (Config.DEBUG) {
...
}

Lorsque j'écris une classe Toto que je met dans le package 
truc, cette classe commence bien entendu par :
package truc;
import Config;

Et voilà le problème : en compilant avec le jdk1.4, il me 
sort une erreur à la compilation de Toto.java :

truc/Toto.java:8: '.' expected
import Config;
                  ^

Inutile de préciser que j'ai aussi une erreur sur 
Config.DEBUG, car il ne reconnaît pas Config.

Je me doute bien qu'en mettant Config dans le package 
monappli et Toto dans monappli.truc, le problème serait 
résolu par un import monappli.Config, mais que voulez-vous, 
j'aime bien ne pas faire trop propre parfois.

Un autre truc rigolo est que la version de forte pour 
SDK1.4 (<TROLL sur les IDE>que je trouve pas mal par 
rapport aux versions précédentes -ce qui m'a poussé à 
passer en 1.4 - et que j'utilise à la place de mon 
emacs/jde habituel pour faire des interfaces</TROLL>) ne me 
génère pas d'erreur !

Bref, comment faire pour que mon import soit accepté par le 
compilateur du jdk1.4 ? S'agit-il d'un bug connu, ou bien 
est-ce une volonté d'imposer un développement plus propre 
(plus académique) en imposant un package pour une appli 
java ?

Autre question :
Dans une classe qui hérite d'un JFrame, j'ai surchargé les 
méthodes permettant d'ouvrir la fenêtre, à savoir 
setVisible(boolean), show() et show(boolean).
Bien entendu, le compilo me sort que c'est deprecated, je 
le sais bien mais je veux être sûr que mon code soit 
exécuté à l'ouverture de la fenêtre.
Mis à part le fait que j'aimerais que le compilateur se 
taise là-dessus (pour voir si je n'ai pas d'autre 
deprecated dans mon code), je me suis rendu compte d'un 
truc bizarre :
Initialement, au lieu d'appeler super.show() dans ma 
méthode show(), j'appelais setVisible(true). Or, surprise, 
en ouvrant ma fenêtre avec setVisible(true), je me 
retrouvais sur un StackOverflow qui me permettait de 
constater que le super.setVisible(true) de mon 
setVisble(true) appelait show() (qui appelait mon 
setVisible()), d'où la boucle....
Est-ce à dire que dans les librairies du jdk1.4 les 
méthodes deprecated sont utilisées ? (qu'elles soient 
implémentées, je comprends, mais utilisées !?!)
Bon, je n'ai pas de question particulière à poser 
là-dessus, j'ai bien entendu changé mes setVisible(true) en 
super.show(), et puis j'ai sorti mon code ajouté dans une 
tierce méthode et tout fonctionne. Mais mon étonnement 
est-il justifié ?

Stéphan BERNARD
-- 
Stéphan BERNARD	stephan.bernard@cemagref.fr
LISC/CEMAGREF - 24 av. des Landais - 63172 Aubière Cedex

Salut,

Concernant ton problème d'import, voilà une réponse:

http://oss.software.ibm.com/developerworks/bugs/?func=detailbug&bug_id=601&group_id=10

La règle a été renforcée dans les JLS pour 1.4. Ça me parait tout à fait
sain comme changement.

Olivier
setVisible() n'est pas deprecated. show() l'est, toutefois.
Le coup de la boucle infinie show()/setVisible() ne date pas du
dernier JDK : j'ai déjà subi sur l'une des versions précédentes
(sans doute une 1.2) !

Personnellement, j'ai jusqu'aujourd'hui utilisé show() pour afficher
une boite de dialogue, setVisible() pour la faire disparaître, et
setVisible()
dans les deux cas pour les classes issues directement de JFrame ... C'est
très inconsistant, mais deprecated or not je n'ai jamais eu de problème !

Zeljko

-----Message d'origine-----
De : Stéphan BERNARD [mailto:stephan.bernard@clermont.cemagref.fr]
Envoyé : jeudi 18 avril 2002 14:21
À : java@u-strasbg.fr
Objet : pb d'import avec jdk1.4


Bonjour la liste,

Autre question :
Dans une classe qui hérite d'un JFrame, j'ai surchargé les
méthodes permettant d'ouvrir la fenêtre, à savoir
setVisible(boolean), show() et show(boolean).
Bien entendu, le compilo me sort que c'est deprecated, je
le sais bien mais je veux être sûr que mon code soit
exécuté à l'ouverture de la fenêtre.
Mis à part le fait que j'aimerais que le compilateur se
taise là-dessus (pour voir si je n'ai pas d'autre
deprecated dans mon code), je me suis rendu compte d'un
truc bizarre :
Initialement, au lieu d'appeler super.show() dans ma
méthode show(), j'appelais setVisible(true). Or, surprise,
en ouvrant ma fenêtre avec setVisible(true), je me
retrouvais sur un StackOverflow qui me permettait de
constater que le super.setVisible(true) de mon
setVisble(true) appelait show() (qui appelait mon
setVisible()), d'où la boucle....
Est-ce à dire que dans les librairies du jdk1.4 les
méthodes deprecated sont utilisées ? (qu'elles soient
implémentées, je comprends, mais utilisées !?!)
Bon, je n'ai pas de question particulière à poser
là-dessus, j'ai bien entendu changé mes setVisible(true) en
super.show(), et puis j'ai sorti mon code ajouté dans une
tierce méthode et tout fonctionne. Mais mon étonnement
est-il justifié ?

Stéphan BERNARD
--
Stéphan BERNARD	stephan.bernard@cemagref.fr
LISC/CEMAGREF - 24 av. des Landais - 63172 Aubière Cedex

Stéphan BERNARD:
> Est-ce à dire que dans les librairies du jdk1.4 les 
> méthodes deprecated sont utilisées ?

Bien sur ;-(
(faites ce que je dis, pas ce que je fais)

Mais c'est pour des raisons de compatibilites ;-)
(en particulier pour les anciens codes qui surchargent les anciennes
methodes)

Conclusion: on ne sait jamais ce qui est appele... ni ce qu'il faut 
surcharger, sauf a regarder les sources de *chaque* jdk.