Note that the set()call that appears in line 290 in Figure 9 cannot be handled by the prior analyses [4,8,20]since getDeclaredFields()is ignored. This code pattern appears one more time in line 432 in the same class,i.e., org.eclipse.osgi.util.NLS.These two set()calls are used to initialize all non-final static fields in four classes(by writing a total of 276 fields each time). Based on target inference,ELF has found all the target fields accessed precisely. Scenario I3:Fieldll fs1 clz.getDeclaredFields():f2=fs2 f1.set(obj,val): VARPOINTSTo(fI,fdHeap)+ SET(invo,f1),VARPOINTSTo(f1,phHeap):MEMBERPH(getDecInvo,clzType,phHeap), GETDECLAREDFIELDS(getDecInvo,)ACTUALARC(invo,2,val),VARPOINTSTo(val,valHeap), HEAPTYPE(valHeap,type),AssICNABLE(AldType,type). FLDDECL(clzType,,fdType,Ad),FLD-FLDHEAP(fd,fdHeap). Scenario 14:Method ml=clz.getMethod(?,params);a=m2.invoke(obj,args). Let us consider a real case from Eclipse4 in Figure 10.In line 174,the Class ob- jects on which getMethod()is invoked can be deduced from the types of the ob- jects pointed to by target but cmd is read from input.Thus,in line 174,method is unknown even though its target class is known.Note that parameters is explic- itly initialized to {this}in line 155.As the type FrameworkCommandInterpreter has not subtypes,we conclude that the corresponding parameter of each poten- tial target method must have this type or one of its supertypes. Application:Eclipse(v4.2.2): Class:org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter 123 public Object execute(String cmd){.. 155 object[parameters new object[{this};... 167 for(int i=0;i<size;i++){ 174 method =target.getclass().getMethod("_"+cmd,parameterTypes); 175 retval method.invoke(target,parameters);...}} Fig.10.Target inference based on the dynamic types of parameters in invoke(). As explained in Section 3.2,we have relied on an intraprocedural analysis to perform the inference when args can be analyzed exactly element-wise as is the case in Figure 10.The MATCHARGs(args,mtd)relation over V x M maintains target methods mtd found from args this way. Scenario I4:Method mI clz.getNethod(?,params):a m2.invoke(obj,args); VARPOINTSTo(mI,phHeap)+ GETMETHOD(getInvo,clz),ACTUALARC(getInvo,1,arg),VARPOINTSTo(arg,strHeap), -MTDDECL(_,strHeap,_),VARPOINTSTo(clz,clzHeap),TYPE-CLASSHEAP(type,clzHeap), MEMBERPH(getInvo,type,phHeap):ACTUALRETURN(getInvo,mI). VARPOINTSTo(m2,mtdHeap) INVOKE(invo,m2),VARPOINTSTo(m2,phHeap),MEMBERPH(getInvo,type,phHeap), GETMETHOD(get/nvo,).PUBLICMTD(type,,mtd),ACTUALARC(invo,2,args), MATCHARCs(args,mtd),MTD-MTDHEAP(mtd,mtdHeap). Let us now look at the rules given in Scenario I4 where clz points to statically known class,type,but the target methods at invoke()are unknown,just like the the case illustrated in Figure 10.In the first rule applied to getMethod(), MTHDECL(,strHeap,,)does not hold,since strHeap is not a constant.AsNote that the set() call that appears in line 290 in Figure 9 cannot be handled by the prior analyses [4, 8, 20] since getDeclaredFields() is ignored. This code pattern appears one more time in line 432 in the same class, i.e., org.eclipse.osgi.util.NLS. These two set() calls are used to initialize all non-final static fields in four classes (by writing a total of 276 fields each time). Based on target inference, Elf has found all the target fields accessed precisely. Scenario I3: Field[] fs1 = clz.getDeclaredFields(); f2 = fs2[i]; f1.set(obj, val); VarPointsTo(f1, fldHeap) ← Set(invo, f1), VarPointsTo(f1, phHeap), MemberPh(getDecInvo, clzType, phHeap), GetDeclaredFields(getDecInvo, _), ActualArg(invo, 2, val), VarPointsTo(val, valHeap), HeapType(valHeap, type), Assignable(fldType, type), FldDecl(clzType, _, fldType, fld), Fld-FldHeap(fld, fldHeap). Scenario I4: Method m1=clz.getMethod(?, params); a=m2.invoke(obj, args). Let us consider a real case from Eclipse4 in Figure 10. In line 174, the Class ob￾jects on which getMethod() is invoked can be deduced from the types of the ob￾jects pointed to by target but cmd is read from input. Thus, in line 174, method is unknown even though its target class is known. Note that parameters is explic￾itly initialized to {this} in line 155. As the type FrameworkCommandInterpreter has not subtypes, we conclude that the corresponding parameter of each poten￾tial target method must have this type or one of its supertypes. Application:Eclipse(v4.2.2): Class:org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter 123 public Object execute(String cmd){... 155 Object[] parameters = new Object[]{this}; ... 167 for(int i=0; i<size; i++) { 174 method = target.getClass().getMethod("_"+cmd, parameterTypes); 175 retval = method.invoke(target, parameters); ...}} Fig. 10. Target inference based on the dynamic types of parameters in invoke(). As explained in Section 3.2, we have relied on an intraprocedural analysis to perform the inference when args can be analyzed exactly element-wise as is the case in Figure 10. The MatchArgs(args, mtd) relation over V × M maintains target methods mtd found from args this way. Scenario I4: Method m1 = clz.getMethod(?, params); a = m2.invoke(obj, args); VarPointsTo(m1, phHeap) ← GetMethod(getInvo, clz ), ActualArg(getInvo, 1, arg), VarPointsTo(arg, strHeap), ¬MtdDecl(_, strHeap, _, _), VarPointsTo(clz, clzHeap), Type-ClassHeap(type, clzHeap), MemberPh(getInvo, type, phHeap), ActualReturn(getInvo, m1). VarPointsTo(m2, mtdHeap) ← Invoke(invo, m2), VarPointsTo(m2, phHeap), MemberPh(getInvo, type, phHeap), GetMethod(getInvo, _), PublicMtd(type, _, mtd), ActualArg(invo, 2, args), MatchArgs(args, mtd), Mtd-MtdHeap(mtd, mtdHeap). Let us now look at the rules given in Scenario I4 where clz points to statically known class, type, but the target methods at invoke() are unknown, just like the the case illustrated in Figure 10. In the first rule applied to getMethod(), MthDecl(_, strHeap, _, _) does not hold, since strHeap is not a constant. As