The RMI/JRMP implementation generates stubs dynamically by default. This was added in Java 5. Support for statically generated stubs is no longer necessary and should be deprecated. 

Deprecation and eventual removal will proceed in three phases. This bug covers only phase 1. The other phases are described only for informational purposes and will be covered by future bug reports, and they will be implemented in future releases.

1. All APIs and runtime support having to do with static JRMP stubs will be deprecated. This bug covers just this phase.

2. The second phase covers the removal of facilities related to the development of new RMI applications that use static stubs.

3. The third and final phase includes the removal of runtime support for static JRMP stubs. This will be rather involved, as RMI internals such as DGC, the Registry, and Activation use static stubs. In addition, other parts of the JDK including JMX, JNDI, and JDI also use static stubs. All such dependencies must be removed before runtime support for static stubs can be removed.

Details of phase 1 are listed below.

The following APIs and behaviors are to be deprecated, along with a change to the default value of a system property.

A. The java.rmi.server.RemoteStub class. This class is the common superclass for all statically generated stubs, and as such, it is no longer necessary and can be deprecated. There is no replacement for this class, nor is a replacement necessary.

B. The java.rmi.server.UnicastRemoteObject.exportObject(Remote) method. This method exports a remote server object and returns an instance of a static stub class. That static stub must already exist, e.g., having been created using rmic. Applications should use the exportObject(Remote, port) method instead, which creates stubs dynamically.

C. The portion of the rmic stub compiler that supports JRMP stub and skeleton creation is to be deprecated. We may want to add a warning message to rmic that is emitted if JRMP stub creation is requested. Rmic also supports stub generation for IIOP/CORBA (using the -iiop option to rmic); this support is not deprecated as part of this effort.

D. Runtime support for JRMP skeletons and static stubs is deprecated. This behavior is not visible through any specific APIs, though use of static stubs is governed by the ignoreStubClasses system property (see below). Note, the skeleton classes themselves are already deprecated.

E. The java.rmi.server.ignoreStubClasses system property exists and currently has a default value of false. Its default value could be changed to true, which would cause APIs such as exportObject(Remote, port) not to search for static stubs before creating dynamic stubs. NOTE: this change may affect higher-level services (such as JMX, JNDI, and JDI) as well as built-in RMI services (Registry, RMID/Activation, Activation Groups, DGC) which have static stubs compiled into the platform and which may rely on static stub support to be enabled by default. (An earlier version of this proposal changed the default to true so that static stubs would be ignored. This had some compatibility issues, so the change in default has been removed from this proposal.)

This change will affect various pieces of documentation other than the java.rmi.* javadoc. External changes include:

* The rmic tool page. See JDK-8026020.

* The RMI Specification, section 3.1 and chapter 8.

* The java.rmi.server.ignoreStubClasses property is not documented on the java.rmi properties page, although it is documented in the UnicastRemoteObject javadoc. This property should be documented on the java.rmi properties page. 

Most tutorials and other documentation already seems to have been updated with information about dynamic stubs, so there is relatively little mention of static stubs remaining.