OSGi开发中应当优先选择Dynamic-Import而非Require-Bundle吗？

1. 保留Import-Package: net.sf.ehcache的同时添加Dynamic-Import: net.sf.ehcache.*能否解决类缺失问题？ #

完全可以。
你遇到类缺失的核心原因是：配置文件中隐式引用的ehcache子包类，没有被你显式声明在Import-Package列表中，OSGi框架默认不会加载未显式声明导入的包。添加Dynamic-Import: net.sf.ehcache.*后，框架会在运行时动态匹配加载所有net.sf.ehcache及其子包下的类，刚好覆盖配置文件中的隐式引用，可直接解决类缺失异常。

2. 是否应该优先使用Dynamic-Import而非Require-Bundle方案？ #

没有绝对的优先选项，需要结合你的项目需求选择，两种方案的优缺点对比如下：

• Dynamic-Import + Import-Package方案
  • 优势：符合OSGi面向包的松散依赖规范，不需要绑定具体的ehcache bundle，只要有任意bundle导出对应版本的ehcache相关包即可使用，跨版本适配性更强。
  • 劣势：会失去OSGi启动阶段的依赖预校验能力，框架不会在启动时检查所有需要的ehcache包是否存在，只有运行时用到对应类时才会抛出异常，排查问题的成本更高，同时会带来轻微的类加载性能开销。
• Require-Bundle方案
  • 优势：是bundle级别的整体依赖，ehcache bundle导出的所有包都会被自动导入，不需要你逐个声明依赖包，启动阶段就会校验ehcache bundle是否存在，不会出现运行时才发现类缺失的问题。
  • 劣势：强绑定具体的ehcache bundle，违背OSGi松散依赖的设计原则，如果后续ehcache官方拆分bundle、或者你要替换为其他兼容ehcache API的实现bundle，原有依赖会直接失效，版本适配性更差。

更推荐的折中方案 #

如果不想在两种方案里二选一，可以先排查配置文件中实际引用了哪些net.sf.ehcache的子包，把这些子包也显式添加到Import-Package列表中。既不需要用Dynamic-Import放弃预校验能力，也不需要用Require-Bundle强绑定具体bundle，是最符合OSGi最佳实践的解决方案。

内容的提问来源于stack exchange，提问作者wilx