Created attachment 27421 [details]
stack-trace

This seems to be caused by special combination of source files. Can you provide steps and source files to 
reproduce it? Thanks.

Dang, I knew this one would bite me in the ass :) I got this stack-trace while
compiling but I don't remember the exact source files. When you compile the
entire project, how do you find one which one of the files is the one triggering
the error?

Closing as INVALID. I haven't seen this since trying a fresh userdir.

I can reproduce this again. I get this exception and I try cut/pasting a class
in explorer from one package to another. I've attached the offending Java file.

Created attachment 27530 [details]
Offending file

I was trying to move ContentTypeDAOImpl from package
desktopbeautifier.server.dao.impl to package desktopbeautifier.dao.impl but it
turns out that ContentTypeDAOImpl already existed in that package, from another
project. I am expecting Netbeans to give me a clearer error message explaining
why the move operation is illegal.

I renamed the file to avoid a namespace collision. Next, I had to rename some
import statements which pointed to nonexistant classes (if I didn't I would get
yet another sort of exception). Next, I noticed that the interface that
ContentTypeDAOImpl.java "implemented" happened to have a namespace collision of
its own. That is, I had two interfaces with identical names in two different
packages (one dependant on the other). So I renamed the interface. I also
noticed a cyclical depencency in that interface (since both interfaces had the
same name) so I fixed it.

Now... once this was all done I could move ContentTypeDAOImpl.java without
getting an exception. So in a nutshell here is what I think the code needs to do:

1) Check for preexisting cyclical dependencies not only in the class being moved
but also in its dependencies

2) Check for namespace collisions when scanning the classpath. This is only
relevant if project A depends on project B and both declare a class/interface in
the exact same namespace.

3) If a move operation would cause namespace collision or cyclical dependencies
warn the user and abort the operation.

Yes, StackOverflowError can be caused by cyclic dependencies in your interfaces. 

Ok, so can you try adding some of the checks I mentioned? I am especially
interested in the check for namespace collision across projects since that is
harder to notice manually.

Javacore module was replaced by Retouche infrastructure. This bug is not valid
in trunk any more.

Reorganization of java component