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:
- 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. - Remote methods need to declare
java.rmi.RemoteException
in theirthrows
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. - 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.
- Cast the proxy to
- 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.
This is some complicated code
This is some complicated code that I never would have been able to figure out myself. Thanks for this.
Thanks for sharing! Check out
Thanks for sharing! Check out Marysville WA's best painters
Agree! Mrs. Hanes -
Agree!
Mrs. Hanes - https://www.colourinyourlife.com.au/members/bathroommakeover/profile/
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.
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.
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.
I like how the author
I like how the author discusses and expresses his opinion on Java RMI. Also, thankful here that the author shared how he uses it. Anyway, if you need the best home insulation service in Phoenix, I recommend you check this: https://www.insulationinstallphoenix.com/
This may possibly be quite
This may possibly be quite helpful for some within your work opportunities I plan to never only with my web site
This is one of the first
This is one of the first times where I've had someone say exactly what I'm feeling. Thank you!
It's truly very complex in
It's truly very complex in this busy life to listen news on TV,
therefore I simply use the web for that purpose, and take the hottest news.
I understand the feeling.
I understand the feeling. That's what I felt too. By the way, if you want the best tile and grout cleaning service in Glendale, try https://www.tileandgroutcleaningprosglendale.com/ today.
Thanks for the very useful
Thanks for the very useful facts!
Thankful To You For Sharing
Thankful To You For Sharing Amazing And Unique Content On Your Web Blog. Please also check our website at
Thanks for this, keep on
Thanks for this, keep on posting.
I'm amazed at the content of
I'm amazed at the content of your article, very informative.
Interesting article you
Interesting article you posted here.
I agree with your statement.
I agree with your statement. In fact, I learned something new today.
Thanks for sharing nice
Thanks for sharing nice content.
Rasomojo stalo kedes dirbant
Rasomojo stalo kedes dirbant labia padeda susikaupti. Noredami patogiai dirbti ar zaisti su kompiuteriu, naudokite rasomojo stalo kedes.
Thanks for sharing good
Thanks for sharing good ideas. Keep on sharing!
Such an interesting post.
Such an interesting post. I've learned quite a few from reading this. Thanks!
Looking forward to more great
Looking forward to more great post from here.
Thanks for sharing your
Thanks for sharing your insights about JAVA, useful info.
Thank you very much for
Thank you very much for sharing this one.
Great! You explained it very
Great! You explained it very well, Thanks for the detailed information.
Yes yes, I think what you're
Yes yes, I think what you're doing is still absolutely brilliant! Keep up the good job.
Thanks for posting this one.
Thanks for posting this one. So informative.
Good reasons you have for not
Good reasons you have for not liking Java RMI and wise one for finding a way to use it anyway.Very wise indeed,Thanks for sharing.
THis is really great and I
THis is really great and I like to know more about RMI! Thanks!
Thanks for the explanation
Thanks for the explanation and sharing your ideas.
Great for the very clear
Great for the very clear explanation and tips. I really appreciate your work. Thank you.
https://www.paintingsantarosa.com/
Thankful To You For Sharing
Thankful To You For Sharing Amazing And Unique Content On Your Web Blog. Please also check our website at
It is really wonderful that I
It is really wonderful that I get to know some good information! Thanks for sharing!
Thank you for sharing! I
Thank you for sharing! I would never of known this if I did not stumble across this post!
I was in a situation that I
I was in a situation that I hate seeing this code until I realized that there are only a few people who can do this and I am one of them. It's not easy at first, but you can get the hang of it over time.