On 19/04/2020 16:05, Uwe Schindler wrote:
Hi Alan,
from what I understood: He has some utility method in a shared class that wraps
ServiceLoader to discover services and do something with it (the usual way to
prevent code duplication). Problem is that ServiceLoade.load() is
caller-sensitive, so a shared utility method only sees the services that the
modules is allowed to see.
I answered on this in another mail: He can have a shared utility class, but the
ServiceLoader instance should NOT be instantiated inside the utility class.
What you suggest is to additionally open the shared module to allow reading
services, which looks wrong.
Unfortunately, the caller-sensitiveness of ServiceLoader.load() cannot easily
be seen from the Javadocs. IMHO there should be some improvements on this. I
was stumbling on this, too.
The ServiceConfigurationError specified by each of the load methods does
try to make it clear it will be thrown when the module does not declare
that is uses the service. The exception should be clear too. I agree
that addUses is not easy to find but it is right method for these scenarios:
"This method is intended for use by frameworks that invoke ServiceLoader
on behalf of other modules or where the framework is passed a reference
to the service type by other code. This method is a no-op when invoked
on an unnamed module or an automatic module."
So it's just adding a use-edge at run-time, it's not opening any
packages or changing the readability.
-Alan.
