Discussion :

[le y@m's]

Bonjour,

Je viens d'écrire un petit article qui présente l'utilisation des services Java.
http://ydisanto.developpez.com/tutoriels/java/services/

Bonne lecture.

le y@m's

[Aldian]

La complexité (requiert un fichier de config externe) est difficile à justifier. Si mon interface se nomme IAuthenticate, je préfère que le module chargé de l'implémentation possède une factory AuthenticateFactory implémentant l'interface IAuthenticateFactory

Ensuite de quoi dans le code qui fait appel au module, j'ai quelque chose du genre

Code :

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

1
2
IAuthenticateFactory authFact = (IAuthenticateFactory) Class.forname("mon.package.ma.AuthenticateFactory").newInstance();
IAuthenticate aut = authFact.getAuthenticate();

Je vous fait grâce du traitement des exceptions que peut générer ce code. Ce code impose l'existence d'un factory de nom fixe dans le sous module, mais par contre il permet d'éviter d'avoir recours à un fichier de propriétés. Avec l'expérience, les fichiers de config en java font moins peur, mais pour les gens qui débutent, je me souviens que c'était pas de la tarte.


J'en viens à ma question: qu'apportent vraiment de plus les services java comparé à la méthode alternative que je viens de donner et qui permet a priori d'aboutir au même résultat?

[Deaf]

J'en viens à ma question: qu'apportent vraiment de plus les services java comparé à la méthode alternative que je viens de donner et qui permet a priori d'aboutir au même résultat?

D'un point de vue organisation d'un projet, je trouve peu pratique d'imposer un nom de classe et donc de package. Si j'avais envie de sceller mon JAR, je serais alors obligé d'exclure la factory.

Avec la solution de la factory statique, tu es moins souple. Essaie d'imaginer la procédure à suivre pour remplacer ton implémentation par une autre, de préférence sans avoir à recompiler. C'est un point important car quand tu dois faire fonctionner ton logiciel et que tu n'es pas sur ton poste de travail, tu dois faire avec ce que tu as. Cela peut être très pratique de remplacer un module défaillant par un module prévu pour le debuggage.

Mais le point le plus important qui me vient à l'esprit et qui est évoqué dans l'article, c'est le fait de pouvoir avoir plusieurs implémentations de ton service. Pour t'en sortir avec la factory statique, il va falloir jongler avec les classloaders. Ce qui me semble plus difficile que d'utiliser un fichier de configuration.

[bugsan]

@Aldian

Dans ton exemple tu es obligé de connaitre la classe d'implémentation.

Quand on utilise les fameux fichier META-INF/services, on ne présage aucune implémentation. C'est l'ajout d'un jar d'implémentation qui active le truc ...
D'ailleurs il me semble que le ServiceLoader ne se base pas uniquement sur les META-INF/services, et regarde également dans les System.properties.

C'est très utilisé par les API XML. C'est relativement rare d'avoir à implémenter ce genre de chose...

[le y@m's]

D'ailleurs il me semble que le ServiceLoader ne se base pas uniquement sur les META-INF/services, et regarde également dans les System.properties.

Le ServiceLoader utilise exclusivement les répertoires META-INF/services, il n'utilise jamais les System.properties .

[micromy]

Bonjour,

Merci pour cet exemple et cet article, cette fonction est intéressante, même si certains préfèrent les proxys

j'ai relevé [ou plutôt : Eclipse n'a pas aimé...] un petit bug dans l'implémentation de Authenticator.java :
l'argument "password" de la méthode authenticate est déclaré comme String alors que la variable "password" issue du console.readPassword est de type tableau de char.
Comme l'implémentation de cette méthode dans StubAuthenticator a bien "password" en char[], je suppose que c'est dans l'interface qu'il y a une coquille...

[le y@m's]

j'ai relevé [ou plutôt : Eclipse n'a pas aimé...] un petit bug dans l'implémentation de Authenticator.java :
l'argument "password" de la méthode authenticate est déclaré comme String alors que la variable "password" issue du console.readPassword est de type tableau de char.
Comme l'implémentation de cette méthode dans StubAuthenticator a bien "password" en char[], je suppose que c'est dans l'interface qu'il y a une coquille...

C'est corrigé de l'avoir signalé.

[Aldian]

@Aldian

Dans ton exemple tu es obligé de connaitre la classe d'implémentation.

Je pense que vous avez lu un petit peu trop vite. Mon implémentation ne pose aucun souci du point de vue du remplacement d'un module par un autre. La seule chose sur laquelle je m'engage, c'est sur le fait que tout module doit contenir un factory nommé AuthenticateFactory implémentant l'interface IAuthenticateFactory, qui est donc connue de la même manière que l'interface IAuthenticate est connue.


Mais à aucun moment, je n'ai besoin de connaitre l'implémentation concrête du factory. Je suis totalement libre de la changer d'un module à l'autre du moment que le nom est conservé et l'interface implémentée. Par conséquent vos objections concernant la perte de l'abstraction ne tiennent pas .


Merci pour les autres commentaires

[le y@m's]

Je pense que vous avez lu un petit peu trop vite. Mon implémentation ne pose aucun souci du point de vue du remplacement d'un module par un autre. La seule chose sur laquelle je m'engage, c'est sur le fait que tout module doit contenir un factory nommé AuthenticateFactory implémentant l'interface IAuthenticateFactory, qui est donc connue de la même manière que l'interface IAuthenticate est connue.

Mais à aucun moment, je n'ai besoin de connaitre l'implémentation concrête du factory. Je suis totalement libre de la changer d'un module à l'autre du moment que le nom est conservé et l'interface implémentée. Par conséquent vos objections concernant la perte de l'abstraction ne tiennent pas .

Et comment fais tu pour avoir plusieurs implémentations ? Tu écris X fois une Factory avec le même nom que tu mets dans chacun de tes jars ? Que va te donner un Class.forName() dans ce cas ? Comment vas tu récupérer toutes les implémentations ?
Ce que tu dis est peut être valable dans le cas où tu ne veux qu'une seule implémentation, mais pas si tu veux gérer une collection de plugins/modules (ce pour quoi est conçu le ServiceLoader).

[Aldian]

Non je n'écris qu'un seul factory, mais lors de l'appel de la méthode IAuthenticate aut = authFact.getAuthenticate(); du factory, je passe en paramètre une string qui indique l'implémentation qui m'intéresse. Ce n'est donc pas un problème rédhibitoire non plus, mais je vois bien où tu veux en venir: ça introduit la nécessité de réécrire le factory chaque fois qu'on ajoute une possibilité d'implémentation. Merci de ta patience .

[le y@m's]

@Aldian

Comme vous le soulignez il est effectivement préférable d'utiliser une factory, je suis parfaitement d'accord avec vous et c'est d'ailleurs ce qui est dit dans la javadoc du ServiceLoader.
Mais je ne me suis volontairement pas attardé sur le coté "design" car je voulais un tutoriel simple qui se contentait de présenter la technologie.

L'avantage des services Java sur la méthode que vous présentez est tout simplement l'abstraction. Dans votre exemple le nom de l'implémentation (en tout cas de l'implémentation de la factory) est écrit en dur dans le code... votre code fait donc directement référence à l'implémentation, l'abstraction est perdue. Votre code revient à écrire

Code :

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

IAuthenticateFactory authFact = new AuthenticateFactor();

A la différence qu'il utilise la réflexion inutilement (je ne m'étendrais pas sur la mauvaise utilisation de la réflexion).
Si demain vous voulez changer l'implémentation de la factory vous êtes bon pour changer votre code (certes une seule petite ligne mais ça suffit), recompiler votre application et la réinstaller chez votre client.

C'est là qu'est la "justification" du fichier de déclaration qui sert juste à dire "hey, moi j'implémente telle interface" pour pouvoir être listé par le ServiceLoader. Typiquement vous placerez ce fichier dans un jar contenant votre implémentation et vous ajouterez ce jar au classpath de l'application. Ce qui ressemble assez fortement au concept de module/plugin vous en conviendrez.
Et je ne pense franchement pas que l'écriture de ce simple fichier ajoute une complexité faramineuse, au contraire je trouve ça assez mineur au vu du gain apporté.


[edit] grilled [/edit]