Richard S. Hall wrote:
>> Since ServiceLoader is loading the class, and ServiceLoader isn't in the
>> same bundle/module as the class, seems to me it shouldn't be able to
>> access the class. If the JVM were enforcing module boundaries, wouldn't
>> this fail if the implementation class isn't exported?
>
> Conceptually, that is accurate, but OSGi cannot do such enforcement. For
> OSGi, there is only one class loader that is used to load classes from a
> bundle, so if you get a reference to the class loader then you can load
> any class from the bundle that is on its bundle class path. Typically,
> bundles should not be loading classes this way and should only use their
> own class loader which will delegate appropriately.
>
> In the long run, if we get VM support for module visibility, then yes
> this could be an issue, but for me it is probably more a sign of how the
> META-INF/services approach is broken with respect to modularity.
That's why I suggested "should" rather than "must". Even if you don't
export it today, it will probably work.
But if you envision a future where the JVM supports modules, I think you're
going to need to export such classes.
If ServiceLoader isn't the right approach, what would be a more modular
approach?