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.
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);
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.