Enhanced ServiceLoader?

[David M. Lloyd]

I agree that consistent ordering is an important property.  I think it's 
a given that more than one provider will often be available for some 
particular service; you wouldn't want a situation where (to be 
specifically pathological) one application could be started twice, each 
time getting different providers for such services.

Explicit ordering *should* be possible as well though, at least within 
some specific well-defined bounds (e.g. a single service loader provider 
file should always be reported in order as it is today).  I don't think 
the requirements as stated forbid that at least.  And I would hope that 
explicit ordering at the module level should be achievable through the 
use of configurations, though that section in general needs some more 
thought and discussion I suspect.

On 02/12/2015 02:20 AM, Peter Kriens wrote:
> 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
>

-- 
- DML