Analysis and Extension of Java Dynamic Proxy Mechanism

introduction

The emergence of Java dynamic proxy mechanism allows Java developers to obtain proxy classes dynamically without manually writing proxy classes. They only need to specify a set of interfaces and delegate class objects to obtain proxy classes dynamically. The proxy class is responsible for dispatching all method calls to the delegate object for reflection execution. During the dispatch execution process, developers can also adjust the delegate class object and its functions as needed. This is a very flexible and elastic proxy framework. By reading this article, readers will have a deeper understanding of Java dynamic proxy mechanism. This article first analyzes the code of Java dynamic proxy based on its operation mechanism and characteristics, and deduces the internal implementation of dynamically generated classes.

Proxy: Design Pattern

Proxy is a commonly used design pattern, the purpose of which is to provide a proxy for other objects to control access to an object. The proxy class is responsible for preprocessing messages for the delegate class, filtering messages and forwarding messages, as well as performing subsequent processing after the message is executed by the delegate class.

Figure 1. Proxy mode

In order to maintain consistency of behavior, the proxy class and the delegate class usually implement the same interface, so there is no difference between the two in the eyes of the visitor. Through the proxy class, the direct access to the delegate class object can be effectively controlled, and the delegate class object can be well hidden and protected. At the same time, it also reserves space for implementing different control strategies, thus gaining greater flexibility in design. The Java dynamic proxy mechanism implements the design concept of the proxy pattern in a clever way.

Related classes and interfaces

To understand the mechanism of Java dynamic proxy, you first need to understand the following related classes or interfaces:

• java.lang.reflect.Proxy: This is the main class of the Java dynamic proxy mechanism, which provides a set of static methods to dynamically generate proxy classes and their objects for a set of interfaces.

Listing 1. Proxy's static methods

// Method 1: This method is used to obtain the call handler associated with the specified proxy object  
 static InvocationHandler getInvocationHandler(Object proxy) 
 
 // Method 2: This method is used to obtain the class object of the dynamic proxy class associated with the specified class loader and a set of interfaces  
 static Class getProxyClass(ClassLoader loader, Class[] interfaces) 
 
 // Method 3: This method is used to determine whether the specified class object is a dynamic proxy class  
 static   boolean isProxyClass(Class cl) 
 
 // Method 4: This method is used to generate a dynamic proxy class instance for a specified class loader, a set of interfaces, and a call handler  
 static Object newProxyInstance(ClassLoader loader, Class[] interfaces,
 InvocationHandler h)

• java.lang.reflect.InvocationHandler: This is the call processor interface, which customizes an invoke method to centrally handle method calls on dynamic proxy class objects. Usually, proxy access to the delegate class is implemented in this method.

Listing 2. InvocationHandler's core method

// This method is responsible for centrally processing all method calls on the dynamic proxy class. The first parameter is the proxy class instance, and the second parameter is the method object being called  
 // The third method is to call parameters. The call processor pre-processes or dispatches to the delegate class instance to execute according to these three parameters  
 Object invoke(Object proxy, Method method, Object[] args)

Each time a dynamic proxy class object is generated, a call processor object that implements the interface needs to be specified (see the third parameter of the Proxy static method 4).

• java.lang.ClassLoader: This is the class loader class, which is responsible for loading the bytecode of a class into the Java Virtual Machine (JVM) and defining a class object for it before the class can be used. The Proxy static method also generates a dynamic proxy class that needs to be loaded through a class loader before it can be used. The only difference between it and an ordinary class is that its bytecode is dynamically generated by the JVM at runtime rather than pre-existing in any .class file. Each time a dynamic proxy class object is generated, a class loader object must be specified (see the first parameter of the Proxy static method 4)

Agent mechanism and its characteristics

First, let's learn how to use Java dynamic proxy. There are four steps:

1. Create your own invocation handler by implementing the InvocationHandler interface;
2. Create a dynamic proxy class by specifying a ClassLoader object and a set of interfaces for the Proxy class;
3. The constructor of the dynamic proxy class is obtained through the reflection mechanism, and its only parameter type is the call processor interface type;
4. The dynamic proxy class instance is created through the constructor, and the call handler object is passed in as a parameter during construction.

Listing 3. Dynamic proxy object creation process

