Bug ID: JDK-4507539 support using dynamic proxies as RMI stubs

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
5.0 tigerFixed



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.

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

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b15 VERIFIED IN: tiger

14-06-2004

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 ======================================================================

01-02-2002