I read about guice AOP in the documentation here :- https://github.com/google/guice/wiki/AOP From the documentation :-
Behind the scenes, method interception is implemented by generating bytecode at runtime. Guice dynamically creates a subclass that applies interceptors by overriding methods. If you are on a platform that doesn't support bytecode generation (such as Android), you should use Guice without AOP support.
What does the documentation means by extending the subclass. Is this the method interceptor subclass? Does it work by using reflection to intercept the method? The reason I ask this question is because in the documentation, this line is followed by this :-
Due to this, we have the following limitations on the guice AOP
a) AOP cannot be applied to a private method.
Unclear to me why AOP cannot be applied to a private method.
Unclear to me why AOP cannot be applied to a private method.
Because private methods are not inherited by subclasses, i.e. there is no way to intercept a private method and then delegate to it because the subclass cannot even call that method. This is a normal Java limitation and has nothing to do with AOP specifically.
BTW, if you want a full-fledged, powerful AOP tool working with any JVM language and able to intercept private methods without the need to resort to dynamic proxies (subclasses created during runtime like Guice or Spring AOP), just use AspectJ.
What does the documentation means by extending the subclass.
The JRE knows the concept of dynamic proxies in order to be able to intercept method calls and (optionally) delegate to the original call before/after doing something else in an interceptor method. This works for interfaces only, but CGLIB extends this concept to subclasses of non-interface classes, which is why in proxy-based AOP frameworks such as Spring AOP (and maybe Guice, not 100% sure) proxies are used in order to implement AOP. AspectJ works differently, it does not use or need any dynamic proxies or other types of subclasses.