// InvocationHandlerImpl implements the InvocationHandler interface and can dispatch and forward method calls from the proxy class to the delegate class  
 // It usually contains a reference to the delegate class instance, which is used to actually execute the method call forwarded by the dispatch  
 InvocationHandler handler = new InvocationHandlerImpl(..); 
 
 // Dynamically create a proxy class object for a group of interfaces including the Interface interface through Proxy  
 Class clazz = Proxy.getProxyClass(classLoader, new Class[] { Interface. class , ... }); 
 
 // Get the constructor object from the generated class object through reflection  
 Constructor constructor = clazz.getConstructor( new Class[] { InvocationHandler. class }); 
 
 // Create a dynamic proxy class instance through the constructor object  
 Interface Proxy = (Interface)constructor.newInstance( new Object[] { handler });

The actual usage process is simpler because the static method newProxyInstance of Proxy has encapsulated the process from step 2 to step 4 for us, so the simplified process is as follows

Listing 4. Simplified dynamic proxy object creation process

// InvocationHandlerImpl implements the InvocationHandler interface and can dispatch and forward method calls from the proxy class to the delegate class  
 InvocationHandler handler = new InvocationHandlerImpl(..); 
 
 // Create a dynamic proxy class instance directly through Proxy  
 Interface proxy = (Interface)Proxy.newProxyInstance( classLoader,
 new Class[] { Interface. class },
 handler );

Next, let us take a look at some characteristics of the Java dynamic proxy mechanism.

First, some characteristics of the dynamically generated proxy class itself. 1) Package: If the interfaces being proxied are all public, then it will be defined in the top-level package (that is, the package path is empty). If there are non-public interfaces among the proxied interfaces (because interfaces cannot be defined as protect or private, so except for public, it is the default package access level), then it will be defined in the package where the interface is located (assuming that a non-public interface A in the com.ibm.developerworks package is proxied, then the package where the newly generated proxy class is located is com.ibm.developerworks). The purpose of this design is to ensure to the greatest extent that the dynamic proxy class will not be successfully defined and accessed due to package management issues; 2) Class modifiers: The proxy class has final and public modifiers, which means that it can be accessed by all classes, but cannot be inherited again; 3) Class name: The format is "$ProxyN", where N is an Arabic numeral that increases one by one, representing the dynamic proxy class generated by the Proxy class for the Nth time. One thing worth noting is that not every call to the static method of Proxy to create a dynamic proxy class will result in N The value increases because if you try to create a dynamic proxy class repeatedly for the same set of interfaces (including the same order of interfaces), it will intelligently return the class object of the previously created proxy class instead of trying to create a new proxy class. This saves unnecessary code duplication and improves the efficiency of creating proxy classes. 4) Class inheritance relationship: The inheritance relationship of this class is shown in the figure:

Figure 2. Inheritance diagram of dynamic proxy class

As can be seen from the figure, the Proxy class is its parent class, and this rule applies to all dynamic proxy classes created by Proxy. In addition, this class also implements a set of interfaces that it proxies, which is the fundamental reason why it can be safely type-converted to a certain interface that it proxies.

Next, let's take a look at some of the characteristics of proxy class instances. Each instance is associated with a call handler object, and the call handler object of the proxy class instance can be obtained through the static method getInvocationHandler provided by Proxy. When calling the methods declared in the proxy interface on the proxy class instance, these methods will eventually be executed by the invoke method of the call handler. In addition, it is worth noting that there are three methods in the root class java.lang.Object of the proxy class that will also be dispatched to the invoke method of the call handler for execution. They are hashCode, equals and toString. The possible reasons are: first, because these methods are public and non-final types, they can be overridden by the proxy class; second, because these methods often present certain characteristic attributes of a class and have a certain degree of distinction, so in order to ensure the consistency of the proxy class and the delegate class to the outside world, these three methods should also be dispatched to the delegate class for execution. When a set of interfaces of a proxy have a method declared repeatedly and the method is called, the proxy class always obtains the method object from the first interface and dispatches it to the call processor, regardless of whether the proxy class instance is being referenced externally in the form of this interface (or a subinterface inherited from this interface), because the current referenced type cannot be distinguished within the proxy class.

