We Keep Coding

What happens when an interface is Autowired vs the implementation

I am working on a spring project that has the Service layer divided in two packages:
Interfaces
Implementation
While calling methods declared in the interface and defined in the implementation, which of the two should be #Autowired for which purpose?
What is the difference in autowiring the interface and the implementation?
I ask these keeping in mind that the point of this abstraction is usually to hide the declaration from the implementation

You can always autowire interfaces, but if you are having multiple implementations of your interface then you will need to tell spring which implementation to consider, and there are multiple ways to do so.
either mark one of them as #Primary
define name of bean on implementation and use #Qualifier annotation while autowiring it

As long as there is only a single implementation of the interface and that implementation is annotated with #Component with Spring's component scan enabled, Spring framework can find out the (interface, implementation) pair.
Once you have more than one implementation, then you need to qualify each of them and during auto-wiring, you would need to use the #Qualifier annotation to inject the right implementation, along with #Autowired annotation. If you are using #Resource (J2EE), then you should specify the bean name using the name attribute of this annotation.
Normally, both will work, you can autowire interfaces or classes.

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

Spring recommendations: proxying mechanism vs #Transactional on class or interface

Spring doc has the two recommendations:
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.
(from http://static.springsource.org/spring/docs/3.0.x/reference/transaction.html)
and
Spring AOP uses either JDK dynamic proxies or CGLIB to create the
proxy for a given target object. (JDK dynamic proxies are preferred
whenever you have a choice).
(from http://static.springsource.org/spring/docs/3.0.x/reference/aop.html#aop-understanding-aop-proxies)
Do I understand correctly that in order to follow both recommendations, I need to have #Transactional annotation on concrete class, but still provide an interfaces (that this class implements) containing all transactional methods, so that Spring can use JDK dynamix proxies for this interface?

It works like this
Have a business interface with methods, do not annotate interface methods with #Transactional
Write an implementation class for interface defined above and annotate methods in impl class with #Transactional
As spring recommends usage of JDK dynamic proxies which are interface based hence we need to have business interface in place.
Also, as stated
Java annotations are not inherited from interfaces
We need to annotate concrete / implementation class methods with #Transactional

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.