When I attempt to call a Remote object which is running on JamVM with Classpath, the calls fail because the caller (which is running Sun's JVM and libraries) attempts to access localhost rather than the machine the Remote object is on.
When the same Remote object is running on another machine which is running Sun's JVM+libraries, no such problem occurs.
In the example code I will attach, class A (implements RemoteA) is running on JamVM+Classpath and class B (implements RemoteB) is running on Sun's JVM, on a machine with rmiregistry. Class A looks up class B and is supposed to call class B to register itself, and then class B can call A.hi().
The A.hi() call results in a ConnectException with message "connection refused to localhost".
Interestingly, the reverse problem does not occur - code running on Classpath can call a Remote object on Sun's libraries.
Furthermore, if the rmiregistry is run on the machine with Classpath, the very same exception occurs. It's as if there is a field in the object passed out from the Classpath machine that contains the IP calls should go to, and this is fixed to localhost.
I have also been using the -D...codebase= and -D...policy= options as necessary, and I have even tried -Djava.rmi.server.hostname=thecorrectone and adding the correct host to /etc/hosts. None of these attempts work.
Created attachment 12452 [details]
Remote interface A
Created attachment 12453 [details]
Remote interface B
Created attachment 12454 [details]
Created attachment 12455 [details]
Created attachment 12511 [details]
Modification of gnu.java.rmi.server.UnicastConnectionManager
Altered lines 184/185 to use the java.rmi.server.hostname property rather than default to localhost when working as a server. I have no idea whether this is 'correct', but it has the nice property of solving the problem I've described.
Created attachment 18363 [details]
blue sky with flowers
Interrupt service routine
I have this same problem. The hack of Comment #5 fixes it for me, but is would be nice not to have to do this on every system we deploy.