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.
> If ServiceLoader isn't the right approach, what would be a more modular
> approach?
Well, I won't claim to have a full grasp of all of the issues around
this, since I have only looked at it in passing. I think the
ServiceLoader concept is an improvement in Java 6, since it at least
attempts to centralize lookups, but I am not sure about its capabilities
for hooking into the lookup.
I think this would be a great topic about which to have a detailed
discussion.
-> Richard
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>