7:10 Yue Li,Tian Tan,and Jingling Xue and how often can non-constant strings be resolved by a simple string analysis that models string operations such as“+”and append()? Q2.Existing reflection analyses ignore the member-retrieving methods that return an array of member metaobjects.Is it necessary to handle such methods? .Q3.Existing reflection analyses usually treat reflective method calls and field accesses as being non-static.Does this treatment work well in real-world programs?Specifically,how often are static reflective targets used in reflective code? .Q4.In [38],intraprocedural post-dominating cast operations are leveraged to resolve newInstance() when its class type is unknown.This approach is still adopted by many reflection analysis tools.Does it generally work in practice? .Q5.The Java reflection API contains many class-retrieving methods for returning Class objects.Which ones should be focused on by an effective reflection analysis? .Q6.The core part of reflection analysis is to resolve all the nine reflective-action methods (Table 1)effectively.What are the reflective-action methods that are most widely used and how are the remaining ones used in terms of their relative frequencies? Q7.What are new insights on handling Java reflection(from this paper)? 2.3.2 Experimental Setup.We have selected a set of 16 representative Java programs,including three popular desktop applications,javac-1.7.0,jEdit-5.1.0 and Eclipse-4.2.2(denoted Eclipse4),two popular server applications,Jetty-9.0.5 and Tomcat-7.0.42,and all eleven DaCapo benchmarks(2006-10-MR2)[3].Note that the DaCapo benchmark suite includes an older version of Eclipse(version 3.1.2).We exclude its bloat benchmark since its application code is reflection-free.We consider lucene instead of luindex and lusearch separately since these two benchmarks are derived from lucene with the same reflection usage. We consider a total of 191 methods in the Java reflection API(version 1.6),including the ones mainly from package java.lang.reflect and class java.lang.Class. We use Soor [63]to pinpoint the calls to reflection methods in the bytecode of a program. To understand the common reflection usage,we consider only the reflective calls found in the application classes and their dependent libraries but exclude the standard Java libraries.To in- crease the code coverage for the five applications considered,we include the jar files whose names contain the names of these applications(e.g.,*jetty*.jar for Jetty)and make them avail- able under the process-dir option supported by Soor.For Eclipse4,we use org.eclipse.core. runtime.adaptor.EclipseStarter to let Soor locate all the other jar files used. We manually inspect the reflection usage in a program in a demand-driven manner,starting from its reflective-action methods,assisted by Open Call Hierarchy in Eclipse,by following their backward slices.For a total of 609 reflective-action call sites examined,510 call sites for calling class-retrieving methods and 304 call sites for calling member-retrieving methods are tracked and studied.As a result,a total of 1,423 reflective call sites,together with some nearby statements,are examined in our study. 2.3.3 Results.Below we describe our seven findings on reflection usage as our answers to the seven focus questions listed in Section 2.3.1,respectively.We summarize our findings as individual remarks,which are expected to be helpful in guiding the development of practical reflection analysis techniques and tools in future research. O1.String Constants and String Manipulations.In class-retrieving methods,Class.forName( and loadclass()each have a String parameter to specify the target class.In member-retrieving methods,getDeclaredMethod(String,...and getMethod(String,...)each return a Method ACM Trans.Softw.Eng.Methodol.,Vol.28,No.2,Article 7.Publication date:February 2019.7:10 Yue Li, Tian Tan, and Jingling Xue and how often can non-constant strings be resolved by a simple string analysis that models string operations such as “+” and append()? • Q2. Existing reflection analyses ignore the member-retrieving methods that return an array of member metaobjects. Is it necessary to handle such methods? • Q3. Existing reflection analyses usually treat reflective method calls and field accesses as being non-static. Does this treatment work well in real-world programs? Specifically, how often are static reflective targets used in reflective code? • Q4. In [38], intraprocedural post-dominating cast operations are leveraged to resolve newInstance() when its class type is unknown. This approach is still adopted by many reflection analysis tools. Does it generally work in practice? • Q5. The Java reflection API contains many class-retrieving methods for returning Class objects. Which ones should be focused on by an effective reflection analysis? • Q6. The core part of reflection analysis is to resolve all the nine reflective-action methods (Table 1) effectively. What are the reflective-action methods that are most widely used and how are the remaining ones used in terms of their relative frequencies? • Q7. What are new insights on handling Java reflection (from this paper)? 2.3.2 Experimental Setup. We have selected a set of 16 representative Java programs, including three popular desktop applications, javac-1.7.0, jEdit-5.1.0 and Eclipse-4.2.2 (denoted Eclipse4), two popular server applications, Jetty-9.0.5 and Tomcat-7.0.42, and all eleven DaCapo benchmarks (2006-10-MR2) [3]. Note that the DaCapo benchmark suite includes an older version of Eclipse (version 3.1.2). We exclude its bloat benchmark since its application code is reflection-free. We consider lucene instead of luindex and lusearch separately since these two benchmarks are derived from lucene with the same reflection usage. We consider a total of 191 methods in the Java reflection API (version 1.6), including the ones mainly from package java.lang.reflect and class java.lang.Class. We use Soot [63] to pinpoint the calls to reflection methods in the bytecode of a program. To understand the common reflection usage, we consider only the reflective calls found in the application classes and their dependent libraries but exclude the standard Java libraries. To in￾crease the code coverage for the five applications considered, we include the jar files whose names contain the names of these applications (e.g., *jetty*.jar for Jetty) and make them avail￾able under the process-dir option supported by Soot. For Eclipse4, we use org.eclipse.core. runtime.adaptor.EclipseStarter to let Soot locate all the other jar files used. We manually inspect the reflection usage in a program in a demand-driven manner, starting from its reflective-action methods, assisted by Open Call Hierarchy in Eclipse, by following their backward slices. For a total of 609 reflective-action call sites examined, 510 call sites for calling class-retrieving methods and 304 call sites for calling member-retrieving methods are tracked and studied. As a result, a total of 1,423 reflective call sites, together with some nearby statements, are examined in our study. 2.3.3 Results. Below we describe our seven findings on reflection usage as our answers to the seven focus questions listed in Section 2.3.1, respectively. We summarize our findings as individual remarks, which are expected to be helpful in guiding the development of practical reflection analysis techniques and tools in future research. Q1. String Constants and String Manipulations. In class-retrieving methods, Class.forName() and loadClass() each have a String parameter to specify the target class. In member-retrieving methods, getDeclaredMethod(String,...) and getMethod(String,...) each return a Method ACM Trans. Softw. Eng. Methodol., Vol. 28, No. 2, Article 7. Publication date: February 2019