WO2005111795A1

WO2005111795A1 - Method for evaluation of the compatibility of a java application and a java platform

Info

Publication number: WO2005111795A1
Application number: PCT/FR2004/000914
Authority: WO
Inventors: Cuihtlauac Alvarado; Yannick Yerro
Original assignee: France Telecom
Priority date: 2004-04-14
Filing date: 2004-04-14
Publication date: 2005-11-24

Abstract

The invention relates to a method for analysing the compatibility of a Java application (50) and at least one Java platform (P, 20, 30, 40), comprising the step of identification of at least one class which may contain a method called by said Java application (50), in which such a class is identified by means of a data base (10), representing at least those platform classes (20, 30, 40) considered, characterized in that identification of at least one class which may provide an effective method corresponding to the methods called is carried out by means of a devirtualisation step applied to the classes of said data base (10). The method further comprises identification in the data base of one or more platforms supporting said effective method which may be provided by said class.

Description

Compatibility assessment method for an application and a JAVA-type platform

The technical fields of the invention are embedded computing and automatic program analysis, in particular for J2ME platforms (Java 2, Micro Edition). In particular, the invention relates to a method for evaluating the compatibility or interoperability of the application / platform of an application embedded on a platform or a set of J2ME platforms, as a function of the resources specific to the different platforms. A Java platform is a device that contains a computer with an execution environment capable of hosting applications that have been developed in the Java programming language. There are four types of Java platforms [3]: - J2EE (Java 2, Enterprise Edition), for servers; - J2SE (Java 2, Standard Edition), for personal computers; - J2ME (Java 2, Micro Edition), for small embedded computers; - Java Card, for microprocessor cards. A J2ME platform is a couple made up of a machine offering a main function (examples: mobile phone, camera, video recorder or parking meter) and an integrated computer with an execution environment for Java applications, in the J2ME variant. The execution environment of a Java platform is composed of a virtual machine for Java executable programs (an interpreter for Java binary codes, Java bytes codes) and a library of functions for these same programs . These functions are called methods in the context of object-oriented programming languages. The methods are grouped into classes, which are themselves grouped into packages. We call distribution all the classes established in a platform (we also speak of libraries of classes). Classes are organized using an inheritance mechanism: descendants acquire the properties of ascendants. The inheritance relationship induces a hierarchy between the classes, we speak of an inheritance tree or class hierarchy. An object of class C is a data structure declared to respond to the methods of class C and all of the classes ascending to C. The differences between the J2ME platforms are reflected in their Java runtime environment , by differences in the sets of methods they offer to applications. These differences create compatibility problems, an application being able to function on a platform A (if all the methods used by the application are available on A) whereas it will not function on a platform B (if at least one method used by the application is not available on B). A J2ME compatibility analysis typically makes a diagnosis of compatibility of a Java application for a J2ME platform. In the following, only two diagnoses are retained: - positive: all the method calls work on the platform, - negative: at least one method call does not work on the platform. Certain analyzes can also lead to a result of a third kind: inconclusive. This happens in cases where these analyzes are not able to pronounce. To perform the analysis of an application in relation to a platform, at least two data are necessary: - the description of the methods implemented in the J2ME platform, - the list of methods used by the Java application. This data may be required in more or less detail depending on the method used to perform the analysis. A J2ME compatibility analysis can be performed manually (by a human operator) or automatically (by software). The diagnosis of a J2ME compatibility analysis may be wrong. The vocabulary of dependability makes it possible to classify the results of the analyzes: - true-positive: positive and correct diagnosis; - true negative: negative and correct diagnosis; - false positive: positive and wrong diagnosis; - false negative: negative and incorrect diagnosis. The Sensé product, marketed by the company Elata (htttp: //elata.com/) is the software closest to the invention described in this document (J2ME compatibility analyzer). Elata SENSE software has an automatic J2ME compatibility analysis component (without human intervention). To perform the analysis, Elata Sensé uses the executable code of the class library of a J2ME platform and the executable code of the application to be analyzed. These executable codes are called Java byte codes. Elata Sensé uses a database to store the class distributions of a set of platforms. This database makes it possible to carry out several analyzes simultaneously (the same application on several platforms). Elata Sensé may provide erroneous results. The MAS product, marketed by the company 4thpass

(http://www.4thpass.com/) is a competitor to Elata's offer. It has a comparable compatibility analysis tool. It seems that this tool is capable of carrying out analyzes at the method level. The main object of the invention is to propose a method and means of compatibility analysis between a Java application and a telecommunications terminal platform, which are of greater speed and reliability. Another object is to provide such a method and such means which make it possible to carry out such an analysis on a plurality of platforms at the same time, such as a fleet of mobile terminals of a telecommunications operator. These aims are achieved according to the invention thanks to a compatibility analysis method between a Java application and at least one platform Java comprising the step consisting in identifying at least one class capable of containing a method called by said Java application, in which method such a class is identified using a database representing at least the classes of the platform considered , characterized in that at least one class capable of delivering an effective method corresponding to the called method is identified by a devirtualization step applied to the classes of this database, the method further comprising identifying in the database one or more platforms carrying said effective method capable of being delivered by this class A device is also proposed according to the invention for analyzing compatibility between a Java application and at least one Java platform comprising means for identifying at least one class capable contain a method called by said Java application, the device includes ant means for identifying such a class using a database representing at least the classes of the platform considered, characterized in that the device comprises means for identifying by a devirtualization step applied to the classes of this database at least one class capable of delivering an effective method corresponding to this called method, the device further comprising means for identifying in the database one or more platforms carrying said effective method capable of being delivered by this class. Thus, devirtualization followed by such identification proves to provide a result of notably high reliability, and with high efficiency. Other characteristics, aims and advantages of the invention will appear on reading the detailed description which follows, made with reference to the appended figures in which: - Figure 1 shows a process according to a preferred variant of the invention; - Figure 2 schematically represents a hierarchical configuration of class inheritance in a devirtualization approach. The prior art consists of a limited analysis at the class level. This technique is used by Elata Sensé. This has the disadvantage of under-approximating the causes of incompatibility. Indeed, for a given method call, a platform can set up the reference class of the call although no method is actually capable of responding to this call. This can happen in the case where no class of the distribution is able to answer the call, although the reference class of the call is present in the platform. For the methods described in the JCP specifications (Java

Community Process) library, these problems should be detected by the Technology Compatibility Kit (TCK) tests, which are sold by Sun for each of these libraries. Testing the presence of an expected method definition in a class is sufficiently conclusive. The detailed description of the invention which will now be made uses the specification of the Java language [2] as well as the specification of the Java virtual machine [4]. A class c is defined by a pair (p, N) where p is a package name and N is a class name. A method is defined by a quadruplet (c, v, m, s) where c is a class, v is an accessibility qualifier, m is a name, and s is a signature. In our context, we consider. that an accessibility qualifier is information attached to a method definition, which restricts the set of classes authorized to call the defined method. The details of these restrictions are described in [2]. A method call γ is a quintuplet (k, ce, CR, m, s) in which ke K is a call qualifier, with K = {special, virtual, static, interface}; it is the context class, ie the class where the call takes place; CR is the reference class (static type), it is a superclass of the dynamic class of the receiving object, m is the name of the method invoked and s is the signature of the invoked method. The details of specifying a Java method call are described in [4]. The invention here calls for the use of a database referenced 10 in FIG. 1. The set of all the platforms stored in the database is called P. These platforms are referenced 20, 30, 40 in FIG. 1. We call C the set of all the classes stored in the database 10. A compatibility ratio is a set of quadruplets (c, m, s, φ) where (c, m, s) is a method and φ is the set of platforms that do not support the method (c, m, s). For the compatibility analysis of an application A (also referenced 50 in FIG. 1) with respect to a set of distributions P, the algorithm used here is the following: 1) Initialization: ψ _A : = 0; the application compatibility report

