Community
Participate
Working Groups
I20041216-2000 package p; class Bindings { java.util.List<URL> method(java.util.List<URL> list) { java.util.List<URL> url= new java.util.List<URL>(); return url; } } The ParameterizedType "java.util.List<URL>" sometimes has a binding, sometimes not. In the example above, all references to "java.util.List<URL>" have a generic binding for List<E>, except the method parameter type, which has a null binding. Up to now, bindings were either correct, or null iff not resolvable. I would expect to get null for all references to "java.util.List<URL>".
Do you have java.net.URL as an import? If not, it can make sense that the type cannot be resolved.
I added a regression test to check that all qualified names, simple names, qualified types, simple types and parameterized types have a binding if java.net.URL is resolved. Can you please confirm that this is your test case? If you don't import java.net.URL, you cannot expect all bindings to be resolvable.
Ok, looking at 81101, it seems that URL is not imported. Therefore we do the best we can to provide you with some bindings.
Kent, is it possible to get a binding for the method and for its parameters in this case if URL is not imported. The DOM/AST bindings cannot return any value for the parameter, because it has no compiler binding. Kent, why do we get a return type binding?
Because we check the parameter types first & fail. The parameter binding is null because it cannot be resolved. We did not bother to null out the return type's binding in this case but we can if you want us to... we don't need to for normal compilation.
Actually the MethodDeclaration's return type is a TypeReference (which knows about List). The MethodDeclaration's arguments are Argument nodes that know about the TypeReference (which knows about List). You have everything you need to answer List back in both cases.
ok, I take it back. Thanks.
Fixed and released in HEAD. The resolved type of the type reference was wrongly reset to null in the bind of argument. Therefore I didn't have the binding when converting the code. Added a regression test to check that all parameterized type returns a binding java.util.List<E>. Only the name for the method selector and occurences of URL don't have a binding.
Sorry, I was away and couldn't answer your questions in time. Unfortunately, the solution in HEAD does not match our expectations. As I said in comment 0, "java.util.List<URL>" should have 'null' as binding, and not 'List<E>' (without an import statement for "URL"). References to generic types should never be of kind #isGenericType(). Either a type binding should be correct, or it should be absent. Otherwise, it's getting hard to deal with code like "java.util.List<java.util.ArrayList<URL>>", where you never know what's really resolved and what's not.
If I nullify the binding in this case, it will also be null in cases where you want a binding to be returned. I can nullify the binding as soon as the binding is not a valid binding (problem bindings). But you will lose bindings in cases the code is illegal. From the binding resolver perspective, there is no difference.
For me this depends on clients: - refactoring: in allmost all cases refactoring isn't interrested in guessed bindings - quick fix: will be interested in guessed bindings. So I would opt for having a flag on ASTParser to control this. The default should be to not guess bindings.
We need a consistent way to get the binding. The resolved type is set to be a generic type binding and it is not tagged as an invalid binding. So I cannot fix it on the DOM/AST side if I don't have more information. It should either be a problem binding, or it should be null.
Compiler issue can be resolved in this case. I would propose that partial matches are nulled out (like here where no argument was bound), due to inconsistencies. But if non visible etc... it would remain connected. BTW - isn't the AST tagged with having problems anyway ?
We investigate if we can nullify the binding in the case. But it would be null all the time.
As said in #11 the behaviour should be controllable via a flag. Quick fix for example would be interested in this. Alternatively we can think about annotating the binding itself. But this might cause problems with existing clients which assume that null is returned from resolveBinding in the case it isn't accurate.
I support Dirks comment 15. 'Null' would hurt quick fix quite a lot. I would like to offer quick fixes for mismatching type parameters, e.g. too many or not enough type parameters, similar to mismatching method arguments. (remove type arguments, add type parameter to type...) In 'List<String, String>' having not even a binding to List would be tough. A generic binding is better than nothing, but what maybe would be a good idea is to attach some 'erasured' binding like List<Object> to it. To distiguish guessed bindings from correct bindings, would it maybe make sense to have a new API 'isGuessed' to IBinding? (or 'isProblemBinding').
The compiler doesn't always create problem bindings when it knows that the binding won't be used later. So for performance reason, I won't push to add an API for this. The actual behavior is acceptable for me.
Olivier, can you outline the performance problems and what you mean by "actual behaviour". The whole PR complains about the actual behaviour.
The performance problem is simple. In this case, the compiler doesn't need to carry the binding for invalid type. Creating a problem binding each time such a case occurs would penalize the compiler. I can change the actual behavior to get a binding for all occurences of java.util.List<URL>. But I cannot get null for all occurrences in one case and not null in the other case. For your information, the binding I am getting is not a problem binding. So from the converter point of view, I cannot make the distinction between a valid binding and this invalid case.
Ok, I'll do what Philippe suggests in comment 13. If the argument cannot be resolved, the dom binding will always be null. If this is simply a visibility issue, then a binding will be returned. This would make the resolution of java.util.List<URL> consistent in all cases.
Fixed and released in HEAD. Regression test added in ASTConverter15Test.test0138.
Need further investigation.
In HEAD right now, the binding is always the generic type java.util.List<E>. Is this ok for you? If yes, I would close this one.
This is good from the quick fix side.
The current solution conflicts with bug 80472. When I get a generic binding, I don't know whether it's generic because of bug 80472 or because type arguments could not be resolved. I think we can ship 3.1 with the current solution, but this should definitely be discussed again for 3.2.
Because URL cannot be resolved, we end up with a generic type binding. The point of this PR was that the resolution was inconsistent. This is not the case anymore.
OK to close this bug then. Will use bug 84585 for further discussions about partly unresolved bindings.
Close as WORKSFORME. Regression test is org.eclipse.jdt.core.tests.dom.ASTConverter15Test.test0138. A fix has been done for another problem. No specific changes for this PR.
I had to adjust a regression test for this bug when fixing bug 230127, because you can only get a binding for URL in java.util.List<URL>, if the binding recovery is on.
