This message was deleted.

sounds like some funky classloading manipulation is going on to get

java.lang.Class.getEnumConstants()

and NoClassDefFoundErrors. Have seen cases where plugins assume every run is a clean environment, which isn’t the case with the Gradle Daemon (by design), resulting in classloader pollution / corruption.

I'm rewriting some bytecode so the failing

getEnumConstants

is somehow expected at this point. What caught me off guard is that until I thought about stopping the daemon I had no clue at all what it could be

gotta love classloaders. 🙄 Depending how they are implemented, the behaviour for subsequent failures could be different (for example, they may have a negative cache of classes that aren’t found or could not be loaded).

Almost all cases of

NoClassDefFoundError

I've seen so far were follow-up problems after some static initializer threw an error as indeed JVM does not try to load the class again after initialization failed but throws

NoClassDefFoundError

, not to be confused with

ClassNotFoundException

.