Surviving a shrinker on desktop

Shrinking a desktop JVM app is not the same job as shrinking a mobile one. Three differences drive everything below: the desktop JVM's class-file verifier is strict and runs at load time, the UI stack reaches its rendering backend reflectively and by name, and the packager builds its classpath from your build output, so a shrink step that nothing consumes is invisible.

The policy this skill assumes: shrinking and obfuscation stay on, permanently. Runtime breakage is fixed with additional keep rules, never by turning a pass off. optimize = false as a "quick test" is how a temporary workaround becomes the permanent configuration.

Traps

Three optimization families must be disabled; everything else stays on. Each was found by a crash in a release build that the development run could not reproduce:

-optimizations !method/specialization/*,!code/allocation/variable,!method/inlining/*