它更有可能是一个主观的问题。我想创建第三方API的子类以自定义行为，但是问题是API类中的方法之一是具有默认访问说明符，因此我不允许覆盖，因为我的子类不在同一包中。
但是，如果我想要一个解决方案，我可以将我的子类与API类相同的软件包中，并扩展具有默认访问说明符的方法。第三方JAR文件是根据允许X11类型许可（类似于MIT许可）许可的
我正在寻找以下查询的答案
在第三方罐子外创建子类（不同的jar文件）但保持类似的软件包转换是合法的吗？
这种方法的任何已知问题（即使同一包名称，我都保留在两个罐子中）（我刚刚单独使用单位测试进行了测试）
在这种情况下，应用程序服务器的类加载器如何行为（首先将加载哪个JAR文件）
表示歉意，如果我的查询（1）与许可证不适用。
预先感谢。
for（1）：X11许可证基本上说您可以使用该软件做任何事情，只要您归功于作者，并且不要起诉他们违反保修。您的建议没有任何违法。
虽然您的建议应该起作用，但这是hackish。问题是第三方库正在使用其部分API的过度严格访问规范。最好的方法是向开源项目提交补丁。
您的修补程序应简单地将所讨论的方法指定为protected而不是软件包 - 私有化，这将允许子类调用该方法（以及库中包装中的其他类别，因为protected包括包含软件包 - 捕性访问访问）。这样，它也将帮助库的其他用户扩展类。
-
我无法回答您的第一个问题，因为我对此没有足够的了解：）
-
这取决于您的classloader。在常见的情况下，它首先看到的类将被加载。第二个将被省略。我不会在这里依靠ClassLoader解决顺序，您唯一可以确定的是将从Class Path读取资源。因此，如果您的班级路径是
c:a;c:b您有2个具有相同名称的文件和包装，该文件将首先加载在" A"中的文件。 -
在应用程序服务器内部的类负载程序通常由特定服务器的供应商实现。例如，战争通常装有自定义类负载器，不同的classloaders用于不同的战争。耳朵相同。类负载器通常在应用程序服务器中包含层次结构。
因此，即使在技术上有效，它也可能会引起很多头痛。
如果它是一个开源项目，我认为最好的是将您的补丁提交给开源社区，甚至汇编您自己的版本（如果许可证允许SO）。
希望这有帮助