Processor safety rules

The static-proxy processors fail compilation for method and class shapes that cannot be safely proxied. The rules are intentional: a proxy that silently misses a method or one that pretends to override final would do more harm than refusing the build.

What is refused

final classes annotated for static proxy generation. The generated class needs to extend or implement the target type. A final class cannot be extended; an interface declared final is a compile error anyway, so this rule mainly catches final implementations being annotated by mistake.
final methods. A generated proxy must override every interface method. Overriding final is not allowed.
private methods. A proxy cannot interpose on a private call. If you see this finding, move the method to a different surface or strip the annotation off the type.
static methods. Static methods cannot be overridden, so the proxy cannot interpose on them. The processor refuses by default. Use -Aproxybuilder.failOnStaticMethods=false to downgrade the finding to a warning if you have a legacy interface mixing instance and static methods.

What is not generated as proxy methods

Methods declared by java.lang.Object are skipped — the generated class inherits them through normal Java inheritance. Specifically:

equals
hashCode
toString
finalize
wait, notify, notifyAll
getClass

If you want a logging or metrics wrapper around toString for debugging, write a @StaticLoggingProxy-equivalent custom processor that opts in to those methods explicitly.

Where the diagnostics show up

Findings are emitted through processingEnv.getMessager(). They appear in the Maven build log with the file and line of the offending element, and they fail the build at the compile phase.

How to override

Aside from the failOnStaticMethods flag, the rules are non-negotiable by design. If you have a legitimate reason to relax one, write a custom processor that does not subclass BasicStaticProxyAnnotationProcessor and implements its own safety checks (or none).