Excellent point. So the desired behavior is that DS can call any method the declared implementation class could call itself.
So then, DS can call activate/deactivate/bind/unbind methods of any visibility (private, default, protected, public) if the method is defined by the implementation class declared in the component description. But, if the method is defined by a super class of the declared implementation class, DS will only call it if the method has public or protected visibility or if it has default visibility and the super class is in the same package as the declared implementation class and loaded by the same class loader as the declared implementation class. I will propose this change to the DS spec. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 From: "Fredrik Alströmer" <[EMAIL PROTECTED]> To: "OSGi Developer Mail List" <[email protected]> Date: 2008/12/03 10:35 Subject: Re: [osgi-dev] DS / method visibility...? Sent by: [EMAIL PROTECTED] Hi BJ, thanks for you're answer, although default-visibility methods are not private, they're still not callable from the class hierarchy if the class is not in the same package. However, the activate/bind methods are perfect candidates to be used by unit-tests, and these are often depending on the package-protected visibility. Wouldn't be easier in that case to define it as 'whatever the implementation class would be able to call', i.e. in the class itself, even private methods may be called, in parent classes protected and public are always callable and default is callable if it's the same package as the implementation class? I assume since SCR is using reflection and traversing the hierarchy anyway, such a check should be fairly cheap. It's also making the spec more consistent with the Java environment, as you're suggesting is the (quite reasonable i might add) rationale behind it, without adding complexity. Greetings, Fredrik. On Wed, Dec 3, 2008 at 15:50, BJ Hargrave <[EMAIL PROTECTED]> wrote: > The reasoning is inheritance. Since a component implementation class can > extend some other class, we wanted DS to only call methods which would be > callable by the implementation class declared in the component description. > If we allowed DS to call private methods, then this breaks the visibility of > the class hierarchy. It would allow someone to extend some class and have DS > call its private methods. > -- > > BJ Hargrave > Senior Technical Staff Member, IBM > OSGi Fellow and CTO of the OSGi Alliance > [EMAIL PROTECTED] > office: +1 386 848 1781 > mobile: +1 386 848 3788 > > > From: "Fredrik Alströmer" <[EMAIL PROTECTED]> > To: "OSGi Developer Mail List" <[email protected]> > Date: 2008/12/03 04:33 > Subject: [osgi-dev] DS / method visibility...? > Sent by: [EMAIL PROTECTED] > ________________________________ > > > Hi, > > perhaps this question has been asked many times before, but here goes > anyway: > > What's the rationale behind the fact that all methods that should be > called by DS should be public or protected? Why is it not 'not > private' (i.e. including default)? > > Thanks, > Fredrik. > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
