Java 是否可以从jar中编织一些类，同时排除其余的类？

我试图用新功能扩展第三个lib代码

由于我只需要在一个类的一个方法周围注入一些代码，我想我可以：

分叉项目并应用我的更改（

似乎有些草率，每当我尝试升级到新版本的lib时，肯定需要做大量工作，更不用说许可噩梦了

）

使用[AOP]从一个巨大的jar中的一个类截取一个方法（

似乎更干净

），并注入额外的测试

如果你们中有人想知道，有一个类不是Springbean，并且在代码中使用得很深，所以我不能简单地扩展它并重写/包装该方法，它至少需要两层额外的extend&override/wrap。因此AspectJ&AOP似乎是更好的选择

我设法用一些插件来设置我的项目，以调用

ajc

，并在

-inpath

参数中用我想要的jar编织代码。唯一的问题是，

ajc

似乎编织了一切（或者至少复制了它）

---

所以我需要的基本上是要求

AJC

简单地从那个jar中波动那个类，而不是整个jar

正如您所注意到的，AspectJ编译器总是输出weave依赖项（在JAR中）中找到的所有文件，无论它们是否更改。不能通过命令行AFAIK更改此行为。所以你需要自己包装你的罐子

下面是一个包含Maven POM的示例项目，向您展示了如何做到这一点。我选择了一个涉及Apache Commons编解码器的相当愚蠢的例子：

示例应用程序：

应用程序base64对文本进行编码，再次解码并将两个文本打印到控制台

package de.scrum\u master.app；
导入org.apache.commons.codec.binary.Base64；
公共类应用程序{
公共静态void main（字符串[]args）引发异常{
String originalText=“你好，世界！”；
System.out.println（originalText）；
byte[]encodedBytes=Base64.encodeBase64（originalText.getBytes（））；
String decodedText=新字符串（Base64.decodeBase64（encodedBytes））；
System.out.println（解码文本）；
}
}

通常，输出如下所示：

你好，世界！
你好，世界！

这一点也不奇怪。但是现在我们定义了一个方面，它处理从第三方库返回的结果，将每个字符“o”（oh）替换为“0”（零）：

package de.scrum\u master.aspect；
导入org.apache.commons.codec.binary.Base64；
基于公共方面的操作器{
byte[]around（）：执行（byte[]Base64.decodeBase64（byte[]））{
System.out.println（此连接点）；
字节[]结果=继续（）；
for（int i=0；i

顺便说一句，如果您在这里只使用

call（）

而不是

execution（）

，那么就不需要实际编入第三方代码。但不管怎样，这是你自找的，所以我要教你怎么做

Maven POM:

4.0.0
de.scrum-master.stackoverflow

正如您所看到的，只剩下一个Apache Commons类文件进入创建的JAR。
在我看来，这就像构建中的一个简单的前/后处理步骤。编织您的jar依赖项，结果将是某个地方的一堆二进制类。获取所需的修改类，从原始jar中获取未修改的其他类，并将它们打包为jar。@NándorElődFekete我的项目是一个OSGI捆绑包，当
ajc
创建编织类时，它们会自动打包到捆绑包中。但是一些3d party类确实依赖于其他第三方LIB（可选LIB），在我的例子中，这些LIB由一个从未访问过的代码使用，但是导致OSJI容器安装缺少依赖项的捆绑包。在这种情况下，我看不到OSGI有任何改变。当然，除非您不使用headless构建环境，而是依赖EclipseIDE来构建您的项目。如果您可以描述您希望以何种方式更改的类/方法，我可以提供更精确的解决方案。查看方面代码也会很有帮助。你为什么还要担心重复但未更改的类？@kriegaex我之所以担心它们，是因为我的OSGI捆绑包上启用了动态导入，所以如果要在我的捆绑包jar中包含一个类，那么容器上需要有所有引用的包，以便能够安装/激活捆绑包，甚至那些被无法访问的代码引用的代码。对于记录，我的切入点通过名称、限定符和参数列表引用确切的方法&&object调用该方法，它不会为任何不希望的调用触发；-）首先，谢谢你的努力！你的回答表明你确实付出了一些努力。但我最终放弃了这种方法，并重写了几个层以实现所需的行为。尽管我使用gradle来管理依赖项和构建，但我还是提出了一个类似于您的解决方案，后来才发现，我的捆绑包中存在该包的一个类，这会阻止OSGI容器从原始库导入该包中的其余类……因为我的捆绑包是ECM解决方案的附加组件，应该可以在该解决方案的多个版本上插入，我认为为每一个版本的主机软件准备编织的依赖关系将是一件非常痛苦的事情。。。但是正如我所说的，你的回答显示了很多努力，如果我没有整个OSGi的复杂性，肯定会起作用，所以