We report findings on a reflection-usage study using 14 representative Java benchmarks and applications (Section 2).We expect these findings to be useful in guiding the design and implementation of reflection analysis. We introduce a static reflection analysis,ELF,to improve the effectiveness of pointer analysis tools for Java (Section 3).ELF adopts a new self-inferencing mechanism for reflection resolution and handles a significant part of the Java reflection aPI that was previously ignored or handled partially. We formulate ELF in Datalog consisting of 207 rules,covering the majority of reflection methods frequently used in Java programs(Section 4). We have evaluated ELF against a state-of-the-art reflection analysis in DooP (version r160113)under the same context-sensitive Andersen's pointer anal- ysis framework,using all 11 DaCapo benchmarks and two Java applications, Eclipse4 and Javac (Section 5).Our results show that ELF can make a dis- ciplined tradeoff among soundness,precision and scalability while resolving usually more reflective call targets than DooP. 2 Understanding Reflection Usage Section 2.1 provides a brief introduction to the Java reflection API.Section 2.2 reports our findings on reflection usage in Java benchmarks and applications. 2.1 Background The Java reflection API provides metaobjects to allow programs to examine themselves and make changes to their structure and behavior at run time.In Figure 1,the metaobjects clz,mtd and fld are instances of the metaobject classes Class,Method and Field,respectively.Constructor can be seen as Method except that the method name"<init>"is implicit.Class provides ac- cessor methods such as getDeclaredMethod()in line 6 and getField in line 8 to allow the other metaobjects (e.g.,of Method and Field)related to a Class object to be introspected.With dynamic invocation,a Method object can be commanded to invoke the method that it represents (line 7)and a Field object can be commanded to access the field that it represents (lines 9 and 10). As far as pointer analysis is concerned,we can divide the pointer-affecting methods in the Java reflection API into three categories:(1)entry methods, e.g.,forName()in line 3,for creating Class objects,(2)member-introspecting methods,e.g.,getDeclaredMethod()in line 6 and getField()in line 8,for retrieving Method (Constructor)and Field objects from a Class object,and(3) side-effect methods,e.g.,newInstance(),invoke(),get (and set()in lines 4,7,9 and 10,that affect the pointer information in the program reflectively. Class provides a number of accessor methods for introspecting methods, constructors and fields in a target class.Unlike [4,8,ELF is the first to handle all such accessor methods in reflection analysis.Let us recall the four on return- ing Method objects.getDeclaredMethod(String,Class []returns a Method object that represents a declared method of the target Class object with the name (formal parameter types)specified by the first (second)parameter (line– We report findings on a reflection-usage study using 14 representative Java benchmarks and applications (Section 2). We expect these findings to be useful in guiding the design and implementation of reflection analysis. – We introduce a static reflection analysis, Elf, to improve the effectiveness of pointer analysis tools for Java (Section 3). Elf adopts a new self-inferencing mechanism for reflection resolution and handles a significant part of the Java reflection API that was previously ignored or handled partially. – We formulate Elf in Datalog consisting of 207 rules, covering the majority of reflection methods frequently used in Java programs (Section 4). – We have evaluated Elf against a state-of-the-art reflection analysis in Doop (version r160113) under the same context-sensitive Andersen’s pointer anal￾ysis framework, using all 11 DaCapo benchmarks and two Java applications, Eclipse4 and Javac (Section 5). Our results show that Elf can make a dis￾ciplined tradeoff among soundness, precision and scalability while resolving usually more reflective call targets than Doop. 2 Understanding Reflection Usage Section 2.1 provides a brief introduction to the Java reflection API. Section 2.2 reports our findings on reflection usage in Java benchmarks and applications. 2.1 Background The Java reflection API provides metaobjects to allow programs to examine themselves and make changes to their structure and behavior at run time. In Figure 1, the metaobjects clz, mtd and fld are instances of the metaobject classes Class, Method and Field, respectively. Constructor can be seen as Method except that the method name “<init>” is implicit. Class provides ac￾cessor methods such as getDeclaredMethod() in line 6 and getField in line 8 to allow the other metaobjects (e.g., of Method and Field) related to a Class object to be introspected. With dynamic invocation, a Method object can be commanded to invoke the method that it represents (line 7) and a Field object can be commanded to access the field that it represents (lines 9 and 10). As far as pointer analysis is concerned, we can divide the pointer-affecting methods in the Java reflection API into three categories: (1) entry methods, e.g., forName() in line 3, for creating Class objects, (2) member-introspecting methods, e.g., getDeclaredMethod() in line 6 and getField() in line 8, for retrieving Method (Constructor) and Field objects from a Class object, and (3) side-effect methods, e.g., newInstance(), invoke(), get() and set() in lines 4, 7, 9 and 10, that affect the pointer information in the program reflectively. Class provides a number of accessor methods for introspecting methods, constructors and fields in a target class. Unlike [4, 8], Elf is the first to handle all such accessor methods in reflection analysis. Let us recall the four on return￾ing Method objects. getDeclaredMethod(String, Class[]) returns a Method object that represents a declared method of the target Class object with the name (formal parameter types) specified by the first (second) parameter (line