Use cglib BeanCopier with multiple classloaders

Question

I'd like to copy one bean to another in Java. The problem that it is inside classloading-juggler framework and both classes are loaded by different classloaders which also differs from the current classloader.

It is required to do it in most efficient way, so the best way is to use bytecode generation solutions (like cglib BeanCopier), but not reflection-based.

The issue is that cglib BeanCopier doesn't work in this case. The simplest code to show it is:

URL classesUrl = new File("/directory/with/class-files-for-Person").toURL();
Class<?> c1 = new URLClassLoader(new URL[] {classesUrl}).loadClass("Person");
Class<?> c2 = new URLClassLoader(new URL[] {classesUrl}).loadClass("Person");
Object o1 = c1.newInstance();
Object o2 = c2.newInstance();
BeanCopier copier = BeanCopier.create(o1.getClass(), o2.getClass(), false);
copier.copy(o1, o2, null);

It gives the exception:

Exception in thread "main" java.lang.ClassCastException: Person cannot be cast to Person
at net.sf.cglib.empty.Object$$BeanCopierByCGLIB$$da60538e.copy(<generated>)
at Main.main(Main.java:22)

I'm finding the way to resolve it. In my case both classes are the same but loaded with custom classloaders. Also the properties contain only privimives and classes from java.* (so they are loaded by standard classloader).

Answer 1

This sounds like there is a bug in cglib that only considers the class name but does not look at the class loader. As a matter of fact, cglib is full of bugs when you are not using the Enhancer which is used a little bit more while the BeanCopier is rather exotic. There is more bad news, cglib is not very actively developed, so the best you could do to fix the bug was trying yourself.

What you could try is to add a Converter as the third argument to copy and to alter the third constructor argument to true in order to activate this converter. Let the Converter simply return the value argument. A draw back of this solution is that your primitives will be both boxed and unboxed each time a value is copied what is terrible for performance.

However, there is good news. Modern JVMs such as HotSpot know a concept called inflation. Inflation is applied when a specific reflection is applied multiple times (more than 15 times on the current HotSpot JVM). The JVM then creates byte code that corresponds to this reflective call and replaces it by the generated byte code. This is exactly what the BeanCopier does but with bugs (apparently). For this reason, the BeanCopier is old news. Modern JVMs are smart enough to apply this optimization themselfs. If you want to know more about inflation, you can for example consult HotSpot related javadoc.

For further reading, I found this article that you might find interesting.