Discussion :

[professeur shadoko]

Bonjour
petite question très théorique.
Jusqu'à présent on ne pouvait pas avoir de bloc "static" dans une interface.
bon (je pensais -dans doute faussement- que c'était lié à la manière dont les interfaces étaient initialisées -ou pas initialisées du tout - par les ClassLoaders).

Je pensais qu'avec l'introduction de tas de machin static dans les interfaces de java8 ça deviendrait possible.
Selon toutes apparences ce n'est toujours pas possible: quelqu'un voit précisément pourquoi?
Merci

edit: vague brainstorming ... serait-ce lié au fait qu'une interface ne devrait pas avoir d'effet de bord? mais on peut toujours avoir une méthode statique, une classe statique -ou même une simple initialisation de variable static final- qui a un effet de bord quelque part non?

[thelvin]

edit: vague brainstorming ... serait-ce lié au fait qu'une interface ne devrait pas avoir d'effet de bord?

À mon sens c'est surtout ça, oui...

Avant, une interface ne devait pas avoir de code du tout (sauf à la limite dans la déclaration de ses champs si elle en a, pour les initialiser, portée assez réduite.)
Maintenant, une interface peut éviter de créer à côté les bien connues classes utilitaires, dont l'idée est de faire du code qui porte entièrement sur le contrat exposé par l'interface et pas sur la représentation interne de l'état des instances ou des classes. Autrement dit du code oui, mais pas d'effet de bord.

Conclusion les champs déclarés par une interface ne sont toujours pas mutables malgré ces changements, et un bloc d'initialisation static ne me semble donc toujours pas d'une utilité quelconque.
Si on commence à parler d'objets mutables à construire les uns par rapport aux autres, moi je dis c'est plus une interface, c'est une classe : ça touche à bien plus de choses que les seules méthodes exposées.

mais on peut toujours avoir une méthode statique, une classe statique -ou même une simple initialisation de variable static final- qui a un effet de bord quelque part non?

"Quelque part" oui, dès qu'on a du code c'est toujours une possibilité, c'en était déjà une effectivement avec les initialisations de leurs variables.
"Quelque part" mais pas dans l'interface elle-même ni dans l'instance qu'elle représente.

[professeur shadoko]

Conclusion les champs déclarés par une interface ne sont toujours pas mutables malgré ces changements, et un bloc d'initialisation static ne me semble donc toujours pas d'une utilité quelconque.

L'objectif n'est pas d'avoir des champs mutables mais de compléter l'initialisation de ces champs. Plusieurs cas peuvent se présenter:
- initialisations susceptibles de propager une exception
- initialisations par chargement d'une ressource (ex: peuplement d'un objet Properties)
- initialisations par recherche de service (avec ServiceLoader)

On y arrive mais en torturant la grand-mère .... A ce stade je ne suis pas encore totalement convaincu.

[thelvin]

Mouais mais bon c'est précisément le genre de trucs qui, en principe, n'ont rien à faire dans une interface.

[professeur shadoko]

Mouais mais bon c'est précisément le genre de trucs qui, en principe, n'ont rien à faire dans une interface.

A tout bon principe on trouve des exceptions (et j'en ai).
Je soupçonne quand même des raisons plus fondamentales ....

[thelvin]

Ma foi, d'autres avis (ou un lien expliquant directement les raisons de départ du choix) ne me déplairaient pas non plus.

[tchize_]

Je crois que si les méthodes utilitaires que tu rajoute dans ton interface ont besoin d'un état (même statique), le plus propre, c'est de créer une classe utilitaire, et de limiter tes méthodes par défaut de l'interface à des appels vers cette classe utilitaire.

Pour moi un interface ça n'a pas lieu d'avoir un état.

A noter que c'est plus une règle liée au language, qu'une contrainte de la jvm. Tu peux créer, à priori, des interfaces avec toute ce que tu veux dans le bloc static, pourvu que tu trouve un compileur qui laisse passer ça

Faudrait voir comment ça se justifie dans la spec 8, mais je suppose que ce serait comme dans la spec 7, il n'y aura simplement pas de chapitre "static initializers" dans la section interfaces de la specs

[professeur shadoko]

Je crois que si les méthodes utilitaires que tu rajoute dans ton interface ont besoin d'un état (même statique), le plus propre, c'est de créer une classe utilitaire, et de limiter tes méthodes par défaut de l'interface à des appels vers cette classe utilitaire.

Pour moi un interface ça n'a pas lieu d'avoir un état.

Tirons un peu les choses par les cheveux: il n'est pas nécessairement question d'état. Imaginons N classes qui implantent l'interface X et pour lesquelles on veut que l'initialisation de load-time provoque au moins une fois les opérations d'initialisations de load time de l'interface. Une méthode par défaut ne fait pas ça.

A noter que c'est plus une règle liée au language, qu'une contrainte de la jvm. Tu peux créer, à priori, des interfaces avec toute ce que tu veux dans le bloc static, pourvu que tu trouve un compileur qui laisse passer ça

effectivement on trouve dans le binaire des opérations de load-time de l'interface qui ont déjà été mises en douce par le compilo.

[tchize_]

Pour moi, ça n'a pas à être dans l'interface .

Si j'implémente ton interface par un stub pour un unit test, t'as pas envie que ton stub aille tripatouiller la base de données parce que le dev de l'interface a supposé que chaque implémentation irait trifouiller cette base.

Une interface c'est un markeur de contrat, et ce contrat précise quelles sont les méthodes disponibles. Ca s'arrête là. Si il faut des comportement associé, alors c'est une classe abstraite qu'il te faut ou une classe utilitaire, mais pas une interface


Maintenant, tu as peut être ce besoin, mais ce n'est pas compatible avec le langage. Mais j'ai du mal à voir un cas concret, ça aiderait si tu en donnais un. Déjà avec des classes, j'ai extrêmement rarement des bloc statiques d'initialisation (et honnêtement, la seule fois ou j'en ai croisé un gros dans un code, j'avais surtout envie d'étriper le dev qui l'avait écrit).

Après, tu peux toujours contourner avec un champ final et mettre le code dans le constructeur de la classe concernée, mais c'est de la bidouille

Code :

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

1
2
3
4
5
public interface X {
   public static final Object o = new Object(){{
       // code d'initialisation
   }};
}