在ByteBuddy中重建jvm期间拦截构造函数

我正试图用Bytebuddy 1.6重新基址和重命名类，以拦截它的构造函数。7.

我正在开发SAAS系统，用户可以提供注释的java类，系统应该在存储或启动之前对它们进行测试。我已经开发了执行我需要的仪器的管道，但它可以在两个地方使用。

第一个模块在不加载的情况下对类进行仪器化和存储。它使用类名作为“component”id，所以我不想创建一个插入指令类型的子类来避免类名中不必要的后缀。这就是我想使用rebase的原因。

另一个模块已经加载类并立即使用它们，而不关心类名。在这个模块中，我希望重用第一个模块中的代码，并在加载之前另外更改插入指令类型的名称。

这里有完整的工作示例。

我想知道为什么下面的方法适用于内部类，而不适用于根类。

private static void rebaseConstructorSimple(Class<?> clazz) throws InstantiationException, IllegalAccessException {
    new ByteBuddy()
            .rebase(clazz)
            .name(clazz.getName() + "Rebased")
            .constructor(ElementMatchers.any())
            .intercept(SuperMethodCall.INSTANCE.andThen(
                    MethodDelegation.to(new ConstructorInterceptor()
                    )))
            .make()
            .load(clazz.getClassLoader(), ClassLoadingStrategy.Default.INJECTION)
            .getLoaded()
            .newInstance();
}

如果提供根类，则会出现以下异常：

Exception in thread "main" java.lang.IllegalStateException: Cannot call super (or default) method for public OuterClassRebased()
    at net.bytebuddy.implementation.SuperMethodCall$Appender.apply(SuperMethodCall.java:97)
    at net.bytebuddy.implementation.bytecode.ByteCodeAppender$Compound.apply(ByteCodeAppender.java:134)
    at net.bytebuddy.dynamic.scaffold.TypeWriter$MethodPool$Record$ForDefinedMethod$WithBody.applyCode(TypeWriter.java:614)
    at net.bytebuddy.dynamic.scaffold.TypeWriter$MethodPool$Record$ForDefinedMethod$WithBody.applyBody(TypeWriter.java:603)
    at net.bytebuddy.dynamic.scaffold.TypeWriter$Default$ForInlining$RedefinitionClassVisitor$CodePreservingMethodVisitor.visitCode(TypeWriter.java:3912)
    at net.bytebuddy.jar.asm.MethodVisitor.visitCode(Unknown Source)
    at net.bytebuddy.jar.asm.ClassReader.b(Unknown Source)
    at net.bytebuddy.jar.asm.ClassReader.accept(Unknown Source)
    at net.bytebuddy.jar.asm.ClassReader.accept(Unknown Source)
    at net.bytebuddy.dynamic.scaffold.TypeWriter$Default$ForInlining.create(TypeWriter.java:2894)
    at net.bytebuddy.dynamic.scaffold.TypeWriter$Default.make(TypeWriter.java:1612)
    at net.bytebuddy.dynamic.scaffold.inline.RebaseDynamicTypeBuilder.make(RebaseDynamicTypeBuilder.java:200)
    at net.bytebuddy.dynamic.scaffold.inline.AbstractInliningDynamicTypeBuilder.make(AbstractInliningDynamicTypeBuilder.java:92)
    at net.bytebuddy.dynamic.DynamicType$Builder$AbstractBase.make(DynamicType.java:2560)
    at net.bytebuddy.dynamic.DynamicType$Builder$AbstractBase$Delegator.make(DynamicType.java:2662)
    at TestConstructorInterceptor.rebaseConstructorSimple(TestConstructorInterceptor.java:35)
    at TestConstructorInterceptor.main(TestConstructorInterceptor.java:89)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:497)
    at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)

正如我之前提到的，如果类未加载，我可以避免类：

public static void rebaseConstructorNotLoaded(String classPath, String className) throws Exception {
    ClassFileLocator.ForFolder folderClassLoader = new ClassFileLocator.ForFolder(new File(classPath));
    TypePool typePool = TypePool.Default.ofClassPath();
    TypeDescription typeDescription = typePool.describe(className).resolve();

    new ByteBuddy()
            .rebase(typeDescription, folderClassLoader)
            .constructor(ElementMatchers.any())
            .intercept(
                    SuperMethodCall.INSTANCE.andThen(
                            MethodDelegation.to(new ConstructorInterceptor())))
            .make()
            .load(TestConstructorInterceptor.class.getClassLoader(), ClassLoadingStrategy.Default.INJECTION)
            .getLoaded()
            .newInstance();
}

我还可以通过以下步骤来实现这个目标：使用rename重新设置基础，make。然后创建SimpleClassLoader，它只包含为新类名生成的字节。截取构造函数

public static void rebaseWithIntermediateMake(Class<?> clazz) throws IllegalAccessException, InstantiationException {
    DynamicType.Unloaded<?> unloaded = new ByteBuddy()
            .rebase(clazz)
            .name(clazz.getName() + "Rebased")
            .make();
    ClassFileLocator dynamicTypesLocator = getClassFileLocatorForDynamicTypes(unloaded);
    TypeDescription typeDescription = unloaded.getTypeDescription();
    new ByteBuddy()
            .rebase(typeDescription, dynamicTypesLocator)
            .constructor(ElementMatchers.any())
            .intercept(
                    SuperMethodCall.INSTANCE.andThen(
                            MethodDelegation.to(new ConstructorInterceptor())))
            .make()
            .load(clazz.getClassLoader(), ClassLoadingStrategy.Default.INJECTION)
            .getLoaded()
            .newInstance();
}

private static ClassFileLocator getClassFileLocatorForDynamicTypes(DynamicType.Unloaded<?> unloaded) {
    Map<TypeDescription, byte[]> allTypes = unloaded.getAllTypes();
    Map<String, byte[]> nameByteMap = new HashMap<>();
    for (Map.Entry<TypeDescription, byte[]> entry : allTypes.entrySet()) {
        nameByteMap.put(entry.getKey().getName(), entry.getValue());
    }
    return new ClassFileLocator.Simple(nameByteMap);
}

我检查了ByteBuddy代码，可能发现了导致第一次测试失败的代码。

当MethodRebaseResolver在RebedDynamicTypeBuilder中构造时，我们在生成的MethodRebaseResolver中得到了0个instrumentedMethods。看起来，匹配期间的RebasableMatcher在instrumentedMethodTokens中只有一个值：

MethodDescription.Token{name='<init>', modifiers=1, typeVariableTokens=[],
 returnType=void, parameterTokens=[], exceptionTypes=[], annotations=[],
 defaultValue=null, receiverType=class net.bytebuddy.dynamic.TargetType}

但与以下目标吻合

MethodDescription.Token{name='<init>', modifiers=1, typeVariableTokens=[],
 returnType=void, parameterTokens=[], exceptionTypes=[], annotations=[],
 defaultValue=null, receiverType=class OuterClass}

令牌是不同的，因为它们具有不同的接收器类型，并且未检测构造函数。

最后，问题是：如果我想使用rebase rename，我是否在概念上做错了什么。这可能是个bug？

回答：

你是对的，你发现了一个我刚刚修复的bug。对于内部类，重命名解析与使其工作的解析略有不同。

至于你的问题，链接解决方案可能是最好的主意。然而，更好的方法是使用Java剂。这样，您可以保证不会过早地加载类。