Game is crashing on launch. java 8 used.

https://paste.ee/p/wvLGq

Forge 36.0.15
FD 0.3.2

Weird. Did you get this just once, or have you tried booting again? Sometimes Forge can be temperamental.
Anyway, I'll need your latest.log to debug it.

Every time I launch.

https://paste.ee/p/hVBC5

Sorry to dirty up the comments, but I'm having the same issue when I launch my server, though not on clientside.
Forge Ver: forge-1.16.5-36.0.42
FarmersDelight Ver: FarmersDelight-1.16.3-0.3.2
PasteBin crash report: https://pastebin.com/q482h1KB
PasteBin latest.log: https://pastebin.com/KnpAtRj0

This is extremely likely to be caused by your choice of a JVM to run the game being OpenJ9. Please try with HotSpot?
(Also note that ModLauncher is supposed to stop the game from even attempting to start on OpenJ9, but the check is broken)

Hey, @Hubry , thanks for the solution. Hotspot works for me and my server is up and running. Can you explain why J9 would cause such an issue btw? Or a link that can clarify this.

Well, the cause of the crash is simply that typetools (a library that Forge's event bus is using) uses JVM internals for a few things, and these internals are different on OpenJ9, which makes it fail a lookup it is doing when a mod subscribes to events manually. See the issue above your comment.

This JVM was blacklisted in modlauncher apparently because of some ASM transformation weirdness (see commit message here), but there are other problematic spots like around runtime enum changes.

MinecraftForge/typetools#3
I recommend that move CropPatchGeneration.onBiomeLoad method to another class.

It is also worth pointing out that, by relying on static initializer, you are accidentally accessing your RegistryObjects too early. The following stacktrace are from the linked issue ticket above:

Caused by: java.lang.NullPointerException: Registry Object not present: farmersdelight:wild_cabbages
	at java.util.Objects.requireNonNull(Objects.java:290) ~[?:1.8.0_281] {}
	at net.minecraftforge.fml.RegistryObject.get(RegistryObject.java:120) ~[forge:?] {re:mixin,re:classloading}
	at vectorwing.farmersdelight.world.CropPatchGeneration.<clinit>(CropPatchGeneration.java:22) ~[farmersdelight:1.16.3-0.3.2] {re:classloading}
	... 14 more

This was in turn occured during

java.lang.ExceptionInInitializerError: null
	at vectorwing.farmersdelight.FarmersDelight.<init>(FarmersDelight.java:35) ~[farmersdelight:1.16.3-0.3.2] {re:classloading}

Of course your ModBlocks won't be ready when your mod is still constructing, and the registry events have not been dispatched yet.

Please consider migrating your Feature<?> registration, i.e. these

to DeferredRegister as well. Edit: for ConfiguredFeature you apparently cannot use registry event, see below

I wasn't aware there was a DeferredRegister for Features, that's good to know. Glad to know people are spotting these details! 😄
Gonna put a marker on this to enhance the code as suggested.

The issue has been fixed by eclipse-openj9/openj9#12148 and eclipse-openj9/openj9#12164.
The first nightly build which applied the fix is https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/tag/jdk8u-2021-03-11-08-45.

@vectorwing A quick correction on my previous statement: apparently you cannot use DeferredRegister on ConfiguredFeature<?, ?>; you have to use vanilla Registry.register for ConfiguredFeature. @ZekerZhayard was correct on separating out the event listener to a new class because doing so avoids the accidental class initialization.

For regular Feature, DeferredRegister seems viable and should be preferred when possible.

An example may be found at here: https://github.com/MysticMods/Traverse/blob/1.16/src/main/java/epicsquid/traverse/init/ModFeatures.java
Notice the empty load() method at the end of the class, which is for triggering class initialization; call it within a registry event.

Finally got some time to look at this properly. 🤦‍♂️

OK, so I already use DeferredRegister for my RiceCropFeature, and seems I won't need to change the ConfiguredFeature registers. So just to make sure I understood it correctly: ideally, I should separate onBiomeLoad from CropPatchGeneration into its own class? Perhaps the usual CommonEventHandler I already use?

Also, good to know the surrounding OpenJ9 issues are resolved! 👍

ideally, I should separate onBiomeLoad from CropPatchGeneration into its own class

That is correct.

I pushed a branch with the proposed changes, after chatting a bunch on Discord as well. Gonna open a PR for it soon; to anyone here, feel free to look over it and review whether I understood what was meant here, as I'm a bit new to some of this. x)