Sponsored Link •
Bill Venners: What are the challenges of using mobile objects?
James Gosling: It's the standard fallacies of distributed programming. When people use mobile objects straight out of the gate, they think mobile objects are like any regular objects. But you have to absolutely take into account things like the performance is different. At least 2, probably 3 or 4 orders of magnitude slower. And that's not just a minor annoyance at that level. That deeply affects your architecture.
Bill Venners: You mean, if that object is doing something back on the network?
James Gosling: Yeah, so if you have an array or an object that represents and array. Pinging that thing for every element can be expensive. It might actually be cheaper just to make a local copy of the whole frigging thing in one transaction.
But also, there are issues like errors. If it's not a distributed object, not a remote object, people tend to -- and fairly legitimately can -- ignore all kinds of errors. And yet when it is a remote object, you have to pay attention to the fact that the network can go down. Things that are equivalent to that. The remote host can be hit by a meteorite. Or there are a vast number of things which are similar to being hit by a meteorite. Anybody who does programming in California these days...
Bill Venners: ...could be hit by a blackout.
James Gosling: I run Solaris on my desktop here and for the last 10 years, the #1 source of reliability problems has been the frigging power supply to the building. And when you are building a distributed system, talking to somebody else, there's this question of is he dead or is he slow? You can't tell the difference. Or did the network just go away and it will come back again? Or was it just glitch in the network? Did it just drop a few packets?
Bill Venners: That's what Jini really tries to address with leases and the fact that
you can put
RemoteException in your throws clause to say, "This method may do something the network,
therefore, it might be slower or it might fail." And that way I'll know because it will throw me back this
checked exception that I have to deal with.
James Gosling: Right. And that's really built into RMI.
Bill Venners: It's a philosophy of not trying to paper over the fact that there may be a network there.
James Gosling: Right, because if you try to paper it over, you're fundamentally kidding yourself. You just can't paper over either the performance issue or the error issue.