Service Providers and versioning

[Alan Bateman]

On 18/04/2012 19:04, Jesse Glick wrote:
>
> It may be useful to point out that there are two related but distinct 
> features Jigsaw currently forgoes:
>
> 1. Declaring a dependency on a service matching some attribute - in 
> other words, rejecting an attempt to resolve the module when some 
> service providers are present but not the "right" one. While the app 
> module could of course just emit a graceful message if it does not 
> find the desired signature algorithm, you might want a DSL in module 
> metadata for specifying such dependencies ahead of time. (For example, 
> OSGi 4.3 "capabilities" can be annotated with attributes you can match 
> on.) This could be interpreted not just by the module system runtime, 
> but by native packaging schemes too - so that "sudo apt-get install 
> signing-app" would prompt to install also java-ecdsa-8.deb (or 
> whatever), rather than installing every known provider or none of them.
>
> 2. Directly loading ECDSASignature. While you can simply iterate every 
> Signature implementation and check impl.getAlgorithm().equals("ECDSA") 
> until you find the one you want, this adds startup overhead and 
> pollutes the PermGen with unused providers. ServiceLoader's API cannot 
> do any better, which is why other frameworks exist which can inspect 
> service metadata without triggering class loading, such as 
> sezpoz.java.net and Eclipse extension points.
Yes, with ServiceLoader then it's the user of the API that selects the 
specific provider for cases where they require specific capabilities or 
there is other selection involved. We haven't changed this in Jigsaw. On 
the performance point then one difference with Jigsaw is that the 
searching and the parsing of the configuration file is eliminated. Also 
the provider implementation classes are loaded lazily so implementations 
of a particular service type will only be loaded if someone iterates 
through all of them.

-Alan.