IllegalAccessError when loading a class generated with a NamingStrategy

I have a simple scenario where I receive an IllegalAccessError when loading a generated class that uses a NamingStrategy.

java.lang.IllegalAccessError: class FooBar.Foo cannot access its superclass org.modelmapper.FooTest$Foo
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:791)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
    at net.bytebuddy.dynamic.loading.ByteArrayClassLoader.findClass(ByteArrayClassLoader.java:48)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
    at net.bytebuddy.dynamic.ClassLoadingStrategy$Default.load(ClassLoadingStrategy.java:59)
    at net.bytebuddy.dynamic.DynamicType$Default$Unloaded.load(DynamicType.java:1132)
    at org.modelmapper.FooTest.proxyClassFor(FooTest.java:35)
    at org.modelmapper.FooTest.test(FooTest.java:40)

Here’s the complete test:

@Test
public class FooTest {
  static class Foo {
  }

  public void test() {
    new ByteBuddy().withNamingStrategy(new NamingStrategy() {
          public String getName(UnnamedType unnamedType) {
            return "FooBar." + unnamedType.getSuperClass().getSimpleName();
          }
        })
        .subclass(Foo.class)
        .method(MethodMatchers.any())
        .intercept(InvocationHandlerAdapter.of(new InvocationHandler() {
          public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
            return null;
          }
        }))
        .make()
        .load(FooTest.class.getClassLoader(), ClassLoadingStrategy.Default.WRAPPER)
        .getLoaded();
  }
}

[raphw]

Java is a quite tricky language when it comes to package-private access. Package-private access is also rather an invention for being used by compilers rather then by users since they have strange semantics.

You might have heard before that two classes are only consider equal by the Java run time if they were loaded with the same class loader even if they otherwise represent an identical class. The same is true for Java packages. If a class is loaded with a different class loader, it cannot get private-package access to any classes (or class members) that belong to another class loader.

The injection strategy uses reflection to load a class into a given class loader. The wrapper class loader on the other hand, creates a new child class loader for loading a given class. The former strategy is more efficient since a class loader is a rather expensive object to Java (takes about 70 nanoseconds to create it in my benchmarks). However, it does not need to call internal methods. Also, the wrapper class loader allows the unloading of the generated class if none of its instances and its class and class loader are not longer reachable. This is handy when creating classes that are only needed for a limited amount of time such as in bootstrap procedures. One specific use case of this strategy would be mocking for example as for creating type safe DSLs. This allows to keep the perm gen requirements of an application down as the injector strategy often targets the system class loader what makes loaded classes invincible for the application’s life time.

The injector strategy is equivalent to Javassist and cglib’s approaches.

[raphw]

I thought about predefining such a strategy for Byte Buddy 0.2. However, this would require you to resolve any invokable method of a class in order to check if any of those methods is package-private relatively to the generated class in order to determine its necessity. Such reflective look-ups are unfortunately expensive. I might still just add the strategy and add an explicit warning of its costs.