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.

Attachments: 

Nice information you shared.

Nice information you shared.

Very informative as well

Very informative as well

Exciting post! Great share

Exciting post! Great share indeed.

Awesome post! Glad to check

Awesome post! Glad to check this informative site.

I go to see each day a few

I go to see each day a few sites and sites to read articles,
except this website offers feature based articles.

Thank you for taking the time

Thank you for taking the time to share this post here.

The examples you used were

The examples you used were really effective.

Thank you for the great

Thank you for the great content you shared.

It's a great site to visit.

It's a great site to visit.

Awesome stuff indeed. Keep it

Awesome stuff indeed. Keep it up!

Nice post! Looking forward to

Nice post! Looking forward to seeing more incredible content from this site.

It's worth the visit for this

It's worth the visit for this informative article.

Great post! I totally agree

Great post! I totally agree with your point.

I found this post very

I found this post very helpful.

Thank you for the great

Thank you for the great information you shared.

Great post! I totally agree

Great post! I totally agree with your point on this topic.

Glad to visit this

Glad to visit this informative content here.

Not everyone knows all

Not everyone knows all information about a celebrity and their net worth which changes every day according to their fame and investment but you can follow the info on https://www.idolnetworth.net/ which is available for everyone.

really helpful thanks

really helpful thanks

I actually save this website,

I actually save this website, I love the free stuff provided here... Thanks a lot! Just in time! This resource is what I am needing right now. Thank you for sharing.

it is a great piece of

it is a great piece of information thank you

If you are interested in your

If you are interested in your favorite actors' heights and detailed information, please take a look at https://www.celebheightwiki.com/ database.

Java RMI can be a source of

Java RMI can be a source of frustration due to its complexities, but its functionality is undeniable. Despite its flaws, I've found creative ways to leverage its power in my projects. However, mastering it requires patience and perseverance. By incorporating it strategically, like implementing remote method invocations for distributed systems, we can unlock its potential. Check out how I tackled this challenge at https://pressurecleaningmaryborough.com.au/roof-cleaning/.

I completely understand the

I completely understand the frustration with the intricacies of Java RMI. It's great that it's readily available in the J2SE runtime environment, but the requirements for interfaces, RemoteException, and explicit exporting can be cumbersome. Your approach of automating the generation of remote interfaces and providing a proxy factory to handle the transportation layer sounds like a clever way to address these issues. It simplifies the development process while keeping the local and remote aspects transparent. It's always exciting to see innovative solutions to improve existing technologies.

This is some complicated code

This is some complicated code that I never would have been able to figure out myself. Thanks for this.

Same here. I even need Chat

Same here. I even need Chat GPT to explain to me what this is.

Thanks for sharing! Check out

Thanks for sharing! Check out Marysville WA's best painters

Agree! Mrs. Hanes -

Fantastic! Thank you, I've

Fantastic! Thank you, I've recently been looking for information about this topic https://www.drywallcoquitlambc.com/

The article is well-written

The article is well-written and clear in its criticism of RMIRex, and it provides valuable insights for anyone considering using this technology. I believe that this article would be useful for anyone interested in the topic of RMI over HTTP and its drawbacks. Overall, I think the article is a well-written and informative critique of a technology that is often overlooked in the realm of Distributed Computing. I appreciate the author's clear and concise critique of the technology and I think it's a valuable article for anyone interested in the topic.

Wow, this is so great! Thanks

Wow, this is so great! Thanks

The net worth of a person

The net worth of a person expresses how rich and popular they are, let's see who is the #1 at the present in https://www.celebnetworthpost.com

Fantastic! I think You put a

Fantastic! I think You put a lot of effort to create this article. I appreciate your work.

Wow that was unusual. I just

Wow that was unusual. I just wrote an really long comment but after I clicked submit my comment didn't appear.
Grrrr... well I'm not writing all that over again.
Regardless, just wanted to say wonderful blog!

The blog post offers a valid

The blog post offers a valid perspective on the challenges and limitations of RMI, and provides useful insights for developers who are evaluating different options for distributed systems. However, it's worth noting that RMI has been used successfully in many applications and remains a viable option for some use cases. As with any technology, it's important to carefully evaluate the pros and cons before making a decision on whether or not to use it.

RMI is a software component

RMI is a software component and a Java technology. It does link together various components of programs (and processes). Java is geared around objects. Therefore, it is unquestionably possible to integrate all of these definitions and claim that RMI is an object-oriented middleware.

I wonder how a lot attempts

I wonder how a lot attempts you set to make this kind of excellent informative site.

try and try until you

try and try until you succeed. this should not stop you from achieving your goals.

When an object is sent from

When an object is sent from one Java virtual machine to another Java virtual machine, RMI considers it differently from a non-remote object. RMI sends a remote stub for a remote object rather than copying the implementation object into the receiving Java virtual machine.

I don't like RMI too.

I don't like RMI too.

Thanks for sharing this great

Thanks for sharing this great article here.

Thanks for sharing the

Thanks for sharing the article. I had a great time reading this, the article was informative and useful.

There are several reasons why

There are several reasons why I don't like Java RMI. First, it is very difficult to use. The documentation is terrible, and the code is often needlessly complex. Second, it is very slow. Third, it is not very reliable. Fourth, it does not scale well. Finally, it is not very secure. Anyway, if you'd like the best air duct cleaning in Mesa, contact https://www.airanddryerventcleaningmesa.com to provide exceptional service.

همچنین اگر می خواهید از ماشین

همچنین اگر می خواهید از ماشین لباسشویی استفاده کنید سعی کنید آن ها را
از لباس های دیگر جدا کنید و به با دور
کند بشورید.

یکی از بهترین مراکز خریدی
که می‌توان برای خرید انواع لباس،
هودی و سویشرت در بازارهای آن قدم زد و لذت برد، هودی فروشی در
رشت است. فروشگاه اینترنتی پارچی
به عنوان یکی از مراکز اصلی هودی، این امکان را برایتان بوجود آورده که لباس موردنظرتان را پس از پرداخت در محل تحویل بگیرید.

Thanks for sharing your

Thanks for sharing your experience. Keep on posting.

You could certainly see your

You could certainly see your enthusiasm in the article
you write. The world hopes for even more passionate writers such as you who are not
afraid to say how they believe. At all times follow your heart.

The idea of automating the

The idea of automating the separation of the transportation layer from interfaces is proposed, potentially simplifying RMI development. The example provided demonstrates this concept. While it acknowledges some limitations, it encourages discussion on improving RMI in Java. Overall, it offers a promising direction for development in this area.

Thanks for sharing here an

Thanks for sharing here an informative article.

It's great to see this great

It's great to see this great article here.

I appreciate how the author

I appreciate how the author explores and presents his thoughts on Java RMI. I'm also grateful that the author explained how he utilizes it.