In https://issues.redhat.com/browse/WELD-2712, we allowed self-interception of protected methods.
However, this changes the way bytecode is generated and causes bytecode verification errors in certain scenarios.

Problems were reported in WFLY as well as GF.

I managed to create a reproducer here. In short, there needs to be a hierarchy where the superclass has protected methods and is in a different package than its subclass. If Weld then tried to create client proxy of the subclass, a VerifyError will pop up.

This error is misleading though because it refers to a missing stackmap frame but looking at generated bytecode, classfilewriter doesn't create stackmap at all (which is technically valid since the generated code is targetted for JDK 6).

I didn't manage to nail down the actual cause and for now I think the best course of action is to revert the change and release 5.0.0.SP1 to prevent this error from happening.