Support Functional Interface for Batch Message Listener

[Darshanbc]

Currently, in Java, default methods in functional interfaces cannot be overridden using lambda expressions. While functional interfaces are designed to simplify code using lambdas, default methods are excluded from this flexibility.

@FunctionalInterface
public interface MessageListener<T> {
    void onMessage(Message<T> message);

    default void onMessage(Collection<Message<T>> messages) {
        throw new UnsupportedOperationException("Batch not implemented by this MessageListener");
    }
}

If I want to override the
onMessage(Collection<Message<T>> messages)
method using a lambda, the following code is invalid

 
 MessageListener<String> listener = messages -> {
    messages.forEach(msg -> System.out.println(msg.getContent()));
};

Solution:
Have Separate Functional Interfaces:
Define separate interfaces for single and batch processing. However, this creates redundancy and bloats the codebase.

[shreyas957]

@Darshanbc You're correct that default methods in functional interfaces cannot be overridden using lambda expressions, as lambdas can only target the single abstract method of a functional interface. This is a design limitation in Java.

To address your specific use case, while avoiding redundancy or bloating the codebase with multiple interfaces, you can use an anonymous class to provide an implementation for the onMessage(Collection<Message> messages) method alongside the lambda for the single message handling:

MessageListener<String> listener = new MessageListener<>() {
    @Override
    public void onMessage(Message<String> message) {
        System.out.println(message.getContent());
    }

    @Override
    public void onMessage(Collection<Message<String>> messages) {
        messages.forEach(msg -> System.out.println(msg.getContent()));
    }
};

This approach avoids creating multiple interfaces while giving you flexibility to override the onMessage method for batch processing.

Java's current lambda behavior only targets the single abstract method (SAM) in a functional interface, so a direct workaround isn't possible without changes to the API design.
So either create second lambda expression or modify the default method to call another method that can be overridden with a lambda-friendly design. For example:

@FunctionalInterface
public interface MessageListener<T> {
    void onMessage(Message<T> message);

    default void onMessage(Collection<Message<T>> messages) {
        messages.forEach(this::handleSingleMessage);
    }

    default void defaultBehaviour(Message<T> message) {
        throw new UnsupportedOperationException("Single message handling not implemented");
}

CC : @maciejwalkowiak

[tomazfernandes]

Hi @Darshanbc and @shreyas957.

Yup, you're both correct.

This was a design decision - we could have separate interfaces for batch and single message operations, but that would mean double the amount of interfaces, and as @Darshanbc pointed out, this would bloat the codebase.

As @shreyas957, there are a number of strategies to mitigate this in a more lambda-friendly way for batch operations, so IMO the current approach is appropriate.

Would you both agree, or is there any other strategy we could look into?

[Darshanbc]

With current limitation of Java supporting only SAM for lambda. We could accept the cons of having the bloated code and have seperate interfaces which makes the developer life easy.

[shreyas957]

Yes, for now, the current approach is better. Leave it as it is for now 🙂.
So what I believe is two have either a second interface or a default method for batch processing.

@tomazfernandes let me know, if we have to take any action on this. I am happy to work on it 🙌

[tomazfernandes]

I believe most users will rely on single-message listeners, and we already support batch listeners with the annotation which is convenient.

As @shreyas957 pointed out, this is easily addressed by creating an anonymous inner class (which is what lambda does behind the scenes anyway).

Even if we had separate interfaces, we'd still need to somehow let the container know whether that's a Single or Batch message listener, either by explicitly casting the lambda function, or by adding separate methods for setting single and batch message listeners. This would also need to be done in all other interfaces for consistency.

IMO, we would be making the DevX more complex for what I believe to be the most common case.

So I still believe the current approach is the correct one.

Besides all of that, it'd be very hard to add this second set of interfaces without breaking changes, and it would touch very sensitive areas of the integration which unless for a more compelling reason I'd rather not.

That being said, if you can come up with another solution for this that does not require breaking changes or that won't make the devX for the most common use case worse, I'm happy to hear.

Thanks!