How can I make a URLClassLoader behave like this?

Question

I'm trying to make a URLClassLoader which behaves as follows:

• If asked for a class whose name is in a given set of inclusions, load it as normal
• Otherwise, return a dummy class

I can't get this to work. In the attempt below, I expect the SpecialClassLoader to load Test$Thing succesfully. In doing so, I expect it to attempt to load Test$SuperThing, and I expect it to be okay about the fact that the dummy class Nothing is loaded instead.

However, something goes awry and a NoClassDefFoundError is thrown looking for Test$SuperThing.

Does anyone know how to fix this?

public class Test {

    private static class SuperThing {}

    private static class Thing extends SuperThing {}

    public static void main(String[] args) {
        Set<String> inclusions = new HashSet<String>();
        inclusions.add("Test$Thing"); // note Test$SuperThing is excluded
        URLClassLoader cl = (URLClassLoader) 
            Thread.currentThread().getContextClassLoader();
        SpecialClassLoader cll = 
            new SpecialClassLoader(cl.getURLs(), inclusions);
        try {
            cll.loadClass("Test$Thing"); // line 22 (see stacktrace below)
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
    }

    private static class Nothing {}

    private static final class SpecialClassLoader extends URLClassLoader {

        private final Set<String> inclusions;

            public SpecialClassLoader(URL[] urls, Set<String> inclusions) {
                super(urls);
                this.inclusions = inclusions;
            }

        @Override
        public Class<?> loadClass(String name) throws ClassNotFoundException {
            if (inclusions.contains(name)) {
                return findClass(name); // line 40 (see stacktrace below)
            }
            return Nothing.class;
        }
    }
}

EDIT: here is the stacktrace I get (line numbers 22 and 40 are indicated in listing above):

    Exception in thread "main" java.lang.NoClassDefFoundError: Test$SuperThing
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
        at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
        at Test$SpecialClassLoader.loadClass(Test.java:40)
        at Test.main(Test.java:22)

Answer 1

Can a class named Test$Thing.class found in the output of the compiler? As the code is given here it will be never directly referenced and maybe the compiler optimized the class away. In that case the reflection cannot find the class.

If that is the case you simply could add a (non-reflection) reference to the class, so that it will be compiled.

EDIT: After trying it out myself, I think I found the source of the problem. If I removed the 'extends SuperThing' from the Thing-declaration it complains about not finding java.lang.Object. Probably the classloader tries to load also all dependent classes (including the ones it extends) and cannot because they aren't on the whitelist. But that is a theory.

Answer 2

Here is what is happening.

• When you attempt to load Test$Thing, the defineClass method figures out that it needs to load the superclass of Test$Thing; i.e. Test$SuperThing.

• The system classloader calls your classloader, which returns the Nothing class.

• The system class loader says "Woah! that class doesn't have the right fully-qualified classname!!", and throws NoClassDefFoundError.

Basically, this system classloader is protecting against things that would destabilize the JVM. If it allowed a custom classloader to load the wrong class, nasty things could happen. For example, think about what might happen if some code invoked some method defined for the Test$SuperThing class after you had tricked classloader into loading the Nothing class.

If you want to do dirty tricks that substitute a dummy version of some class, you will need to generate bytecode on the fly, using the right fully qualified class name, the right superclass and interfaces, and methods with the right signatures. In short, you must satisfy the binary compatibility rules. If you don't, the system classloader will refuse to load your class ... no matter what you try to do in your custom classloader.

Frankly, you should be taking a completely different approach to whatever it is you are trying to do.