Examples of Class Objects

You can obtain a class object in Java in several ways. The simplest is:

Class<?> myCl = getClass();

This returns the class object of the instance that it is called from. However, as we know from our survey of the public methods of Object, the getClass() method on Object is public, so we can also obtain the class of an arbitrary object o:

Class<?> c = o.getClass();

Class objects for known types can also be written as “class literals”:

// Express a class literal as a type name followed by ".class"
c = int.class; // Same as Integer.TYPE
c = String.class; // Same as "a string".getClass()
c = byte[].class; // Type of byte arrays

For primitive types and void, we also have class objects that are represented as literals:

// Obtain a Class object for primitive types with various
// predefined constants
c = Void.TYPE; // The special "no-return-value" type
c = Byte.TYPE; // Class object that represents a byte
c = Integer.TYPE; // Class object that represents an int
c = Double.TYPE; // etc.; see also Short, Character, Long, Float

For unknown types, we will have to use more sophisticated methods.

Class Objects and Metadata

The class objects contain metadata about the given type. This includes the methods, fields, constructors, and the like that are defined on the class in question. This metadata can be accessed by the programmer to investigate the class, even if nothing is known about the class when it is loaded.

For example, we can find all the deprecated methods in the class file (they will be marked with the @Deprecated annotation):

Class<?> clz = getClassFromDisk();
for (Method m : clz.getMethods()) {
  for (Annotation a : m.getAnnotations()) {
    if (a.annotationType() == Deprecated.class) {
      System.out.println(m.getName());
    }
  }
}

We could also find the common ancestor class of a pair of class files. This simple form will work when both classes have been loaded by the same classloader:

public static Class<?> commonAncestor(Class<?> cl1, Class<?> cl2) {
  if (cl1 == null || cl2 == null) return null;
  if (cl1.equals(cl2)) return cl1;
  if (cl1.isPrimitive() || cl2.isPrimitive()) return null;

  List<Class<?>> ancestors = new ArrayList<>();
  Class<?> c = cl1;
  while (!c.equals(Object.class)) {
    if (c.equals(cl2)) return c;
    ancestors.add(c);
    c = c.getSuperclass();
  }
  c = cl2;
  while (!c.equals(Object.class)) {
    for (Class<?> k : ancestors) {
      if (c.equals(k)) return c;
    }
    c = c.getSuperclass();
  }

  return Object.class;
}

Class files have a very specific layout that they must conform to if they are to be legal and loadable by the JVM. The sections of the class file are (in order):

• Magic number (all class files start with the four bytes CA FE BA BE in hexadecimal)

• Version of class file standard in use

• Constant pool for this class

• Access flags (abstract, public, etc.)

• Name of this class

• Inheritance info (e.g., name of superclass)

• Implemented interfaces

• Fields

• Methods

• Attributes

The class file is a simple binary format, but it is not human readable. Instead, tools like javap (see Chapter 13) should be used to comprehend the contents.

One of the most often used sections in the class file is the Constant Pool, which contains representations of all the methods, classes, fields, and constants that the class needs to refer to (whether they are in this class or another). It is designed so that bytecodes can simply refer to a constant pool entry by its index number—which saves space in the bytecode representation.

There are a number of different class file versions created by various Java versions. However, one of Java’s backward compatibility rules is that JVMs (and tools) from newer versions can always use older class files.

Let’s look at how the classloading process takes a collection of bytes on disk and turns it into a new class object.

Loading

The classloading process starts with loading a byte array. This is usually read in from a filesystem, but can be read from a URL or other location (often represented as a Path object).

The Classloader::defineClass() method is responsible for turning a class file (represented as a byte array) into a class object. It is a protected method and so is not accessible without subclassing.

The first job of defineClass() is loading. This produces the skeleton of a class object, corresponding to the class you’re attempting to load. By this stage, some basic checks have been performed on the class (e.g., the constants in the constant pool have been checked to ensure that they’re self-consistent).

However, loading doesn’t produce a complete class object by itself, and the class isn’t yet usable. Instead, after loading, the class must be linked. This step breaks down into separate subphases:

• Verification

• Preparation and resolution

• Initialization

Verification

Verification confirms that the class file conforms to expectations, and that it doesn’t try to violate the JVM’s security model (see “Secure Programming and Classloading” for details).

