Michael, Yes, sorry for not being precise. Imports shadow both private *and* public packages.
That is, if bundle A imports com.foo and also contains and exports com.foo, then the framework can choose to import com.foo from another bundle, and this will override both bundle A's internal use of the package and the export. In fact this is the rule rather than the exception, see section 3.5.6, "Exporting and Importing a Package". It is good practice to import the packages we export, since this allows the framework to reduce the number of isolated class spaces it creates. Neil On Mon, Aug 30, 2010 at 4:53 PM, Michael Yuan <[email protected]> wrote: > Hi Neil, > > Thanks for your quick response. You are saying import packages could shadow > private packages, but my concern is why public packages are not in the class > space. In my understanding, import packages could shadow both public/private > packages: half of private packages could not be in the class space as well, > but figure 3.10 only show half of public package is not in the class space. > > Regards, > > Michael > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Neil Bartlett > Sent: Monday, August 30, 2010 11:25 AM > To: OSGi Developer Mail List > Subject: Re: [osgi-dev] question about class space in OSGi R4 core > > Michael, > > "Private packages" merely means the packages that are not exported by > a bundle. They are only visible within that bundle, hence "private". > In contrast, a package that is exported is "public". > > The class space of a bundle can of course also include the public > packages of that bundle. However, note that imported packages and > required bundles are listed *before* private packages, since they take > precedence. If bundle A both imports package com.foo and contains > com.foo somewhere in its Bundle-ClassPath, the imported package wins > (so long as the import is satisfied). > > This is the reason why only half of the public packages of bundle A in > figure 3.10 are shown as being in the class space. Although the figure > does not say so explicitly, those packages are likely shadowed by > imports from either bundle B or bundle C. > > Regards > Neil > > On Mon, Aug 30, 2010 at 4:03 PM, Michael Yuan <[email protected]> wrote: >> Hi, >> >> >> >> I am reading OSGi Service Platform Core Specification Release 4, Version >> 4.2. In Section 3.4(Class Loading Architecture, page 37-332), it describes >> the definition of class space as follows: >> >> >> >> A class space is then all classes reachable from a given bundle’s class >> loader. >> >> Thus, a class space for a given bundle can contain classes from: >> >> >> >> • The parent class loader (normally java.* packages from the boot class >> >> path) >> >> • Imported packages >> >> • Required bundles >> >> • The bundle's class path (private packages) >> >> • Attached fragments >> >> >> >> I am wondering why there is a comment on this item: >> >> >> >> • The bundle's class path (private packages) >> >> >> >> Does that mean a class space cannot contain classes from public packages? >> Actually, in Figure 3.10(page 38-332), half of bundle A’s public is in >> class space for bundle A, half of the public is not. >> >> Can someone help me understand this? >> >> >> >> Thanks, >> >> Michael >> >> --- >> This communication may contain confidential and/or privileged information. >> If you are not the intended recipient (or have received this communication >> in error) please notify the sender immediately and destroy this >> communication. Any unauthorized copying, disclosure or distribution of the >> material in this communication is strictly forbidden. >> >> Deutsche Bank does not render legal or tax advice, and the information >> contained in this communication should not be regarded as such. >> >> _______________________________________________ >> 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 > --- > This communication may contain confidential and/or privileged information. > If you are not the intended recipient (or have received this communication > in error) please notify the sender immediately and destroy this > communication. Any unauthorized copying, disclosure or distribution of the > material in this communication is strictly forbidden. > Deutsche Bank does not render legal or tax advice, and the information > contained in this communication should not be regarded as such. > > _______________________________________________ > 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
