Review generated event audit hierarchy

from Sealed classes
Java 25 LTS advanced 6 min 4 issues to find

Review this generated event-audit hierarchy before it becomes a shared API.

Model a controlled event root with an intentional plugin branch, keep credentials out of audit output, reject null explicitly, force review of new root variants, and preserve event order without unjustified parallel work.

Java
import java.util.List;
public class GeneratedEvents {
    sealed interface Event permits Login, Payment, PluginEvent {}
    record Login(String userId, String accessToken) implements Event {}
    record Payment(String id, int cents) implements Event {}
    non-sealed interface PluginEvent extends Event {}
    static String audit(Event event) {
        return switch (event) {
            case Login login -> "login " + login;
            case Payment payment when payment.cents() > 0 -> "paid " + payment.id();
            case Payment payment -> "ignored " + payment.id();
            default -> "other";
        };
    }
    static List<String> auditAll(List<Event> events) {
        return events.parallelStream()
                .map(GeneratedEvents::audit)
                .sorted()
                .toList();
    }
}

generated code is illustrative, not from any one model

Open in playground
Report an error