JVM bytecode is designed so that it can be (mostly) checked statically. This has the effect of slowing down the classloading process but speeding up runtime (as checks can be omitted).

The verification step is designed to prevent the JVM from executing bytecodes that might crash it or put it into an undefined and untested state where it might be vulnerable to other attacks by malicious code. Bytecode verification is a defense against malicious hand-crafted Java bytecodes and untrusted Java compilers that might output invalid bytecodes.

Preparation and Resolution

After successful verification, the class is prepared for use. Memory is allocated and static variables in the class are readied for initialization.

At this stage, variables aren’t initialized, and no bytecode from the new class has been executed. Before we run any code, the JVM checks that every type referred to by the new class file is known to the runtime. If the types aren’t known, they may also need to be loaded—which can kick off the classloading process again, as the JVM loads the new types.

This process of loading and discovery can execute iteratively until a stable set of types is reached. This is called the “transitive closure” of the original type that was loaded.¹

Let’s look at a quick example, by examining the dependencies of java.lang.Object. Figure 11-1 shows a simplified dependency graph for Object. It only shows the direct dependencies of Object that are visible in the public API of Object, and the direct, API-visible dependencies of those dependencies. In addition, the dependencies of Class on the reflection subsystem, and of PrintStream and PrintWriter on the I/O subsystems, are shown in very simplified form.

In Figure 11-1, we can see part of the transitive closure of Object.

Figure 11-1. Transitive closure of types

Initialization

Once resolved, the JVM can finally initialize the class. Static variables can be initialized and static initialization blocks are run.

This is the first time that the JVM is executing bytecode from the newly loaded class. When the static blocks complete, the class is fully loaded and ready to go.

Classloader Hierarchy

The JVM has a hierarchy of classloaders; each classloader in the system (apart from the initial, “bootstrap” classloader) has a parent that it can delegate to.

The convention is that a classloader will ask its parent to resolve and load a class, and will only perform the job itself if the parent classloader is unable to comply. Some common classloaders are shown in Figure 11-2.

Figure 11-2. Classloader hierarchy

public static class DiskLoader extends ClassLoader {
  public DiskLoader() {
    super(DiskLoader.class.getClassLoader());
  }

  public Class<?> loadFromDisk(String clzName) throws IOException {
    byte[] b = Files.readAllBytes(Paths.get(clzName));

    return defineClass(null, b, 0, b.length);
  }
}

When to Use Reflection

Many, if not most, Java frameworks use reflection in some capacity. Writing architectures that are flexible enough to cope with code that is unknown until runtime usually requires reflection. For example, plug-in architectures, debuggers, code browsers, and REPL-like environments are usually implemented on top of reflection.

Reflection is also widely used in testing (e.g., by the JUnit and TestNG libraries) and for mock object creation. If you’ve used any kind of Java framework you have almost certainly been using reflective code, even if you didn’t realize it.

To start using the Reflection API in your own code, the most important thing to realize is that it is about accessing objects where virtually no information is known, and that the interactions can be cumbersome because of this.

If some static information is known about dynamically loaded classes (e.g., that the classes loaded all implement a known interface), this can greatly simplify the interaction with the classes and reduce the burden of operating reflectively.

It is a common mistake to try to create a reflective framework that attempts to account for all possible circumstances, instead of dealing only with the cases that are immediately applicable to the problem domain.

How to Use Reflection

The first step in any reflective operation is to get a Class object representing the type to be operated on. From this, other objects, representing fields, methods, or constructors, can be accessed and applied to instances of the unknown type.

To get an instance of an unknown type, it is simplest to use the no-arg constructor, which is made available directly via the Class object:

Class<?> clz = getSomeClassObject();
Object rcvr = clz.newInstance();

For constructors that take arguments, you will have to look up the precise constructor needed, represented as a Constructor object.

The Method objects are one of the most commonly used objects provided by the Reflection API. We’ll discuss them in detail—the Constructor and Field objects are similar in many respects.

private Class<?>                   clazz;
private int                        slot;
// This is guaranteed to be interned by the VM in the 1.4
// reflection implementation
private String                     name;
private Class<?>                   returnType;
private Class<?>[]                 parameterTypes;
private Class<?>[]                 exceptionTypes;
private int                        modifiers;
// Generics and annotations support
private transient String           signature;
// Generic info repository; lazily initialized
private transient MethodRepository genericInfo;
private byte[]                     annotations;
private byte[]                     parameterAnnotations;
private byte[]                     annotationDefault;
private volatile MethodAccessor    methodAccessor;

