Reducing boilerplate with annotations

[bjmdev]

I wonder whether boilerplate could be reduced by annotations which allow writing an actor in a short, but precise and clear way?

Maybe something like this:

@Actor(Msg.class)
class SomeActor {

    @ActorContext
    private ActorContext<Msg> ctx;

    @HandleMessage(SomeMsg.class)
    public void onSomeMsg(final SomeMsg msg) {
        ctx.getLog().info("received some message: {}", msg);
    }

}

Of course, there is more to consider like switching behaviors (FSM), handling signals, etc... but it should be possible to come up with useful annotations to shorten the required LoC for (standard) actors.
People using Spring are used to annotation magic anyway :-)

What is the general opinion of this direction of thought from the maintainers?

Thanks and best regards!

[pjfanning]

I'm not sure if anyone is going to take this on but if they want, it will be reviewed. For me, people who want to use Pekko and Java for new actors, they should consider using Java Records for the message definitions, new style Java switch statements for matching the messages and typed actors instead of classic actors.

Example generated by AI.

// Requires Java 21+ and Apache Pekko (org.apache.pekko:pekko-actor-typed_2.13)
//
// This shows the least-boilerplate way to write a Pekko Typed actor in Java today:
//   - sealed interface + records for the protocol (no getters, no equals/hashCode/toString to write)
//   - Behaviors.setup + Behaviors.receiveMessage instead of extending AbstractBehavior
//     (skips the ReceiveBuilder entirely)
//   - a switch expression over the sealed interface, which the compiler checks for
//     exhaustiveness — add a new Command subtype and forget to handle it, and this won't compile
//   - record patterns to destructure messages inline instead of calling accessor methods
 
package example;
 
import org.apache.pekko.actor.typed.ActorRef;
import org.apache.pekko.actor.typed.ActorSystem;
import org.apache.pekko.actor.typed.Behavior;
import org.apache.pekko.actor.typed.javadsl.Behaviors;
 
public class CounterActor {
 
    // --- Protocol ---
    // sealed = the compiler knows every possible message type, so the switch below
    // needs no `default` branch and breaks at compile time if you add a case and
    // forget to handle it.
    sealed interface Command {}
    record Increment(int by) implements Command {}
    record GetCount(ActorRef<Count> replyTo) implements Command {}
    record Reset() implements Command {}
 
    record Count(int value) {}
 
    // --- Behavior ---
    // No class to extend, no constructor, no builder. State is just a method parameter,
    // and "changing state" means calling counting(...) again with a new value.
    public static Behavior<Command> create() {
        return counting(0);
    }
 
    private static Behavior<Command> counting(int total) {
        return Behaviors.receiveMessage(command -> switch (command) {
            case Increment(var by) -> counting(total + by);
            case GetCount(var replyTo) -> {
                replyTo.tell(new Count(total));
                yield Behaviors.same();
            }
            case Reset() -> counting(0);
        });
    }
 
    // --- Demo ---
    public static void main(String[] args) throws InterruptedException {
        ActorSystem<Command> system = ActorSystem.create(CounterActor.create(), "counter-system");
 
        system.tell(new Increment(5));
        system.tell(new Increment(10));
 
        // In real code you'd use the ask pattern to get Count back asynchronously;
        // this is just enough to show messages flowing.
        Thread.sleep(200);
        system.terminate();
    }
}

[bjmdev]

Thank you, that is indeed a nice and clean way, especially the exhaustive pattern matching!