Constantes Java - `static final` ou `enum`? Évitez les pièges !

En Java, on ne déclare pas une constante avec const : la mécanique correcte repose sur final, et souvent sur static final quand la valeur doit être partagée à l’échelle de la classe ou de l’application. Ce détail change la lisibilité, la sécurité du code et même la maintenance des bibliothèques. Je vais distinguer ce qui est réellement constant, ce qui est seulement verrouillé, et les cas où un enum est plus adapté.

Pourquoi const ne fonctionne pas comme en C ou en JavaScript

Le premier point à clarifier est simple: en Java, const est un mot-clé réservé, mais il n’est pas utilisable pour définir une constante. Autrement dit, écrire const int MAX = 10; provoque une erreur de compilation. C’est une source de confusion fréquente pour les développeurs qui passent d’un autre langage à Java.

// Incorrect en Java
const int MAX_RETRY = 3;

La vraie logique du langage est différente. Java sépare la notion de variable finale de la notion de constante de compilation. Une variable marquée final ne peut être affectée qu’une seule fois, mais cela ne veut pas dire que la valeur est forcément figée dans tous les sens du terme. C’est précisément pour cela qu’il faut comprendre le mécanisme avant d’écrire du code qui sera partagé ou réutilisé.

Avant de choisir une syntaxe, il faut donc distinguer trois cas très concrets: une valeur locale qui ne doit plus changer, une valeur partagée dans une classe, et un ensemble fermé de choix métier. C’est ce tri qui évite les mauvaises abstractions, et il mène naturellement à la manière correcte de déclarer une constante.

Comment déclarer une constante proprement

La forme la plus courante est static final. static place la valeur au niveau de la classe, et final interdit sa réaffectation. Dans une vraie base de code, je recommande de l’encapsuler dans une classe utilitaire finale avec un constructeur privé si elle ne sert qu’à regrouper des valeurs stables.

public final class ApiConfig {
    private ApiConfig() {
        // Empêche l'instanciation
    }

    public static final int MAX_RETRY = 3;
    public static final long TIMEOUT_MS = 2_000L;
    public static final String BASE_PATH = "/api/v1";
}

Le nom aussi compte. En Java, une constante se nomme en général en majuscules avec des tirets de soulignement: MAX_RETRY, DEFAULT_TIMEOUT_MS, BASE_PATH. Cette convention n’est pas cosmétique. Elle permet de repérer instantanément une valeur qui ne devrait pas être traitée comme une variable ordinaire.

Je privilégie presque toujours le niveau le plus fermé possible. Si une valeur n’a pas vocation à sortir de la classe, je la garde en private static final. Plus l’API expose de constantes, plus elle devient difficile à faire évoluer proprement.

Mais attention: final n’est pas synonyme d’immutabilité absolue. C’est là que beaucoup de développeurs se font piéger, et c’est le point suivant qu’il faut traiter avec précision.

Ce que final garantit vraiment

final garantit qu’une variable ne peut être affectée qu’une seule fois. En revanche, si cette variable contient une référence vers un objet mutable, l’objet lui-même peut encore changer. C’est une différence fondamentale entre “la variable ne bouge plus” et “la valeur est immuable”.

final List roles = new ArrayList<>();
roles.add("ADMIN");   // autorisé
roles.add("USER");    // autorisé aussi
// roles = new ArrayList<>(); // interdit

Dans cet exemple, la référence est figée, mais le contenu de la liste évolue. Si je veux une collection vraiment immuable, je préfère utiliser les fabriques immuables de l’API moderne, comme List.of(...), Set.of(...) ou Map.of(...), selon le besoin. Cela évite de confondre “référence finale” et “données non modifiables”.

Il y a aussi un autre cas important: une variable final de type primitif ou String initialisée avec une expression constante devient une constante de compilation. C’est le cas de static final String BASE_PATH = "/api/v1"; ou de static final int MAX_RETRY = 3;. Cette nuance a des conséquences sur la compilation et sur la façon dont le code consommateur voit la valeur.

Quand la valeur ne représente plus une simple donnée fixe mais un ensemble fermé d’options, le bon outil change encore. C’est là qu’un enum devient souvent plus propre qu’une constante isolée.

Quand un enum vaut mieux qu’une constante

Je vois souvent des projets accumuler des int ou des String pour représenter des états métier: 1 pour “en attente”, 2 pour “payé”, 3 pour “annulé”. Ce système marche au début, puis il devient fragile. Un enum apporte un vrai gain de robustesse parce qu’il encode explicitement un ensemble fermé de valeurs.

public enum PaymentStatus {
    PENDING,
    PAID,
    CANCELLED
}

Le gros avantage de l’enum, c’est qu’il évite les valeurs magiques et améliore la lisibilité dans les switch ou les validations métier. Dès que je vois une constante qui représente en réalité un état, un type ou une catégorie, je me demande si ce n’est pas un enum déguisé. Très souvent, la réponse est oui.

Reste un sujet plus discret, mais beaucoup plus important en production qu’il n’y paraît: la compatibilité entre modules, les valeurs inlinées et les pièges de maintenance.

Les pièges qui coûtent du temps en maintenance

Le premier piège concerne l’inlining. Quand une constante publique est une vraie constante de compilation, le compilateur peut remplacer son nom par sa valeur dans le code client. Conséquence concrète: si vous modifiez ensuite la valeur dans une bibliothèque, les classes déjà compilées ne voient pas forcément la nouvelle version tant qu’elles ne sont pas recompilées. C’est un détail technique, mais il peut produire des écarts de comportement très réels.

Le deuxième piège, c’est l’usage des interfaces comme “poubelle à constantes”. On rencontre encore des interfaces remplies de public static final, alors qu’elles ne décrivent pas un contrat métier mais seulement un tas de valeurs. Je déconseille cette pratique: elle brouille le rôle de l’interface et pousse à exposer des symboles qui auraient parfois dû rester internes à une classe utilitaire.

Le troisième piège est plus subtil: appeler “constante” une valeur qui dépend en réalité de l’environnement. Un timeout issu d’un fichier de configuration, une URL lue au démarrage ou un paramètre influencé par le déploiement ne sont pas de bonnes candidates à static final. Dans ces cas-là, je préfère une configuration explicite plutôt qu’une constante maquillée.

• Ne changez pas une constante publique sans penser aux consommateurs déjà compilés.
• Ne transformez pas une classe d’options métier en liste d’int anonymes.
• N’utilisez pas final pour donner une fausse impression d’immutabilité.
• Ne mettez pas en constante ce qui devrait être une configuration.

Si je dois résumer mon approche de travail, elle tient en une idée simple: une constante doit être stable, lisible et réellement utile à l’API ou au domaine. Dès qu’elle commence à ressembler à un paramètre de configuration ou à un code métier ambigu, je change de modèle avant que le code ne se fige dans une mauvaise direction.

La règle simple que j’applique pour garder le code lisible

Ma règle est pragmatique: j’utilise private static final par défaut, public static final seulement si la valeur doit vraiment faire partie du contrat public, et enum dès qu’il s’agit d’un ensemble fini de choix. Pour les collections ou les structures de données figées, je pars sur des versions immuables plutôt que sur une simple référence final. C’est cette discipline qui garde le code prévisible sur la durée.

En pratique, si une valeur doit être remplacée souvent, elle n’est probablement pas une constante. Si elle décrit un état fermé, elle mérite souvent un enum. Et si elle ne doit jamais changer mais qu’elle reste interne, je la cache au maximum pour limiter les dépendances. C’est une approche simple, mais elle évite beaucoup de bruit, de confusion et de dettes techniques quand la base Java commence à grandir.