Importing a package provides an extra level of indirection over requiring a bundle.
Consider the case of some standard API... org.standard.framework
. Suppose two companies implement this API, maybe you have bundles com.abc.framework
and com.xyz.framework
. Both of these implementation bundles would export org.standard.framework
package.
Now suppose, you need an org.standard.framework
implementation, but you don't particularly care which one. If you require either com.abc.framework
or com.xyz.framework
bundle, you are tying yourself to a particular implementation. With an import-package directive, you are letting OSGi serve as an indirection layer.
Another advantage of import-package is that your dependencies do not need to change if a package is moved to another bundle. This situation can arise during refactoring when bundles are broken up or combined.
For these reasons, OSGi spec writers now generally recommend using the relatively newer import-package directive over require-bundle. The problem is that not all of the bundles are ready for this. Many do not yet specify a version when exporting a package. This makes import-package impractical in many cases.