If certain types of methods exist in the analysed project, then the initialization of the iFL session fails with an unexpected error and exception.
Steps
Select a project.
Start an iFL session using any of the available options (icon, menu or key shortcut).
Expected behavior
Given the following code:
package test;
import java.util.Collection;
public class Bar {
public static <T> T foo(T arg) {
return arg;
}
public static <T extends CharSequence> T foo(T arg) {
return arg;
}
public static <T extends Collection<?>> T foo(T arg) {
return arg;
}
}
The plugin should recognize the method erasures correctly. The expected list of methods is (in accordance with the naming scheme used in Java byte-code):
Workaround:
After method binding the correct method signatures are available, therefore a possible solution is to replace/extend the getSignature method with the following code:
Field bindingField = method.getClass().getDeclaredField("binding");
bindingField.setAccessible(true);
Object binding = bindingField.get(method);
Field signatureField = binding.getClass().getDeclaredField("signature");
signatureField.setAccessible(true);
String paramsAndReturn = new String((char[]) signatureField.get(binding));
If certain types of methods exist in the analysed project, then the initialization of the iFL session fails with an unexpected error and exception.
Steps
Expected behavior Given the following code:
The plugin should recognize the method erasures correctly. The expected list of methods is (in accordance with the naming scheme used in Java byte-code):
test.Bar.foo(Ljava/lang/Object;)Ljava/lang/Object;
test.Bar.foo(Ljava/lang/CharSequence;)Ljava/lang/CharSequence;
test.Bar.foo(Ljava/util/Collection;)Ljava/util/Collection;
However, all methods are recognized as
test.Bar.foo(TT;)TT;
and hence iFL is not able to distinguish them.The upper bounds of the generic types are just for the sake of the example. The behavior should not/does not change if other types are used.
Screenshots
Environment:
Additional context
Workaround: After method binding the correct method signatures are available, therefore a possible solution is to replace/extend the
getSignature
method with the following code: