add behavior to method with ByteBuddy

Question

Given Sample.someMethod(...) and InvocationHandler decoration, I want to create a dynamic subclass that overrides someMethod with

someMethod(...) {
  decoration.invoke(...);
  super.someMethod(...);
}

My code looks like this:

    Class<? extends Sample> dynamicSubclass = new ByteBuddy()
        .subclass(Sample.class)
        .method(ElementMatchers.named("someMethod"))
            .intercept(new Implementation.Compound(
                InvocationHandlerAdapter.of(decoration),
                SuperMethodCall.INSTANCE))
        .make()
        .load(Sample.class.getClassLoader())  // line 42
        .getLoaded();

...and it results in the following exception:

java.lang.VerifyError: Expecting a stack map frame
Exception Details:
  Location:
    pl/morgwai/sample/pojo/ByteBuddySample$Sample$ByteBuddy$PXUw8Sz7.someMethod(I)Ljava/lang/String; @27: aload_0
  Reason:
    Error exists in the bytecode
  Bytecode:
    0000000: b200 0a2a b200 0e04 bd00 1059 031b b800
    0000010: 1653 b900 1c04 00c0 001e b02a 1bb7 0020
    0000020: b0                                     

    at java.base/java.lang.Class.getDeclaredFields0(Native Method)
    at java.base/java.lang.Class.privateGetDeclaredFields(Class.java:3061)
    at java.base/java.lang.Class.getDeclaredField(Class.java:2409)
    at net.bytebuddy.implementation.LoadedTypeInitializer$ForStaticField.onLoad(LoadedTypeInitializer.java:122)
    at net.bytebuddy.implementation.LoadedTypeInitializer$Compound.onLoad(LoadedTypeInitializer.java:192)
    at net.bytebuddy.dynamic.TypeResolutionStrategy$Passive.initialize(TypeResolutionStrategy.java:102)
    at net.bytebuddy.dynamic.DynamicType$Default$Unloaded.load(DynamicType.java:6292)
    at net.bytebuddy.dynamic.DynamicType$Default$Unloaded.load(DynamicType.java:6281)
    at pl.morgwai.sample.pojo.ByteBuddySample.main(ByteBuddySample.java:42)

What am I doing wrong and how to fix it?
(I'm using byte-buddy 1.10.22 and openjdk-11)

Thanks!

UPDATE:

I'm able to achieve

someMethod(...) {
  decoration.invoke(...);
}

and

someMethod(...) {
  super.someMethod(...);
}

by doing .intercept(InvocationHandlerAdapter.of(decoration)) and .intercept(SuperMethodCall.INSTANCE) respectively, so it seems, I'm not using Implementation.Compound properly...

UPDATE-2:

I'm also able to achieve

someMethod(...) {
  super.someMethod(...);
  decoration.invoke(...);
}

by

.intercept(SuperMethodCall.INSTANCE.andThen(InvocationHandlerAdapter.of(decoration)))

but I can't do the other way around to achieve the order I need as InvocationHandlerAdapter does not implement Implementation.Composable...

Answer 1

As kindly explained by Rafael Winterhalter it's an unintended omission and in the next release InvocationHandlerAdapter will be implementing Composable (commit already pushed) and then the simplest way will be to do

.intercept(InvocationHandlerAdapter.of(decoration).andThen(SuperMethodCall.INSTANCE))