About Rafal Borowiec

Rafal is an IT specialist with about 8 years of commercial experience, specializing in software testing and quality assurance, software development, project management and team leadership.

Spring 4: CGLIB-based proxy classes with no default constructor

In Spring, if the class of a target object that is to be proxied doesn’t implement any interfaces, then a CGLIB-based proxy will be created. Prior to Spring 4, CGLIB-based proxy classes require a default constructor. And this is not the limitation of CGLIB library, but Spring itself. Fortunately, as of Spring 4 this is no longer an issue. CGLIB-based proxy classes no longer require a default constructor. How can this impact your code? Let’s see.

One of the idioms of dependency injection is constructor injection. It can be generally used when the injected dependencies are required and must not change after the object is initiated. In this article I am not going to discuss why and when you should use constructor dependency injection. I assume you use this idiom in your code or you consider using it. If you are interested in learning more, see the resources section in the bottom of this article.

Contructor injection with no-proxied beans

Having the following collaborator:

package pl.codeleak.services;

import org.springframework.stereotype.Service;

public class Collaborator {
    public String collaborate() {
        return "Collaborating";

we can easily inject it via constructor:

package pl.codeleak.services;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

public class SomeService {

    private final Collaborator collaborator;

    public SomeService(Collaborator collaborator) {
        this.collaborator = collaborator;

    public String businessMethod() {
        return collaborator.collaborate();


You may notice that both Collaborator and the Service have no interfaces, but they are no proxy candidates. So this code will work perfectly fine with Spring 3 and Spring 4:

package pl.codeleak.services;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.ContextConfiguration;
import org.springframework.test.context.junit4.SpringJUnit4ClassRunner;
import pl.codeleak.Configuration;

import static org.assertj.core.api.Assertions.assertThat;

@ContextConfiguration(classes = Configuration.class)
public class WiringTests {

    private SomeService someService;

    private Collaborator collaborator;

    public void hasValidDependencies() {



Contructor injection with proxied beans

In many cases your beans need to be decorated with an AOP proxy at runtime, e.g when you want to use declarative transactions with @Transactional annotation. To visualize this, I created an aspect that will advice all methods in SomeService. With the below aspect defined, SomeService becomes a candidate for proxying:

package pl.codeleak.aspects;

import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;
import org.springframework.stereotype.Component;

public class DummyAspect {

    public void before() {
        // do nothing


When I re-run the test with Spring 3.2.9, I get the following exception:

Could not generate CGLIB subclass of class [class pl.codeleak.services.SomeService]: Common causes of this problem include using a final class or a non-visible class; nested exception is java.lang.IllegalArgumentException: Superclass has no null constructors but no arguments were given

This can be simply fixed by providing a default, no argument, constructor to SomeService, but this is not what I want to do – as I would also need to make dependencies non-final.

Another solution would be to provide an interface for SomeService. But again, there are many situations when you don’t need to create interfaces.

Updating to Spring 4 solves the problem immediately. As documentation states:

CGLIB-based proxy classes no longer require a default constructor. Support is provided via the objenesis library which is repackaged inline and distributed as part of the Spring Framework. With this strategy, no constructor at all is being invoked for proxy instances anymore.

The test I created will fail, but it visualizes that CGLIB proxy was created for SomeService:

to be exactly an instance of:
but was an instance of:

After removing the first assertion from the test, it will run just perfectly fine.


Related Whitepaper:

Functional Programming in Java: Harnessing the Power of Java 8 Lambda Expressions

Get ready to program in a whole new way!

Functional Programming in Java will help you quickly get on top of the new, essential Java 8 language features and the functional style that will change and improve your code. This short, targeted book will help you make the paradigm shift from the old imperative way to a less error-prone, more elegant, and concise coding style that’s also a breeze to parallelize. You’ll explore the syntax and semantics of lambda expressions, method and constructor references, and functional interfaces. You’ll design and write applications better using the new standards in Java 8 and the JDK.

Get it Now!  

One Response to "Spring 4: CGLIB-based proxy classes with no default constructor"

  1. Fedor says:

    >> And this is not the limitation of CGLIB library, but Spring itself.

    This problem is not directly related to cglib: cglib just do subclassing to implement proxy. How to instantiate such proxy – there is the question. The simplest way is to call constructor and this approach was used before Spring 4.0. Other way is to skip constructor call: object will have invalid state, no fields will be initialized, but for proxy we do not need them. Also all side effects from constructor will note take effect.
    Currently Spring use objenesis library – it helps do such instantiation on different jvm.

Leave a Reply

five − = 1

Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books