A client hosting a distributed object

Consider the following definitions: This example has a server that hosts a "Barney" instance of the PersonTalk distributed object class (line 41), and, a client that binds to the remote "Barney" instance (line 58) and hosts a local "Fred" instance (line 59). Once they each hold a "reference" to the other object (to be discussed next), either instance can be told to talk() (lines 60 and 61) and the other instance is subsequently sent the message listen() (line 29). The order in which the output occurs in the two different windows is lines: 46, 47, 64, 65, 48, 49, 66.

Let's see how each instance comes to hold a reference to the other. Line 41 causes the 1-argument constructor at line 15 to be invoked. Line 58 returns a remote reference to the "Barney" instance. Line 59 causes the 2-argument constructor at line 19 to be invoked. "Fred" can now message "Barney" with the remote reference that it holds (lines 21 and 25). "Fred" sends the meet() message to "Barney", passing its "identity" as an argument. "Barney" can now message "Fred" with the remote reference that it holds (lines 22 and 25).

The previous example only introduced the topic of "security managers" (step 5). Java insists that a security manager be in place to oversee the segment of its security architecture associated with dynamic class loading. Applets are automatically configured with a security manager to make sure that the applet code does not do any harm. But, applications do not have a default security manager, so one must be explicitly created when RMI is in use (see lines 39 and 55).