dev@glassfish.java.net

Re: [v3] exporting all Metro packages for OSGi

From: Bill Shannon <bill.shannon_at_sun.com>
Date: Thu, 21 Aug 2008 13:59:32 -0700

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?