I believe, the use of "DynamicImport-Package" has to be avoided whenever
possible, particularly when you're quite certain on the list of packages,
the module that's being implemented depends on. Always make it a best
practice to use selective package imports within "Import-Package" clause as
it not only helps you (and others looking at your implementation) provide a
clear view to the outside parties on the list of dependencies being used,
but also avoid the problems described in the article you've referred to.

As for the instances where this approach could be useful, like the article
itself mentions, you can use it whenever there's an absolute requirement to
let your bundle differ resolving its dependencies till the execution time.
For instance, say there's some implementation of a particular SPI that's
read from a configuration file and loaded at runtime. There, you wouldn't
probably know of the required set of classes to be loaded, etc till your
module is inititalized.

I'm pretty sure that the OSGi experts can add more to this, just thought of
sharing my experiences upon the same.

Cheers,
Prabath

On Wed, Jan 21, 2015 at 2:43 AM, Manoj Gunawardena <[email protected]> wrote:

> Hi,
> I have notice some off our OSGI bundles use this DynamicImport-Package
> option. According to the OSGI WIKI, it's use for safe side and backwards
> compatibility.
>
> http://wiki.osgi.org/wiki/DynamicImport-Package
> According to the wiki, using the wildcard is expensive. Is there any valid
> reasons to use this DynamicImport-Package our platform?
>
> Thanks
> Manoj
> --
> Manoj Gunawardena
> Tech Lead
> WSO2, Inc.: http://wso2.com
> lean.enterprise.middleware
> Mobile : +94 77 2291643
>
> _______________________________________________
> Dev mailing list
> [email protected]
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Prabath Abeysekara
Associate Technical Lead, Data TG.
WSO2 Inc.
Email: [email protected]
Mobile: +94774171471
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to