Enhanced ServiceLoader?

[Peter Kriens]

Explicit ordering requires a global view of the runtime, which is imho something you have to avoid in a modular system. 

Consistent ordering based on an intrinsic aspect is however relevant to prevent spurious failures, e.g. sorted by name.

Kind regards,

	Peter Kriens


> On 12 feb. 2015, at 04:05, Tim Boudreau <niftiness at gmail.com> wrote:
> 
> *Binding — The Java run-time system must bind service implementations to
> interfaces and make these bindings available via an enhanced version of the
> existing java.util.ServiceLoader API.*
> 
> Are there any specifics as to what is meant by "enhanced" here?
> 
> One thing that has always seemed needed here is ordering.  Specifically,
> it's common to provide an API, and a default implementation of it (which
> may be a dummy implementation - essentially there to ensure a lookup will
> never return null, or be an implementation the system should fail over to
> in tests or even a working but not optimal for every scenario
> implementation - I've seen all of the above).  You want that implementation
> to appear last in the total order of available implementations, regardless
> of load-order (ordering on the classpath, or whatever implementation deal
> generates the order they're discovered in).
> 
> To play devil's advocate, you *can* do something like define an @Ordered
> annotation with an integer value, gather all the implementations and sort
> them according to it (assuming you can enforce that they all have it, or
> there is something reasonable you can do with ones that don't).  But it
> means instantiating all available instances in order to sort them, which
> may not be desirable if you're want to lazy-load (I can think of
> complicated ways you could avoid that, but most are not good ideas).
> 
> My experience is that whenever you create a API with a set of things that
> specifies "this has no order", sooner or later someone will write code
> that, unknowingly, depends on whatever order they see in practice - so when
> in doubt, allowing explicit ordering leads to more reliable dependent code.
> 
> -Tim
> 
> -- 
> http://timboudreau.com