JDK-8060488 : Drop RMI statically generated stubs from JMX Remote API
  • Type: Enhancement
  • Component: core-svc
  • Sub-Component: javax.management
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2014-10-14
  • Updated: 2024-08-07
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
tbdUnresolved
Related Reports
Relates :  
JDK-8058830 - Update rmic to work a modular image
Relates :  
JDK-8023863 - deprecate support for statically-generated stubs from RMI (JRMP)
Relates :  
JDK-8132353 - add deprecation annotations and javadoc tags to static stubs generated by rmic
Sub Tasks
JDK-8132134 :  
Make the javadocs for the JMX RMI stub classes explicit about them being deprecated - Closed
Description
RMI has been generating stubs dynamically by default since Java SE 5 / JDK 5. Support for statically generated stubs is no longer necessary and has was deprecated in Java SE 8.

This issue tracks dropping the statically generated stubs from the JMX Remote API. Dropping the statically generated stubs will simplify the build and allow us to eventually drop the rmic tool.
Comments
The linked issue JDK-8132353 will add the @Deprecated info to the emitted static stubs.
30-07-2015
There is nothing that can be done here in JMX. Stuart, could you, please, comment on the possibility of enabling the dynamic stubs for JMX by default?
22-06-2015
Currently, to maintain compatibility we need to keep the generated stubs around (so we can connect to the older versions) but don't use them when exporting the remote objects and use dynamic proxies instead. I came across the "java.rmi.server.ignoreStubClasses" property which, when set to true, will force using dynamic stubs even though the statically generated ones are available. This is something which could actually make it possible to phase out the statically generated stubs gradually. Eg. in JDK9 we'd still keep generating the stubs via rmic but wouldn't actually use them when exporting remote objects. The generated stubs would be used to communicate with the pre-jdk9 JMX agents. Simultaneously, the stubs will be marked as deprecated in JavaDoc (using the trick you showed me). The problem is that the property is set to 'false' by default and needs to be set from command line. I am wondering whether we could agree changing the default value of this property to true. The dynamic proxies have been around for quite a few years and releases now. Another way to tackle this would be to have a way to force using the dynamic stubs when actually exporting a remote object. Eg. for JMX we know for sure that not using the static stubs is ok - JMX is ready and willing to use the dynamic stubs whenever possible. Or use a system property to specify packages which would preferentially use dynamic stubs. I am afraid that there is nothing to be done in the JMX to address this issue - JMX is consuming (and prefering) the dynamic stubs already. At most I can add @Deprecated annotation to the static stubs. It's just that by removing the static stubs from JDK 9 without will make it impossible to connect to pre-9 JVMs since they will still use static stubs and require the classes to be present in the other party as well.
18-05-2015
Regarding the compatibility issues - after removing the static stubs it won't be possible to open JMX connection (via RMI) to applications with the static stubs present, unless 'java.rmi.server.ignoreStubClasses' property is set to 'true'. If it is done for JDK 9 that would mean that an application running on JDK 9 wouldn't be able to talk to other applications running on JDK 8, 7, ... via JMX RMI connector.
11-03-2015
Currently, to maintain compatibility we need to keep the generated stubs around (so we can connect to the older versions) but don't use them when exporting the remote objects and use dynamic proxies instead. I came across the "java.rmi.server.ignoreStubClasses" property which, when set to true, will force using dynamic stubs even though the statically generated ones are available. This is something which could actually make it possible to phase out the statically generated stubs gradually. Eg. in JDK9 we'd still keep generating the stubs via rmic but wouldn't actually use them when exporting remote objects. The generated stubs would be used to communicate with the pre-jdk9 JMX agents. Simultaneously, the stubs will be marked as deprecated in JavaDoc. The problem is that the property is set to 'false' by default and needs to be set from command line.
11-03-2015
Those particular stubs *do* end up in the API docs. http://docs.oracle.com/javase/8/docs/api/javax/management/remote/rmi/RMIConnectionImpl_Stub.html http://docs.oracle.com/javase/8/docs/api/javax/management/remote/rmi/RMIServerImpl_Stub.html But yes, removing them is desirable to consider.
14-10-2014
Note that removal of RMI-JRMP static stubs requires an API change. There are currently a couple static stubs that appear in the Java SE API in the javax.management.remote.rmi package: RMIConnectionImpl_Stub RMIServerImpl_Stub There may be additional private static stubs, but of course removing these doesn't involve any API changes. This is a potential protocol change for JMX, though. RMI-JRMP dynamic stubs are not necessarily compatible with static stubs. There may be interoperability problems with mixing JDKs that support JMX static stubs vs dynamic-only stubs on the network. The compatibility implications needs to be assessed.
14-10-2014