Next, let's take a look at the characteristics of a set of interfaces being proxied. First, be careful not to have duplicate interfaces to avoid compilation errors when the dynamic proxy class code is generated. Second, these interfaces must be visible to the class loader, otherwise the class loader will not be able to link them, which will cause the class definition to fail. Third, all non-public interfaces to be proxied must be in the same package, otherwise the proxy class generation will also fail. ***, the number of interfaces cannot exceed 65535, which is a limit set by the JVM.

*** Let's take a look at the characteristics of exception handling. From the method declared in the call processor interface, we can see that in theory it can throw any type of exception, because all exceptions are inherited from the Throwable interface, but is this true? The answer is no, because we must abide by an inheritance principle: that is, when a subclass overrides a parent class or implements a parent interface method, the exception thrown must be within the exception list supported by the original method. So although the call processor can be called in theory, it is often restricted in practice unless the method in the parent interface supports throwing Throwable exceptions. So what if an exception that is not supported in the interface method declaration is indeed generated in the invoke method? Don't worry, the Java dynamic proxy class has designed a solution for us: it will throw an UndeclaredThrowableException exception. This exception is a RuntimeException type, so it will not cause a compilation error. Through the getCause method of the exception, you can also get the original unsupported exception object to facilitate error diagnosis.

The code is ***'s teacher

Now that we have introduced the mechanism and features, let's take a look at the source code to understand how Proxy is implemented.

First, remember several important static variables of Proxy:

Listing 5. Important static variables of Proxy

// Mapping table: used to maintain class loader objects to their corresponding proxy class cache  
 private   static Map loaderToCache = new WeakHashMap(); 
 
 // Mark: used to mark that a dynamic proxy class is being created  
 private   static Object pendingGenerationMarker = new Object(); 
 
 // Synchronization table: records the type of dynamic proxy classes that have been created, mainly used by the isProxyClass method for related judgment  
 private   static Map proxyClasses = Collections.synchronizedMap( new WeakHashMap()); 
 
 // Associated call handler reference  
 protectedInvocationHandler h;

Then, let's take a look at the construction method of Proxy:

Listing 6. Proxy construction method

// Since the Proxy never calls the constructor directly, the private type means that any call is prohibited  
 private Proxy() {} 
 
 // Since the Proxy internal constructor is never called directly, protected means that only subclasses can call it  
 protected Proxy(InvocationHandler h) { this .h = h;}

Next, let's take a quick look at the newProxyInstance method, as it's fairly simple:

Listing 7. Proxy static method newProxyInstance

public   static Object newProxyInstance(ClassLoader loader,
            Class<?>[] interfaces,
            InvocationHandler h)
 throws IllegalArgumentException { 
 
 // Check if h is not empty, otherwise throw an exception  
 if (h == null ) {
 throw   new NullPointerException();
 } 
 
 // Get the proxy class type object associated with the specified class loader and a set of interfaces  
    Class cl = getProxyClass(loader, interfaces); 
 
 // Get the constructor object through reflection and generate a proxy class instance  
 try {
        Constructor cons = cl.getConstructor(constructorParams);
 return (Object) cons.newInstance( new Object[] { h });
    } catch (NoSuchMethodException e) { throw   new InternalError(e.toString());
    } catch (IllegalAccessException e) { throw   new InternalError(e.toString());
    } catch (InstantiationException e) { throw   new InternalError(e.toString());
    } catch (InvocationTargetException e) { throw   new InternalError(e.toString());
 }
 }

It can be seen that the real key to dynamic proxy is the getProxyClass method, which is responsible for dynamically generating proxy class type objects for a set of interfaces. Inside this method, you will be able to see all the heroes (static variables) in Proxy appear. Can't wait? Then let's walk into the most mysterious hall of Proxy and appreciate it. This method can be divided into four steps:

A certain degree of security check is performed on this set of interfaces, including checking whether the interface class object is visible to the class loader and is exactly the same as the interface class object that the class loader can recognize. It also checks to ensure that it is of interface type rather than class type. This step is completed through a loop. After the check passes, a string array containing all interface names will be obtained, recorded as String[] interfaceNames. Overall, this part of the implementation is relatively intuitive, so most of the code is omitted, leaving only the relevant code on how to determine whether a class or interface is visible to a specific class loader.

Listing 8. Determine the visibility of the interface through the Class.forName method

