not dynamically updatable FINDING 1.Almost all changed classes (187/190,or 98.4%) 1.6% ▣non-trivial(need a transformer） are dynamically updatable using either trivial default or non- trivial provided object transformers. non-trivial (need update-time config) 700 69 trivial (object unchanged) In the three failing cases,two of them added new fields trivial (object changed) whose values are only available in an already popped stack frame.Another one is a fix for a resource leak in which whether an object is leaked cannot be effectively determined. Fig.2:Taxonomy of the 190 changed classes in Tomcat 8. Fortunately,refactoring the program to discard partial states at a component level [4,29,30]can make them updatable. This observation motivates us to explore the possibility of Furthermore,we found that simple default object transfor- mation suffices in most cases: automatically synthesizing object transformers by reassembling existing code snippets,including both old and new versions of a FINDING 2.Most class changes (166/190,or 87.4%)can be program.This observation is further validated in our empirical dynamically updated via trivial object transformers. study in Section III,and then implemented as a heuristic search 133 out of the 166 class changes (80.1%)involve only algorithm in Section V. code logic upgrades that do not affect the concerned objects' III.EMPIRICAL STUDY data representations,i.e.,field values are unchanged.A typical example is a security patch.The rest 33(19.9%)class changes In this short empirical study,we seek insights for under- can be automatically handled by a DSU system's default standing the challenges of object transformation in DSU over policy [15,17,18],e.g.,assigning a newly created field with a a set of randomly sampled real-world class changes. default value or garbage collecting a removed field's referred objects. A.Methodology Finally,class changes that require non-trivial object trans- We empirically studied the applicability of DSU in the formers are of particular research interest: evolution of Apache Tomcat 8 [23],one of the most popular Java Web servers.Tomcat 8 is still under active maintenance FINDING 3.Not many but non-negligible class changes(21/190, upgrades since its first release in 2013,making it a suitable or 11.1%)require non-trivial object transformers.These subject for studying DSU.We uniform-randomly sampled changes substantially hinder the application of DSU in practice. 100 commits from all 2,114 Tomcat 8 commits in its entire For these updates,the upgrade maintainer can manually maintenance history by the paper was written (from 8.0.0 to provide an object transformer to enable DSU over such non- the latest release 8.0.53).The sampled commits consist of in trivial class changes.However,this is not an easy task because total 190 class changes3. non-trivial object transformers usually exploit a program's For each changed class,we manually inspected the program implicit invariants or object state constraints (like the example state at a hypothetical update-safe point in which all changed in Figure 1).Automatic transformer synthesis [27,28]can methods of the class are popped off the stack.We determine be a promising and highly-preferred solution.Unfortunately. whether object transformation is possible(i.e.,whether DSU is our later experiments show that even the best state-of-the-art applicable)at that point and try to provide each of 2,957 fields technique produces correct transformations in <10%of these in the 190 changed classes a transformer.Given a class change non-trivial class changes. that can be dynamically updated,its object transformer is Therefore,the general unavailability of non-trivial object considered trivial if all of its field transformations are default transformers should be recognized as a key obstacle in making (explained in Section ID).Otherwise,the non-trivial object DSU practical.To address this challenge,we examined the transformer has at least one field that requires non-trivial characteristics of our manually crafted object transformers to transformation (like ka in Figure 1). find potentially useful guidance for automatic object trans- To validate our observation that non-trivial transformers can former synthesis.Figure 3 summarizes the basic constructs be constructed by reassembling existing code snippets,we in our manual transformers,which can be concluded by the preferred reusing old/new version code statements with minor following finding: revisions.We collect and analyze the statistics of those reused FINDING 4.Default transformations and existing code snippets statements in constructing transformers. are the major constructs of a non-trivial object transformer. B.Results and Findings The basic constructs of the 21 non-trivial object transformers The statistics in Figure 2 first indicate that DSU can be are:42 right-hand side expressions of assignments,15 if- broadly applicable in a program's maintenance lifetime: then-else branch conditions,and 2 for-each loop conditions. Understanding the characteristics of these basic constructs 3Commits that do not change the Tomcat-core source code (e.g..documen- is critical to the development of an automatic transformer tation or test case updates)are excluded from the study because they are irrelevant to DSU.190 are all class changes because changes to Tomcat 8 are 4Dynamically updating such a class with a default transformer will result mainly maintenance upgrades. in a crash or broken application logic.1.6% 9.5% 1.6% 70.0% 17.4% not dynamically updatable non-trivial (need a transformer) non-trivial (need update-time config) trivial (object unchanged) trivial (object changed) Fig. 2: Taxonomy of the 190 changed classes in Tomcat 8. This observation motivates us to explore the possibility of automatically synthesizing object transformers by reassembling existing code snippets, including both old and new versions of a program. This observation is further validated in our empirical study in Section III, and then implemented as a heuristic search algorithm in Section V. III. EMPIRICAL STUDY In this short empirical study, we seek insights for under￾standing the challenges of object transformation in DSU over a set of randomly sampled real-world class changes. A. Methodology We empirically studied the applicability of DSU in the evolution of Apache Tomcat 8 [23], one of the most popular Java Web servers. Tomcat 8 is still under active maintenance upgrades since its first release in 2013, making it a suitable subject for studying DSU. We uniform-randomly sampled 100 commits from all 2,114 Tomcat 8 commits in its entire maintenance history by the paper was written (from 8.0.0 to the latest release 8.0.53). The sampled commits consist of in total 190 class changes3 . For each changed class, we manually inspected the program state at a hypothetical update-safe point in which all changed methods of the class are popped off the stack. We determine whether object transformation is possible (i.e., whether DSU is applicable) at that point and try to provide each of 2,957 fields in the 190 changed classes a transformer. Given a class change that can be dynamically updated, its object transformer is considered trivial if all of its field transformations are default (explained in Section II). Otherwise, the non-trivial object transformer has at least one field that requires non-trivial transformation (like ka in Figure 1). To validate our observation that non-trivial transformers can be constructed by reassembling existing code snippets, we preferred reusing old/new version code statements with minor revisions. We collect and analyze the statistics of those reused statements in constructing transformers. B. Results and Findings The statistics in Figure 2 first indicate that DSU can be broadly applicable in a program’s maintenance lifetime: 3Commits that do not change the Tomcat-core source code (e.g., documen￾tation or test case updates) are excluded from the study because they are irrelevant to DSU. 190 are all class changes because changes to Tomcat 8 are mainly maintenance upgrades. FINDING 1. Almost all changed classes (187/190, or 98.4%) are dynamically updatable using either trivial default or non￾trivial provided object transformers. In the three failing cases, two of them added new fields whose values are only available in an already popped stack frame. Another one is a fix for a resource leak in which whether an object is leaked cannot be effectively determined. Fortunately, refactoring the program to discard partial states at a component level [4, 29, 30] can make them updatable. Furthermore, we found that simple default object transfor￾mation suffices in most cases: FINDING 2. Most class changes (166/190, or 87.4%) can be dynamically updated via trivial object transformers. 133 out of the 166 class changes (80.1%) involve only code logic upgrades that do not affect the concerned objects’ data representations, i.e., field values are unchanged. A typical example is a security patch. The rest 33 (19.9%) class changes can be automatically handled by a DSU system’s default policy [15, 17, 18], e.g., assigning a newly created field with a default value or garbage collecting a removed field’s referred objects. Finally, class changes that require non-trivial object trans￾formers are of particular research interest: FINDING 3. Not many but non-negligible class changes (21/190, or 11.1%) require non-trivial object transformers4 . These changes substantially hinder the application of DSU in practice. For these updates, the upgrade maintainer can manually provide an object transformer to enable DSU over such non￾trivial class changes. However, this is not an easy task because non-trivial object transformers usually exploit a program’s implicit invariants or object state constraints (like the example in Figure 1). Automatic transformer synthesis [27, 28] can be a promising and highly-preferred solution. Unfortunately, our later experiments show that even the best state-of-the-art technique produces correct transformations in <10% of these non-trivial class changes. Therefore, the general unavailability of non-trivial object transformers should be recognized as a key obstacle in making DSU practical. To address this challenge, we examined the characteristics of our manually crafted object transformers to find potentially useful guidance for automatic object trans￾former synthesis. Figure 3 summarizes the basic constructs in our manual transformers, which can be concluded by the following finding: FINDING 4. Default transformations and existing code snippets are the major constructs of a non-trivial object transformer. The basic constructs of the 21 non-trivial object transformers are: 42 right-hand side expressions of assignments, 15 if￾then-else branch conditions, and 2 for-each loop conditions. Understanding the characteristics of these basic constructs is critical to the development of an automatic transformer 4Dynamically updating such a class with a default transformer will result in a crash or broken application logic