bridgeSpecial

Reroutes a class's invokespecial through the bridge. A super call always goes, as every other call to a foreign member does: AccessBridge.superCall opens the method, and its erased descriptor takes an argument that crossed the bridge as Object. A constructor goes only where the call as written would fail — its descriptor names a type the bridge erased, so verification would fail, and the whole class with it; or the constructor itself is not public (closedInit) — since rerouting one costs a discarded allocation. True if owner's call was rerouted.

A rerouted constructor keeps its NEW and DUP, so the class still initializes where it did: AccessBridge.construct builds the instance, and the two uninitialized copies under it are dropped. Only a NEW's <init> can go that way. A super(...)/this(...) initializes this, which nothing but invokespecial can do, so it stays as written and fails past what invokespecial allows: a non-public constructor, an erased argument. The verifier's own rule tells the two apart — such a call exists only in a constructor and names the class itself (ours, never here) or its direct superclass, superInit — except for a NEW of the direct superclass inside a constructor, which stays as written too, deliberately: telling it apart would take state carried across instructions, for a shape a snippet almost never writes.

Only a class's call is rerouted. An interface's super call, super<I>.m(), stays as written: a default method is public, and none in the game names a type a snippet cannot, so there is nothing for the bridge to do.