domain H rather than a string in S.We have done the same for method/field names in MTDDECL,FLDDECL,PUBLICMTD and PUBLICFLD. MTDDECL records all methods and their declaring classes and FLDDECL records all fields and their declaring classes.To find the metaobjects returned by getMethod()and getField(),PUBLICMTD matches a public target method m named mName in a class of type type,its superclasses or its interfaces searched in that order (as discussed in Section 2.1)and PUBLICFLD does the same for fields except that type's interfaces are searched before type's superclasses. The last four input relations record four different types of heap objects cre- ated.NEwINSTANCEHEAP relates the heap objects created at newInstance()calls with their class types.TYPE-CLASSHEAP,MTD-MTDHEAP and FLD-FLDHEAP re- late all the classes,methods and fields in the (closed-world)program to their metaobjects (i.e.,Class,Method and Field objects),respectively. When working with a pointer analysis,ELF both uses and modifies the four output relations recording the results of the pointer analysis.VARPoINTsTo and FLDPoINTSTo maintain the points-to relations and CALLGRAPH encodes the call graph of the program.As in 4,REFCALLGRAPH is used to record the potential callees resolved from a call to invoke().The second argument of invoke()is an array containing the arguments of its target calls;special handling is needed to assign these arguments to the corresponding parameters of its target methods. 4.2 Target Propagation We give seven target propagation scenarios corresponding to Labels 1-7 in Fig- ure 5 when both a target method/field name and its target class type are known. These rules (used later in Section 4.3)are standard except for getField()and getMethod().These two methods are ignored by Doop [4]but handled conser- vatively in [8,as shown in Table 2,with the target class of a target method/field ignored,causing the targets in all the classes in the program to be included. The syntax of a rule is easy to understand:""separates the inferred fact (i.e.,the head of the rule)from the preciously established facts (i.e.,the body of the rule).In Scenario P1,the rule for FoRNAME says that among all static invocation sites.record the calls to forName()in the FoRNAME relation.The rule for RESOLVEDCLASSTYPE records the fact that all such invocation sites with constant names are resolved.Note that const is a heap object representing"string constant".Meanwhile,the points-to and call-graph relations are updated.For each resolved class,its static initialiser"<clinit>()",at the callsite is discovered in case the class has never been referenced in the program. In Scenario P2,a newInstance()call is analyzed for each statically known class type pointed by clz.For such a type,a call to its default constructor "<init>()"is noted.In Scenario P3 for handling a getField()call,both the statically known field and all the known target classes pointed by clz,i.e.,fld- Name (a heap object representing "string constant")and type are considered. Similarly,a getMethod()call is handled in Scenario P6.Note that its second argument is ignored as discussed in Section 3.2.In Scenarios P4 and P5,calls to get()and set()are analyzed,respectively.Finally,in Scenario P7,an invoke()domain H rather than a string in S. We have done the same for method/field names in MtdDecl, FldDecl, PublicMtd and PublicFld. MtdDecl records all methods and their declaring classes and FldDecl records all fields and their declaring classes. To find the metaobjects returned by getMethod() and getField(), PublicMtd matches a public target method m named mName in a class of type type, its superclasses or its interfaces searched in that order (as discussed in Section 2.1) and PublicFld does the same for fields except that type’s interfaces are searched before type’s superclasses. The last four input relations record four different types of heap objects cre￾ated. NewInstanceHeap relates the heap objects created at newInstance() calls with their class types. Type-ClassHeap, Mtd-MtdHeap and Fld-FldHeap re￾late all the classes, methods and fields in the (closed-world) program to their metaobjects (i.e., Class, Method and Field objects), respectively. When working with a pointer analysis, Elf both uses and modifies the four output relations recording the results of the pointer analysis. VarPointsTo and FldPointsTo maintain the points-to relations and CallGraph encodes the call graph of the program. As in [4], RefCallGraph is used to record the potential callees resolved from a call to invoke(). The second argument of invoke() is an array containing the arguments of its target calls; special handling is needed to assign these arguments to the corresponding parameters of its target methods. 4.2 Target Propagation We give seven target propagation scenarios corresponding to Labels 1 – 7 in Fig￾ure 5 when both a target method/field name and its target class type are known. These rules (used later in Section 4.3) are standard except for getField() and getMethod(). These two methods are ignored by Doop [4] but handled conser￾vatively in [8], as shown in Table 2, with the target class of a target method/field ignored, causing the targets in all the classes in the program to be included. The syntax of a rule is easy to understand: “←” separates the inferred fact (i.e., the head of the rule) from the preciously established facts (i.e., the body of the rule). In Scenario P1, the rule for ForName says that among all static invocation sites, record the calls to forName() in the ForName relation. The rule for ResolvedClassType records the fact that all such invocation sites with constant names are resolved. Note that const is a heap object representing “string constant”. Meanwhile, the points-to and call-graph relations are updated. For each resolved class, its static initialiser “<clinit>()”, at the callsite is discovered in case the class has never been referenced in the program. In Scenario P2, a newInstance() call is analyzed for each statically known class type pointed by clz. For such a type, a call to its default constructor “<init> ()” is noted. In Scenario P3 for handling a getField() call, both the statically known field and all the known target classes pointed by clz, i.e., fld￾Name (a heap object representing “string constant”) and type are considered. Similarly, a getMethod() call is handled in Scenario P6. Note that its second argument is ignored as discussed in Section 3.2. In Scenarios P4 and P5, calls to get() and set() are analyzed, respectively. Finally, in Scenario P7, an invoke()