Enhanced ServiceLoader?

[Tim Boudreau]

*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