Bill Shannon wrote:
> Richard S. Hall wrote:
>> Bill Shannon wrote:
>>> 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.
>>
>> Right. Hypothetically, if ClassLoader.loadClass() is modified in the
>> future to return a module private class to member classes of the
>> module and an exception for non-member classes, then you would have
>> an issue.
>
> So, are we back to ... you *should* export such implementation classes
> so that ServiceLoader can load them?
In such a future with VM support, I would say yes. This is somewhat
ugly, but not much can be done about it. What you really want to have
happen is that the service provider publishes their own services using a
common Factory interface (in OSGi this could be published into the
service registry), so that no one would ever need to know their
implementation class, but at least if it can be limited to the
ServiceLoader, that is better than nothing.
> Great! When and where? :-) Let's include the JDK guys...
>
> (I know, this is not a high priority item right now...)
I am pretty much always available for discussions.
-> richard
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>