Enhanced ServiceLoader?

[Tim Boudreau]

>
> Well, at the very least it means, "enhanced so as to integrate it
> with the module system so that service bindings can be based upon
> the available modules rather than (or in addition to) whatever
> META-INF/services files happen to be found on the class path."
>
> The ordering of service providers is a tricky topic.
>
> I agree with Peter when he says that explicit ordering requires a global
> view of the run-time system.  That's not possible from the perspective of
> a single module, which is why an @Ordered annotation makes no sense, but
> sometimes you actually do have a global (or sufficiently-global) view.
>

Happy to hear that.  I agree, in principle, in a modular system, the pieces
don't know about each other and so ordering seems at odds with the
concept.  But reality is rarely so pure (I remember someone arguing this
exact point with regard to a UI designer insisting on a explicit ordering
of menu items where the items were contributed by modules that didn't know
about each other - thankfully, UI design won over architectural purism and
Exit stayed at the bottom of the File menu).

Sometimes the only interesting thing about ordering is the bounds -
MIN_VALUE = high-priority/low-performance-cost, 0 = don't care, MAX_VALUE =
low-priority/high-performance-cost.  Anything using the filter-chain
pattern to break a decision tree about what to do with some input into a
pluggable list of things that can process the input needs that.

The two ways this is usually seen is either comes-before/comes-after
constraints + topological sort, or ad-hoc integers.  Neither is perfect
(both NetBeans and Gnome abandoned the before/after approach because the
results are unpredictable if one of the constraints is absent);  but the
fact that it cannot be done perfectly without a universal view doesn't mean
that having nothing is preferable.


> When assembling an entire standalone application, e.g., it could well
> make sense, as I think David was trying to suggest, to allow an order to
> be specified when linking the application together.
>
> It could also make sense to allow a sophisticated application that's
> managing modules on its own, via dynamic configurations, to specify an
> order in the context of a particular configuration.


An application assembled like that is not necessarily going to have enough
knowledge of the pieces it's composed from to impose an order without some
hints from the pieces themselves - that's really the catch here.  I'll
grant that they are hints.


>   That way an app
> server could, e.g., control which providers are seen, and in what order,
> by the web apps that it hosts.
>
> In any case, I think this is a somewhat detailed (and, also, somewhat
> orthogonal) design issue which we can tackle later on, unless someone
> thinks it's critical to mention it in the requirements.
>

NetBeans did the ordering hints for years by enhancing META-INF/services
files with magic comments, e.g.

#position 1000
com.foo.Bar

It would be good if ServiceLoader could grow enough heft to handle that
role - not necessarily identically - but the feature satisfies a proven
need.

-Tim