Home/ Questions/Q 8108977
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-06T01:16:35+00:00

I know that the specification exactly defines it but cannot get what is the

  • 0

I know that the specification exactly defines it but cannot get what is the reason for this:

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

Let’s assume:

  1. A bundle declares “import-package: a”
  2. There is a local class a.X in this bundle
  3. There is a class a.X in another bundle

new a.X() would load the class from another bundle.

What is the reason that imported classes take precedence over bundle classes? Is it just a consequent continuation of java hierarchical class loading policy?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    This is actually a core aspect of OSGi.

    Sharing classes

    The whole import/export mechanism is intended to let different bundles use the same class when communicating. Same in this case means not only binary equal, but loaded by the same class loader (recall that every bundle has its own class loader). If the bundle’s own classes would be favored over imported ones, bundles would not be able to ‘agree’ on which copy of a class to use.

    But… why?

    Why would you have a copy of a class, which you also intend to import?
    Consider a situation in which you want to do some logging, so you import org.osgi.service.log, but it’s not a vital aspect, you can happily run without a LogService present. Now,

    • if you would only import the package, your bundle would fail to resolve, and thus fail to start, and
    • if you would only include the class, you would never use the other bundle’s LogService class, so you cannot use the service (this is the agreeing part).

    In this situation, you both import and include the class, so you can run in either situation, using your own copy when no one else has one, and sharing a copy if someone else does. You can even choose to export your copy, and let the framework decide.

    As a sidenote, this is exactly the reason you should (almost) always import what you export.

    • 0