在纯java中拆分包

Question

OSGi有一个拆分包的问题，即相同的包，但托管在多个包中。

在普通的java (没有OSGi)中，拆分包可能会带来问题吗？

只是好奇而已。

Answer 1

因为不同捆绑包中的OSGi包是不同的，不管它们的名称是什么，因为每个捆绑包都使用自己的类加载器。这不是一个问题，而是一个特性，以确保包的封装。

因此，在普通的Java中，这通常不是问题，除非您开始使用某些使用类加载器的框架。这通常是加载组件时的情况。

Answer 2

拆分包的来源

拆分包(在OSGi中)发生在使用清单标头Require-Bundle时(我相信，在Eclipse的清单中也是如此)。Require-Bundle命名用于搜索类的其他包(如果包不是Import版的)。搜索发生在包自己的类路径被搜索之前。这允许从多个包(可能是不同的jars)的导出中加载单个包的类。

OSGi规范(4.1)第3.13节描述了Require-Bundle，并列出了使用此头的一长串(意想不到的)后果(此头应该被弃用吗？)，其中有一节专门用于拆分包。其中一些后果是奇怪的(更确切地说，是OSGi特有的)，但如果你理解一件事，大多数都是可以避免的：

• 如果一个类(在一个包中)由多个包提供，那么您就有麻烦了。

如果包部分是不相交的，那么一切都应该是好的，除了您可能不会让类在所有地方都可见，并且如果从拆分包的“错误”部分查看，包可见性成员可能看起来是私有的。

当然，这太简单了-可以安装多个版本的包-但从应用程序的角度来看，在任何时候，包中的所有类都应该来自单个模块。

“标准Java”中发生了什么？

在没有花哨的类加载器的标准Java中，您有一个类路径，并且在jars (和目录)中搜索要加载的类的顺序是固定的、定义良好的:得到的就是得到的。(然后，我们放弃了可管理的模块化。)

当然，你可以拆分包--事实上这是很常见的--而且这是模块性差的表现。症状可能是模糊的编译/构建时错误，但在多个类实现的情况下(其中一个覆盖了单个类路径中的其余实现)，由于语义的细微差别，它通常会产生模糊的运行时行为。

如果你是幸运的，你最终会看到错误的代码--而没有意识到这一点--并问自己“但这怎么可能做到这一点呢？”

如果你是一个不走运的，你看到的是正确的代码，问的是完全相同的事情--因为有些东西产生了意想不到的结果。

这并不是完全不同于旧的数据库格言：“如果你在两个地方记录相同的信息，很快它就不再一样了”。我们的问题是，“很快”通常还不够快。

Answer 3

将包分散到jars中可能不是一个好主意。我建议让所有的包都密封在罐子里(把"Sealed: true"放在清单的主要部分)。密封的包裹不能在罐子里分开。

对于OSGi，具有相同包名但具有不同类加载器的类被视为位于不同的包中。