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

Reply via email to