假设甚至有可能，您对在不同平台发行版之间实现捆绑兼容的建议是什么？特别是在R3和R4之间。
有关我的要求的最新信息：
这个想法是为当前运行OSGi R3容器的嵌入式设备开发一个Web界面，但是可以很快将其升级到R4（我们对此没有太多控制权）。 Web界面将使用OSGi HTTP服务进行部署。我看到三个选择：
使用R4进行应用程序处理，因为我已经发现某些Web工具包不适用于较早的发行版。我想设备的提供者可以毫不费力（但不确定）在R4上部署当前的R3捆绑包。
使用R3实现Web界面，而没有现代Web工具包的好处（或者向我推荐）。
使用某些R4捆绑包执行此操作，但是以某种方式与发布无关，因此我们最终可以将其部署在R3或R4上。
最佳答案
通常，R4大多为捆绑清单引入了新的标头，R3的实现忽略了这些标头。导入/导出行为在语义上存在一些差异，但是取决于您制作的捆绑类型，这些可能并不重要。您可以使用的一种策略是简单地创建R3捆绑包，该捆绑包在R4框架上仍然可以正常工作。在这种情况下，您肯定会错过一些新的R4功能。
跟进：
从HttpService的角度来看，从R3到R4.2没有太大的变化。前者使用HttpService的1.1规范，后者使用1.2。差别很小（规范使用API文档中的@since标记来说明什么时候引入了什么方法）。
R3捆绑包确实像R4一样工作，这是完全正确的。请记住，尽管在实践中您可能会在R4中运行R3捆绑软件时发现错误。当R4刚发布时，我将一个大项目从R3迁移到R4，我们遇到了很多小问题，都是我们自己的错误，这些错误导致捆绑软件在R4上快乐地运行时在R4上失败。这些通常与R4实现有关，通常在委托给其父类加载器时更为严格。确保在要对其进行部署的框架上测试捆绑包。
我想知道，您看过的Web工具包不能在R3上工作吗？它们是否依赖于HttpService 1.2？我想自己在R3上运行1.2或将其桥接到1.1实现并不难。