MixinService lookup mechanism limits logging abstraction and causes unintentional Log4J use

[sfPlayer1]

Mixin abstracts logging away to not use a particularly library, based on what the IMixinService implementation chooses to use. The IMixinService itself gets discovered through ServiceLoader and has a variety of builtin implementations bundled with Mixin's releases.

The problem is that MixinServiceAbstract as the super class of most Mixin services including MixinServiceModLauncher creates the logger in the constructor. The service loader mechanism constructs all implementations during regular use (lazily). So Mixin looks for IMixinServices, runs across MixinServiceModLauncher, instantiates it, which instantiates LoggerAdapterLog4j2, which uses and loads Log4J2.

My particular scenario doesn't really support Log4J2 in this context (config/plugins/partial class path), which leads to some garbage on stderr and potentially other unwanted state changes. The problem goes away when our IMixinService comes first, but this isn't something we can always guarantee.

For my uses it'd be sufficient to have a way to bypass the service loader based IMixinService lookup, e.g. through a system property declaring the desired impl class directly or an API to pass the instance cleanly (difficult with the current code flow). This would bypass MixinServiceModLauncher and others, working around the problem outlined above. It's probably also speed initialization up a little, the desired service impl is well known in advance.

Long term it'd be nice to change IMixinService discovery such that each service verifies its eligibility for the environment before having any impact on it, particularly not loading any classes specific to it, directly or indirectly.