Created attachment 1754 [details]
Test file that contains a method whose return type is another class contained in the package

Created attachment 1756 [details]
2nd Test file (this class is used as a return type for a method defined in Test1)

Created attachment 1757 [details]
Test app used to print out MethodElement info

Sorry, worksforme. I've tried exactly the reproduction steps (including order 
of file creation) in both production and debugging environment - it worked as 
expected. 
I noticed that your reproduction algorithm does not mention the confirmation 
dialog which is displayed after package rename (something like "You've renamed 
package blah to foo, do you want to update package declarations ?"). I assume 
that you've answered "yes".
From the debug traces, it seems that during the package decl update all 
necessary changes are detected and fired as property change events (package 
decl, class name, method return type).

Oops, worksforme in dev trunk; will test further on 3.2 release.

Verified worksforme on 3.2 release. Both "old" element and "new" element 
output shows updated information.

I just did a new test and found that there was a problem even
before renaming the package. What I did was:

* Create a new package, 'a';
* Select package 'a' node, display pop up, select New->Classes->Interface
* Enter name 'Tst1'
* Finish dialog
* Tst1.java displayed in editor.
* Add this method:
     public Tst2 aMethod (int i);
* Save the file and close editor
* Select package 'a' node again, display pop up, select New->Classes->Interface
* Enter name 'Tst2'
* Finish dialog
* Tst2.java displayed in editor
* Add this method:
     public java.lang.String tst2Method (boolean b);
* Save the file and close editor
* Run MethodTest test program again
* In JTextField, enter 'a.Tst1'
* Output shows:
  Method found:  Name: aMethod 
                             Return Type Full String: Tst2 
                             Return Type Source String: Tst2 
                             Return Type Full Name: Tst2 
                             Return Type Res Status: 2 
* Full name should be a.Tst2 and status shows not yet resolved.
* Compile package a, run MethodTest again, same output
* Couldn't seem to do anything to get the return type
  identifier 'resolved'.

Btw, this is using my own build of FFJ, both open and closed
sources updated  6/26/01,  around 8:00 AM PDT.

Svata, what platform are you testing this on? I just
checked and I cannot reproduce this problem on Win-NT,
but on my Solaris machine, I can faithfully reproduce
it. Btw, I'm running Solaris 7, but someone running
Solaris 8 can also reproduce it.

FYI - I'm usually working on a Linux RH-7.1, KDE-2.1

I don't know whether the later comment is relevant to the reported issue; 
however the second testcase works _as designed_ although it may seem strange. 
Here's why:
1. The source is parsed if and only if the both the following conditions are 
true:
a) someone requests parsing using parse() operation
b) parsed data are marked "dirty" or the parse operation is invoked with 
"force" flag.

2. The framework dirties parser data every time the document is modified, or 
the source file is changed externally. 
3. If the document is opened, java module schedules a task, delayed for 2 
seconds, which will invoke parse(force = false).
4. parse(force = true) is called when the document is reloaded, discarded 
without saving changes
5. parse(force = false) is called when the document is read into memory and 
when it is saved to the disk.
6. parse() is called when somebody calls getClasses(), getPackage() or 
getImports() on a source, which does not have any parsing information 
associated (or they were GCed).

No other parsing actions are done automatically by the basic IDE.

So - after you finish working with 'Tst1', the method's return type is still 
unresolved, because 'Tst2' does not exist yet.
Even though you create 'Tst2' later, you don't seem to change Tst1 in a way 
which would trigger the parser. So, the metadata remain untouched.

As a test, you could modify 'Tst1' and wait for 2 seconds; the parser should 
report resolve the type name and fire appropriate change events.
Another approach is to use interface (not an official API)
	org.netbeans.modules.java.parser.JavaParser
to trigger/force parsing programmatically.

I was able to reproduce this problem using Windows well, try the following:
1. create new package p1
2. create new class t
package p1;

public class t {
    public t() {
    }
}
3. create new class t1
package p1;

public class t1 {
    public t1() {
    }
}   
4. add to t1 public t tst(t v){return null;}
5. add to t public t1 tst(t1 v) {return null;}
6. Save all
7. Rename package to p2, answer yes to changing package declarations
8. Expand the class element node for t and open property sheet for tst method
9. Open Parameters custom property editor, as you can see the full qualified 
name of the parameter is p1.t1 which is incorrect, it should now be p2.t1
 

Svata, Chris is right. I've tested it on [010716_1] and it really 
works as Chris have described above.

Uff. After all, it seems that after package declaration change, the 
source needs to be reparsed unconditionally just to revalidate all 
unqualified identifiers within.
I fear that it will greatly slow down copy/move to another package 
and the results won't be what you're expecting but that's the way to 
go :-(

Fixed in dev-trunk.

[200110050100] Verified

Resolved for 3.4.x or earlier, no new info since then -> closing.