Community
Participate
Working Groups
The current specification is very vague when this method returns null and when not. I expect the following behaviour: Types: - primitive types, including null and void: ==> null - for wildcard types: ==> null - for array types the Java element of the element type, or null if the element type is a primitive - for all other kind of types this method never returns null (even not for local and anonymous types inside a method) - for Raw type the Java element of the erasure - for Parameterized types the Java element of the erasure PackageBinding: - never returns null VariableBinding - never returns null since we have IJavaElements for locals.
Note: for parameterized types, getJavaElement() currently returns the unresolved type. We could consider returning the resolved type in such cases in order to be consistent with ICodeAssist#codeSelect(..) on a reference such as List<Integer> intList; I don't have a specific use case for this right now; just wanted to mention the difference before the specification is set in stone.
IVariableBinding#getJavaElement() should return null for an array's 'length' field (see bug 92059).
Revised the spec as follows. /** * Returns the Java element that corresponds to this binding. * Returns <code>null</code> if this binding has no corresponding * Java element. * <p> * For array types, this method returns the Java element that corresponds * to the array's element type. For raw and parameterized types, this method * returns the Java element of the erasure. * </p> * <p> * Here are the cases where a <code>null</code> should be expected: * <ul> * <li>primitive types, including void</li> * <li>null type</li> * <li>wildcard types</li> * <li>capture types</li> * <li>the "length" field of an array type</li> * <li>array types of any of the above</li> * </ul> * For all other kind of type, method, variable, and package bindings, * this method returns non-<code>null</code>. * </p> * * @return the Java element that corresponds to this binding, * or <code>null</code> if none * @since 3.1 */ public IJavaElement getJavaElement(); The implementation should be brought into line with this spec at the same time bug 92059 is addressed.
Integrated spec changes, and addressed bug 92059. I believe resolved elements make sense there two when applicable. Will not close this bug until this is resolved as well.
Changed implementation of getJavaElement() to return a resolved element when possible. Use isResolved() to check if it is resolved.
Verified for 3.1 M7 using build I20050509-2010 + jdt.core HEAD. (considering that ASTModelBridge tests all these cases and pass)
