Java ByteBuddy方法拦截器与@AllArguments不'；好像不行

我正在为我的一个项目探索ByteBuddy。我试图截取带注释的方法，如下所示：

import net.bytebuddy.ByteBuddy;
import net.bytebuddy.dynamic.loading.ClassLoadingStrategy.Default;
import net.bytebuddy.implementation.MethodDelegation;
import net.bytebuddy.matcher.ElementMatchers;

public class Fibonacci {

  public static void main(String[] args) throws IllegalAccessException, InstantiationException {
    Fibonacci fibonacci =
        new ByteBuddy()
            .subclass(Fibonacci.class)
            .method(ElementMatchers.isAnnotatedWith(PreCondition.class))
            .intercept(MethodDelegation.to(new FiboAgent()))
            .make()
            .load(Fibonacci.class.getClassLoader(), Default.WRAPPER)
            .getLoaded()
            .newInstance();
    fibonacci.printFibo(5);
  }

  @PreCondition(expression = "n > 5")
  public void printFibo(Integer i) {
    System.out.println("Here");
  }
}

FiboAgent.java：

import net.bytebuddy.asm.Advice.AllArguments;

public class FiboAgent {
  public void intercept(@AllArguments Object[] args) {
    System.out.println("Intercepted");
  }
}

我不明白为什么这不起作用

---

ByteBuddy版本：1.10.19

不幸的是，这是一个简单的错误。建议和授权是有区别的。方法委派功能更强大，但在字节码级别上更具侵入性，这使得它对通常无法添加成员的Java代理不那么有吸引力。为了简化两者之间的切换，注释是对齐的，因为通知包含委托功能的一个子集。如果更换：

import net.bytebuddy.asm.Advice.AllArguments;

与

---

一切都应该按预期进行。

我真的不明白为什么这么多开发人员认为最好发布一组不连贯的代码片段，没有人可以复制、编译和运行这些代码片段来重现问题，但这会让他们更难找到帮助，而不是仅仅发布一个可以立即给出答案的帖子，而不会让每个潜在的志愿者在能够回答一个简单的问题之前，尝试猜测真正的代码是什么样子，并尝试填充拼图中缺失的部分。简洁而不是再现性-为什么？我道歉。这是一段相对简单的代码（我觉得我犯了一个愚蠢的错误），所以我没有真正发布整个内容。我已经更新了问题的MCVE。没有一段代码太简单而不会出错。这是人类的行为，而不是愚蠢的行为。看看你完整的导入课程如何让Rafael轻松回答你的问题？（我会的，但刚刚在我当前的时区醒来。）现在也很清楚，您以前的3个代码片段实际上只属于2个类，这在这里并不重要，但在其他情况下也可能很重要。注释的包名是重要信息。公平地说，你之前提到过，但不是作为守则的一部分，而是在守则后面的某个句子中，这很难被注意到。当我在这里教人们如何提问时，我总是感到有点不安，担心他们会把它当成个人问题。但我还是这么做了，因为我知道如果他们听从建议，我会帮助他们自助，因为如果问题很容易重现，那么解决问题的可能性要比助手必须开始猜测和做出（或多或少）有根据的猜测的可能性大得多。谢谢拉斐尔的回答，这是我犯的错误。看起来需要更彻底地阅读文档。

import net.bytebuddy.implementation.bind.annotation.AllArguments;