6 in Figure 1).getMethod(String,Class[])is similar except that the re- turned Method object is public(either declared or inherited).If the target Class does not have a matching method,then its superclasses are searched first recur- sively (bottom-up)before its interfaces(implemented).getDeclaredMethods() returns an array of Method objects representing all the methods declared in the target Class object.getMethods()is similar except that all the public methods (either declared or inherited)in the target Class object are returned.Given a Method object mtd,its target method can be called as shown in line 7 in Figure 1. 2.2 Empirical Study The Java reflection API is rich and complex in details.We conduct an empirical study to understand reflection usage in practice in order to guide the design and implementation of a sophisticated reflection analysis. We select 14 representative Java programs,including nine DaCapo bench- marks (2006-10-MR2),three latest versions of popular desktop applications, javac-1.7.0,jEdit-5.1.0 and Eclipse-4.2.2 (denoted Eclipse4),and two latest versions of popular server applications,Jetty-9.0.5 and Tomcat-7.0.42. Note that DaCapo consists of 11 benchmarks,including an older version of Eclipse(version 3.1.2).We exclude bloat 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.5). including the ones in java.lang.reflect and java.lang.Class,loadClass() in java.lang.ClassLoader,and getclass()in java.lang.Object.We have also considered A.class,which represents the Class object of a class A. We use SooT[19]to pinpoint the calls to reflection methods in the bytecode of a program.To understand reflection usage,we consider only the reflective calls found in the application classes and their dependent libraries but exclude the standard Java libraries.To increase 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 available under the process-dir option supported by SOOT.For Eclipse4,we use org.eclipse.core runtime.adaptor.EclipseStarter to enable SooT to locate all the other jar files used.We manually inspect the reflection usage in a program in a demand- driven manner,starting from its side-effect methods,assisted by Open Call Hier- archy in Eclipse,by following their backward slices.For a total of 609 side-effect callsites examined,510 callsites for calling entry methods and 304 callsites for calling member-introspecting methods are tracked and analyzed. Below we describe our five findings on reflection usage in our empirical study. Side-Effect Methods Table 1 lists a total of nine side-effect methods that can possibly modify or use (as their side effects)the pointer information in a program. Figure 2 depicts their percentage frequency distribution in the 14 programs studied.We can see that invoke()and Class:newInstance()are the two most frequently used (32.7%and 35.3%,respectively,on average),which are6 in Figure 1). getMethod(String, Class[]) is similar except that the re￾turned Method object is public (either declared or inherited). If the target Class does not have a matching method, then its superclasses are searched first recur￾sively (bottom-up) before its interfaces (implemented). getDeclaredMethods() returns an array of Method objects representing all the methods declared in the target Class object. getMethods() is similar except that all the public methods (either declared or inherited) in the target Class object are returned. Given a Method object mtd, its target method can be called as shown in line 7 in Figure 1. 2.2 Empirical Study The Java reflection API is rich and complex in details. We conduct an empirical study to understand reflection usage in practice in order to guide the design and implementation of a sophisticated reflection analysis. We select 14 representative Java programs, including nine DaCapo bench￾marks (2006-10-MR2), three latest versions of popular desktop applications, javac-1.7.0, jEdit-5.1.0 and Eclipse-4.2.2 (denoted Eclipse4), and two latest versions of popular server applications, Jetty-9.0.5 and Tomcat-7.0.42. Note that DaCapo consists of 11 benchmarks, including an older version of Eclipse (version 3.1.2). We exclude bloat 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.5), including the ones in java.lang.reflect and java.lang.Class, loadClass() in java.lang.ClassLoader, and getClass() in java.lang.Object. We have also considered A.class, which represents the Class object of a class A. We use Soot [19] to pinpoint the calls to reflection methods in the bytecode of a program. To understand reflection usage, we consider only the reflective calls found in the application classes and their dependent libraries but exclude the standard Java libraries. To increase 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 available under the process-dir option supported by Soot. For Eclipse4, we use org.eclipse.core. runtime.adaptor.EclipseStarter to enable Soot to locate all the other jar files used. We manually inspect the reflection usage in a program in a demand￾driven manner, starting from its side-effect methods, assisted by Open Call Hier￾archy in Eclipse, by following their backward slices. For a total of 609 side-effect callsites examined, 510 callsites for calling entry methods and 304 callsites for calling member-introspecting methods are tracked and analyzed. Below we describe our five findings on reflection usage in our empirical study. Side-Effect Methods Table 1 lists a total of nine side-effect methods that can possibly modify or use (as their side effects) the pointer information in a program. Figure 2 depicts their percentage frequency distribution in the 14 programs studied. We can see that invoke() and Class::newInstance() are the two most frequently used (32.7% and 35.3%, respectively, on average), which are