Pourquoi, et qu’est-ce au juste que cette directive  ?

Dans la norme OSGi, il est indiqué que “singleton” (renseigné dans l’entrée de MANIFEST Bundle-SymbolicName) doit être placé à true lorsque l’on souhaite interdire la résolution par le framework de plusieurs versions d’un même bundle.

C’est donc tout à fait logique qu’un plug-in amenant des extensions ou des points d’extension soit impérativement un singleton ; car il serait sans cela très difficile, voire impossible, de gérer les différentes versions résolues au runtime…
Imaginez simplement un plug-in amenant une vue, que l’on pourrait déployer dans deux, trois, … versions différentes au sein du même Eclipse : à quoi devrait-on s’attendre lors de l’affichage du menu “Show View > Other…” ???

Dans le cas où on écrit un plug-in n’amenant ni extension ni point d’extension —un plug-in de librairies, par exemple—, on sera en revanche ravi de pouvoir dire que ce n’est pas un singleton (c’est le comportement par défaut), et ainsi faire coexister différentes versions de nos librairies dans le même Eclipse. C’est d’ailleurs exactement ce qui se passe avec les plug-ins ICU, Ant ou log4j, dont les utilisateurs viennent dépendre en venant préciser le numéro (ou l’intervalle) de version qui les intéresse…

Pour l’ajouter, allez dans Window->Preferences->Java->Editor->Templates ; puis créez un nouveau snippet que vous appelerez… au hasard … “singleton” !

Vous pouvez éventuellement vous créer des variantes pour avoir également une version thread-safe, une autre non “lazy-loadée”, etc…

[sourcecode language='java']
private static ${enclosing_type} instance;

private ${enclosing_type}(){}

public static ${enclosing_type} getInstance(){
if(null == instance){
instance = new ${enclosing_type}();
}
return instance;
}
[/sourcecode]