We Keep Coding

How to get Java custom annotations from Implementation class methods

For one of my requirment i have created a inteface with multiple methods and each method annotated with my own java custom annotation.
I have a spring aop aspect for my implementation class and i am not able to get my custom annotation in aop aspect.
after doing debug i understood my custom annotation is part of the interface and not in implementation class.
How can i get my custom annotation in my implementation methods which declared in interface ?

In Java, annotations are not inhereted from interfaces.With aspects you must annotate the implementation class (and/or methods within that class), not the interface (if any) that the class implements. String aop follows Java’s rule that annotations on interfaces are not inherited.
So, if you want to work with your annotation , create an abstract super class to be able to do this.
Inside aspect you work with proxy object and methods are wrapped in proxy calls. But if you know a real class/interface , you can get annotation by reflection api from source class/interface

Will an annotation on the interface persist on the implementation?

I have this technical doubt...
If I have an interface
public interface test{
#Transactional
public void mymethod();
}
and then I have my implementation
public class testImpl implements test{
#Override
public void mymethod(){
//..do something
}
}
Since I am using #Override, will my annotation #Transactional, #Lock or any other persist on my implementation? or will overriden by the interface method without adding any special behaviour from the annotation?

Best answer I have read on this matter:
See this link https://stackoverflow.com/a/5551597/3447634
COPY OF THAT ANSWER:
"It really all depends on your application architecture, in my opinion. It depends on how you are proxying your classes. If you have your app set to "proxy-target-class='true'" (in your application context, then your #Transactional information wont be picked up if you annotate the Interface.
Check out The Spring Docs -- "Tips" for more information.
Spring recommends that you only annotate concrete classes (and methods of concrete classes) with the #Transactional annotation, as opposed to annotating interfaces. You certainly can place the #Transactional annotation on an interface (or an interface method), but this works only as you would expect it to if you are using interface-based proxies. The fact that Java annotations are not inherited from interfaces means that if you are using class-based proxies (proxy-target-class="true") or the weaving-based aspect (mode="aspectj"), then the transaction settings are not recognized by the proxying and weaving infrastructure, and the object will not be wrapped in a transactional proxy, which would be decidedly bad."

Placing annotations on Implementation class methods and using proxy with reflection

I am working with proxy-reflection-annotations concept in java. I have created a proxy with Proxy.getInstance method.What I observed is this method takes only interface as parameters. So while using annotations, I can only place annotations on method names in Interface, but I would like to place annotations on methods in implementations of those interfaces.
So how can I achieve this.
Thanks

I have understood that JDKProxy is used when proxying interface via implementation and CBLIB proxy is used via inheritance(subclass extends superclass) proxying.

Use of proxies in Spring AOP

I am reading a book, which talks about enabling AspectJ support in Spring AOP.
Given below is a paragraph taken from the book:
To enable AspectJ annotation support in the Spring IoC container, you only have to define an empty
XML element aop:aspectj-autoproxy in your bean configuration file. Then, Spring will automatically
create proxies for any of your beans that are matched by your AspectJ aspects.
For cases in which interfaces are not available or not used in an application’s design, it’s possible to
create proxies by relying on CGLIB. To enable CGLIB, you need to set the attribute proxy-target-class=true in <aop:aspectj-autoproxy />.
I am not able to get the second paragraph. What is meant by 'interfaces are not available'. Can anyone illustrate this with an example ?

Spring AOP uses either JDK dynamic proxies or CGLIB to create the proxies for your target objects.
According to Spring documentation, in case your target implements at least one interface, a JDK dynamic proxy will be used. However if your target object does not implement any interfaces then a CGLIB proxy will be created.
This is how you can force creation of the CGLIB proxies (set proxy-target-class="true"):
<aop:config proxy-target-class="true">
<!-- other beans defined here... -->
</aop:config>
When using AspectJ and its autopoxy support you can also force CGLIB proxies. This is where the <aop:aspectj-autoproxy> is used and also here the "proxy-target-class" must be set to true:
<aop:aspectj-autoproxy proxy-target-class="true"/>
Please refer to Proxying mechanisms section of Aspect Oriented Programming with Spring documentation for more details.

Spring prefers to use interfaces for AOP because it can use JDK proxies.
Say for example I have an interface MyService
public interface MyService {
void doSomething();
}
And an implementation MyServiceImpl
#Service
public class MyServiceImpl implements MyService {
public void doSomething() {
// does something!
}
}
If Spring discovers that you've configured aspects for MyService, it will create a JDK Proxy that implements MyService and then proxy all calls through to your MyServiceImpl bean, adding aspect functionality where appropriate.
JDK proxies work by implementing the same interface as your target object and delegating calls to it; they do not work if there is no interface to implement. In case you don't have an interface like above, Spring needs to use a byte code library like CGLIB to dynamically create classes at runtime that incorporate the aspect functionality.

