Obfuscating every class name in a Quarkus native build stops startup inside SmallRye Fault Tolerance

Native image was already half an answer to the bytecode problem. You ship machine code instead of class files, and closed-world analysis strips what nothing reaches ^[2]. Names survived that, and Advanced Obfuscation takes them too, across third-party dependencies as well as application code ^[1].

A Quarkus service does not only call methods; it resolves them by string. CDI bean resolution, reflective lookup, `Class#getName()` and Fault Tolerance frames all read names at runtime, and renaming changes what they read ^[8]. The build completed. Startup then died inside SmallRye Fault Tolerance with an NPE ^[5]. Diagnosis cost more than the failure suggests, because the trace was partly obfuscated as well; the author wrote that it "made the evening more educational than it needed to be" ^[6].

The flag he used was `-H:AdvancedObfuscation=export-mapping`, which writes a JSON map from original names to obfuscated ones and supports deobfuscating stack traces afterwards ^[7]. That map is what turned the NPE into something readable ^[7].

Oracle's documentation points at `-H:Preserve` as the carve-out ^[9]. On a Quarkus classpath it does more than that. "Preserve is a reachability mechanism as well as a rename exclusion," he wrote ^[10]. He wanted something narrow: if a type is already reachable, keep its name. Preserve makes code available even when analysis did not find it, and then does not rename it ^[12]. Broad package preservation started dragging in logging bridges, Kotlin metadata, MicroProfile Metrics and deployment classes, and the build failed with missing classes; narrower Preserve lists still pulled optionals in ^[11]. "For Quarkus, that second behaviour felt like a bit of a sledgehammer," he wrote ^[13].

Your release build has to move to Oracle GraalVM, because AO is experimental and Oracle-only while the Quarkus native ecosystem is Mandrel-first ^[14]. And your reflection registrations have to be complete, because the AO rule he points at starts with classes registered for reflection in reachability metadata ^[20].

On the protection question he is careful. AO is the binary distribution boundary and nothing else: Community still requires a signed licence, and the platform runs its own integrity and entitlement checks ^[15]. He states plainly that this is not a security boundary and not DRM, that a skilled attacker with time and the right tools can still reverse-engineer a native binary, and that this is a different bar from unzipping a JAR and reading class files ^[16].

So the strongest reading the evidence supports is narrower than a general answer for closed-source Java. One developer, eighteen months into building the Backbone platform, got AO through a CDI-heavy service and published the reproduction; he says he could not find a public write-up of anyone else doing it ^[18][4].