I want to standardize how I handle mod compatibility, since 1.5.0 is planned to introduce a lot of it. This is based on the compatibility I did for Lootr for 1.5.0 Alpha 2.

For all mod compatibility:

• There should be an interface defining all methods needed by ImmersiveMC to interface with the mod. The objects used in the interface should always be available if only ImmersiveMC and its mandtory requirements are installed. Aka, the interface should NEVER involve objects from the mod its interfacing with outside of implementations.
• There should be a "null" implementation of the interface, that returns default values.
• From here, the interface can be given actual implementations for different mod versions across different modloaders. If the mod is loaded, we use the actual implementation. If not, we default to the "null" implementation. I'm thinking to put all the instances of the different compats in a single Compat file, rather than a different compat for each mod (such as the Lootr Compat currently in-code).

An issue this inevitably runs into is that mods change, and since most compat won't have a proper API to hook into, we need to account for sudden and unexpected changes, and act accordingly. For mods that don't expose an API that we can't already handle in some other safe way (see things like the IronFurnaces compat), it would be good to use Dynamic Proxies (see InvocationHandler in Java) to wrap all method calls to the implementations that aren't the "null" implementation. From there, we can catch any and all exceptions, log them, replace the active implementation with the null implementation, and message the user accordingly that something went wrong, and to report the issue to me.

To go with the above, we also need to handle import errors on mod compat implementations. Instance creation of implementations should catch exceptions and act the same way as the proxies above.

This is done, and Lootr has been migrated to it!