Object rcvr = "a";
try {
  Class<?>[] argTypes = new Class[] { };
  Object[] args = null;

  Method meth = rcvr.getClass().getMethod("hashCode", argTypes);
  Object ret = meth.invoke(rcvr, args);
  System.out.println(ret);

} catch (IllegalArgumentException | NoSuchMethodException |
         SecurityException e) {
  e.printStackTrace();
} catch (IllegalAccessException | InvocationTargetException x) {
  x.printStackTrace();
}

public class MyCache {
  private void flush() {
    // Flush the cache...
  }
}

Class<?> clz = MyCache.class;
try {
  Object rcvr = clz.newInstance();
  Class<?>[] argTypes = new Class[] { };
  Object[] args = null;

  Method meth = clz.getDeclaredMethod("flush", argTypes);
  meth.setAccessible(true);
  meth.invoke(rcvr, args);
} catch (IllegalArgumentException | NoSuchMethodException |
         InstantiationException | SecurityException e) {
  e.printStackTrace();
} catch (IllegalAccessException | InvocationTargetException x) {
  x.printStackTrace();
}

public class CustomClassloadingExamples {
    public static class DiskLoader extends ClassLoader {

        public DiskLoader() {
            super(DiskLoader.class.getClassLoader());
        }

        public Class<?> loadFromDisk(String clzName)
          throws IOException {
            byte[] b = Files.readAllBytes(Paths.get(clzName));

            return defineClass(null, b, 0, b.length);
        }
    }

    public void findDeprecatedMethods(Class<?> clz) {
        for (Method m : clz.getMethods()) {
            for (Annotation a : m.getAnnotations()) {
                if (a.annotationType() == Deprecated.class) {
                    System.out.println(m.getName());
                }
            }
        }
    }

    public static void main(String[] args)
      throws IOException, ClassNotFoundException {
        CustomClassloadingExamples rfx =
          new CustomClassloadingExamples();

        if (args.length > 0) {
            DiskLoader dlr = new DiskLoader();
            Class<?> clzToTest = dlr.loadFromDisk(args[0]);
            rfx.findDeprecatedMethods(clzToTest);
        }
    }
}

Dynamic Proxies

One last piece of the Java Reflection story is the creation of dynamic proxies. These are classes (which extend java.lang.reflect.Proxy) that implement a number of interfaces. The implementing class is constructed dynamically at runtime, and forwards all calls to an invocation handler object:

InvocationHandler h = new InvocationHandler() {
  @Override
  public Object invoke(Object proxy, Method method, Object[] args)
                    throws Throwable {
    String name = method.getName();
    System.out.println("Called as: "+ name);
    switch (name) {
      case "isOpen":
        return false;
      case "close":
        return null;
    }

    return null;
  }
};

Channel c =
  (Channel) Proxy.newProxyInstance(Channel.class.getClassLoader(),
                            new Class[] { Channel.class }, h);
c.isOpen();
c.close();

Proxies can be used as stand-in objects for testing (especially in test mocking approaches).

Another use case is to provide partial implementations of interfaces, or to decorate or otherwise control some aspect of delegation:

public class RememberingList implements InvocationHandler {
  private final List<String> proxied = new ArrayList<>();

  @Override
  public Object invoke(Object proxy, Method method, Object[] args)
                         throws Throwable {
    String name = method.getName();
    switch (name) {
      case "clear":
        return null;
      case "remove":
      case "removeAll":
        return false;
    }

    return method.invoke(proxied, args);
  }
}

RememberingList hList = new RememberingList();

List<String> l =
  (List<String>) Proxy.newProxyInstance(List.class.getClassLoader(),
                                        new Class[] { List.class },
                                        hList);
l.add("cat");
l.add("bunny");
l.clear();
System.out.println(l);

Proxies are an extremely powerful and flexible capability that are used within many Java frameworks.

MethodType

In Reflection, method signatures are represented as Class[]. This is quite cumbersome. By contrast, method handles rely on MethodType objects. These are a typesafe and object-oriented way to represent the type signature of a method.

They include the return type and argument types, but not the receiver type or name of the method. The name is not present, as this allows any method of the correct signature to be bound to any name (as per the functional interface behavior of lambda expressions).

