Fighting Class Name Clashes in Java Component Systems

Transcription

1 Fighting Class Name Clashes in Java Component Systems Petr Hnětynka, Petr Tůma Charles University Department of Software Engineering Distributed System Research Group Malostranské náměstí 25, Prague 1, Czech Republic Abstract: This paper deals with class and interface name clashes in Java component systems that occur because of evolutionary changes during the lifecycle of a component application. We show that the standard facilities of the Java type system do not provide a satisfactory way to deal with the name clashes, and present a solution based on administering the names of classes and interfaces with a version identifier using a byte code manipulation tool. The solution is demonstrated on a proof of concept implementation. Keywords: Components, Java, versioning, classes, interfaces, name clashes. 1 Introduction The introduction of components into the software engineering process brings the benefits of easier reuse and dynamic integration. Being elements of reuse and integration, the components follow the typical lifecycle of applications [9] and are therefore subject to evolutionary changes that may change both their internals and their interfaces. Because of features such as platform independence, type safety, garbage collection, dynamic loading and others, both the component platforms and the components themselves are often developed in Java [8]. The components are typically sets of Java classes and interfaces, evolutionary changes to the internals and interfaces of components thus require changes of the corresponding Java classes and interfaces. Some evolutionary changes lead to a situation that requires different versions of a class or an interface to coexist in one application. This is difficult to do in Java, where two classes or interfaces with the same name cannot coexist unless loaded by unrelated classloaders. In this paper, we describe how to deal with such a situation without resorting to an elaborate naming scheme or an elaborate classloader hierarchy, which we show to be worse than our solution.

2 2 Petr Hnětynka, Petr Tůma In section 2, we detail the context in which the name clashes appear and explain why some of the apparently straightforward solutions such as naming schemes or classloader hierarchies do not work well. In section 3, we outline our approach to avoiding the name clashes and illustrate it on a proof of concept implementation. In section 4, we show how our approach differs from that of other Java component systems. Section 5 concludes the paper. 2 Java Component Systems 2.1 Components, Classes, Interfaces A software component is an independent unit in a sense that its interface, which includes both the offered services and the context dependencies, is specified explicitly. This facilitates an easy reuse of components without knowledge of their internals. In contemporary Java component systems [2,6,13,15], the offered services are represented by a set of interfaces that a component provides, and the context dependencies are represented by a set of interfaces that a component requires. Given the provided and required interfaces, a component is represented by a set of classes that implement the provided interfaces and call the required interfaces. Besides being implemented directly as a set of Java classes, a component can also be composed from other components. We term these components composed, as opposed to primitive. A composed component is created by connecting other components through their provided and required interfaces. The connections can be described in an architecture description language, which will then provide information necessary for generating parts of the composed component implementation such as component bindings and factories. The composition of components forms a hierarchical structure that can be represented as a tree or, in a component system that allows sharing of components, an acyclic graph. 2.2 Sources of Name Clashes By a name clash, we understand a situation where a class or an interface cannot be loaded by the Java virtual machine because its name is the same as a name of another class or interface that has already been loaded. The name clashes that are of interest to us are related to the evolutionary changes that can occur during the lifecycle of a component application, namely changes to classes that make up the component and changes to interfaces that make up the component. 1 The first source of name clashes is a situation where the classes that make up a component are replaced by a new version while the component application that uses 1 For sake of brevity, we omit the discussion of the likelihood that the situations described here as sources of name clashes will occur in practice. For readers that will not find the practicality of the situations evident, good arguments can be found in [1,9,11,14].

3 Fighting Class Name Clashes in Java Component Systems 3 the component is running. This can lead to a name clash between the old and the new version of the classes. As an example, consider a component with a class LoggerImpl that is to be updated. 2 An attempt to replace this class by a new version will cause a name clash because the Java virtual machine will refuse to load the new LoggerImpl class after the old one has been loaded. The second source of name clashes is a situation where the interfaces that make up the component are replaced by a new version but the component application that uses the component does not change and an adapter is used to bridge the mismatch. This can lead to a name clash inside the adapter, which needs to access both the old and the new version of the interfaces. As an example, consider a component with an interface Log that is to be updated. An attempt to create an adapter between the old and the new version will cause a name clash because both versions of the interface will use the same name. The third source of name clashes is a situation where a single Java virtual machine is used to run several component applications to avoid redundant loading of shared code. This can lead to a name clash when the component applications use different versions of the same component. 2.3 Straightforward Solutions Do Not Work Well Unique names: Probably the most straightforward solution that helps to avoid the name clashes is to use unique names for each version of the classes and interfaces that make up a component. The obvious disadvantage of this approach is the need to change the names with each new version of the class and the interface. This disadvantage is further aggravated when the change is not confined to the component itself, but also needs to be made in the component application that uses the component. The use of unique names also leads to using longer names with prefixes or suffixes, which inconveniences the programmer. Different classloaders: Another straightforward solution is to use different classloaders to load classes and interfaces of different components. Each classloader is associated with a namespace and can therefore load a class or an interface even when another class or interface with the same name was already loaded by a different classloader. Using a distinct classloader for each component will therefore avoid name clashes because the names of classes and interfaces that make up each component will belong to a different namespace. Unfortunately, this solution makes the Java virtual machine see the interfaces of different components as incompatible even when they have the same definition. This is a problem when the components are to be connected to each other, because it is impossible to connect the incompatible interfaces directly through Java references. Java reflection: One way to avoid the problem of connecting seemingly incompatible interfaces is to use the Java reflection API. The references used to connect the interfaces can be passed as of the java.lang.object type rather than their most 2 For more details on the components considered in the examples, see section 3.2.

