Community
Participate
Working Groups
Build Identifier: I20100608-0911 [also reported in JDT Forum, message #639249] I am using JDT in batch mode as a parser that resolves bindings (thank for it). In the resulting AST built by the JDT Parser, accesses to the "length" attribute of an array is a FieldAccess ASTNode (which is perfectly ok) If I get the binding of this node (node.resolveFieldBinding()) I get an IVariableBinding. Now if I do a getDeclaringClass() on this binding, the result is null. The problem is, how do I know that the 'null' does not come from a missing binding (some problem in the parsing), but from the fact that this is an array's attribute? Reproducible: Always Steps to Reproduce: 1.Import the project attached to this bug report 2.Run the class BugParser on itself (inside eclipse or outside it: "java BugParser BugParser") 3.A message appears on the console when the bug is discovered in the AST Visitor
Created attachment 183206 [details] An Eclipse Java Project exemplifying the bug As explained in the bug report, this is a Java project that exemplifies the bug. The sole class is a JDT batch parser that when run on itself (when analyzing its own code) shows that the "length" attribute used in the method "performCompilation()" results in a IVariableBinding that has no DeclaringClass
Probably not significant, but the bug was found on a MacBook Pro (a Macintosh therefore) but running Ubuntu 10.10, not MacOS
The compiler usually returns a ProblemBinding in cases where there was a parsing error / invalid construct, etc. It definitely wont return null in such cases. Also, in this case, I'm not sure what else can the compiler return as a binding from getDeclaringClass(). Srikanth, whats your take?
This is the expected behavior. See the javadoc on org.eclipse.jdt.core.dom.IVariableBinding.getDeclaringClass() Also see https://bugs.eclipse.org/bugs/show_bug.cgi?id=14322#c3 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=9016#c2
I would also add that you should not use internal code inside your own code. That code can change from release to release. You can easily use DOM/AST API without referring to internal compiler code.
