Stack frames have three components: Locals, OperandStack, and Flags. The StackMapTable attribute lets class files declare the first two components directly, but the Flags are always inferred.

Here's the inference rule in 4.10.1.4:

"If any local variable in Locals has the type uninitializedThis, then Flags has the single element flagThisUninit, otherwise Flags is an empty list."

If a StackMapTable entry declares an OperandStack with an uninitializedThis type, but does not include uninitializedThis in Locals, per the rule the Flags will *not* include flagThisUninit.

This seems to suggest that an <init> method could return without fully initializing 'this', since there's no flag to prevent it. That would break an important invariant. Fortunately, while it's possible to write such code, it would be unreachable: any reachable code that tried to jump here would have had to remove the flag first via invokespecial, and when they did so, all UninitializedThis types would have been removed from the type state. There's no way to push one back on the stack.

Why does the inference rule ignore the OperandStack? Looks to me like an oversight, probably because the author of the rule took for granted that <init> methods would always store an uninitializedThis in their 0th local variable.

The odd combination of uninitializedThis without flagThisUninit seems like fertile ground for unhandled cases and broken invariants. We can eliminate the risk by updating the inference rule so that any entries with an uninitializedThis in their OperandStack get the flag.

This is a technically incompatible change, breaking verification for a class that has unreachable code declaring an uninitializedThis stack type (but not a local), and then tries to either return or jump to another unrestricted basic block. That seems very unlikely in practice.