Table 2.Comparing ELF with the two closely-related reflection analyses [4,8]. Member-Introspecting ⑧ DooP 4 ELF Side-Effect Methods Methods ◆一◆一 getMethod invoke getDeclaredMethod getMethods n/a n a v n avv getDeclaredMethods n/a n/a v n/a vv getField get getDeclaredField set getFields n/a n/av n/a vv getDeclaredFields n/a n/a v n/a vv Vn/a√/n/aVn/aWn/a Propagation from them is implicitly performed.All the other methods available in Class for introspecting methods/fields/constructors are handled similarly. 3.3 ELF vs.Livshits et al.'s Analysis and Doop Table 2 compares ELF with Livshits et al.'s and Doop's analyses [4,8 in terms of how four representative side-effect reflective calls are resolved. Target Propagation ELF resolves a target method/field at a reflective callsite by requiring both its target class type (red circle)and its target name(blue circle)to be known.However,this is not the case in the other two analyses. In the case of Livshits et al.'s analysis,the target class type is always ignored. Therefore,the target methods/fields with a given name in all the classes in the program are conservatively included.Doop suffers the opposite problem by ignoring the target method/field names.As a result,all methods/fields in the target class are included.Finally,of the three analyses,ELF is the only one that can handle all the member-introspecting methods listed. Target Inference Of the three analyses,ELF is the only one to adopt a self inferencing principle to find the target classes and methods/fields at a reflec- tive callsite.Livshits et al.'s analysis narrows the type of reflectively-created objects at newInstance()in Figure 5,but Doop does not do this.However, Doop is more sophisticated than Livshits et al.'s analysis in distinguishing virtual,static and special calls and considering the modifiers of fields for loads and stores.These are all handled by the ELF reflection analysis. 4 Reflection Resolution We specify the reflection resolution in ELF as a set of Datalog rules,i.e.,mono- tonic logical inferences(with no negation in a recursion cycle),following the style of [6].The main advantage is that the specification is close to the actual imple- mentation.Datalog has been the basis of several pointer analysis tools [4,6,8, 21].Our rules are declarative:the order of evaluation of rules or examination of their clauses do not affect the final results.Given a program to be analyzed,these rules are repeatedly applied to infer more facts until a fixed point is reached.Table 2. Comparing Elf with the two closely-related reflection analyses [4, 8]. Side-Effect Methods Member-Introspecting [8] Doop [4] Elf Methods invoke getMethod √ √ √ √ √ getDeclaredMethod √ √ √ √ √ √ getMethods n/a n/a √ n/a √ √ getDeclaredMethods n/a n/a √ n/a √ √ getField √ √ √ √ √ get getDeclaredField √ √ √ √ √ √ set getFields n/a n/a √ n/a √ √ getDeclaredFields n/a n/a √ n/a √ √ newInstance √ n/a √ √ n/a √ n/a √ n/a Propagation from them is implicitly performed. All the other methods available in Class for introspecting methods/fields/constructors are handled similarly. 3.3 Elf vs. Livshits et al.’s Analysis and Doop Table 2 compares Elf with Livshits et al.’s and Doop’s analyses [4, 8] in terms of how four representative side-effect reflective calls are resolved. Target Propagation Elf resolves a target method/field at a reflective callsite by requiring both its target class type (red circle) and its target name (blue circle) to be known. However, this is not the case in the other two analyses. In the case of Livshits et al.’s analysis, the target class type is always ignored. Therefore, the target methods/fields with a given name in all the classes in the program are conservatively included. Doop suffers the opposite problem by ignoring the target method/field names. As a result, all methods/fields in the target class are included. Finally, of the three analyses, Elf is the only one that can handle all the member-introspecting methods listed. Target Inference Of the three analyses, Elf is the only one to adopt a self￾inferencing principle to find the target classes and methods/fields at a reflec￾tive callsite. Livshits et al.’s analysis narrows the type of reflectively-created objects at newInstance() in Figure 5, but Doop does not do this. However, Doop is more sophisticated than Livshits et al.’s analysis in distinguishing virtual, static and special calls and considering the modifiers of fields for loads and stores. These are all handled by the Elf reflection analysis. 4 Reflection Resolution We specify the reflection resolution in Elf as a set of Datalog rules, i.e., mono￾tonic logical inferences (with no negation in a recursion cycle), following the style of [6]. The main advantage is that the specification is close to the actual imple￾mentation. Datalog has been the basis of several pointer analysis tools [4, 6, 8, 21]. Our rules are declarative: the order of evaluation of rules or examination of their clauses do not affect the final results. Given a program to be analyzed, these rules are repeatedly applied to infer more facts until a fixed point is reached