[1.13.2] Alternative to postInit() post 1.13? [SOLVED]

[JaredBGreat]

I see that that old preInit(), init(), postInit() system seems to have bee replaced with a single setup() method in 1.13, and understand that mods are now loaded concurrently.  Is there anything still around equivalent to the old postInit(), or some event for all mods have loaded (preferably before server start)?  I used postInit extensively for compatibility and inter-mod interaction -- specifically to allow things like blocks, items, and biome from other mods to be used with my world-gen.  This way I could load player configurable changes after all other mods should have their core content loaded.  For example, Doomlike Dungeons loads its base config during preInit() but wait to postInit() to load its theme files, in order to allow dungeons to use blocks/loot from other mods without explicit dependence on any other mod (or even for me to know the mods in question exist).  My new Climatic Biomes mod does something similar with biomes.  I also generate lists of usable content by resource location at this time, as this is not always obvious from names that appear in-game.

 

No, IMC is not likely to be useful and should not be necessary for my use case.  Is there a still a good (preferably simple) way to do this? -- or are my theme systems dead and doomed?

 

 

Edited April 24, 2019 by JaredBGreat
Marking as (probably) solved

[JaredBGreat]

Everything I see on @ObjectHolder seems to use it as an annotation for a specific class or field, attaching it to something specific and defined as static.  Could I use it on a dynamic array wrapper, like an ArrayList or something similar?  If I have to hard-code annotations on each block in advance ... what about when you don't what blocks you're using or how many there will be?

 

But if I can use it to create data structures holding an arbitrary number of unknown blocks/items it might actually work.

 

EDIT: If the field doesn't have to be static, I suppose I can use that on the field in my block wrapper class, DBlock, that same thing has allowed easy transitions from IDs to Blocks to BlockStates.  (Otherwise, uh-oh.) Thanks.

Edited April 24, 2019 by JaredBGreat
Avoid double posting back to back

[JaredBGreat]

OK, thanks.  That is probably much more useful for what I'm doing.