That's great, I was thinking to add a Java client as well. I'm just so short with the time at the moment. Let me know how you are proceeding with it and if you are facing any challenges.

One "choice" I made I feel weird about is keeping log levels around

it is just another type of metadata but 🤷

And i'm punting on the ring buffer stuff since idk how to implement that without a dependency

https://lmax-exchange.github.io/disruptor/user-guide/index.html

...tempted but idk the difference between this and the persistent ring buffer

the disruptor is a nice project, be careful about what you add in your core project as the more you add the more possibility of version conflict with other (direct or transitive) dependencies. The nice thing about the persistent/immutable ring-buffer I use is that being immutable it removes a ton of possible concurrency issues. The disruptor is designed for concurrent use as well, but you have to follow its model very closely.

The only thing (I think) stopping this from being able to be used as a frontend to mulog is the context system

I am currently storing all the context for a call like so

private static final AtomicReference<ThreadLocal<Context>> CONTEXT_REFERENCE =
            new AtomicReference<>(ThreadLocal.withInitial(() -> Context.Global.EMPTY));

public sealed interface Context {
        record Global(List<Log.Entry> entries) implements Context {
            static final Global EMPTY = new Global(List.of());
        }

        record Child(
                @Design(Design.Choice.EVERY_CHILD_CONTEXT_ELEMENT_HAS_ITS_OWN_REFERENCE_TO_A_THREAD)
                Thread thread,
                Instant timestamp,
                Flake flake,
                List<Log.Entry> entries,
                Context parent
        ) implements Context {
        }
    }

which isn't too dissimilar from mulog's approach

(defonce ^{:doc "The global logging context is used to add properties
             which are valid for all subsequent log events.  This is
             typically set once at the beginning of the process with
             information like the app-name, version, environment, the
             pid and other similar info."}
  global-context (atom {}))



(def ^{:doc "The local context is local to the current thread,
             therefore all the subsequent call to log withing the
             given context will have the properties added as well. It
             is typically used to add information regarding the
             current processing in the current thread. For example
             who is the user issuing the request and so on."}
  local-context (ut/thread-local nil))

just they aren't the same context - and making a "context provider" feels gross

+ I am being more restrictive in terms of data allowed in events. Fine flowing from this -> mulog, hard to handle if context from mulog flows -> this