4 4 Petr Hnětynka, Petr Tůma derived type, and the Java reflection API can be used to invoke methods on the interfaces. To invoke a method through the Java reflection API, an instance of the java.lang.reflect.method class must be obtained to represent the method, and all arguments of the method that are of primitive types must be stored in corresponding wrapper classes. Although the code to do this can be generated from the interface description and therefore be no burden to the programmer, it slows down the invocations considerably. Table 1 illustrates this by comparing the times of a direct method invocation with the times of a method invocation through the Java reflection API on a dual CPU 360MHz UltraSparc machine with Java 1.4. no arguments single String five int argument arguments Direct invocation 11.22µs 11.22µs 22.35µs Java reflection 872.4µs 803.3µs 1643µs Table 1. Times of method calls Hierarchy of classloaders: Another way to avoid the problem of connecting seemingly incompatible interfaces is to use a hierarchy of classloaders. A classloader has exactly one parent, which is set during its creation and cannot be changed. Typically, a classloader delegates requests to load a class or an interface to its parent and only if the parent cannot load the class or the interface, the classloader tries to load it by itself. Classloaders that share a parent therefore also share parts of their associated namespaces. In addition to using different classloaders to load classes and interfaces of different components, the classloaders can be set up so that whenever two components are to be connected to each other, the loading of their interfaces will be delegated to the same parent classloader. The resulting hierarchy of classloaders will mirror the hierarchy formed by the composition of components. This solution makes the Java virtual machine see the interfaces of components that are to be connected to each other as compatible, because they were loaded by the shared parent classloader. Unfortunately, even this solution fails when the interfaces that make up a component are replaced by a new version and an adapter is used to bridge the mismatch between the component and the component application that uses the component. The interfaces that make up the adapter necessarily belong to a single namespace and because the adapter needs to access both the old and the new version of the interfaces, a name clash will occur. Modified Java virtual machine: Albeit not so straightforward, the third solution to be mentioned is to modify the Java virtual machine. This solution is used by some systems described in section 4. Without going into detail, we just note that this solution requires the component application to run on a nonstandard Java virtual machine and may interfere with mechanisms such as just in time compilation, which makes it generally less flexible.

5 Fighting Class Name Clashes in Java Component Systems 5 3 Removing Name Clashes in Byte Code 3.1 Byte Code Manipulation The Unique names solution from section 2.3, which rested in using unique names for each version of the classes and interfaces that make up a component, is attractive in that it does not require changes to the Java virtual machine, does not incur performance penalty, and works for all the sources of name clashes considered in section 2.2. The problem rests with the convenience of its usage. Ideally, the programmer should be able to use the same names for different versions of the classes and interfaces, but the executable code of the component application should use unique names for each version. A solution to this problem rests with byte code manipulation of the executable code of the component application. Several tools for byte code manipulation are available [3,4,5,17]. Usually, they are used for performance optimizations, for extending functionality by intercepting method invocations, or for generating code in adaptable systems. In our solution, the byte code manipulation is used to augment the names of classes and interfaces that make up a component by adding a unique version identifier, and to rename the references to these classes and interfaces to use the augmented names. That way, the programmer can use the same names for different versions of the classes and interfaces in a convenient way, without running into name clashes. With this solution, an associated problem appears when the standard classloader of the Java virtual machine is used to load the classes or interfaces whose names were augmented by the byte code manipulation. The standard classloader expects the files that contain the classes and interfaces to be named the same as the classes and interfaces themselves, which means that renaming and repackaging of the files is also required. Alternatively, remote loading of classes from a version aware class server can be used. 3.2 Proof of Concept As a proof of concept, we have implemented the approach to avoid name clashes through byte code manipulation in SOFA [15,7]. SOFA is a project of our research group that provides a platform for component applications that supports a construction of hierarchic components connected by potentially complex connectors. The components are described in a component description language (CDL), which can include a description of the component behavior by protocols [16]. The components are fully versioned [12] and can be updated while the component application that uses them is running. In SOFA, the components are stored in a template repository together with the necessary metadata that describe their classes and interfaces, including versions. When running, the components reside inside a deployment dock, which provides the necessary deployment and execution facilities. A single deployment dock can run

