I've discovered this via bytecode analysis of spring-security-aspects. They have five almost identical aspects all inheriting from an abstract aspect, which has public void setSecurityInterceptor(MethodInterceptor securityInterceptor). I've noticed that one, and only one, concrete class will have this method bridged, at random, while the others won't.
I've provided a reproducer for this issue:
Just run
./gradlew build
./gradlew checkBridgeMethods
and the result is
=== Bridge Method Analysis ===
Checking: PreAuthorizeAspect
Has bridge setSecurityInterceptor: NO
Checking: AbstractMethodInterceptorAspect
Has bridge setSecurityInterceptor: NO
Checking: PostAuthorizeAspect
Has bridge setSecurityInterceptor: NO
Checking: PostFilterAspect
Has bridge setSecurityInterceptor: YES
=== Detailed Method Analysis ===
Methods in PreAuthorizeAspect.class:
Methods in AbstractMethodInterceptorAspect.class:
public void setSecurityInterceptor(pvt.repro.aspectj.MethodInterceptor);
Methods in PostAuthorizeAspect.class:
Methods in PostFilterAspect.class:
public void setSecurityInterceptor(pvt.repro.aspectj.MethodInterceptor);
This looks like a minor issue as of now, but it will make builds irreproducible.
I've discovered this via bytecode analysis of
spring-security-aspects. They have five almost identical aspects all inheriting from an abstract aspect, which haspublic void setSecurityInterceptor(MethodInterceptor securityInterceptor). I've noticed that one, and only one, concrete class will have this method bridged, at random, while the others won't.I've provided a reproducer for this issue:
Just run
./gradlew build
./gradlew checkBridgeMethods
and the result is
This looks like a minor issue as of now, but it will make builds irreproducible.