[typpytyper]

    logger.info("...");

versus:

    EventHandle eh = EBus.getHandle(
        eventBuilder.executing().name("some operation").build());
    if (eh.isAllowed()) {
        eh.addParam("p1","v1").addParam("p2","v2").post();
    }

That's a lot of typing.

It needs a more compact API.

[lnanek2]

Yes, that's pretty full of boilerplate, even for Java, which is notoriously boilerplate.

There are more established event buses in Android with simpler syntax, like greenrobot's: EventBus.getInstance().post(new LogEvent("v1", "v2"));

Seen here: http://greenrobot.org/eventbus/documentation/how-to-get-star...

You can have multiple event buses and other customization there as needed, but you have sensible defaults to keep code small most of the time too.

Square also has one called Otto. If you want a lot of syntax and Java rather than Android, you might as well go full streaming with the RxJava library.

[V-2]

I think Otto is a fork, and simply an enhanced implementation of Guava's built-in EventBus

[ttam]

meanwhile Otto has become deprecated and the authors suggest going with RxAndroid

[hitr]

With event framework,we should use little helper function to wrap each event type,at least that's what I have seen.Windows event tracing(ETW) comes to mind,one of the complex api written[1].I always thought that every application should make use of ETW infrastrucutre. Compared to perf_events or may be lttng in linux(I am not sure how difficult to integrate to perf_events).Currently there are good and easy framework for ETW in .net [2]. But once you integrate your app,your app suddenly gains performance tuning,debugging capability easily. I think this should hold true for any event framework!!

[1]https://mollyrocket.com/casey/stream_0029.html [2]https://www.nuget.org/packages/Microsoft.Diagnostics.Tracing...

[zer0gravity]

Well, to be really fair compare it with :

  if(logger.isDebugEnabled()){
        logger.debug("...");
  }

And yeah, it requires a bit more typting if you want to enforce a certain event format and want to add more parameters. But you only do that once, and I'd say you gain much more for your effort.

[CHY872]

Fyi, intended usage with most Java loggers is to just call

    logger.debug("...");

and ignore the conditional. If `!logger.isDebugEnabled` then the logger will ignore the message, so it avoids boilerplate.

[zer0gravity]

You want to wrap it in an if in order to avoid doing extra work ( like string concatenation or whatever ) and save some computation. It's to improve performance when logging is not enabled.

[jestar_jokin]

No good if you're computing the message somehow. e.g.

    logger.debug(generateSomethingLarge());

[CHY872]

Generally you would log with placeholders, like

    logger.debug("My logger message has placeholders {}, {}, {}", some, objects, toLog);

which avoids the issue.