Decorator for default methods of decorated types not being called

[slinstaedt-hlag]

Describe the bug

First: I am aware, quarkus is an implementation of CDI light, but not CDI full. Nevertheless it provides some functionalities of CDI full, like decorators, which I would expect to work like specified in CDI full.

We discovered actually some corner cases, where quarkus' implementation of CDI decorators actually behaves differently (in terms of not failing with an exception, but interpreting the spec differently) from other CDI implementations: If a bean has a bean type being an interface with default methods, which the bean itself does not override, any applied decorator for that bean type that override that method is never getting called but any calls are directly delegated to the interface's default method. If the bean overrides these default method (even if it just delegates it's calls to interface's default method), the decorator is getting called as expected.

As CDI light is not mentioning anything regarding decoration behaviour, I am referring to the CDI full spec of decotors:

The decorator intercepts every method which is declared by a decorated type of the decorator and is implemented by the bean class of the decorator.

From my interpretation, that reads like: If an interface declares a method (independently of being abstract or concrete) and an decorator class implements this method, the decorator is getting called for invocations of this method. The spec does not mention any differentiation between abstract and default methods.

Expected behavior

You can imagine I was somehow surprised when changing some interface's abstract methods to default ones (e.g. to remove duplications in implementing classes), that some decorations did not get applied any more, especially if these decorations are security relevant. I have silently assumed that decoration works, like in other CDI implementations and also programmatically applied DIY GoF decorator pattern.

Actual behavior

Calls to default methods of decorated bean types, which are not overridden by the decorated bean itself, are not getting decorated, but directly delegated to the default method's implementation.

How to Reproduce?

No response

Output of uname -a or ver

Linux NHH43414 5.15.167.4-microsoft-standard-WSL2 #1 SMP Tue Nov 5 00:21:55 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Output of java -version

Java version: 21.0.6, vendor: Ubuntu, runtime: /usr/lib/jvm/java-21-openjdk-amd64

Quarkus version or git rev

3.19.2

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.9.9

Additional information

No response

[slinstaedt-hlag]

Reproducing project attached:

quarkus-decorator-reproducer.tar.gz

[quarkus-bot]

/cc @Ladicek (arc), @manovotn (arc), @mkouba (arc)

[Ladicek]

The CDI TCK probably doesn't even have a test for this, because default methods were introduced in Java 8, but I agree that what you describe is what should happen. Will take a proper look tomorrow.

[slinstaedt-hlag]

Thanks for taking care.

[Ladicek]

OK, so we actually have a test for decoration of default methods, which leads me to the following:

The decorator intercepts every method which is declared by a decorated type of the decorator and is implemented by the bean class of the decorator.

Does your decorator implement the default methods? As in, override? If not, this exact sentence that you quoted from the specification says that they shouldn't be decorated.

[Ladicek]

So now I'm confused. I extended the existing test for decorating default methods to this:

public class DecoratorDefaultMethodNotImplementedTest {
    @RegisterExtension
    public ArcTestContainer container = new ArcTestContainer(Converter.class, ToLengthConverter.class,
            Add1ConverterDecorator.class);

    @Test
    public void testDecoration() {
        Converter<String> converter = Arc.container().instance(new TypeLiteral<Converter<String>>() {
        }).get();
        assertEquals(6, converter.convert("Hola!"));
        assertEquals(6, converter.convert("Hola!", true));
    }

    interface Converter<T> {
        int convert(T value);

        default int convert(T value, boolean ignored) {
            return convert(value);
        }
    }

    @ApplicationScoped
    static class ToLengthConverter implements Converter<String> {
        @Override
        public int convert(String value) {
            return value.length();
        }
    }

    @Priority(1)
    @Decorator
    static class Add1ConverterDecorator implements Converter<String> {
        @Inject
        @Delegate
        Converter<String> delegate;

        @Override
        public int convert(String value) {
            return 1 + delegate.convert(value);
        }
    }
}

And the test passes. Which is I think what you expected, even though it goes kinda sorta against the specification?

EDIT: actually it doesn't go against the spec. The default method forwards to an abstract method, which is what gets decorated. The default method itself is not. So it's OK.

[slinstaedt-hlag]

OK, so we actually have a test for decoration of default methods, which leads me to the following:

The decorator intercepts every method which is declared by a decorated type of the decorator and is implemented by the bean class of the decorator.

Does your decorator implement the default methods? As in, override? If not, this exact sentence that you quoted from the specification says that they shouldn't be decorated.

In my reproducer the decorator overrides both default methods, but only get called for any invocation, if the implementing bean also overrides the decorated default method.

As mentioned in the original issue text, I would interpret this as a contradiction of the CDI full spec:

The decorator intercepts every method which is declared by a decorated type of the decorator and is implemented by the bean class of the decorator.

The term "decorated type" is defined as:

A decorator implements one or more bean types and intercepts business method invocations of beans which implement those bean types. These bean types are called decorated types.

In brief: Decoration is independent of what the decorated bean class overrides, and what not.

[slinstaedt-hlag]

In your example the decorator does not override the default method, but the abstract method. Just override the default method in the decorator and return 0 without any delegating any call. Your test should fail with the actual returned value also being 0 (because the decorator hardcoded this return value), but still returning 6 as the default method is being invoked, which delegates to the abstract method, which in turn is also decorated and added 1 to the computed result.

@Priority(1)
@Decorator
static class Add1ConverterDecorator implements Converter<String> {

  private Converter<String> delegate;

  Add1ConverterDecorator(@Delegate Converter<String> delegate) {
      this.delegate = delegate;
  }

  @Override
  public int convert(String value) {
      return 1 + delegate.convert(value);
  }

  @Override
  public int convert(String value, boolean ignored) {
      return 0;
  }
}

[slinstaedt-hlag]

For reference, if I would setup the docoration chain programmatically myself (which could be exported as an bean via a producer method), invocations of the default method would return the expected result:

@Test
void testProgrammanticDecoration() {
    var converter = new Add1ConverterDecorator(new ToLengthConverter());

    assertEquals(6, converter.convert("Hola!"));
    assertEquals(0, converter.convert("Hola!", true));
}

I would assume nobody would argue against the behavior of the last programmatic decoration example, because that is just plain old java code from schools when learning how to implement this GoF pattern.

[Ladicek]

Decoration is independent of what the decorated bean class overrides, and what not.

Sure, but it does depend on what the decorator bean overrides.

Just override the default method in the decorator and return 0 without any delegating any call. Your test should fail with the actual returned value also being 0 (because the decorator hardcoded this return value), but still returning 6 as the default method is being invoked, which delegates to the abstract method, which in turn is also decorated and added 1 to the computed result.

Ah, understood! I can confirm this indeed happens and it shouldn't. I'll continue digging tomorrow.

[slinstaedt-hlag]

Sure, but it does depend on what the decorator bean overrides.

Of course :)

If the decorator does not override a default method, I would expect the default method code being called ON the decoratoR instance.
I would NOT expected quarkus to provide decorator bytecode for an overridden default method, which delegates the call to the decorateD instance. This would lead to different behavior, as the default method is getting called on the decorateD instance and not on the decorateR instance.

In brief: The same behavior as for programmatic decoration.

Sorry for the strange upper cases, I just wanted to stress the difference between decorator and decorated instances, because these are of course instances of different types.