A type signature for a method is represented as an immutable instance of MethodType, as acquired from the factory method MethodType.methodType(). For example:

MethodType m2Str = MethodType.methodType(String.class); // toString()

// Integer.parseInt()
MethodType mtParseInt =
  MethodType.methodType(Integer.class, String.class);

// defineClass() from ClassLoader
MethodType mtdefClz = MethodType.methodType(Class.class, String.class,
                                            byte[].class, int.class,
                                            int.class);

This single piece of the puzzle provides significant gains over Reflection, as it makes method signatures significantly easier to represent and discuss. The next step is to acquire a handle on a method. This is achieved by a lookup process.

Method Lookup

Method lookup queries are performed on the class where a method is defined, and are dependent on the context that they are executed from. In this example, we can see that when we attempt to look up the protected Class::defineClass() method from a general lookup context, we fail to resolve it with an IllegalAccessException, as the protected method is not accessible:

public static void lookupDefineClass(Lookup l) {
  MethodType mt = MethodType.methodType(Class.class, String.class,
                                        byte[].class, int.class,
                                        int.class);

  try {
    MethodHandle mh =
      l.findVirtual(ClassLoader.class, "defineClass", mt);
    System.out.println(mh);
  } catch (NoSuchMethodException | IllegalAccessException e) {
    e.printStackTrace();
  }
}

Lookup l = MethodHandles.lookup();
lookupDefineClass(l);

We always need to call MethodHandles.lookup()—this gives us a lookup context object based on the currently executing method.

Lookup objects have several methods (which all start with find) declared on them for method resolution. These include findVirtual(), findConstructor(), and findStatic().

One big difference between the Reflection and Method Handles APIs is access control. A Lookup object will only return methods that are accessible to the context where the lookup was created—and there is no way to subvert this (no equivalent of Reflection’s setAccessible() hack).

Method handles therefore always comply with the security manager, even when the equivalent reflective code does not. They are access-checked at the point where the lookup context is constructed—the lookup object will not return handles to any methods to which it does not have proper access.

The lookup object, or method handles derived from it, can be returned to other contexts, including ones where access to the method would no longer be possible. Under those circumstances, the handle is still executable—access control is checked at lookup time, as we can see in this example:

public class SneakyLoader extends ClassLoader {
  public SneakyLoader() {
    super(SneakyLoader.class.getClassLoader());
  }

  public Lookup getLookup() {
    return MethodHandles.lookup();
  }
}

SneakyLoader snLdr = new SneakyLoader();
l = snLdr.getLookup();
lookupDefineClass(l);

With a Lookup object, we’re able to produce method handles to any method we have access to. We can also produce a way of accessing fields that may not have a method that gives access. The findGetter() and findSetter() methods on Lookup produce method handles that can read or update fields as needed.

Invoking Method Handles

A method handle represents the ability to call a method. They are strongly typed and as typesafe as possible. Instances are all of some subclass of java.lang.invoke.MethodHandle, which is a class that needs special treatment from the JVM.

There are two ways to invoke a method handle—invoke() and invokeExact(). Both of these take the receiver and call arguments as parameters. invokeExact() tries to call the method handle directly as is, whereas invoke() will massage call arguments if needed.

In general, invoke() performs an asType() conversion if necessary—this converts arguments according to these rules:

• A primitive argument will be boxed if required.

• A boxed primitive will be unboxed if required.

• Primitives will be widened is necessary.

• A void return type will be massaged to 0 or null, depending on whether the expected return was primitive or of reference type.

• null values are passed through, regardless of static type.

With these potential conversions in place, invocation looks like this:

Object rcvr = "a";
try {
  MethodType mt = MethodType.methodType(int.class);
  MethodHandles.Lookup l = MethodHandles.lookup();
  MethodHandle mh = l.findVirtual(rcvr.getClass(), "hashCode", mt);

  int ret;
  try {
    ret = (int)mh.invoke(rcvr);
    System.out.println(ret);
  } catch (Throwable t) {
    t.printStackTrace();
  }
} catch (IllegalArgumentException |
  NoSuchMethodException | SecurityException e) {
  e.printStackTrace();
} catch (IllegalAccessException x) {
  x.printStackTrace();
}

Method handles provide a clearer and more coherent way to access the same dynamic programming capabilities as Reflection. In addition, they are designed to work well with the low-level execution model of the JVM and thus hold out the promise of much better performance than Reflection can provide.