Skip to main content

[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

Back to the top