6 6 Petr Hnětynka, Petr Tůma several component applications. Implemented in Java, it is therefore a platform where all the sources of name clashes that were outlined in section 2.2 can occur. When a component application is being launched in SOFA, the classes and interfaces are loaded by the deployment dock using a single classloader. To obtain the byte code of the classes and interfaces, the classloader contacts the template repository, which acts as a class server for the deployment dock. The template repository looks up the classes and interfaces by the names used in CDL. The names of the classes and interfaces in the byte code are then augmented using the ASM tool [3] and the augmented version is sent to the deployment dock. The augmentation is done using the ASM tool [3]. The only exception to this mechanism is the case of components that serve as adapters and therefore use several versions of the same interface. In this case, the programmer has to use different names for different versions of the interface simply to be able to write the adapter. The template repository therefore requires an additional translation table that maps the names used by the programmer to the augmented names. The ASM tool uses the visitor pattern for byte code manipulation. The template repository implements a class visitor with the visit, visitfield, visitmethod and visitinnerclass methods. The visit method is called once for each visited class and augments the name of the class and the references to the parent class and the implemented interfaces. The visitfield, visitmethod and visitinnerclass methods are called once for each field, method and inner class of the visited class. The visitmethod method instantiates a method visitor to modify the byte code of the visited methods. The method visitor iterates through all instructions of a method and augments the type names in all instructions that refer to type names. Similar to the class visitor, the code visitor has a separate method for visiting related groups of instructions. The instructions that need to be augmented are handled by the visitfieldinsn (instructions for loading or storing a field of an object), visitlocalvariable (a local variable declaration), visitmethodinsn (an instruction that invokes a method), visitmultianewarrayinsn (the multianewarray instruction), visittrycatchblock (an exception handling block) and visittypeinsn (instructions that take a type descriptor as an argument) methods. As an example, consider a primitive component of type Logger with a single provided interface of type Log for logging events. The component has the following CDL description: struct Event { }; interface Log { void log (Event e); }; frame Logger { provides:

7 Fighting Class Name Clashes in Java Component Systems 7 }; Log log; architecture CUNI Logger implements Logger primitive; As the CDL description is compiled, the symbols in it are assigned a unique version identifier. In SOFA, a version identifier is globally unique, constructed from the name of the SOFA node and a sequence number. In our example, let us presume that the particular version identifier assigned to the symbols is nenya!0. As a next step of the compilation, a Java mapping for the described types and a component factory is generated. In our example, the generated interface is Log and the generated classes are Event and LoggerBuilder. When the CDL description is compiled and the mapping generated, the programmer provides the implementation of the component. In our example, it is the LoggerImpl class, which implements the Log interface. When writing the class, the programmer uses the same names as in the CDL description. Here is a fragment of the code of LoggerImpl: public class LoggerImpl implements Log { public void log (Event e) {... } } When the component is launched, the template repository augments the names of all the classes and interfaces that make up the component by the version identifier, in this example nenya_e_0. 3 If the programmer had to achieve the same result without byte code manipulation, the fragment of the code of LoggerImpl above would have to look like this: public class LoggerImpl_nenya_E_0 implements Log_nenya_E_0 { public void log (Event_nenya_E_0 e) {... } } To extend our example further, let us presume that during the lifecycle of the component application that uses the Logger component, another method will be added to the Log interface. The symbols in the CDL description of the new version will be assigned a new version identifier nenya!1. When providing the new implementation of the component, the programmer will simply add the new method to 3 The exclamation mark in nenya!0 is replaced because it is not allowed in class names.

