Re: [jdt-dev] org.eclipse.jdt.core.dom binding variables

["Olivier Thomann" <Olivier_Thomann@xxxxxxx>]

Hi,

(1) Does a description of the limitations or behavior of "binding"
exist? I am noting that sometimes package names in import statements
don't resolve (e.g., I get null). In addition sometimes when I examine a
AST almost nothing binds (I have been examining code like Jakarta Ant
and Jakarta Tomcat so out of thousands of files one or two isn't bad:).
Are there known limits or should I file bugs? I did file one bug where a
method was generating a null pointer exception, see:

To reply to your first question, I would say that the bindings should not
be null if the corresponding project's classpath is well set. The
resolution of the bindings uses the bindings from the compiler's ast nodes.
These nodes are not API on purpose. If the compiler's bindings cannot be
created, it should mean something's wrong in the classpath settings or the
DefaultBindingResolver cannot reach the proper compiler's bindings. This
latter case is a bug in the DOM/AST implementation.
So the best you can do to help us solving this issue is to file a bug
trying to give us a reproducable test case. This is very important. Without
a test case, it will be very difficult to track down the bug.

(2) Is jdt.core.jdom built on top of jdt.core.dom? Can you get to the
underlying jdom model?  I guess this is a general question trying to
understand the relationship between the high-level sorta global model in
jdt.core the AST model in jdt.core.dom and the model in jtd.core.jdom.

My understanding is that the jdt.core.jdom should be deprecated to be
replaced by the jdt.core.dom API as soon as the serialization from the AST
to a source file will be fully implemented. This is something we will need
to work on post 2.0. The current implementation of jdt.core.jdom has
several limitations, which reduced its usage. For example, multiple field
declarations are not properly handled. This is much nicer in jdt.core.dom.

Hope this help,

Olivier Thomann