A, which is called ψ _A , is initially empty; 2) Extraction of all the method calls contained in the executable code specific to application A. This is there, and in this embodiment, to identify the methods called. 3) Call loop; if there are any left, draw a call γ = (k, ce, CR, m, s)

€ IA not processed, otherwise go to the end of the calls loop. 4) Call to the database: calculation of the set of classes C _γ containing a method (m, s). 5) Restriction of C _γ to subclasses and superclasses of class CR. 6) Class loop. If there are any left, draw a class that is not processed, otherwise go to the end of the classes loop. 7) Call to the database: calculation of all the Pc platforms that set up (c, m, s). We identify here effective methods, i.e. methods that actually exist on platforms and correspond concretely to the so-called methods identified in step 2. In other words, the database contains a set of links between a list of platforms (for example mobile phone models) and a list of effective methods, links which indicate that a platform of a given type contains a given method or on the contrary does not contain it. In other words, it involves using a table with two inputs (platforms and methods) to indicate which platforms are capable of implementing the given effective method. 8) Restriction of P _c to platforms for which the method (c, m, s) is accessible from class ce. 9) If Pc ≠ P, carry out ψA: = ΨA ^ {(C, m, s, P n P _c )} 10) Return to the start of the classes loop, end of this loop 11) Return to the start of the calls loop , end of this loop 12) If ψ _A = 0 then the application A is compatible with all the platforms of P, otherwise ψ _A contains a set of quadruplets (c, m, s, φ) where (c, m , s) is a method invoked in A and where φ is the set of platforms which do not support (c, m, s). This algorithm performs a devirtualization calculation in step 4 for the method calls of the application. It is the result of this calculation which is submitted to the database for compatibility verification. The results of these calculations are identical to those provided by the CHA method, however the algorithm is different (CHA does not use a database). On the other hand, this example of the invention does not use the RTA method here. Also, a devirtualization step is used, the result of which is applied here to the content of an associated database. In the present embodiment, the method called can be a general definition of method, to which one or more effective methods may correspond. There are different ways of representing the data describing these platforms in the database. We use a relational database containing a table of class distributions, a method table, a class table and two tables for associations between data tables. However, the invention does not relate to the structure of this database. Only the use of a platform database is required. In an object-oriented programming language (such as Java), calls to functions (so-called method calls) use a mechanism called "dynamic resolution". This mechanism makes it possible to fix, at the time of the execution of the program, the function which will carry out the processing responding to a given method call. A method call represents the sending of a message to an object (called receiver), dynamic resolution consists in traversing the inheritance hierarchy by going up starting from the class of the receiver, in search of a method capable of answer the call. This allows this processing to be changed from one method call to another. In non-object-oriented languages, the resolution is static, that is to say fixed once and for all. Devirtualization is a method that calculates the set of classes that respond during execution to a given method call. The devirtualization of a method call provides a set of classes which all contain a method capable of responding to the analyzed call. When executing a method call, only one of these classes will actually be activated by dynamic resolution. Devirtualization is an approximate calculation: the calculated sets must contain all the activatable classes but they also contain non-activatable classes. The more efficient the devirtualization technique, the more precise it provides results (ie sets containing fewer non-activatable classes). There are many devirtualization techniques: Class Hierarchy Analysis (CHA), Rapid Type Analysis (RTA), Extented Type Analysis (XTA) and Variable Type Analysis (VTA) (to name only the most classic). The calculation of all the method calls contained in the code specific to the application is sufficient to perform the analysis at the level classes. The class level restricted compatibility analyzer stops at this stage. To carry out the restriction of the set of classes Cγ to subclasses and superclasses of CR, different layouts are possible. We use a tree data structure to represent the inheritance hierarchy common to all class distributions. However, the invention does not specify any particular technique or data structure for performing this calculation, the details of which are secondary, but the presence of which is required. The algorithm presented corresponds to the processing carried out in the case of a virtual method call (virtual). In the case of other method calls, the processing is slightly different: In the case of a static type method, the call does not use dynamic resolution, there is no approximation to calculate, it suffices to find the platforms that implement the reference class. In the special case for calling a private method, private methods cannot be incompatible, they are in classes provided by the application. For the call to an initialization method, the initialization methods are statically resolved, see this case above. For the call to the super object, we proceed as for the virtual calls except that we do not consider the minimum subclasses of the reference class (we cut the sheets). In the case of an interface type method, for an interface call we start by finding the classes that implement the interface in the database. Then, from these classes we proceed as for virtual calls. The database 10 of the platforms 20, 30, 40 can be on the same computer as that which performs the compatibility analyzes or can be on another computer (they must then be connected by a communication network). The entry of new platforms or applications to be analyzed as well as the report outputs of Compatibility can be carried out locally or remotely, in various forms and with more or less details. The absence of false-positive results is a quality specific to the invention. It is to guarantee this property that we prefer to implement the invention for platforms of the J2ME type. Indeed, in J2ME, the set of classes which can be instantiated in an application to a sure-static approximation and finite the union of the set of classes of the platform and the set of classes of the application. However, the invention is applicable to any version of Java for which this property is verified. However, this is not always the case for J2EE and J2SE. Application of the invention to Java Card is also possible. Also, in the present preferred embodiment, two techniques are used in a combined manner which are devirtualization and automatic byte code auditing. One of these two techniques (devirtualization in the CHA variant) is applied in the use of a database (required in the context of the problem to be solved). Thanks to these provisions, it becomes possible to carry out the compatibility analysis at the level of the methods called up (better quality of the analysis). It also becomes possible to perform compatibility analysis for several phones simultaneously more efficiently than by doing an analysis for each phone (better performance of the analysis). Our invention performs an analysis at the method level, therefore with a finer grain. This has the following advantages: - the absence of false-positive results does not depend on hypothesis on the class distributions; - in the event of a negative result, our invention provides a list of methods which may be incompatible, for each method call, invoked by the application on a given platform. An example of application of the invention is the compatibility analysis of J2ME applications for Java mobile phones. There are several class libraries specific to families of J2ME devices, these libraries are called "profiles", for example: MIDP (Mobile Information Device Profile) for mobile phones, MHP (Multimedia Home Profile) for home electronics and STIP (Smalll Terminal Interoperability Platform) for payment and electronic payment. J2ME applications for mobile phones use the MIDP profile. These applications are called "midlets". Midlets can be downloaded, installed by phone users. There are different versions of MIDP, additional optional libraries, and proprietary libraries (specific to a phone manufacturer). As a result, the available class libraries vary significantly from phone to phone. There is therefore a compatibility problem with the classes and methods used by midlets. The invention enables a J2ME telephone user to know whether a Java application is compatible with his telephone before he has downloaded it. It also allows an application developer to know on which phones his application may not work. It allows a mobile telephone network operator to assess the compatibility of the applications available with its customers' fleet of telephones. The invention can also be used by an operator's customer service to assist a customer who has installed an application incompatible with his terminal. The operators of J2ME application download portals are the main demanders of automatic interoperability assessment. In particular, mobile operators have to deal with the heterogeneity of their customers' terminals and the proliferation of independent midlet providers. J2EE Glossary: Java 2, Enterprise Edition

