RMI Plug-in for Eclipse
The RMI builder begins by scanning your project for all remote classes and then invokes JDK's RMI compiler (rmic) on these classes (the RMI compiler is part of your Java SDK). Depending on your project's settings, the compiler is invoked either inside the Eclipse VM or in a separate process (using the command line "rmic" tool). If the RMI compilation fails, the RMI Plug-in for Eclipse tries to parse the error messages and create the most appropriate "error" entries in the "Problems" view. The complete error messages are always stored in the ".log" file which is located in the ".metadata" subdirectory of your workspace.
The RMI Plug-in for Eclipse supports Sun's JDK RMI compiler on all platforms. IBM J9 (that comes with RAD6.0) is supported on Windows only. Weblogic's RMI is currently not supported.
A remote class is any class that directly implements a remote
interface; and a remote interface is any interface that extends
RMI Project properties
It is possible to change the flags used for the RMI compilation. These flags can be changed in the project's "RMI Compiler Properties" properties page. In order to open this page, right click a project that has stubs generation enabled, and select "Properties" from the context menu. All the properties are described below.
There are two versions of the RMI
protocol. Without going into further details the main difference
from the developer's perspective is that v1.1 protocol requires
both stub files and skeletons, while v1.2 protocol only requires
stub files. The version numbers are the version numbers of the
corresponding Java releases - JDK 1.1 (released in 1997) and JDK
1.2 (released in 1998). So both protocols are quite old and v1.2
protocol is used in most applications today. Unless you're
working with a very old code base you should stay with the (now)
Invoke the compiler inside Eclipse VM
This option, which is on by default, instructs the RMI Plug-in for Eclipse
to load the RMI compiler (rmic) code into the Eclipse VM and invoke it internally. When the
option is unchecked, the RMI Plug-in will locate the command line version of the RMI compiler
and invoke it in a separate process. Obviously invoking the compilation inside the Eclipse VM
is much faster. However, internal invocation may not work in all cases. In particular,
if project's JDK version is not the same as the Eclipse JDK version, internal compilation is
likely to fail. The RMI Plug-in for Eclipse tries to detect the cases in which internal compilation
is going to fail and automatically switches to external compilation (regardless of this option).
Non-standard "tools.jar" location
This setting is only available if the "Invoke compiler inside Eclipse VM" option is checked and is usually not needed on MacOSX installations.
The RMI compiler that comes with a JDK installation is implemented as a set of classes in the tools.jar file. Usually this file is located in the lib/ subdirectory of the JDK installation. Sometimes, when Eclipse did not properly configure the JDK locations, the RMI Plug-in for Eclipse might not find the tools.jar file in the location where it is expected to be found. In such case, you should first try to configure the JDK locations in Eclipse. If for some reason it does not help, you can manually specify the location of the tools.jar file using this setting. It is best to use a tools.jar file that belongs to a JDK version at least the same as the project's JDK. If you still expericece problems, please read about troubleshooting.
Few technical notes: When the Eclipse VM internally loads the RMI compiler it expects to recognize the .class file format of the RMI compiler classes (the class file file version). So if the Eclipse VM is a JDK 1.4 (understands class file versions up to 48.0) and the compiler belongs to JDK 1.5 (class file version is 49.0), Eclipse may fail to load the compiler classes. In such case, you should use JDK 1.5 to run Eclipse [1.4 is too old anyway] (read more about using the -vm switch). On the other hand if your project is developed using JDK 1.4 and the Eclipse VM is JDK 1.5, the RMI compiler code (which expects 1.4 classes, up to class version 48.0) won't be able to run since it can't process the other classe that are already loaded in the Eclipse VM (JDK 1.5 classes have class file version 49.0). The solution for such situation is to use a tools.jar file from a JDK 1.5 installation. It works well with the Eclipse VM and the produced classes are still compatible with your code. Another solution to all tools.jar problems is of course using external compilation.
The following table summarizes the working Eclipse VM/Project's JDK configurations:
Detect hierarchy changes of remote classes
The RMI Plug-in for Eclipse tries to minimize the number of times stub files are generated. In some situations it is possible that stubs generation won't be run when the class hierarchy of the remote class changes. This options, when checked, instructs the RMI Plug-in for Eclipse to look for possible hierarchy changes of the remote classes. Note: turning this option on may hurt performance on projects with lots of remote classes (and therefore the default is off).
Stubs and Java 5.0
RMI-IIOP and Corba support
The RMI Plug-in for Eclipse does not support these two protocols. Corba has been very popular in the late 1990's but its popularity has dropped since then, and new technologies such as web services took over. Only few new projects use Corba today. A very illuminating article by Michi Henning has been published in the "ACM Queue" in June 2006. Get the link and discuss the article here. There isn't much demand for RMI-IIOP either, but if you need such support feel free to contact us for possible solutions.