Are utility classes mandatory?

[Pentasis]

I'm learning both Java and minecraft modding at the same time. And one of the things I notice when looking at tutorials and source code of existing mods, is that utility classes are (always?) used for the setup code for Registries, Config, Eventhandlers, etc. 

Is this how Forge needs it to be? Is there any reason why I shouldn't use an object over static fields/methods in a utility class?

NOTE: I am not asking for a discussion over whether utility classes are "evil"; I just want to know the reason behind this.

[TheGreyGhost]

No you don't need a utility class, it's a matter of preference only.  You can create an object and register it on the event bus, or you can register a utility class instead (for its static methods), Forge supports both methods, eg both of these work:

ServerLifeCycleEvents serverLifeCycleEvents = new ServerLifeCycleEvents();
 MOD_EVENT_BUS.register(serverLifeCycleEvents);


 public class ServerLifecycleEvents {
   @SubscribeEvent
      public void onServerStartingEvent(FMLServerStartingEvent event) { }
}

///------- or ------------

MOD_EVENT_BUS.register(ServerLifeCycleEvents.class);  
public class ServerLifecycleEvents {  
    @SubscribeEvent  
     public static void onServerStartingEvent(FMLServerStartingEvent event) {  }    //static here
}

 

I personally prefer the utility class for setup code because I only ever need a singleton and they are so simple I never need to write a test harness for it, so creating an object just adds a bit of extra overhead.  I also like the imperative style of explicitly adding to registries. 

 

Or do you mean- can you just add registration methods to the objects themselves?  (eg create a new Block and have it register itself?, or perhaps using a static initialiser inside the Block class)  In that case - the answer is "no" because the objects must be registered with vanilla at the correct time, which is not guaranteed unless you use the forge initialisation events.

 

Many folks like to eliminate utility classes as much as possible by using static initialiser assignment of a DeferredRegister, eg

 

*   private static final DeferredRegister<Block> BLOCKS = DeferredRegister.create(ForgeRegistries.BLOCKS, MODID);
*
*   public static final RegistryObject<Block> ROCK_BLOCK = BLOCKS.register("rock", () -> new Block(Block.Properties.create(Material.ROCK)));
*
*   public ExampleMod() {
*       BLOCKS.register(FMLJavaModLoadingContext.get().getModEventBus());
*   }

Again I think that's a matter of personal preference although some people do hold strong opinions about the right way to do it (TM).

[Pentasis]

The initial part of your answer is what I was looking for, thank you so much for clearing it up for me.

 

[Draco18s]

Utility classes can often help reduce the amount of code you need to write. For example, back on 1.12 (when we no longer had the Game Registry and had to register item models ourselves) I wrote this class:
https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/hardlib/EasyRegistry.java 

That's the 1.14 version, but the switch was pretty straight forward.

It meant I could have my "1.7-like" register-a-block one or two line clean system:
https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/HarderOres.java#L119-L131

 

Instead of this utter nonsense people were doing where they'd create a block, set its registry name, set its translation key, add it to a BLOCKS list, then add the blocks list to the registry, then over in the item event loop over their entire BLOCKS list, create an item (set its registry and translation keys), set a creative tab, and add it to an ITEMS list. And then realize "herp a derp, I created this giant loop that does all my blocks, how does I do more than one creative tab where some blocks are in one and others are in another? What if my block has variants that need different items?" and then end up needing nine lines per block (plus a couple lines for registering a model in the client proxy!).

 

The deferred registry system is what I'll be using on 1.16 because it solves the problem I was solving.