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.

Bug 9664 - Problems fully resolving class names
Summary: Problems fully resolving class names
Status: CLOSED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 3.x
Hardware: Sun Solaris
: P2 blocker (vote)
Assignee: issues@java
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-02-16 23:19 UTC by Chris Webster
Modified: 2007-09-26 09:14 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Webster 2001-02-16 23:19:20 UTC
Steps to reproduce:
1. Create Java Class say Jc
2. add via editor to Jc some member of the form:
   String mn;
3. retrieve class element via ClassElement.forName("Jc");
4. add via ClassElement (you can also do this using the
   New Field action under the Java source node) some member of the form: 
  String mn2;
   Use the following construction path 
   FieldElement fe = new FieldElement();
   fe.setType(Type.parse("String"));
   ...
5. execute the following ClassElementNode.getSource().prepare().waitFinished();

6. If you get invoke Type.getFullString on mn you will see java.lang.String but
for mn2 you will see String.

What should happen is that a type/identifier is inserted into the ClassElement
the type should be flagged as unresolved. When the parse occurs any type that is
unresolved should be fully qualified if possible. This would include changing
the fully qualified name of a class that is not resolved to a different package
because of a modification to an import statement (I didn't test what happens
when a fully qualified name of a parameter has already been resolved during a
parse but a change in import statements will not resolve the class to a
different package, obviously this would be important as well). 

*** related issue
 I have a need to have a resolution algorithm that will calculate the resolved
class name given a SourceElement and a proposed sourceString. The method
signature would be something like the method listed below. I may need to
implement this method, so I was wondering if this would be a worth inclusion
into the SourceElement open source class or does something like this already
exist.

   /**
    * This method will resolve the given source string against the current
    * set of import statements. The Identifier returned will be fully qualified
    * if the resolution is unambiguous. If the source string is   
    * ambiguous, this method will return a null identifier. This method throws
    * an IllegalArgumentException if the given source string is not a valid 
    * Java identifier.
    */
   public Identifier resolveSourceString(String sourceString);
Comment 1 Svata Dedic 2001-02-19 09:36:02 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 ?
Comment 2 Svata Dedic 2001-03-01 15:01:04 UTC
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.
Comment 3 Jan Becicka 2001-06-18 13:33:54 UTC
[010616] Verifed
Comment 4 Quality Engineering 2003-07-01 13:18:10 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.