Don't merge classes with static initializers

[BoannWasHere]

When the optimization class/merging/horizontal is enabled, ProGuard includes classes with <clinit> methods, i.e., static initializers, as candidates for merging.

I had always naturally assumed that ProGuard was sensible enough not to do this and so had never worried about it.

I was genuinely stunned when I discovered that a noticeable startup delay in my application – only occurring after some compilations – was being caused by the expensive initialization of a large static HashMap field in a class that would never be touched on most uses of the application, but it had quietly by random chance been merged into a totally unrelated user interface class.

ProGuard's behavior here risks causing some weird and hard to understand bugs with class load order, and it defeats the initialization-on-demand holder idiom.

Disabling the optimization entirely with -optimizations !class/merging/horizontal neutralizes the problem, but I shouldn't have to do that. ProGuard should be smart enough to tell that classes with static initializers are not appropriate merge candidates.

[piazzesiNiccolo-GS]

ClassMerger considers static initializers here already, seems a good place to start looking at.

You should also be able to workaround the performance impact also by keeping the affected class without having to turn off the optimisation entirely.