Ces "anomalies" la ne me genent pas, sauf la (0) que je n'arrive pas a
compiler !.

Par contre :

(1) declaration de classe dans une methode : je trouve cela tres pratique et
je l'utilise tres souvent principalement pour sous-classer Thread et lancer
des processus de portee locale (je n'ai pas besoin de visibilite sur la
sous-classe a l'exterieur de la methode). Les classes anonymes sont une
variantes des classes definies a l'interieur des methodes, et je trouve
qu'il manque cruellement la possibilite d'en creer dans mon autre langage de
predilection (le C++). Il est egalement possible de declarer des classes
dans une methode en C++, au demeurant (du moins en environnement Borland).

(2) Je suis d'accord. Mais il y a pire : le "psuedo-champ statique" class
(ex : StringBuffer.class) qui se confond avec un mot cle ... Comment peut-on
parser ce truc sans tricher ?

(3) C'est parfaitement normal : de meme que le if ... else ne constitue
qu'une seule instruction. Pourquoi (et surtout comment) en serait-il
autrement ?

Ne vire donc pas tout trop vite ...

-----Message d'origine-----
De : Guillaume Desnoix [mailto:[EMAIL PROTECTED]
Envoye : mercredi 28 mai 2003 15:38
A : [EMAIL PROTECTED]
Objet : Anomalies de syntaxe (Ca veut dire quoi ?)



Tout d'abord merci a Herve, Olivier et Remi pour leurs reponses.

Je continue la chasse aux "anomalies" de la syntaxe Java.

0) Deja traite:
   manager.rootLogger = manager.new RootLogger();
   C'est surement utile mais ce n'est JAMAIS utilise (1 seule fois dans
   le jdk et jamais vu ailleurs)

Je rajouterais aussi:

1) La declaration de classe a l'interieur d'une methode
    (a priori ca n'a aucun interet)

2) La possibilite d'avoir un champ du meme nom que la classe
    (certes y'a le contexte mais franchement c'est douteux)
    (ca apparait une fois dans les sources du JDK)

3) Le triplet try/catch/finally compte pour une seule instruction:
      if(!frame.isMaximum())
        try { frame.setMaximum(true); }
        catch (PropertyVetoException e2) { }
      else
        try { frame.setMaximum(false); }
        catch (PropertyVetoException e3) { }
   La encore, je n'avais jamais vu ca avant et ca apparait UNE fois dans
   les sources du JDK.

4) Plus, bien sur, l'appel de methodes statiques a partir d'une instance.

Alors, "si j'etais moi", je virerais tout ca.

Guillaume

Répondre à