Craig L Russell wrote:
>
> On Aug 21, 2008, at 2:18 PM, Bill Shannon wrote:
>
>> Craig L Russell wrote:
>>> The only way ServiceLoader can load the class is to do a
>>> getResource("META-INF/foo") from a ClassLoader that has the jar in
>>> its resource path.
>>> So it makes sense to me that ServiceLoader should use the same
>>> ClassLoader for both getResource("META-INF/foo") and
>>> loadClass("com.sun.fooservice.Foofactory").
>>
>> I guess I need to understand exactly what the JVM module support
>> would control.
>>
>> Today it's true that I can request that private classes be loaded
>> in another class loader, even though I won't be able to use the class
>> once its loaded. I suppose the same could be true for module-private
>> classes.
>>
>> But doesn't ServiceLoader need to instantiate an instance of the class?
>> Would it be able to do that if the class were private (in a way that
>> the JVM enforced)?
>
> Yes, after loadClass, it needs to construct an instance of the class.
> ServiceLoader presumably has permissions to use methods getResource and
> loadClass and then newInstance on the class it just loaded.
>
> I don't know the details of Modules, but does it not anticipate that
> some system classes need to manipulate class loaders?
Well, there's always the security permissions that let you use reflection
and override all the restrictions. I don't know whether ServiceLoader
depends on those. Can ServiceLoader load a package-private class?
> How is OSGi itself
> able to be implemented if the system is nailed shut?
My understanding is that OSGi doesn't enforce any of the restrictions at
runtime.