So how to make sure that a proxy is indeed being used? For your own understanding, it’s interesting to go back into the code and see with your very eyes that you are indeed using a proxy.

A simple way is to print out the class name:

AccountService accountService = (AccountService) applicationContext.getBean(AccountService.class);
String accountServiceClassName = accountService.getClass().getName();
logger.info(accountServiceClassName);

On my computer, it shows the following output:

INFO : transaction.TransactionProxyTest - $Proxy13

This class is a Dynamic Proxy, generated by Spring using the JDK Reflection API (more information here).

At shutdown (eg. When the application  is stopped), the proxy class will be destroyed and you will only have AccountService and AccountServiceImpl on the file system:

How does Spring wire the proxy in-lieu of the target class?

@Controller
public class AccountController {
 private AccountService accountService;

private void setAccountService(AccountService accountService) {
 this.accountService=accountService;
}

 //…
}

The attribute accountService is of type AccountService (interface). The variable dependency is on the interface type AccountService, not the implementation type, which reduces the coupling between classes. This is a best practice.

As seen before, both AccountServiceImpl and the generated Proxy implement the interface AccountService.
•    If there is a proxy, Spring injects the proxy
•    If not, Spring injects the instance of type AccountServiceImpl.

Declarative caching is a new feature in Spring 3.1 that works like Spring’s declarative transaction support.

The @Cacheable annotation should be used in that way:

public class AccountServiceImpl  implements AccountService {

@Cacheable(value="accounts", key="#id")
public Account findAccount (long id) {
 // only enter method body if result is not in the cache already
 }
}

You should also have enabled caching inside Spring configuration as follows:

<cache:annotation-driven />

Here are the expected results:

accountService.findAccount (1); // Result stored into cache for key “1”
accountService.findAccount (1); // Result retrieved from cache. Target method not called.
accountService.findAccount (2); // Result stored into cache for key “2”

At runtime, a proxy is used to add Caching behavior.

Java Configuration

Note: this section requires some background knowledge of Java Configuration in Spring. Please feel free to skip it if you are not comfortable with this new configuration style.

You can learn more about Java Configuration here.  There is also an excellent article which discusses the various configuration styles here.

@Configuration
public class JavaConfig {

@Bean
 public AccountService accountService() {

return new AccountServiceImpl((accountRepository());
 }
@Bean
 public AccountRepository accountRepository () {
//…
 }

}

Spring calls the method accountService() every time it needs to wire an instance of the bean “accountService” and this one returns a “new” object of type AccountService. If 10 beans are using a dependency of type AccountService, this method is called 10 times.

However, no matters the Spring configuration has been made using Java Configuration or not, every bean should be a singleton by default. How is that possible and where is the magic happening?
This diagram explains how things work internally:

So the Proxy is adding behavior there. In the case that your bean should be a singleton, the action to turn your Plain Old Java Object into a singleton is performed by a child class (Proxy).

Conclusion

We’ve seen some use-cases on how proxies are used inside the Spring framework. There are many other examples: Aspect Oriented Programming, Security (using Spring Security), thread safety, scopes, etc…

If you would like to know more on the impact on performance when using proxies, you can read Alef Arendsen’s blog entry here.