J2DE: Java 2, Standard Edition

J2ME: Java 2, Micro Edition

CLDC: Connected Limited Device Configuration

MIDP: Mobile Information Device Profile MHP: Multimedia Home Profile

STIP: Small Terminal Interoperability Platform

JCP: Java Community Process

JSR: Java Specification Request

TCK: Technology Compatibily Kit Midlet: MIDP Application

CHA: Class Hierarchy Analysis

RTA: Rapid Type Analysis

XTA: Extended Type Analysis

VTA: Variable Type Analysis

References

1. DF Bacon, MN Wegman, and FK Zadeck. Object oriented dispatch optimization. US Patent Number 6,041, 179, Mar. 2000. 2. J. Gosling, B. Joy, G. Steele, and G. Bracha. The Java (TM) Language Specification, Second Edition, Addison-Wesley, 2000 3. M. Hardee, M. Smaragdis, F. Rimalovski, C. Cameron, D. Macias, B. Goldberg, T. Beyers, J. Byous, J. Umstattd, L. Doughty, T. Welch, H. Dailey, K. Kayl, D. Nourie, A. Wisnewski, and G. Guinto. What is Java (TM) technology? Sun Microsystems, 2002 http: // iava. su n. com / iava2 / whatis /. 4. FY Tim Lindholm. The Java (TM) Virtual Machine Specification, Second Edition. Addison-Wesley, 1999.

