java - Javassist的ClassFileTransformer实现

不同的来源提供了使用Javassist实现ClassFileTransformer的不同方法：

blog.newrelic.com/2014/09/29/diving-bytecode-manipulation-creating-audit-log-asm-javassist/

public byte[] transform(...) {
    ClassPool pool = ClassPool.getDefault(); // Edited to simplify
    pool.insertClassPath(new ByteArrayClassPath(className, classfileBuffer));
    CtClass cclass = pool.get(className.replaceAll("/", "."));
    ...
    return cclass.toBytecode();
}

blog.javabenchmark.org/2013/05/java-instrumentation-tutorial.html

public byte[] transform(...) {
    ClassPool cp = ClassPool.getDefault();
    CtClass cc = cp.get("org.javabenchmark.instrumentation.Sleeping");
    ...
    return cc.to:byteCode(); // edited to simplify
}

http://javapapers.com/core-java/java-instrumentation/

public byte[] transform(...) {
    ClassPool classPool = ClassPool.getDefault();
    CtClass ctClass = classPool.makeClass(new ByteArrayInputStream(classfileBuffer));
    ...
    return ctClass.to:byteCode(); // edited to simplify
}

哪种方法最正确，为什么？还有其他比这三个更好的解决方案吗？

https://stackoverflow.com/a/26725215/776884提及设置正确的类加载器。使用Instrumentation API时需要吗？ ClassPool classPool = new ClassPool()和CtClass.makeClass()是否应与instumentation API一起使用？

最佳答案

所有这些示例都是错误的，因此无法在常规设置中使用。您永远不要使用默认的类池，并且您永远都不要（如新文物博客中所示）在转换器之间共享类池，因为您无法确定加载的类是否与它们的类加载器相关。

考虑一个应用服务器，其中任何应用都有自己的类加载器；您甚至无法使用默认的类池（它引用系统类加载器，即类路径）来查看转换后的类，并且您不能保证应用程序服务器上的所有应用程序都运行相同版本的某个类（如果它们都包含它们）。

唯一正确的解决方案是：

ClassPool classPool = new ClassPool();
classPool.appendClassPath(new LoaderClassPath(loader));
CtClass ctClass = classPool.makeClass(new ByteArrayInputStream(classfileBuffer));

这样，您考虑到每个类都由不同的类加载器加载，该类加载器可以表示不同的视图，即与类路径相比包含不同的类或不同版本的类，并且您仍然解析提供的字节数组，其中可以包含新成员这些是由其他Java代理先前触发的转换器添加的。

关于java - Javassist的ClassFileTransformer实现，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/35975762/