RMI Stub generation

Hey everyone,

I know this is an annoying and recurring topic, but as a matter of fact I already invested alot of time to find out why the stub generation is not done. Nothing worked so I will explain my application and environment in detail:

1. Application

The program takes a text file and filters foreign words through two dictionaries. It is a distributed application, in order to balance work load of text fragment analysing on different machines. Thus the application is split into two parts: The main program initializing the workers and the Worker/Filter itself.

2. Structure

The structure is simple in packages: de.fu.alp5.foreign.distributed with the following files:

MainAnalyzer.java (Main application)
MainWorker.java (Main application for worker)
TextAnalyzer.java (Interface (!) which extends Remote)
TextAnalyzerImpl.java
TextAnalyzerWorker.java (Interface (!) which extends Remote)
TextAnalyzerWorkerImpl.java

3. Development Environment

On my Windows machine the source code is located at: C:\de\fu\alp5\foreign\distributed

My javac Version is 1.6.0_22, as is my java versio:

java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)

Thus dynamic stub generation through proxy substitude should be given as mentioned in the Java 5 Release Notes to RMI. In fact, this happens anyway:

(1) I start rmiregistry inside the classpath C:\

(2) I compile my code:

C:\> javac de\fu\alp5\foreign\distributed\MainAnalyzer.java

C:\> javac de\fu\alp5\foreign\distributed\MainWorker.java

(3) I execute my code:

C:\>java de.fu.alp5.foreign.distributed.MainWorker
Usage: java -jar ForeignWorker.jar <text file>

Okay, I forgot the text file, no problem:

C:\>java de.fu.alp5.foreign.distributed.MainWorker denglish.txt

And I get the well known Exception:

Exception in thread "main" java.rmi.StubNotFoundException: Stub class not found: de.fu.alp5.foreign.distributed.TextAnalyzerWorkerImpl_Stub; nested exception is:
        java.lang.ClassNotFoundException: de.fu.alp5.foreign.distributed.TextAnalyzerWorkerImpl_Stub
        at sun.rmi.server.Util.createStub(Unknown Source)
        at sun.rmi.server.Util.createProxy(Unknown Source)
        at sun.rmi.server.UnicastServerRef.exportObject(Unknown Source)
        at java.rmi.server.UnicastRemoteObject.exportObject(Unknown Source)
        at java.rmi.server.UnicastRemoteObject.exportObject(Unknown Source)
        at de.fu.alp5.foreign.distributed.TextAnalyzerWorkerImpl.<init>(TextAnalyzerWorkerImpl.java:49)
        at de.fu.alp5.foreign.distributed.MainWorker.main(MainWorker.java:19)
Caused by: java.lang.ClassNotFoundException: de.fu.alp5.foreign.distributed.TextAnalyzerWorkerImpl_Stub
        at java.net.URLClassLoader$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
        at java.lang.ClassLoader.loadClass(Unknown Source)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Unknown Source)
        ... 7 more

4. Actions to be taken

When I compile the stubs manually with rmic the application works well. But this is not Java 4 or older, I want to get it running by mondern methods. So what did I do wrong?

(1) Is it the code? I have attached the source code to section 2. It is not much.

(2) I know there is the option -Djava.rmi.server.codebase. I didn't worked, too. Though I wouldn't know what path to give any way, because the needed Interfaces are already in the classpath.

---

So where is the problem? I don't get it, but I really want it to get running the normal way. I also tried unter Ubuntu, same results.

The question was answered by a member of the Oracle Java Forum. Here is the solution sweated workers who roam on Google:

The problem is the call to export:

With no given port, an anonymous port will be chosen. The export is not designed to get the stub code via rmiregistry. The stub code has to be provided in a separate way. What I actually wanted was this:

0 means the standard port 1099 will be chosen. Works now like a charm