8 8 Petr Hnětynka, Petr Tůma the old LoggerImpl class, without modifying the names of the classes and interfaces. When the new component will be launched, the template repository will augment the names of all the classes and interfaces by the version identifier nenya_e_1, which will make them different from the names used by the old component and therefore avoid name clashes. 4 Related Work Related to our work are the systems that address the need for coexistence of several versions of a class or an interface in a single Java virtual machine, or the need to dynamically update a Java application. One such system is described in [14], where the authors provide a dynamic environment for distributed Java applications that supports hosting multiple applications within a single JVM. The environment manages classes and objects in distinct class and object spaces, which allows hosting multiple applications without running into name clashes. The disadvantage of the system is that the applications must communicate with each other using only the types from the core of the system. The Java Distributed Runtime Updating Management System (JDRUMS) [1] allows updating Java classes at runtime. The name clashes are removed by using a modified Java virtual machine that can load a new version of a class with the same name as the old version. The first version of JDRUMS allows only limited changes of classes and objects. The second version, JDRUMS 2, provides more options for dynamic changes, but also brings security problems as during the update, it is possible to retrieve secret information that is not available during normal program execution. JDRUMS also disables the just in time compilation. The Dynamic Java Classes (DJC) [11] also allow updating Java classes at runtime. Again, the name clashes are removed by using a modified Java virtual machine with a dynamic classloader that allows a class to be defined multiple times. DJC also extend the Java security mechanism to cope with dynamic updates, and disable the just in time compilation. Many other Java component systems that exist today simply do not support the dynamic updates or coexistence of several versions of a class or an interface with the same name. One such system is the Enterprise Java Beans (EJB) framework from Sun [6]. The components in EJB are called enterprise beans or beans for short. There is no support for dynamic updates of beans in EJB. Fractal [2] from ObjectWeb is a general software composition framework that supports components. Fractal supports an explicit definition of provisions and requirements of a component, composed components with a formal architecture description, component bindings, component sharing and other features. Fractal itself is an abstract framework and serves as a base for a reference implementation called Julia. Fractal and Julia support dynamic updates through reconfiguration, which can add new components, change bindings and remove old components, but cannot handle dynamic updates that involve different versions of the same classes or interfaces.

9 Fighting Class Name Clashes in Java Component Systems 9 5 Conclusion In this paper, we have pointed out the problem of name clashes that occur in Java component systems because of evolutionary changes during the lifecycle of a component application, and explained the sources of these name clashes. We have shown that the standard facilities of the Java type system do not provide for a satisfactory solution, and explained how solutions such as naming schemes or classloader hierarchies may lead to performance penalties and inconvenience the programmer. We have proposed a solution to the problem of name clashes based on administering the names of classes and interfaces with a version identifier using a byte code manipulation tool. Through a proof of concept implementation, we have also demonstrated that our solution integrates smoothly with a Java component system. We have shown that our solution differs from and is superior to the solutions used in contemporary Java component systems. Acknowledgements The authors would like to thank František Plášil, Vladimír Mencl and Jiří Adámek for valuable comments. This work was partially supported by the Grant Agency of the Czech Republic in grants number 102/03/0672 and 201/03/0911. References 1. Andersson, J.: A Deployment System for Pervasive Computing, Proceedings of the International Conference on Software Maintenance (ICSM'00), Bruneton, E., Coupaye, T., Stefani, J. B.: The Fractal Composition Framework, 3. Bruneton, E., Lenglet, R., Coupaye, T.: ASM: A code manipulation tool to implement adaptable systems, 4. Cohen, G. A., Chase, J. S., Kaminsky, D. L.: Automatic program transformation with JOIE, USENIX 1998 Annual Technical Conference, New Orleans, Louisiana, USA, Dahm, M.: Byte Code Engineering, Proceedings JIT'99, Springer, DeMichiel, L. G., Yalcinalp, L. U., Krishnan, S.: Enterprise JavaBeans Specification, Version 2.0, 7. Distributed Systems Research Group: SOFA implementation in Java Gosling, J., Joy, B., Steele, G., Bracha, G.: The Java Language Specification, Second Edition, 9. Lehman, M. M., Ramil, J. F.: Software Evolution in the Age of Component Based Software Engineering, IEE Proceedings Software, Special Issue on Component Based Software Eng., v. 147, n. 6, Dec. 2000, pp Lindholm, T., Yellin, F.: The Java Virtual Machine Specification, Second Edition,

10 10 Petr Hnětynka, Petr Tůma 11. Malabarba, S., Pandey, R., Gragg, J., Barr, E., Barnes, J. F.: Runtime support for type-safe dynamic Java classes, Proceedings of the European Conference on Object- Oriented Programming, June Mencl, V., Hnětynka, P.: Managing Evolution of Component Specifications using a Federation of Repositories, Tech. Report No. 2001/2, Dep. of SW Engineering, Charles University, Prague, Jun Object Management Group: CORBA Components, v 3.0, OMG document formal/ Paal, S., Kammüller, R., Freisleben, B.: Customizable Deployment, Composition, and Hosting of Distributed Java Applications, Proceedings of the International Symposium on Distributed Objects and Applications (DOA 2002), Springer, Plášil, F., Bálek, D., Janeček, R.: SOFA/DCUP: Architecture for Component Trading and Dynamic Updating, Proceedings of ICCDS'98, Annapolis, Maryland, USA, IEEE CS Press, May Plášil, F., Višňovský, S.: Behavior Protocols for Software Components, IEEE Transactions on Software Engineering, vol. 28, no. 11, Nov White, A.: Serp,