Java Reference
In-Depth Information
REMOTE CALL SEMANTICS
One of the things that often surprises people about calling remote objects in Java is a
subtle change in the semantics of the language. Java inherits a lot of its syntax and
behavior from C. This includes its behavior when calling methods that use a pass-by-
value mechanism for method parameters. This means that when you pass a value to a
method (say, an int ) the method gets a copy of the int , not the original. Therefore, if
you modify the int in your method, the int the caller had will remain unchanged.
This initially surprises many people, because they're used to the fact that if you pass an
object as a method parameter, then the method operates on the same object, not a
copy. There isn't a difference between objects and primitives passed as parameters,
but you do need to know that what you pass to a method isn't the object itself, it's a ref-
erence to the object, and that's passed as a copy. If object references weren't passed as
copies, then you would be able to re-assign your caller's object reference to some
other object. This would be confusing and open to abuse; what if someone were
allowed to replace the unmodifiable collection you gave them with a modifiable Hash-
Set without you knowing!
Even though it doesn't always feel like it, Java uses pass-by-value semantics for local
calls. You can, however, modify objects that are passed to you and expect those modifi-
cations to be visible to the person who called you. This is why you can write methods
like public void fillMap(Map<String,String> map) to add entries to a map passed
to a method. Remote Java calls are different. The local call in your Map filling method
relies on the fact that the method has access to the same Map in memory that the caller
has. If the method were running on a remote machine, then this wouldn't be the case.
In a remote call, all of the method parameters have to be serialized over the network
to the remote machine. This forces Java to copy not only the object reference, but the
whole object as well. If your Map filling method were running on a remote server, then
it would be operating on a copy of the Map , not the original reference, and you'd find
that any Map you tried to fill would remain completely unchanged on the client.
The fact that remote calls behave differently from local ones isn't necessarily a dis-
advantage, and in many cases doesn't matter at all; however, it's a significant change to
the normal flow of Java code. As such, you should be careful to ensure that any inter-
face you write that you might want to expose remotely doesn't rely on changing the
state of objects passed in.
RELIABILITY AND REMOTING
Performance isn't the only thing that suffers when you make remote calls. When you
make a local call, you can usually rely on an answer coming back. You can also rely on
the fact that the data you need to execute will be available and not corrupted. Unfor-
tunately, networks give you no such guarantee.
When you make a remote call, you usually need to wait for a reply indicating that
the remote process has completed, often with a return value. You might receive your
reply within a millisecond, or it might take several seconds, or even minutes. Crucially,
you might never receive a reply from the remote server if, say, the server went down
Search WWH ::




Custom Search