This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Problems fully resolving class names | ||
---|---|---|---|
Product: | java | Reporter: | Chris Webster <cwebster> |
Component: | Unsupported | Assignee: | issues@java <issues> |
Status: | CLOSED FIXED | ||
Severity: | blocker | ||
Priority: | P2 | ||
Version: | 3.x | ||
Hardware: | Sun | ||
OS: | Solaris | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
Chris Webster
2001-02-16 23:19:20 UTC
SourceElement.prepare() is documented as it should _prepare_ the data, not refresh them. I admit that there's no way how (through the OpenAPI) demand refresh of the java hierarchy data - I'll try to convert prepare() into refresh behaviour without introducing too much deadlocking. As for the second issue, <SourceElement, String> pair is not sufficient for typename resolution - you need at least <TargetClassElement, String>. The output is not sufficiently information-rich too, because the resolver may encounter ambiguity, or accessibility issues and the suggested return type does not provide the caller with enough information what went wrong during the resolution. Anyway - this may lead to an interesting discussion - would you mind posting your requiremeners to dev@openide.netbeans.org ? prepare() is now implemented in a different way. If the parsing subsystem notices that the source model is out of sync with the document (that includes unresolved identifiers in the model), it schedules a parse and returs waitable Task. After the task finishes, the source's contents have been parsed and validated, and identifiers should be resolved or unresolved. [010616] Verifed Resolved for 3.4.x or earlier, no new info since then -> closing. |