How costly is Dynamic Import Package ?

[sudheerk84]

I have use cases where i have cyclic dependencies , and i am forced to use Dynamic imports(my resolution process fails in cases of some cyclic dependencies)

Hence when trying to understand how costly it could be , i see the following quotes in OSGi reference guide.

" The key difference between these two mechanisms is when the wires are
made. An attempt is made to establish a wire for a dynamic import every time there is an attempt to load a class in that package, whereas the wire for a resolution optional package may only be established when the bundle is resolved."

Does this means when request for that package comes at runtime for the second , the first time process will be repeated ?

But this contradicts to what is said in the subsequent section of the reference guide

" During class loading, the package of the class being loaded is compared against the specified list of (possibly wild-carded) package names. Each matching package name is used in turn to attempt to wire to an export using the same rules as Import-Package. If a wiring attempt is successful (taking any uses constraints into account), the search is forwarded to the exporter’s class loader where class loading continues. The wiring must not subsequently be modified, even if the class cannot be loaded. This implies that once a package is dynamically resolved, subsequent attempts to load classes or resources from that package are treated as normal imports."

Aren't these two statements contradicting ?

[Glyn Normington]

That text is certainly confusing. An attempt to establish a wire is made each time an attempt is made to load a class from a dynamically imported package, but once a class has been loaded successfully, then the loading bundle will have a wire to the exporter and this wire will be used, with the same performance as a static import, for subsequent class loads from that package by the same bundle.

I'd like to understand why the dynamic import appears to be necessary as cyclic dependencies between bundles shouldn't really be an issue if the bundles can all be resolved together. This would be the case if all the bundles are present in the repository before any of them is deployed.