5. F. Tip and J. Paisberg. Scalable propagation-bases call graph construction algorithms. In Proceeding of OOPSLA'OO, pages 281-293, 2000.

Claims

1. Compatibility analysis method between a Java application (50) and at least one Java platform (P, 20, 30, 40) comprising the step of identifying at least one class capable of containing a method called by said application Java (50), in which method one identifies such a class using a database (10) representing at least the classes of the platform (20, 30, 40) considered, characterized in that one identifies by a devirtualization step applied to the classes of this database (10) at least one class capable of delivering an effective method corresponding to the method called, the method further consisting in identifying in the database one or more platforms carrying said effective method likely to be delivered by this class.

2. Method according to claim 1, characterized in that the database includes the classes and methods of a plurality of platforms (P, 20, 30, 40), the devirtualization step being carried out on all of these platforms (P, 20, 30, 40).

3. Method according to claim 1 or claim 2, characterized in that the platform (s) contained (s) in the database (10) is (are) one (of) platform (s) (P, 20, 30, 40) of mobile telecommunications terminal.

4. Method according to any one of the preceding claims, characterized in that it comprises the final step consisting in providing a compatibility report in the form of a set of quadruplets (c, m, s, ψ) where ( c, m, s) is a method defined by its class c, its name m, and its signature s, and where ψ is the set of platforms that do not support the method (c, m, s).

