扩展Java第三方API

Question

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

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

许可的

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

  

  

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

  

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

  

3. 应用服务器的类加载器如何在这种情况下运行（首先加载jar文件）

  

如果我的查询（1）与许可证相关不适用，请致歉。

提前致谢。

Answer 1

对于（1）：X11许可证基本上表示您可以对软件做任何事情，只要您信任作者并且不因违反保证而起诉他们。你的建议没有任何违法行为。

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

你的补丁应该简单地指定有问题的方法protected而不是package-private，这将允许子类（以及库的包中的其他类）调用它，因为protected包括包私人访问）。这样，它也可以帮助图书馆的其他用户扩展课程。

Answer 2

1. 我无法回答你的第一个问题，因为我对此知之甚少：）

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

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

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

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

希望这有帮助