Consider diagnostics for Java bytecode referencing retired ManagedPeer #11635

Context

The original question was whether trimmable apps should offer an opt-in compatibility shim for old generated or handwritten Java bytecode referencing:

net.dot.jni.ManagedPeer.registerNativeMembers(Class<?> nativeClass, String methods)
net.dot.jni.ManagedPeer.construct(Object self, String constructorSignature, Object... args)

That bridge is now retired, not merely excluded from one runtime JAR. Merged #13030 removed managed/Java ManagedPeer, ManagedPeerNativeRegistration, experimental JavaInterop1 generation, handwritten Java.Interop proxies, and java-interop.jar. The old JCW emitter was subsequently removed in #13080. See #11727 and the broader cleanup tracker #11843.

Compatibility decision

Do not add a runtime shim or an AndroidEnableManagedPeerCompatibility opt-in. The earlier shim/remapping/constructor-dispatch proposals are superseded. Old Java bytecode calling this retired bridge is unsupported and must be regenerated or migrated.

Supported XAJavaInterop1 C# binding generation remains; the trimmable typemap Java generator is a separate pipeline using generated registration/activation rather than ManagedPeer.

Remaining question: actionable diagnostics

The original issue also asked for a clearer failure than an eventual missing-class error for legacy Java bytecode. A dedicated build-time ManagedPeer reference diagnostic has not been implemented by the retirement series. Keep this issue open for that decision rather than treating it as delivered.

• Decide whether existing Java tooling failures provide sufficient guidance or a dedicated diagnostic is warranted.
• If warranted, choose the detection stage (Java source, class/JAR, DEX, or a combination), diagnostic code/severity, and actionable migration message; implement focused coverage.

This remaining work does not authorize restoring ManagedPeer, silently ignoring its calls, or reviving the experimental code-generation path.