RMI and the Runnable Interface

[Ferghal Smyth]

Hi everyone,

This is my first time using the site and I was hoping to get some help with a problem I've been having with my project.

I recently added a method to the interface of a remote object I pass back from my server in RMI.
When I tried to call the method I got this error.

java.lang.AbstractMethodError: gameTable.TexasTable_Stub.getPlayerStack(Ljava/lang/String;)F

Obviously I didn't run the stub generation command after adding the method.
So I went to my folder where the class files reside and typed the command rmic packagename.classname.
When I run this command I get back the following error.

java.lang.Runnable is not a valid remote interface: method void run() must throw java.rmi.RemoteException.

I understand that each method to be called over RMI needs to throw RemoteException but how is this achieved with the run() method.
I don't think I can define any more Exceptions than are defined in the interface.

I'm not sure about how to use tags for displaying code or if its required.
Any help would be much appreciated.
Also maybe this can't be done so any suggestions as to a work around would be very helpful.

Regards,

Ferghal


****

Sorry I think I posted this in the wrong forum.

[Rob Spoor]

Runnable is not eligible for RMI. If you're using Java 5.0 or up you could replace it with Callable<V>. That one has a call method similar to Runnable's run method, with two major differences:
1) it can return a value; you can use Callable<Void> to skip this
2) it can return Exception or any of its subclasses. That includes RemoteException

[Henry Wong]

I don't understand why is the Runnable (or even the Callable) interface been used for the RMI Service? If you are going to create an interface for your RMI service, shouldn't you just create the interface? Instead of reusing one of the core Java interfaces, that were never intended to be remote interfaces?

Henry

[Ferghal Smyth]

I'm using it to create multiple tables in my Poker game.
Each table runs on its own thread.
The reason for the runnable because thread is too costly to extend. I need to extend another class.
The tables are remote objects which I try to create stubs of so the clients make calls on the tables directly.
I'm not sure if this is the best way to go about doing this.

[Henry Wong]

The reason for the runnable because thread is too costly to extend. I need to extend another class.

My question was *not* why your class are implementing the runnable interface. My question was why your IMPL class was implementing the runnable interface. This class is used by the rmi compiler to generate the public stubs -- so unless you want to expose the runnable method to your clients, you should not be implementing it there.

Henry

[Ferghal Smyth]

The reason was that the concrete class is the one I wanted to create in its own thread but I also wanted the client to be able to call the other methods in the concrete class. I wanted to be able to run multiple tables on the server and have the client interact with a choosen table directly.

Ferghal

[Henry Wong]

The reason was that the concrete class is the one I wanted to create in its own thread ....

That's perfectly okay, but why must it use itself as the runnable object -- why can't you use a different object as a runnable object?

To be blunt, I am missing the point of your argument -- do you actually want the run() method exposed to the clients?

Henry

[Ferghal Smyth]

I think want you are saying is that I should be communicating through the server object to my tables and not directly with the Table object itself because that contains the inherited run() method.

What I am looking for is a way to return a remote object to the client for them to interact with directly. Is this possible or is the only way to communicate with threads running on one JVM is through the remote object retrieved from the registry.
Am i approaching my problem the wrong way? Can you suggest any material to read? I think I may need to do some background research to my problem. I'm sorry if I'm not explaining my problem very well.

Ferghal

[Henry Wong]

I think want you are saying is that I should be communicating through the server object to my tables and not directly with the Table object itself because that contains the inherited run() method.

No... I am not saying that at all. I am merely saying why it doesn't work -- and that you have to fix it. You have a few options.... You can change your Table object so that it doesn't have those unwanted interfaces. Or you can create a new Table object (a wrapper table object -- that your client sees), that only has the RMI interfaces, and calls your original table object, which has the unwanted interfaces.

Henry

[Ferghal Smyth]

Hi Henry,

Is the wrapper class like a layer of indirection for calls on my Table object?
If so I think I'll give that a try. Thanks for the help.

Ferghal