pointed by cName,mName and fName if statically known)along the solid lines into the points symbolized by circles.Note that the second argument of getMethod()is an array of type Class[].It may not be beneficial to analyze it to disambiguate overloaded methods.because (1)its size may be statically unknown,(2)its components are collapsed by the pointer analysis, and(3)its components may be Class objects with unknown class names. Target Inference (Marked by Dashed Arrows)By using Target Propaga- tion alone,a target method/field name (blue circle)or its target class type (red circle)at a reflective callsite may be missing.i.e..unknown,due to the presence of input-dependent strings(Figure 4).If the target class type(red circle)is missing,ELF will infer it from the dynamic type of the target ob- ject o (obtained by pointer analysis)at invoke(),get()or set()(when o !=null)or the downcast (if any),such as (A),that post-dominantly op- erates on the result of a call to newInstance().If the target method/field name (blue circle)is missing,ELF will infer it from (1)the dynamic types of the arguments of the target call,e.g.,{...of invoke()and a of set(), and/or(2)the downcast on the result of the call,such as (A)at invoke() and get().Just like getMethod,the second argument of invoke()is also an array,which is also similarly hard to analyze statically.To improve precision, we disambiguate overloaded target methods with a simple intraprocedural analysis only when the array argument can be analyzed exactly element-wise. To balance soundness,precision and scalability in a disciplined manner,ELF adopts the following inference principle:a target method or field is resolved at a reflective callsite if both its target class type (red circle)and its target method/- field name (blue circle)can be resolved (i.e.,statically discovered)during either Target Propagation or Target Inference.As a result,the number of spurious tar- gets introduced when analyzing a reflective call,invoke(),get()or set(),is minimized due to the existence of two simultaneous constraints (the red and blue circles).How to relax ELF in the presence of just one such a constraint will be investigated in future work.Note that the cast operations on newInstance() will still have to be handled heuristically as only one of the two constraints exists. As ELF is unsound,so is the underlying pointer analysis.Therefore,a reflective callsite is said to be resolved if at least one of its targets is resolved. Let us illustrate Target Inference by considering r=(A)F.get(o)in Fig- ure 5.If a target field name is known but its target class type (i.e.,red circle) is missing,we infer it by looking at the types of all pointed-to objects o'by o. If B is the type of o',then a potential target class of o is B or any of its super- types.If the target class type of F is B but a potential target field name (i.e., blue circle)is missing,we can deduce it from the downcast (A)to resolve the call to r =o.f,where f is a member field in B whose type is A or a supertype or subtype of A.A supertype is possible because a field of this supertype may initially point to an object of type,say,A and then downcast to A. In Figure 5,if getMethods()(getFields())is called at Label 6(Label 3) instead,then an array of Method(Field)objects will be returned so that Targetpointed by cName, mName and fName if statically known) along the solid lines into the points symbolized by circles. Note that the second argument of getMethod() is an array of type Class[]. It may not be beneficial to analyze it to disambiguate overloaded methods, because (1) its size may be statically unknown, (2) its components are collapsed by the pointer analysis, and (3) its components may be Class objects with unknown class names. Target Inference (Marked by Dashed Arrows) By using Target Propaga￾tion alone, a target method/field name (blue circle) or its target class type (red circle) at a reflective callsite may be missing, i.e., unknown, due to the presence of input-dependent strings (Figure 4). If the target class type (red circle) is missing, Elf will infer it from the dynamic type of the target ob￾ject o (obtained by pointer analysis) at invoke(), get() or set() (when o != null) or the downcast (if any), such as (A), that post-dominantly op￾erates on the result of a call to newInstance(). If the target method/field name (blue circle) is missing, Elf will infer it from (1) the dynamic types of the arguments of the target call, e.g., {...} of invoke() and a of set(), and/or (2) the downcast on the result of the call, such as (A) at invoke() and get(). Just like getMethod, the second argument of invoke() is also an array, which is also similarly hard to analyze statically. To improve precision, we disambiguate overloaded target methods with a simple intraprocedural analysis only when the array argument can be analyzed exactly element-wise. To balance soundness, precision and scalability in a disciplined manner, Elf adopts the following inference principle: a target method or field is resolved at a reflective callsite if both its target class type (red circle) and its target method/- field name (blue circle) can be resolved (i.e., statically discovered) during either Target Propagation or Target Inference. As a result, the number of spurious tar￾gets introduced when analyzing a reflective call, invoke(), get() or set(), is minimized due to the existence of two simultaneous constraints (the red and blue circles). How to relax Elf in the presence of just one such a constraint will be investigated in future work. Note that the cast operations on newInstance() will still have to be handled heuristically as only one of the two constraints exists. As Elf is unsound, so is the underlying pointer analysis. Therefore, a reflective callsite is said to be resolved if at least one of its targets is resolved. Let us illustrate Target Inference by considering r = (A) F.get(o) in Fig￾ure 5. If a target field name is known but its target class type (i.e., red circle) is missing, we infer it by looking at the types of all pointed-to objects o 0 by o. If B is the type of o 0 , then a potential target class of o is B or any of its super￾types. If the target class type of F is B but a potential target field name (i.e., blue circle) is missing, we can deduce it from the downcast (A) to resolve the call to r = o.f, where f is a member field in B whose type is A or a supertype or subtype of A. A supertype is possible because a field of this supertype may initially point to an object of type, say, A and then downcast to A. In Figure 5, if getMethods() (getFields()) is called at Label 6 (Label 3) instead, then an array of Method (Field) objects will be returned so that Target