How to get the binary name of a java class, if one has only the fully qualified name?

Question

The reflection classes and methods as well as class loaders etc. need the so called "binary" names of classes to work with.

The question is, how does one get the binary name if one only has the fully qualified name, i.e. the name that one would use in source code.

For example:

package frege;
public static class RT {
    ....
    public static class X { .... }
}

The fully qualified name of the class would be frege.RT.X. Yet, to get the class object, one needs to write:

Class.forName("frege.RT$X")

and not

Class.forName("frege.RT.X")    // fails with ClassNotFoundException

because X happens to be an inner class of frege.RT.

A possible, but clumsy, solution would be to replace . with $ from backwards, one by one, until Class.forName() doesn't throw ClassNotFoundException anymore or there are no more . to replace.

Is there any better/well known/standard solution? I looked in the API docs for Class, CLassLoader and java.lang.reflect but did not find anything usable.

Answer 1

A simple name omits a lot of information and it is possible to have many classes with the same simple name. That may make this impossible. For example:

package stack;

/**
 * 
 * @author Simon Greatrix
 */
public class TestLocal {

    public Object getObject1() {
        class Thing {
            public String toString() { 
                return "I am a Thing";
            }
        }
        return new Thing();
    }

    public Object getObject2() {
        class Thing {
            public String toString() { 
                return "I am another Thing";
            }
        }
        return new Thing();
    }

    public Object getObject3() {
        class Thing {
            public String toString() { 
                return "I am a rather different Thing";
            }
        }
        return new Thing();
    }

    /**
     * @param args
     */
    public static void main(String[] args) {
        TestLocal test = new TestLocal();
        Object[] objects = new Object[] {
                test.getObject1(),                
                test.getObject2(),                
                test.getObject3()                
        };

        for(Object o : objects) {
            System.out.println("Object      : "+o);
            System.out.println("Simple Name : "+o.getClass().getSimpleName());
            System.out.println("Name        : "+o.getClass().getName());
        }
    }
}

This produces the output:

Object      : I am a Thing
Simple Name : Thing
Name        : stack.TestLocal$1Thing
Object      : I am another Thing
Simple Name : Thing
Name        : stack.TestLocal$2Thing
Object      : I am a rather different Thing
Simple Name : Thing
Name        : stack.TestLocal$3Thing

As you can see, all three local classes have the same simple name.

Answer 2

I think its a safe bet that canonical names specify unique classes. As mentioned above javac will not let you create two classes with the same canonical name from withen a single compilation unit. If you have 2 compilations then you can get into trouble regarding which class you load, but at that point I'd be more worried about a library's package name colliding with your package names, which is avoided by all but the malicious.

For this reason, I think its a safe bet to assume you wont run into that scenario. Along those lines, for those who are interested, I implemented the OP's suggestion (flipping $s to .s), and simply throwing a ClassNotFoundException in the event that it doesn't find any classes with that canonical name, or if it finds two or more that have that name.

   /**
 * Returns the single class at the specified canonical name, or throws a {@link java.lang.ClassNotFoundException}.
 *
 * <p>Read about the issues of fully-qualified class paths vs the canonical name string
 * <a href="http://stackoverflow.com/questions/13331902/how-to-get-the-binary-name-of-a-java-class-if-one-has-only-the-fully-qualified">discussed here</a>.
 */
public static <TStaticallyNeeded> Class<TStaticallyNeeded> classForCanonicalName(String canonicalName)
        throws ClassNotFoundException {

    if (canonicalName == null) { throw new IllegalArgumentException("canonicalName"); }

    int lastDotIndex = canonicalName.length();
    boolean hasMoreDots = true;

    String attemptedClassName = canonicalName;

    Set<Class> resolvedClasses = new HashSet<>();

    while (hasMoreDots) try {
        Class resolvedClass = Class.forName(attemptedClassName);
        resolvedClasses.add(resolvedClass);
    }
    catch (ClassNotFoundException e) {
        continue;
    }
    finally {
        if(hasMoreDots){
            lastDotIndex = attemptedClassName.lastIndexOf('.');
            attemptedClassName = new StringBuilder(attemptedClassName)
                    .replace(lastDotIndex, lastDotIndex + 1, "$")
                    .toString();
            hasMoreDots = attemptedClassName.contains(".");
        }
    }

    if (resolvedClasses.isEmpty()) {
        throw new ClassNotFoundException(canonicalName);
    }

    if (resolvedClasses.size() >= 2) {
        StringBuilder builder = new StringBuilder();
        for (Class clazz : resolvedClasses) {
            builder.append("'").append(clazz.getName()).append("'");
            builder.append(" in ");
            builder.append("'").append(
                    clazz.getProtectionDomain().getCodeSource() != null
                            ? clazz.getProtectionDomain().getCodeSource().getLocation()
                            : "<unknown code source>"
            ).append("'");
            builder.append(System.lineSeparator());
        }

        builder.replace(builder.length() - System.lineSeparator().length(), builder.length(), "");

        throw new ClassNotFoundException(
                "found multiple classes with the same canonical names:" + System.lineSeparator() +
                        builder.toString()
        );
    }

    return resolvedClasses.iterator().next();
}

it still annoys me greatly that the "expected" flow is to hit that catch(NoClass) continue code, but if you've ever told eclipse or intelliJ to auto-break on any exceptions thrown, you'll know this kind of behavior is par for the course.