Community
Participate
Working Groups
I20050112-1200 + jdt.core v531a - p/A.java: package p; enum A { ONE, TWO, THREE } - p/Client.java: package p; import static p.A.ONE; // resolveBinding() returns null public class Client { Object o= ONE; }
This should work. I am investigating.
When I create the AST using ICompilationUnit#reconcile(..) (ASTView 1.0.2: View Menu > Use Reconciler), I get wrong bindings: All nodes below (and including) the ImportDeclaration resolve to an ITypeBinding for p.A. Expected: - the ImportDeclaration and the SimpleName for "ONE" resolve to an IVariableBinding for p.A.ONE - "p.A" and "A" resolve to ITypeBinding for p.A - "p" resolves to an IPackageBinding for p
I agree that in this case I would expect the same result. The javadoc of the resolveBinding() method on ImportDeclaration needs to be updated to cover the static import cases. Right now it is right not to return a IVariableBinding, because it is only suppose to return either a package binding or a type binding. For static imports, this method could return: - variable binding - type binding - package binding. The method binding case is problematic since there is not enough information to know what method binding it should return if the corresponding class has more than one method with the same selector. In this case, I suggest to return null, since any answer we can return will never help the user. The right method binding is determined when the method is invoked. Jim, I let you update the javadoc and I will take care of the implementation once you are done.
For the method case, we can return a method binding, but without any garantee that this is the only one. It would simply say that the import resolves to a method.
Just to clarify, the onDemand case, in 1.4 we could also have a type binding. The following code is perfectly valid. import p.A.*; public class X { public Object foo() { return new B(); } } ------------------------------------------------ package p; public class A { public static class B {} } import p.A.*; is not a static import. It is an import on demand that would resolve to a type binding. I don't think this case is covered by the actual specs of ImportDeclaration.resolveBinding()
I've changed the spec to cover the static import cases, and clarified the possible returns for on-demand imports: /** * Resolves and returns the binding for the package, type, field, or * method named in this import declaration. * <p> * The name specified in a non-static single-type import can resolve * to a type (only). The name specified in a non-static on-demand * import can itself resolve to either a package or a type. * For static imports (introduced in JLS3), the name specified in a * static on-demand import can itself resolve to a type (only). * The name specified in a static single import can resolve to a * type, field, or method; in cases where the name could be resolved * to more than one element with that name (for example, two * methods both named "max", or a method and a field), this method * returns one of the plausible bindings. * </p> * <p> * Note that bindings are generally unavailable unless requested when the * AST is being built. * </p> * * @return a package, type, field, or method binding, or <code>null</code> * if the binding cannot be resolved */ public IBinding resolveBinding() {
Some cases where a static import can resolve to either a field or a method are not supported yet in the compiler. But the support from the DOM/AST perspective is there. Fixed in HEAD. Regression test added in ASTConverter15Test.test0103. test0104 is disabled until the support in the compiler is fine.
Also added a regression test in ASTConverterTestAST3_2.test0595.
Verified in I20050215-2300
