United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4507539 support using dynamic proxies as RMI stubs
JDK-4507539 : support using dynamic proxies as RMI stubs

Details
Type:
Enhancement
Submit Date:
2001-09-26
Status:
Closed
Updated Date:
2003-08-20
Project Name:
JDK
Resolved Date:
2003-08-13
Component:
core-libs
OS:
generic
Sub-Component:
java.rmi
CPU:
generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.3.1,1.4.0
Fixed Versions:
5.0 (tiger)

Related Reports
Duplicate:

Sub Tasks

Description


Name: pj23592			Date: 02/01/2002


Currently, exporting a remote object from J2SE RMI requires the presence of a
pre-generated stub class whose name is a function of the remote implementation
class being exported.  This stub class typically must be generated as a separate
compile-time step using the "rmic" tool, and it must be made available to all
clients of the remote object through various possible means (HTTP server, file
system, etc.).

It would be very straightforward for RMI to instead use a dynamic proxy class
(obtained using the java.lang.reflect.Proxy API) for the remote stub of a remote
object being exported-- in fact, java.lang.reflect.Proxy was designed with this
application in mind, and its generated dynamic proxy classes are very similar to
the stub classes generated by "rmic" with the "-v1.2" option used.  This would
require one new public class in the java.rmi APIs: a public InvocationHandler
class whose instances contain a java.rmi.server.RemoteRef instance.

Supporting the use of dynamic proxies as RMI stubs would simplify the
development and deployment of RMI applications by eliminating the "rmic" step
from the build process and by eliminating the need to provide for the
distribution of remote stub classes.

It would also facilitate exporting dynamic proxy instances as remote objects
themselves (which is currently only prevented by the need for named stub
classes), which has also been a highly requested feature-- which would allow for
more convenient logging, checking, and other server-side pre- and
post-processing handling of remote method invocations.

======================================================================

                                    

Comments
EVALUATION

The original Description of this RFE seems to focus on the desire to be able to export instances of dynamic proxy classes as remote objects-- currently that cannot be done in a straightforward manner (although various hacky workarounds are possible) because a static remote stub class must be available in the dynamic proxy's class loader with a name that is a function of the dynamic proxy class's (unpredictable) name.  The suggested "dynamic web server that generates stubs on the fly" is a possible bandage solution to this problem, but it is only a narrow solution, and it severly limits generality (can't use web server of choice for serving classes, etc.).

A more general solution to this particular problem (as well as to a much broader issue) within the J2SE RMI implementation is to actually use dynamic proxy classes for remote stub classes, so that statically-built remote stub classes are never required at all.  Not only would this remove the current limitation against being able to export dynamic proxy instances as remote objects (the original problem statement of this RFE), it would also eliminate the need to generate stub classes at compile-time with the rmic tool for all remote objects-- a development-time simplification that has been much requested by users of RMI for a long time.  This solution would best cover what most users see as the problem titled "RMI does not support dynamic proxies".

Therefore, this RFE will be interpreted as a request for J2SE RMI to support using dynamic proxy classes for stubs instead of requiring pre-built remote stub classes.  As far as new public API, this RFE will presumably require a public InvocationHandler class that contains an underlying RemoteRef.  There also would need to be a means for determining when dynamic proxies should be used instead of statically available stub classes.

###@###.### 2002-02-01

Name: pj23592			Date: 02/01/2002


This feature has been added for Tiger release

======================================================================
                                     
2002-02-01
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
tiger

FIXED IN:
tiger

INTEGRATED IN:
tiger
tiger-b15

VERIFIED IN:
tiger


                                     
2004-06-14



Hardware and Software, Engineered to Work Together