5. Method according to claim 1 or claim 2, characterized in that the method is implemented on the basis of a control algorithm, which, for each call of the application, loops over the whole classes identified by the devirtualization step, and examines at least one method within each loop.

6. Method according to any one of the preceding claims, characterized in that it comprises the steps in which: a) an initialization is implemented in which it is considered that the set (ΨA) of the platforms (P, 20, 30, 40) incompatible with the application (A) is empty, b) we extract a set (l _A ) made up of method calls from the application (50) (A), c) we set up an indexed loop on the calls of this set, this loop consisting of the following sub-steps: d) for a call considered, we identify by devirtualization the set of classes (c _ga ma) likely to contain the method called by this call, c2) we restrict this set (C _ga m _a ) to subclasses and superclasses of a base class (CR), c3) we implement an indexed sub-loop on the classes, consisting of the following steps: c3- 1) using the database, we identify the set (P _c ) of platforms that implement the met hode called, c3-2) if this set (P _c ) is different from the set formed by the platforms (P, 20, 30, 40) that can be analyzed by the process, the complementary of this set (Pc) is entered in this set studied as platform (s) not supporting the method called. d) a compatibility report is delivered in the form of a set of method / set of platform pairs, where, for each method, a set of platform (s) is associated (P, 20, 30, 40) which does not support the method, this set can be an empty set.

7. Method according to any one of the preceding claims, characterized in that the platform (s) (P, 20, 30, 40) is (are) one (or more) platform (s) of J2ME type.

8. Method according to any one of claims 1 to 7, characterized in that it further comprises the step of identifying if the effective method is able to respond to the call of the application (50), by comparison of the binary codes of the application (50) and of the effective method.

9. Compatibility analysis device between a Java application and at least one Java platform (20, 30, 40) comprising means for identifying at least one class capable of containing a method called by said Java application (50), the device comprising means for identifying such a class using a database (10) representing at least the classes of the platform (20, 30, 40) considered, characterized in that the device comprises means for identifying by a devirtualization step applied to the classes of this database (10) at least one class capable of delivering an effective method corresponding to this called method, the device further comprising means for identifying in the database one or more platforms bearing said effective method likely to be delivered by this class.

10. Device according to claim 9, characterized in that it comprises means for implementing the steps, in which: a) an initialization is implemented in which it is considered that all (ΨA) of the platforms (P , 20, 30, 40) incompatible with the application (A) is empty, b) we extract a set (IA) made up of method calls from the application (50) (A), c) we set up a loop indexed on the calls of this set, this loop consisting of the following sub-steps: d) for a call considered, we identify by devirtualization the set of classes (c _ga ma) likely to contain the method called by this call, c2) we restrict this set (C _ga ma) to the subclasses and superclasses of a basic class (CR), c3) we implement an indexed sub-loop on the classes, consisting of the following steps: c3-1) using the database, we identify the set (P _c ) of the platforms that implement the method called, c3-2) if this set (Pc) is different from the set formed by the platforms (P, 20, 30, 40) that can be analyzed by the process, the complementary of this set (Pc) is registered in this set studied as platform (s) not supporting the method called. d) a compatibility report is delivered in the form of a set of method / set of platform pairs, where, for each method, a set of platform (s) is associated (P, 20, 30, 40) which does not support the method, this set can be an empty set.

11. Device according to claim 9 or claim 10, characterized in that the database includes the classes and methods of a plurality of platforms (P, 20, 30, 40), the devirtualization step and the step identification method (s) being performed on this plurality of platforms (P, 20, 30, 40).

12. Device according to any one of claims 9 to 11, characterized in that it comprises means for identifying whether the effective method is capable of responding to the call to the application (50), by comparison of the binary codes of the application (50) and of the effective method.