Java Do es not Distribute Gerald Brose KlausPeter Lohr Andre Spiegel fbroselohrspiegelginffub erlinde Technical Report B Octob er Abstract Java is commonly considered the ideal language for implementing software for the In ternet A closer lo ok however reveals that distributed programming is p o orly supp orted in Java This is b ecause the very design of the language rules out distributiontransparent remote invo cation It is shown that Suns technology for distributed Java programming RMI makes things worse by allowing two dierent invo cation semantics to hide b ehind an ob ject variable The consequences of using CORBA instead of RMI are inv estigated Various options for changing either RMI or Java itself are considered so that language platforms supp orting a high degree of distribution transparency could be built Freie Universitat Berlin Institut fur Informatik Takustrae D Berlin Germany This rep ort also app ears in Pro c TOOLS Pacic Melb ourne Australia November Intro duction Java Gosling is b eing heralded as the ultimate language for internetbased distributed programming But when it comes to actually writing distributed applications a serious aw in the basic design of the language b ecomes apparent Javas typ e system together with its mechanism of parameter passing leads to problems with remote metho d invo ca tion The current version of Java do es not allow for a distributed implementation where remote metho d invo cation would have the same semantics as its lo cal counterpart The problem is also not adequately addressed in RMI Sun Suns proprietary technology a programming As a result semantic deviations from the intended for distributed Jav program logic can o ccur in distributed programs written in JavaRMI It is therefore questionable whether Java in its current form is a suitable platform for distributed pro gramming The problem is explained in section which is followed by a discussion of RMI in section Section explores the combination of Java and CORBA OMG Our observations suggest that revising the language itself may b e the only satisfactory solution Several options for this are discussed in section and our preferred option is presented Remote parameters in Jav a Javas metho d invo cation mechanism is not suitable for distributed programming based on remote invo cation To show this we will rst sketch the syntax and semantics of purely lo cal invo cations fo cussing on parameter passing and then lo ok at the consequences of extending this invo cation semantics to the distributed case Java parameter passing An ordinary Java metho d is invoked using the familiar notation objectRefmethodNamearg arg n Java like C has only one parameter passing mo de passbyvalue For primitive types such as integer character etc this means that the metho d receives a copy of the actual value If an ychanges aremadetosuch a copy during the execution of the metho d these changes are not visible in the calling context If an actual parameter has a reference type a reference to an ob ject is copied causing the ob ject to be shared among caller and callee Any changes the metho d makes to the ob ject are visible in the calling context In Java all instances of classes have reference typ es including strings which are instances of the library class String and arrays for which no library class exists Java provides no parameter passing mo de that would er a copy of the ob ject as eg Eiel do es using dereference a parameter and deliv expanded typ es Meyer Wesay that Java passes ob jects by reference not byvalue It is imp ortant to note that since the only way of constructing userdened typ es is by writing new classes al l userdened typ es are reference typ es Thus there is no way of passing an ob ject of a userdened class by value Parameters in distributed programs In a distributed program ob ject invo cation may cross machine b oundaries If the caller and the callee reside on dierent machines invo cation must be implemented as remote method invocation which is the ob jectoriented analog to remote pro cedure call RPC Instead of passing the arguments in pro cessor registers or on the stack the caller must pack them into a network message and the callee must unpack them This is called marshalling or serialization and unmarshalling of the parameters A problem arises when references are involved in passing parameters remotely a reference is usually represented as a virtual address in the callers address space it makes no sense to dereference it in a dierent address space So the reference has to be passed in a networkwide representation which can in turn be used for remotely invoking the ob ject it refers to How do es this apply to Java The rst observation is that there is no obstacle to implementing remote invo cation for programmerdened classes Referencetyp e param eters can b e passed in a networkwide representation embedded references can b e taken care of in the same manner A closer view however reveals that the resulting programming platform is of little use Generally sp eaking it is alright to distribute services in this way ie passing references to ob jects that are invoked infrequently so that the increased latency of remote invo cations is negligible But what ab out distributing data ie passing arrays and records ob jects without metho ds If an array of say numb ers is passed to a remote metho d for pro cessing the receiver just gets the reference Pro cessing the arraymay then require remote accesses given the latency of each individual access this approach is plainly prohibitivenot to mention the problem of compiling array indexing into remote access The same problem is encountered with records where while not as drastic it is still annoying With strings fortunately the problem disapp ears Strings are immutable ob jects in Java so passing a string by reference can be implemented as pass byvalue b ecause the semantics is the same RMI Suns Remote Metho d Invo cation RMI system aims at providing mechanisms for seam less remote invo cation on ob jects in dierent virtual machines Sun and tries to inte grate the distributed ob ject mo del into the Java language in a natural way while retaining most of the Java languages ob ject semantics It turns out that the keyword is most tries RMI RMI do es preserve the regular Java invo cation syntax but parameters of remote op er ations are treated dierent from those of lo cal op erations Remote passing is done as follows If an actual parameter has a primitive typ e it is passed by value If an actual parameter has a reference typ e and its class implements the Remote interface it is passed by reference the lo cal reference b eing replaced with a network reference If the class do es not implement Remote but rather implements the Serializable interface the ob ject is passed by v alue using serialization If the class implements neither Remote nor Serializable an exception is raised Arrays are serializable by default While this seems to solve the main problem by not promoting arrays to full remote ob jects and allowing for records to be passed by value rather than by reference this approach has its own pitfalls Consider the following example Let RemoteStack denote a class for remotely invokable stacks of integers implementing Remote A stack stores its values in an array int cells In addition to the usual stack op erations such as push pop top it exp orts an op eration public int dump return cells delivering the values currently stored in the stack There are several stacks in our distributed system registered in a StackDictionary ob ject Our demonstration program plays with two stacks listed in the dictionary public class RMItest static RemoteStack s null static RemoteStack s null static StackDictionary stacks new StackDictionary public static void mainString args stacks are created at different sites and registered with dictionary s stacksgetthat s stacksgetthis spush spush int there sdump int here sdump there here Systemoutprintthere stop Systemoutprinthere stop but fails As dump delivers an array and arrays are Serializable by default the result of a remote invo cation will be a copy of the stacks array So the output of the program should b e there here but be also prepared to see there here Why is this It is p ossible that one of the stacks s in this case happ ens to be lo cal to the caller which causes the standard parameter passing semantics to take eect yes So a reference to the array will b e delivered causing the assignment here to eectively mo dify the stack The example shows that not only can two seemingly alike ob jects have dierent be haviour but worse there is no way to tell them apart This is b ecause it is imp ossible to or actually lo cal nd out whether an ob ject with a Remote interface is indeed remote to the caller If we inadvertently and not knowing use a Remote ob ject lo cally as in the example the op eration semantics may be dierent from what was exp ected Note that we are not referring to a dierent exceptional semantics in the face of network latency or failure but to the successful execution of an op eration Also note that there is indeed no way of telling remote from lo cal ob jects even if we knew that taking one for the other might cause problems both ob jects have the same typ e and wehav enoway of tracking down every single ob ject reference in a system RMI turns out to b e dangerously confusing it gives the programmer the false impression that although Remote and Serializable parameters are treated dierently at least