Discussion :

[ZouBi]

Bonjour,
Une simple question, j'aimerai savoir s'il est possible de faire l'équivalent de ce code en Java:

Code :

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

1
2
3
4
5
#ifdef DEBUG
   ...
#else
   ...
#endif

en gros, que selon une configuration de compilation, un bout de code change?
Dois-je forcément gérer ça avec des simples constantes, ou il y a t'il un moyen plus propre?

[rtg57]

Bonjour,

il n'y a pas a ma connaissance de précompilateur ou de compilation conditionnelle en JAVA.
Une astuce consiste a utiliser des classes statiques permettant d'accéder à des constantes publiques.
Vous pouvez éventuellement initialiser ces valeurs par un fichier de configuration, ou prendre des arguments depuis une ligne de commande.
Jetez aussi un coup d'oeil à la classe Properties: http://download.oracle.com/javase/6/...roperties.html, ainsi que la classe Preferences: http://download.oracle.com/javase/6/...eferences.html

@ bientôt...

[Logan Mauzaize]

Normalement si tu déclares une champ "private static final <type de base>" et que tu encapsules tes morceaux de code dans un "if" qui teste l'égalité de champ, le compilateur devrait optimiser et ne pas inclure le morceaux de code qui correspond au cas compilé ...

En pratique
Le code source original

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 FooBar
{
  private static final boolean DEBUG = false;
  public static void main(String[] args)
  {
    if (DEBUG)
    {
       System.out.println("Debugging FooBar");
    }
    System.out.println("Hello World !");
  }
}

Ne devrait subsister dans ton bytecode uniquement:

Code :

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

1
2
3
4
5
6
7
8
9
 
public class FooBar
{
  private static final boolean DEBUG = false;
  public static void main(String[] args)
  {
    System.out.println("Hello World !");
  }
}

A vérifier.

Si vraiment tu ne veux pas que des morceaux codes apparaissent dans le produit "final", le mieux doit être l'AOP.

[ZouBi]

Merci à tous pour vos réponses.
Je pense que le plus simple reste les constantes statiques; la seule idée que je pensais au départ; je cherchais juste à savoir si il y avait un moyen plus propre (à partir d'une configuration lors de la compilation).

L'idée de l'utilisation des classes 'Properties' ou 'Preferences' n'est pas du tout approprié, car ici ça concerne des propriétés pour l'utilisateur.

[Logan Mauzaize]

Si tu utilises un script (ex: Ant) pour compiler, tu peux "activer" le mode DEBUG en utilisant du remplacement de chaîne ou l'AOP.

[hibour]

Je ne vois pas comment on peut utiliser l'AOP dans ce genre de problématique!
Il n'y a pas de préprocessor en java c'est sûr
On ne peut pas modéliser un aspect générique sur un morceau de code qui se trouve au milieu du code!

[Logan Mauzaize]

Qui a dit qu'on devait développer un aspect générique ?
Ni qu'on pouvait facilement insérer un aspect au beau milieu du code ...

En revanche, je pense que c'est la façon la plus simple d'injecter du code au milieu d'un code.

[Uther]

Il n'y a en effet pas de préprocesseur en Java, On peut souvent se débrouiller comme expliqué par rtg57 et Nemek ou moyen de constantes qui permettent au compilateur de déterminer des bloc qu'ils peut supprimer.

J'ai bossé sur des projets J2ME où on utilisait des préprocesseurs maison ou même le préprocesseur de GCC. C'est faisable mais très moche et je ne le conseille absolument pas.

[hibour]

Qui a dit qu'on devait développer un aspect générique ?
Ni qu'on pouvait facilement insérer un aspect au beau milieu du code ...

En revanche, je pense que c'est la façon la plus simple d'injecter du code au milieu d'un code.

Ce n'est pas faisable avec l'AOP ni avec un script ant avec une tasklet standard.
Peut être l'utilisation d'une xdoclet (des javadoc spéciales) qui supprime les lignes se trouvant au milieu avant compilation (genre

Code :

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

1
2
3
4
5
6
7
8
 
/** 
 * @DEBUG-BEGIN 
 */
//code visible en mode debug...  
/** 
 * @DEBUG-END 
 */

)
Où peut être avec les annotations plus tard car d'après mes connaissances les annotations sur les variables ne sont pas récupérable après en bytecode!

[tchize_]

rappelons qu'une des raisons de l'absence de préprocesseur en java, c'est justement l'impossibilité pour un ide, par exemple, d'arriver à faire correctement de l'analyse sur des bout de code non prédictibles. Y a qu'à voir la difficulté de faire de l'autocompletion correcte en C


Pour désactiver le code, il y a les constantes. Pour des trucs plus avancé, il y a les plugins du compilateur, mais ça casse tout dans l'ide si tu ne t'intègre pas aussi à l'IDE.

A noter que, comme précisé, le code qui ne s'exécutera jamais (constante finale à false) peut être abandonné par le compilateur (c'est autorisé par la JLS)

[Logan Mauzaize]

Ce n'est pas faisable avec l'AOP

Tu peux à condition:

1. De connaître la méthode à modifier (c'est facile puisque c'est là que tu veux insérer le code !)
2. D'identifier un appel à une méthode avant et/ou après et/ou à la place de laquelle tu vas insérer le code de DEBUG. Le plus simple étant de créer une classe "com.developpez.zoubi.Debug" avec une méthode "public static void debug();" pour identifier un pointcut. Il ne reste plus qu'à écrire l'advice "around".

Il y a après la possibilité d'écrire une bibliothèque basée sur BCEL qui modifie le bytecode (comme le fait AspectJ) afin d'insérer "stratégiquement" des instructions.

ni avec un script ant avec une tasklet standard.

Voir Replace, ReplaceRegExp, Script et Exec.

[ZouBi]

Et bien, il y a tant d'idées; mais j'ai l'impression que pour la plupart, on passe plus de temps à mettre en place le système et sa configuration qu'autre chose...

Je pense que la constante Debug suffit amplement, d'autant plus est, qu’apparemment, Java sait virer le code mort automatiquement.

[Logan Mauzaize]

Forcément puisqu'il faut recoder un pre-processeur

Si c'est juste pour envoyer des messages sur la console, penses aux logger !