try {
 //Specify the interface name, class loader object, and set initializeBoolean to false to indicate that the class does not need to be initialized  
 // If the method returns normally, it means it is visible, otherwise it will throw a ClassNotFoundException exception to indicate that it is not visible  
    interfaceClass = Class.forName(interfaceName, false , loader);
 } catch (ClassNotFoundException e) {
 }

Get the cache table corresponding to the class loader object as the key from the loaderToCache mapping table. If it does not exist, create a new cache table and update it to loaderToCache. The cache table is a HashMap instance. Under normal circumstances, it will store key-value pairs (interface name list, dynamically generated proxy class class object reference). When the proxy class is being created, it will temporarily save (interface name list, pendingGenerationMarker). The purpose of the pendingGenerationMarker mark is to notify subsequent requests of the same type (the interface array is the same and the interface arrangement order in the group is also the same) that the proxy class is being created. Please wait until the creation is completed.

Listing 9. Use of cache table

do {
 // Use the interface name list as the keyword to get the corresponding cache value  
    Object value = cache.get(key);
 if (value instanceof Reference) {
        proxyClass = (Class) ((Reference) value).get();
 }
 if (proxyClass != null ) {
 // If it has been created, return directly  
 return proxyClass;
 } else   if (value == pendingGenerationMarker) {
 // The proxy class is being created, keep waiting  
 try {
 cache.wait();
        } catch (InterruptedException e) {
 }
 // Wait to be awakened, continue the loop and pass the second check to ensure that the creation is completed, otherwise wait again  
 continue ;
 } else {
 // Mark the proxy class is being created  
        cache.put(key, pendingGenerationMarker);
 // break out of the loop and enter the creation process  
 break ;
 } while ( true );

Listing 10. Dynamically generated proxy class

//Dynamically generate the bytecode array of the proxy class  
 byte [] proxyClassFile = ProxyGenerator.generateProxyClass( proxyName, interfaces);
 try {
 // Dynamically define the newly generated proxy class  
    proxyClass = defineClass0(loader, proxyName, proxyClassFile, 0 ,
        proxyClassFile.length);
 } catch (ClassFormatError e) {
 throw   new IllegalArgumentException(e.toString());
 } 
 
 // Record the generated proxy class object into the proxyClasses table  
 proxyClasses.put(proxyClass, null );

It can be seen that all code generation work is done by the mysterious ProxyGenerator. When you try to explore this class, the only information you can get is that it is located in the undisclosed sun.misc package, and there are several constants, variables and methods to complete this magical code generation process, but sun does not provide source code for study. As for the definition of dynamic classes, it is performed by the native static method defineClass0 of Proxy.

The code generation process enters the final part and updates the cache table according to the results. If successful, the class object reference of the proxy class is updated into the cache table. Otherwise, the corresponding key value in the cache table is cleared, and all possible waiting threads are finally awakened.

After completing the above four steps, all the details of proxy class generation have been introduced. The remaining static methods such as getInvocationHandler and isProxyClass are so intuitive that they can be completed by querying related variables, so their code analysis is omitted.

Proxy class implementation deduction

After analyzing the source code of the Proxy class, I believe that readers will have a clearer understanding of the Java dynamic proxy mechanism. However, when the exploration journey stops at the sun.misc.ProxyGenerator class, all the mysteries converge at this point. I believe that many readers will have similar doubts about this ProxyGenerator class: What does it do? How does it generate the code of the dynamic proxy class? Admittedly, there is no definite answer here. Let us start the exploration journey with these doubts.

Things are often not as complicated as they seem. What we need is to simplify them, so that we may have more opportunities to see the light. Putting aside all the unknown and complex mysterious factors in our imagination, if we use the simplest method to implement a proxy class, the only requirement is to implement the dispatch forwarding of the call processor, what will be your first reaction? "It doesn't sound very complicated." Indeed, the work involved in the calculation is nothing more than a few reflection calls and the boxing or unboxing process of primitive type data. The rest seems to have come naturally. Very good, let's sort out our thoughts and complete a complete deduction process together.

Listing 11. Implementation of dispatch forwarding deduction for method calls in proxy classes

// Assume that the proxy interface Simulator is required  
 public   interface Simulator {
 short simulate( int arg1, long arg2, String arg3) throws ExceptionA, ExceptionB;
 } 
 
 // Assuming the proxy class is SimulatorProxy, its class declaration will be as follows  
 final   public   class SimulatorProxy implements Simulator { 
 
 // Calling a reference to the handler object  
 protected InvocationHandler handler; 
 
 // Constructor that takes the call handler as a parameter  
 public SimulatorProxy(InvocationHandler handler){
 this .handler = handler;
 } 
 
 // Implement interface method simulate  
 public   short simulate( int arg1, long arg2, String arg3)
 throws ExceptionA, ExceptionB { 
 
 // The first step is to get the Method object of the simulate method  
        java.lang.reflect.Method method = null ;
 try {
            method = Simulator. class .getMethod(
 "simulate" ,
 new Class[] { int . class , long . class , String. class } );
        } catch (Exception e) {
 // Exception handling 1 (omitted)  
 } 
 
 // The second step is to call the handler's invoke method to dispatch the forwarding method call  
 Object r = null ;
 try {
            r = handler.invoke( this ,
 method,
 // Boxing is required for primitive type parameters  
 new Object[] { new Integer(arg1), new Long(arg2), arg3});
        } catch (Throwable e) {
 // Exception handling 2 (omitted)  
 }
 // The third step is to return the result (if the return type is a primitive type, unboxing is required)  
 return ((Short)r).shortValue();
 }
 }

In order to highlight the general logic, the simulation focuses more on the normal process and downplays the error handling, but in practice, error handling is also very important. From the above deduction, we can derive a very general structured process: the first step is to obtain the called method object from the proxy interface, the second step is to dispatch the method to the call processor for execution, and the third step is to return the result. In this process, all the information is known, such as the interface name, method name, parameter type, return type, and the required boxing and unboxing operations. Since this is how we write it manually, what reason do we have to believe that ProxyGenerator will not do a similar implementation? At least this is a more possible implementation.

Next, let's return our attention to the previously downplayed error handling. In exception handling 1, since we have reason to ensure that all information such as interface name, method name and parameter type are accurate, the probability of this part of the exception occurring is basically zero, so it can basically be ignored. As for exception handling 2, we need to think more. Recall that the interface method may declare support for a list of exceptions, and the call handler invoke method may throw an exception that is not supported by the interface method. Recall the previously mentioned characteristics of Java dynamic proxy regarding exception handling. For unsupported exceptions, the UndeclaredThrowableException runtime exception must be thrown. So by deducing again, we can come up with a clearer situation for exception handling 2:

Listing 12. Refined exception handling 2

Object r = null ; 
 
 try {
    r = handler.invoke( this ,
 method,
 new Object[] { new Integer(arg1), new Long(arg2), arg3}); 
 
 } catch ( ExceptionA e) { 
 
 // The interface method supports ExceptionA and can throw  
 throw e; 
 
 } catch ( ExceptionB e ) {
 // The interface method supports ExceptionB and can throw  
 throw e; 
 
 } catch (Throwable e) {
 // Other unsupported exceptions will be thrown UndeclaredThrowableException  
 throw   new UndeclaredThrowableException(e);
 }

In this way, we have completed the deductive implementation of the dynamic proxy class. The deductive implementation follows a relatively fixed pattern and can be applied to any interface defined arbitrarily. In addition, the information required for code generation is known, so there is reason to believe that even machine-generated code can continue this style, at least it can be guaranteed to be feasible.

a fly in the ointment

It is true that Proxy has been designed very beautifully, but there is still a little regret, that is, it can never get rid of the shackles of only supporting interface proxy, because its design is destined to this regret. Recall the inheritance relationship diagram of those dynamically generated proxy classes, they are destined to have a common parent class called Proxy. Java's inheritance mechanism destined these dynamic proxy classes to be unable to implement dynamic proxy for class, because multiple inheritance is essentially not feasible in Java.

There are many reasons why people can deny the necessity of class proxy, but there are also some reasons to believe that supporting class dynamic proxy will be better. The division between interface and class is not very obvious, but it has become so detailed in Java. If we only consider the declaration of methods and whether they are defined, there is a hybrid of the two, and its name is abstract class. Implementing dynamic proxy for abstract classes is believed to have its intrinsic value. In addition, there are some historical classes that will never have dynamic proxy because they do not implement any interface. All these things have to be said to be a small regret.

However, not being the best does not mean not being great. Greatness is an essence, and Java dynamic proxy is an example.