Browse Prior Art Database

A Pattern for Reducing Cost of Creating a Dynamic Proxy

IP.com Disclosure Number: IPCOM000021305D
Original Publication Date: 2004-Jan-13
Included in the Prior Art Database: 2004-Jan-13
Document File: 3 page(s) / 12K

Publishing Venue

IBM

Abstract

Disclosed is a method for reducing the cost of creating Java dynamic proxy objects when the typical technique of pooling is not permitted. In a middleware system where one software vendor is the user of a dynamic proxy object and a different software vendor is the provider of the dynamic proxy object, pooling a dynamic proxy object may not be permitted. Pooling may not be allowed in order to provide greater isolation between software from different vendors and to assist in problem determination.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 43% of the total text.

Page 1 of 3

A Pattern for Reducing Cost of Creating a Dynamic Proxy

The newProxyInstancemethod of the java.lang.reflect.Proxyclass provides the capability to dynamically generate a proxy object that implements an arbitrary set of java interfaces. The first parameter of the newProxyInstance method is the java.lang.ClassLoader object for the proxy class. The second parameter is an array of java.lang.Classobject that contains the list of interface classes the proxy must implement. The third parameter is an object that implements the java.lang.reflect.InvocationHandlerinterface. A method invocation on a proxy instance through one of its proxy interfaces will be dispatched to the invokemethod of the instance's invocation handler, passing the proxy instance, a java.lang.reflect.Methodobject identifying the method that was invoked, and an array of type java.lang.Objectcontaining the invoked method's arguments. The InvocationHandlerprocesses the invoked method as appropriate

Although the Proxyclass provides a very useful and powerful function, it is also fairly expensive to create a dynamic proxy object by calling the newProxyInstancemethod. To reduce this cost, a typical approach is to create a pool of proxy objects that allows reuse of the proxy object by allocating the proxy from the pool rather than creating a new proxy object. However, in a middleware it where one software vendor is the user of a dynamic proxy object and a different software vendor is the provider of the dynamic proxy object, pooling a dynamic proxy object may not be allowed in order to provide greater isolation between different vendors software and to assist in problem determination. This paper discloses a method for reducing the cost or dynamic proxy creation when pooling is not allowed.

The first step for reducing the cost is to use the abstract factory design pattern for creating a proxy object. The factory object can then cache in its own instance variable the java.lang.Constructor object for constructing a new Proxy instance. It can do this by using the getProxyClass method on the Proxyclass to get the Classobject for the generated Proxyobject and then using the getContructor method on the proxy Classobject to get the Constructorobject. By caching the Constructorobject in the factory object, the cost of creating the Class array of interfaces needed for the getProxyClass method is avoided and is only done once to get the Constructorobject. Once this is done, a new Proxyinstance can be created by simply using the newInstancemethod on the cached Constructor object to create a new proxy instance.

The next step involves making it possible for the factory object to keep a free pool of InvocationHandlerobjects. By doing so, the factory can avoid the cost of creating a new InvocationHandlerinstance each time it needs to call the newInstancemethod on the Constructor object for creating a new Proxyinstance. Instead, it just allocates an InvocationHandlerobject from the free pool. T...