动态Java编译和反射加载类的AbstractMethodError

Question

I am trying the following wrt Refleciton, let me know if this is possible

public class A {
    void start(){
       execute();
     }

}

public class B extends A {
    void execute()
    {
       doWork();
    }
    public abstract void doWork();
}

I have the above classes packaged in a jar and have it running on a JVM. Now I am trying to create another class at run time, compile it at run time and trying to use reflection to invoke Class B's execute function().

public class C extends B {
     @Override
     public void doWork()
     {
       //Implementation
     }
}

Reflection code:

Classloader = urls of application jars and url of C.class, compiled at run time. Parent loader - Thread.currentThread().getContextClassLoader() I am also setting the current thread's context class loader to the classloader created above.

Class<? extends B> cls = (Class<? extends B>) Class.forName("className", true, clsLoader);

Object obj = cls.newInstance();
Method method = obj.getClass().getSuperclass().getMethod("start", new Class[0]);
method.invoke(obj, new Object[0]);   

I am able to get the method and the invoke also gets called. However when class B's execute is called, it is trying to call the doWork() and then I run into an AbstractMethodError. Upon looking up on the exception, I see that the exception happens with incorrect classloaders/jars. But I am not sure how do I go about fixing it in my case.

Can anyone assist?

Answer 1

First of all, let's clarify the myths about the context class loader of a Thread : unless code asks explicitly for that loader via Thread.getContextClassLoader() (and uses it), it has no relevance for class loading at all.

Each class has an initiating class loader which defined the class and references to other classes within that class are always resolved via that initiating class loader. This even applies to reflective loading via Class.forName(String) (without an explicit ClassLoader ); it will use the initiating class loader of the caller.

If you want to load C via a custom class loader which needs to have access to B , because C subclasses it, the best way to determine the parent loader for the creation of your new loader is B.class.getClassLoader() . However, in your simple setup, it's the same loader as returned by ClassLoader.getSystemClassLoader() which is also the default class loader as returned by Thread.getContextClassLoader() , that's why it worked.

You know that it worked because you could load C successfully. While other references might be resolved lazily, the direct superclass must be resolved immediately, so B is in scope of C 's loader.

Assuming that the absence of a declaration of execute() in A or an abstract modifier on class B are just oversights made by posting the question, the reason why invoking the method doesn't work is much simpler: the method abstract void doWork(); is not public .

Since B and C are loaded by different class loaders, they are considered to reside in different packages, regardless of their qualified name. Therefore, the method doWork() in C does not override the method doWork() in B . This hasn't been detected at compile-time, as, at compile-time, there is no class loader hierarchy. So the compiler considers B and C to reside in the same package, based on their qualified name (or explicit package declaration). Therefore the compiler assumes that C.doWork() implements B.doWork() and C can be declared non- abstract .

If you declare the method doWork() in B as public , it should work. And it should work much simpler:

try(URLClassLoader l = new URLClassLoader(new URL[]{/* url pointing to C */})) {
    l.loadClass("C").asSubclass(B.class).newInstance().execute();
}