Why I don't like Java RMI and how I use it anyways

The Java Remote Method Invocation API is a great thing to have because it is available in almost every J2SE runtime environment without adding further dependencies. However there are some implications when using RMI and I just cannot get my head around them:

  1. Interfaces used as remote interfaces need to extend java.rmi.Remote. Interfaces should be clean and not contain any clutter introduced by a certain technology. This is even more true with modern frameworks and things like dependency injection.
  2. Remote methods need to declare java.rmi.RemoteException in their throws clause. This is basically a continuation of the first point. This point holds, even if you ignore the rant about checked exceptions, which I don’t want to comment on right now.
  3. Remote objects need to be exported explicitly. Even though one explicitly declared which methods should be accessible from a remote site with the above two points, one still needs to explicitly export every single instance of an object implementing those methods.

Don’t get me wrong, all those implications have their right to exist because the decisions leading up to them were made for a reason. But in some circumstances those reasons don’t apply. It is just not the one-to-rule-them-all solution for remote method invocation in Java.

There are ways around those problems. One could for instance duplicate the existing interfaces to fit the needs of RMI. But frankly speaking, I just don’t want to do that myself.

That being said, lets see if the task of separating the transportation layer based on RMI from your precious interfaces can be automated in some way, so it doesn’t have to be done by hand. The following are the key points of the approach:

  • Interfaces can explicitly be marked as remote interfaces at runtime without the need for recompiling them. All methods exposed by such an interface can be invoked from a remote site. All parameters which are subclasses of such interfaces, will be passed by-reference and will not be serialized. This is just the same behavior as if the interface would extend java.rmi.Remote in the RMI world. The actual remote interfaces are generated on-demand at runtime.
  • Provide a proxy factory which supports the rapid development of a transportation layer based on RMI for given clean interfaces. The interface classes do not need to be cluttered with specifics of the transportation implementation.
  • A proxy in this context is a transparent object implementing both, the local and the generated remote interface. Both interfaces are usable:
    • Cast the proxy to java.rmi.Remote and use it with any naming or registry service available to the RMI world. Every proxy implicitly is a remote object without the need for explicitly exporting it.
    • Cast the proxy to your local interface and don’t bother whether it actually targets a local or a remote site.
  • The decision how an invocation actually is dispatched can be solely based on whether the target object of a proxy is a remote or a local one. This decision is hidden inside the transportation layer.

Available as a download attached to this post you’ll find a first reference implementation of such a proxy factory as described above. Note that it is just a sketch to illustrate my point and will probably contain major flaws. Also it brings a dependency on Javassist, which kind of contradicts the very first sentence of this post. However it is capable of distributing this tiny example across several sites without modifying the given interfaces, which also represents my only test-case:

public interface Client {
	public void callback(String message);
public interface Server {
	public void subscribe(Client subscriber);
	public void notify(String message);
public class ClientImpl implements Client {
	public void callback(String message) {
		// ... do some important job ...
public class ServerImpl implements Server {
	public void subscribe(Client subscriber) {
		// ... remember "subscriber" in some fancy data structure ...
	public void notify(String message) {
		// ... invoke all "subscribers" like they were local ...

This is my attempt to show how I personally think that RMI should have been designed in the first place. Please feel free to comment, improve, ignore or flame.


Been struggling with how I do

Been struggling with how I do the Java method. I already searched on youtube on how to do it but I can't get the process. Can someone help me?

You just have to grit your

You just have to grit your teeth and keep researching man. It's great that you're reaching out like this. If you keep it up your going to go far. This is what I learned from my Driveway Business.

And sometimes I think I kill

And sometimes I think I kill relationships for art https://guitarlessonsatlantaga.com

Great read. Thanks for

Great read. Thanks for sharing!

So great! Thanks for sharing

So great! Thanks for sharing a wonderful post.

I wish I could help you, I

I wish I could help you, I really do.

I already downloaded it.

I already downloaded it. Thank you for sharing these free resources.

I just want you to know

I also really appreciate free

I also really appreciate free and helpful resources.

I enjoy whɑt you guys агe ᥙp

I enjoy whɑt you guys агe ᥙp tߋo. Such clever work and exposure!
Kеep up the ᴠery good ѡorks guys І'ѵe afded yօu guys tto my blogroll.

So what am I defendin' now?

So what am I defendin' now? https://privateinvestigatorbatonrouge.com

Same here, I also added them.

Same here, I also added them. I will definitely be coming back to this again.

You don't need to pay for

You don't need to pay for getting such brilliant works! all you need is here.Thank you so much!


Really nice and interesting

Really nice and interesting post. I was looking for this kind of information and enjoyed reading this one.

Much thanks to you such a

Much thanks to you such a great amount for sharing this awesome blog. Very moving and accommodating too. Hope you keep on sharing a greater amount of your ideas. I will love to peruse.

Many thanks sharing this very

Many thanks sharing this very diverse opinion post where each expert has no doubt shared his best for knowledge on the topic.