When @target is used in a PointCut, all beans created in the same context are proxied, although that PointCut does not match those beans.
This bug was already mentioned and according to that ticket also fixed (#6859), but this behavior is still present in later versions of Spring.
In our application context some beans cannot be proxied. These beans cannot be modified, so usage of @target PointCuts breaks our application. However, not using @target is also not possible, as our use case requires Aspects to be applied to all methods of a wide range of classes (including inherited and interface methods). Our desired behavior for aspects could not be implemented with other PointCut definitions.
I am experiencing the same problem when using "@target", as compared to "target". In fact, @target cannot be used in even the simplest Spring Boot application, as it tries to proxy all kinds of beans, e.g. configuration classes pulled in by Boot.
In my opinion, Spring's AspectJExpressionPointcut.matches() method, which suggests that it treats Spring beans as non-dynamic with respect to target, @target, et.al, conflicts with the implementation in RuntimeTestWalker.SubtypeSensitiveVarTypeTestVisitor.visit(), which explicitly treats target and @target differently. In fact, when using target in favor of @target, the context ramp-up is fine.