Quibble about James Waldo's book Java: The Good Parts.

[Pat Farrell]

There was a contest here on the 'ranch for questions to James Waldo about his book Java: The Good Parts. I won a copy, and just finished reading it. Its a good book. I enjoyed it and recommend it.

But. One of his list of "good parts" strikes me as bizarre, and I'd like to solicit some wisdom from the 'ranch folks about it.

Jim's list of "good parts" include:

type system

exceptions

packages

garbage collection

the JVM

javadoc

collections

RMI

concurrency

the development ecosystem

I've written many times that I think that the Java concurrency support, even with the new libraries, is simply too complex for most programers. I would not put it in my list of good parts.

But the real one that does not belong on my list of good parts is RMI. Jim writes that he has spent many years writing distributed Java systems. He has many examples in his book. I just don't see it.

I see zero value in RMI. The whole "invoke a method on a remote object" world baffles me. I worked long and hard on it in the 80s and early to mid-90s, and it flat out never was worth the engineering time. The names change, but its the same idea. And I still don't see it delivering any benefit.

Nearly every modern web application uses AJAX or similar technology. Its cool. Its expected. But its not remote object method execution, its about passing normal text back and forth using HTTP.

Why would anyone use RMI?

[Rob Spoor]

Because it makes the networking mechanism transparent. The client uses an interface to call methods on as if the implementation is a local class.

However, I don't think it's a technique that goes well with web applications. As you said, there are different techniques (mostly AJAX) for that. I'd use RMI more in a more classic client-server architecture, where RMI is then used instead of direct socket access to communicate between the two.

[Pat Farrell]

Rob Spoor wrote:I'd use RMI more in a more classic client-server architecture, where RMI is then used instead of direct socket access to communicate between the two.

Do you do this for things like remote clients talking to the server?

When I tried RMI for that, I could never get the RMI port connection through the firewalls of corporations. I gave up and just use HTTP, which is always open.

I'm not buying the making networking transparent argument. You still have to handle when the connection is broken, you have to be aware of version skew between client and server. Sure, the client can call the methods as if they were local, but that is often poor engineering. I've seen too many times where folks use RMI or CORBA or equivalents and make thousands of calls across the network because it looks transparent. The performance implications are staggering.

[Rob Spoor]

Pat Farrell wrote:Do you do this for things like remote clients talking to the server?

Sometimes, yes. I'm building an application at the moment which does exactly that.

When I tried RMI for that, I could never get the RMI port connection through the firewalls of corporations. I gave up and just use HTTP, which is always open.

That's more a limitation of the company security policy. If you can show that your application is secure enough, with the right support (from your manager) you should be able to make the network admins open up the necessary ports.

You still have to handle when the connection is broken,

Which you do by handling the RemoteException that's thrown. How's that different from handling an IOException if an HTTP connection cannot be made?

you have to be aware of version skew between client and server.

If you're talking about the serializable version problem, you have that when you're serializing to / from files or through sockets (both using ObjectInputStream / ObjectOutputStream) as well. That's a limitation of the serialization process in general, something that can be prevented (among others by providing explicit serialVersionUID values). And if the data changes, then AJAX requests need to change as well, and both client and server need to be updated. I don't see how that's so much different from deploying a new class file on both the client and the server when you're using RMI.

Sure, the client can call the methods as if they were local, but that is often poor engineering.

How so?

I've seen too many times where folks use RMI or CORBA or equivalents and make thousands of calls across the network because it looks transparent. The performance implications are staggering.

But you can also make the same mistakes with HTTP requests. Both need good designing to keep the network traffic under control.


I'm not pro-RMI or anti-HTTP, I just believe that each tool can have its uses. In my latest case the server doesn't have an HTTP server, nor can one be installed for that purpose. That leaves me with fewer options, the two most obvious being RMI or using direct sockets. In that case I choose RMI, because I can't be bothered by implementing the remote method call myself. And in the end, the traffic would be similar: send data (the method arguments) to the server, receive the response (the method return value).

And FYI, the same project also involves communication with another server that does have an HTTP server installed. Yes, I'm making simple HTTP requests to that one. Also because one of the clients is not written in Java but *ugh* VBA... (and no, changing that is not possible). But the Java clients are also making the same HTTP requests. Why reinvent the wheel?

[Pat Farrell]

Rob Spoor wrote:

When I tried RMI for that, I could never get the RMI port connection through the firewalls of corporations. I gave up and just use HTTP, which is always open.

That's more a limitation of the company security policy.

Very true, but I've never had any luck at all convincing corporate IT folks that my little application is worth them even considering changing policy.

Rob Spoor wrote: Why reinvent the wheel?

I'd love use it, but I've never been able to get past the TCP/IP port issue.

And frankly, using AJAX or other message passing over HTTP is to popular that there are lots of libraries that let us use someone else's wheels.

Rob Spoor wrote: Both need good designing to keep the network traffic under control.

True. I believe, YMMV, that the idea of "just call the method" is more seductive to programmers to misuse.

[Paul Clapham]

Well, if this is a thread to discuss the merits and demerits of RMI, let me throw in my two cents. (USD 0.0197)

Where I work we have an RMI application. Its purpose is to communicate between our customer-facing web site (servlets and JSPs) and some back-end servers which interface with our back-end database.

This is internal to our network, so all of the networking issues don't exist. We don't have firewalls in the way, or if we did we would deal with them.

The funny part is, though, that we hardly use the "remote method invocation" part of RMI. Every single one of the web site's interactions with the RMI server sends an AbcRequest object to an AbcCommand object, which returns an AbcResponse object. (Where "Abc" is one member of a long list.) In other words it's really just a request-response protocol built on top of RMI. When we want another command, we just generate the three classes (DefCommand, DefRequest, DefResponse) and plug them into some boiler-plate code and we're done.

This was all written back in about 2000, when the term "web service" had hardly been invented, let alone snatched away and elaborated to the Nth degree by the large consulting companies. If we were doing it over again we would probably use a lightweight web service, probably passing JSON objects back and forth, rather than RMI. However if you're looking for somebody who is using RMI for remote method invocation, I don't think I would claim to be that person. And I'm sure that business cases for remote method invocation do exist, but our application isn't one of them.

[Pat Farrell]

Paul Clapham wrote:The funny part is, though, that we hardly use the "remote method invocation" part of RMI. Every single one of the web site's interactions with the RMI server sends an AbcRequest object to an AbcCommand object, which returns an AbcResponse object. (Where "Abc" is one member of a long list.) In other words it's really just a request-response protocol built on top of RMI. When we want another command, we just generate the three classes (DefCommand, DefRequest, DefResponse) and plug them into some boiler-plate code and we're done.

[snip]
If we were doing it over again we would probably use a lightweight web service, probably passing JSON objects back and forth, rather than RMI.

I agree completely. I'll claim that this thread is questioning whether RMI counts as one of the Good Parts (tm).

There are tons of JSON libraries, they are robust and well understood. @Paul's example was really just message passing, so why not just call a spade a spade and design it as message passing.

I know that the Ranch has a whole forum section on RMI, and I'm boggled that anyone uses it anymore. Perhaps its still used in some "certification" tests?

[Rob Spoor]

I agree that calling RMI one of the good parts is a bit too much. It's nice to have, but certainly not one of the reasons to start using Java. Whenever an HTTP server is available I use that as well, with some request-response technique.