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.
The most useful refactoring for me would be the ability to select some classes (or packages) and extract them into a new "Java Library" project, making the original project depend on the new project and managing any library dependencies etc. In an idea world there would be a really sophisticated version of this that could analyse dependencies within a project and suggest ways to refactor the project into sub-projects. For instance, up to now I've been building the client and server for my application within the same project (the client code has primarily been used to test the server functionality up to now), but now I want to move the client into a project of it's own to clean up the server build. Both the client and the server rely on some common network code though, so I'd like a refactoring that would analyse the dependencies and automatically create a shared "networking" sub-project, and the new "client" project, and set up the dependencies between them. Obviously this couldn't be completely automated and would probably need a fairly sophisticated interface to allow you to juggle dependencies around (for instance there might be some network code that was only currently used by the server, and which the client code had no dependency on, but that really belongs in the network sub-project anyway - I should be able to manually add those classes to the sub-project). This is probably very ambitious, but I think it would rove to be extremely valuable.
Reassigning to java projects for evaluation since the requested functionality relates rather to java project support. In order to manipulate with java classes you can reuse existing java refactorings.