From: Craig L Russell <Craig.Russell_at_Sun.COM>
Date: Thu, 21 Aug 2008 14:10:26 -0700

On Aug 21, 2008, at 1:59 PM, Bill Shannon wrote:

> Craig L Russell wrote:
>> On Aug 21, 2008, at 1:21 PM, Bill Shannon wrote:
>>> Craig L Russell wrote:
>>>> Apropos of:
>>>>> We already had to export a lot of supposedly private packages
>>>>> that contained classes that were looked up through META-INF/
>>>>> services.
>>>> I'm interested in the answer to this question:
>>>> If an OSGi-enabled jar file has an entry in META-INF/services/foo
>>>> and the contents of the file foo is
>>>> com.sun.fooservice.Foofactory, does com.sun.fooservice have to be
>>>> exported?
>>>
>>> I'm curious too. I assume the answer is "yes".
>>>
>>> Or at least it's a "should", if not a "must".
>> Ok, I'm of the opinion that if the service is self-contained in the
>> jar file, and all of its dependencies are listed as imports, then
>> the implementation class should not (best practice) be exported.
>> This preserves encapsulation since only the ServiceLoader needs to
>> know anything about the package.
>> By the way is there any interaction between ServiceLoader and OSGi?
>> (I know, RTFM ;-)
>> Here's what Richard Hall has to offer, which I agree with:
>>> It depends on how you want to use it, but I would say no. It only
>>> has to be on the Bundle-ClassPath, so you should be able to load
>>> it from the bundle's class loader, which is the main requirement.
>
> 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?

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").

Craig
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>

Craig L Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell_at_sun.com
P.S. A good JDO? O, Gasp!