David M. Lloyd
david.lloyd at redhat.com
Thu Feb 12 13:44:45 UTC 2015
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.
More information about the jpms-spec-observers