[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jdt-dev] org.eclipse.jdt.core.dom binding variables
|
On Thu, 2002-06-27 at 10:26, Olivier Thomann wrote:
>
> 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.
I didn't note it in my question but my classpath is valid and the
complete software system builds -- hence my surprise at the binding
problems. I will work on generating test cases and posting them to
Bugzilla. The cases are on 60KSLOC sized programs, but they are open
source so I can bundle up a zip and post a link from Bugzilla to my web
page or something similar (people get grumpy when you post 30Mbyte
attachments to Bugzilla).
> (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.
Ahhh, very helpful, and I am doing my work with jtd.core.dom, so that's
good news. What is the long term ties between jdt.core and jdt.core.dom
> Hope this help,
Very much so, thanks Olivier for the clarifications!
> Olivier Thomann
Tim Halloran
CMU