I found a blog here that clearly explains how AOP,Caching & Transaction works using runtime proxy classes.
When not coding to interface (quoting from the blog's section 'What if the bean class does not implement any interface?'):-
By default, if your bean does not implement an interface, Spring uses
technical inheritance: at startup time, a new class is created. It
inherits from your bean class and adds behavior in the child methods.
In order to generate such proxies, Spring uses a third party library
called cglib.

Spring AOP makes extensive use of proxies as a mechanism to implement cross-cutting concerns (a.k.a aspects) in a non-intrusive way, the idea basically is use the proxies as wrappers that enrich the original behaviour, i.e. add transactional capabilities.
To achieve this there are two options, depending of whether the original object implements an interface or not.
In the first case (the original object implements at least one interface) the dynamic proxy capabilities of the reflection API are used to create a proxy object that IMPLEMENTS the same interfaces that the original object and therefore the proxy can be used instead.
In the second case (the original object does NOT implement any interface), so a more elaborated trick must be used, and this is when CGLIB appears. According to the project page "CGLIB is used to extend Java classes and implements interfaces at runtime". So in this case the trick consists on create a proxy that EXTENDS the original object and therefore can be used instead.

Where should I put #Transactional annotation: at an interface definition or at an implementing class?

The question from the title in code:
#Transactional (readonly = true)
public interface FooService {
void doSmth ();
}
public class FooServiceImpl implements FooService {
...
}
vs
public interface FooService {
void doSmth ();
}
#Transactional (readonly = true)
public class FooServiceImpl implements FooService {
...
}

From http://static.springsource.org/spring/docs/2.0.x/reference/transaction.html
The Spring team's recommendation is that you only annotate concrete classes with the #Transactional annotation, as opposed to annotating interfaces. You certainly can place the #Transactional annotation on an interface (or an interface method), but this will only work as you would expect it to if you are using interface-based proxies. The fact that annotations are not inherited means that if you are using class-based proxies then the transaction settings will not be recognised by the class-based proxying infrastructure and the object will not be wrapped in a transactional proxy (which would be decidedly bad). So please do take the Spring team's advice and only annotate concrete classes (and the methods of concrete classes) with the #Transactional annotation.
Note: Since this mechanism is based on proxies, only 'external' method calls coming in through the proxy will be intercepted. This means that 'self-invocation', i.e. a method within the target object calling some other method of the target object, won't lead to an actual transaction at runtime even if the invoked method is marked with #Transactional!
(Emphasis added to the first sentence, other emphasis from the original.)

Spring's recommendation is that you annotate the concrete implementations instead of an interface. It's not incorrect to use the annotation on an interface, it's just possible to misuse that feature and inadvertently bypass your #Transaction declaration.
If you've marked something transactional in an interface and then refer to one of its implementing classes elsewhere in spring, it's not quite obvious that the object that spring creates will not respect the #Transactional annotation.
In practice it looks something like this:
public class MyClass implements MyInterface {
private int x;
public void doSomethingNonTx() {}
#Transactional
public void toSomethingTx() {}
}

You can put them on the interface but be warn that transactions may not end up happening in some cases. See the second tip in Secion 10.5.6 of the Spring docs:
Spring recommends that you only annotate concrete classes (and methods of concrete classes) with the #Transactional annotation, as opposed to annotating interfaces. You certainly can place the #Transactional annotation on an interface (or an interface method), but this works only as you would expect it to if you are using interface-based proxies. The fact that Java annotations are not inherited from interfaces means that if you are using class-based proxies (proxy-target-class="true") or the weaving-based aspect (mode="aspectj"), then the transaction settings are not recognized by the proxying and weaving infrastructure, and the object will not be wrapped in a transactional proxy, which would be decidedly bad.
I would recommend putting them on the implementation for this reason.
Also, to me, transactions seem like an implementation detail so they should be in the implementation class. Imagine having wrapper implementations for logging or test implementations (mocks) that don't need to be transactional.

Supporting #Transactional on the concrete classes:
I prefer to architect a solution in 3 sections generally: an API, an Implementation and a Web (if needed). I try my best to keep the API as light/simple/POJO as possible by minimizing dependencies. It's especially important if you play it in a distributed/integrated environment where you have to share the APIs a lot.
Putting #Transactional requires Spring libraries in the API section, which IMHO is not effective. So I prefer to add it in the Implementation where the transaction is running.

Putting it on the interface is fine as long all foreseeable implementers of your IFC care about TX data (transactions aren't problems that just databases deal with). If the method doesn't care about TX (but you need to put it there for Hibernate or whatever), put it on the impl.
Also, it might be a bit better to place #Transactional on the methods in the interface:
public interface FooService {
#Transactional(readOnly = true)
void doSmth();
}