JDK-8058830 : Update rmic to work a modular image
  • Type: Sub-task
  • Component: core-libs
  • Sub-Component: java.rmi
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-09-19
  • Updated: 2016-01-06
  • Resolved: 2014-10-24
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.
JDK 9
9-repo-jigsawFixed
Related Reports
Relates :  
JDK-8064783 - Change rmic to use jrt:/ instead of jimagefs
Relates :  
JDK-8060488 - Drop RMI statically generated stubs from JMX Remote API
Description
rmic accesses the class files of classes on the boot class path. It uses the value of the sun.boot.class.path property and assumes the elements zip files or directories with class files. This doesn't work with a modular image where the classes are stored in jimage format. This code will need to be updated to work with modular image. One approach is to use the NIO "jimage" file system provider in the same way that javac uses it.
Comments
This is now resolved in jigsaw/m2.
24-10-2014
analysis of an mric -iiop invocation reveals that the initial problems lies in the way rmic navigates the classpath looking for a number of classfiles, such as Remote, Serializable, RemoteException etc, it will use during its code generation and compilation. as there is, now, no rt.jar, tools.jar, resources.jar etc, it fails to find the class files in its search of the classpath. It is not aware of the new structure :-( Is there a spec for the new image structure and a Util which will "find" a class file? (we can refer to URLClassLoader) Is there a spec for how the Classpath is now defined? In the early processing it appears to be using ad hoc classloading, later it will instantiate a ClassPathLoader
29-09-2014
The following tests in the jdk repo will fail until we put in a solution: sun/tools/java/CFCTest.java sun/rmi/rmic/RMIGenerator/RmicDefault.java sun/rmi/rmic/classFileVersion/run.sh sun/rmi/rmic/covariantReturns/run.sh sun/rmi/rmic/defaultStubVersion/run.sh sun/rmi/rmic/manifestClassPath/run.sh sun/rmi/rmic/minimizeWrapperInstances/run.sh sun/rmi/rmic/newrmic/equivalence/run.sh:
29-09-2014
as there is a whole lot of deprecation associated with this area, rmic became a WNF item. As such, it was deemed appropriate that no effort other than essential fixes should be expended on rmic. If deprecation is viewed as essentially meaningless, as there is no meaningful removal strategy associated with deprecation, then an update, modernization and alignment with current javac and new module structure, is probably the most sensible, but I'd imagine a sizable amount of work. Understanding the new module image structure and extending the rmic to cope with it, could provide a short term solution.
29-09-2014
The file system API (java.nio.file) can be used to access the classes in the jimage. This is what (new) javac is using. We will need to decide soon whether it's worth fixing the old javac or look at better options (like re-writting it to be based on javax.lang.model).
29-09-2014