2

它更可能是一个主观问题。我想创建一个第三方 API 的子类来自定义行为，但问题是 API 类中的方法之一是具有默认访问说明符，并且我不允许重写，因为我的子类不在同一个包中.

但是，如果我想要一个解决方案，我可以将我的子类放在与 API 类相同的包中，并扩展具有默认访问说明符的方法。第三方 jar 文件在许可 X11 类型许可下获得许可（类似于 MIT 许可）

我正在寻找以下查询的答案

  1. 在第三方 jar（不同的 jar 文件）之外创建子类但保持类似的包转换是否合法？

  2. 这种方法的任何已知问题（即使包名相同，我保存在两个罐子里）（我只是用独立的单元测试进行了测试）

  3. 应用服务器的类加载器在这种情况下的行为方式（首先加载哪个 jar 文件）

如果我与许可证相关的查询 (1) 不适用于此处，我们深表歉意。

提前致谢。

4

2 回答 2

1

对于 (1)：X11 许可证基本上说您可以使用该软件做任何事情，只要您相信作者并且不起诉他们违反保证。您的建议没有任何违法之处。

虽然您的建议应该可行，但它很老套。问题是第三方库对其部分 API 使用了过于严格的访问规范。最好的方法是向开源项目提交补丁。

您的补丁应该简单地指定有问题的方法protected而不是包私有，这将允许子类（以及库包中的其他类，因为protected包括包私有访问）调用它。这样，它还可以帮助该库的其他用户扩展该类。

于 2012-10-29T07:28:33.413 回答
1

  1. 我无法回答您的第一个问题，因为我对此没有足够的了解:)

  2. 这取决于您的类加载器。通常情况下，它首先看到的类将被加载。第二个将被省略。我不会在这里依赖类加载器解析顺序，唯一可以确定的是资源将从类路径中读取。因此，如果您的类路径是 c:\a;c:\b 并且您有 2 个同名文件并打包，则将首先加载位于“a”中的文件。

  3. 在应用服务器内部，类加载器通常由特定服务器的供应商实现。例如战争通常使用自定义类加载器加载，不同战争的不同类加载器。耳朵也是如此。类加载器通常包含应用服务器中的层次结构。

因此，即使它在技术上有效，将来也会引起很多麻烦。

如果它是一个开源项目，我认为最好的办法是将你的补丁提交给开源社区，甚至编译你自己的版本（如果许可证允许的话）。

希望这可以帮助

于 2012-10-29T07:35:47.950 回答