Changing Java programs

Abstract

The promises of object-orientation and distributed computing could be delivered if the software we needed were written in stone. But it isn't, it changes. The challenge of distributed object-oriented maintenance is to find a means of evolving software, which already has a distributed client base.Working within this scenario, we observe how certain object-oriented language systems seek to support differing client requirements and service obligations. In particular, we examine how the Java Language Specification (JLS) facilitates the concept of binary compatibility, a useful property, but one that may introduce a class of clients who dare not re-compile! Following a suggestion in the new draft JLS, we describe our tool to manage distributed version control and we formulate some proposals for future developments.

Keeping Control of Reusable Components

“…Thus [5] identifies twelve types of maintenance activity, differentiated in terms of the purpose of the change -for example adaptive, preventative or corrective maintenance. By contrast [13] and [27] examine software source modifications from the point of view of when and how they propagate to the client module. Focussing exclusively on runtime changes, [16] have derived a very useful classification that distinguishes between the technical and motivational aspects of maintenance.…”

Evolution of Distributed Java Programs

“…Every individual modification that led to the existence of the new version must have been such as to maintain binary compatibility and so is a binary compatible modification. Binary compatible modifications have been the subject of some study [10,11,7,8]. The way binary compatibility works is that at compile-time the compiler embeds symbolic references (not binary code!)…”

Safe upgrading without restarting

“…We went on to model dynamic linking in [20] and we looked at the nature of dynamic linking in Java [5]. We have looked at the problems that arise with binary compatible code in [7] and built a less powerful tool, described in [6]. Other formal work on distributed versioning has been done by Sewell in [22], but this work does not consider the issue of binary compatibility.…”

“…Earlier versions of this tool [6,7] were concerned with the time taken to download files and the loading of classes (since it was done over a network). DJVCS makes use of a standard Internet protocol (HTTP) for file transfer hence performance issues of this aspect are beyond its control but it means that download speeds are as fast as any other you will experience on your connection.…”

“…As binary compatibility was conceived to assist with the development of distributed libraries [7,6], we examined its effect on evolving libraries. We went on to model dynamic linking in [20] and we looked at the nature of dynamic linking in Java [5].…”