在纯java中拆分包

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

在纯java（没有OSGi）中，是否存在拆分包可能带来问题的边缘情况

---

只是好奇。

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

---

所以在普通Java中，这通常不是问题，除非您开始使用一些使用类装入器的框架。加载组件时通常就是这种情况。

跨jar拆分包可能不是一个好主意。我建议密封JAR中的所有包（在清单的主要部分放置

“sealed:true”

）。密封的包装不能在罐子之间分开

---

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

您这样问是因为所涉及的包是您的，而不是第三方代码

一个简单的例子是一个web应用程序，其中服务层和持久层作为单独的OSGi捆绑包。持久性接口必须由两个包共享

如果我正确地解释了您的问题，那么解决方案是创建一个包含共享接口的密封JAR并使其成为两个包的一部分吗

---

我不是想劫持线程。我要求那些到目前为止可能对OSGi做得比我更多的人做出澄清和更好的见解。

如果在同一个包中有类，并且有些类在签名的JAR中，而另一些则不在其中，那么您将遇到严重的运行时错误。

拆分包来自何处 在OSGi中，当使用清单头

requirebundle

时（我相信Eclipse清单中就是这样），就会出现拆分包

Require Bundle

命名用于搜索类的其他Bundle（如果包未

Import

ed）。搜索发生在搜索bundles自己的类路径之前。这允许从多个bundle（可能是不同的jar）的导出中加载单个包的类

OSGi规范（4.1）第3.13节描述了

Require Bundle

，并列出了使用此标头（是否应弃用此标头？）的一长串（意外）后果，其中一节专门介绍了拆分包。其中一些后果是奇怪的（相当于OSGi特有的），但如果您了解一件事，大多数后果是可以避免的：

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

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

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

“标准Java”中发生了什么 在标准Java中，没有花哨的类加载器，您就有一个类路径，要加载的类的JAR（和目录）搜索顺序是固定且定义良好的：您得到的就是您得到的。（但随后，我们放弃了可管理的模块化。）

当然，您可以使用拆分包—事实上这很常见，这表明模块性较差。症状可能是晦涩难懂的编译/构建时错误，但在多个类实现的情况下（在单个类路径中，一个超过其余的），由于语义上的细微差异，它通常会产生晦涩难懂的运行时行为

如果你是幸运的你最终看到了错误的代码，却没有意识到这一点，并问自己“这怎么可能呢？”
如果你是不幸的你看到了正确的代码，并且问了完全相同的问题，因为其他事情产生了意外的答案

---

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

进一步反省，即使像Tomcat这样的web容器也有不同的类加载器：catalina和webapps。所以这可能会带来一些问题。是的，这些包裹是我的。从根本上说，问题是如何设计软件包的布局并使其模块化。然后我要说，公共接口需要打包到单独的罐子中，罐子可以是两个模块的一部分。Steve，这是一个非常清楚的解释。因为我将代码划分为许多小的maven构件，所以现在我努力为所有构件分配一个唯一的基本包名称。