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.
Performance test reports there is a NetBeans startup regression which is caused by the loading of the following classes: org.netbeans.modules.refactoring.java.CopyHandler org.netbeans.modules.refactoring.java.RefactoringModule Please don't load this class during NetBeans startup. Comment from jtulach: "Bug, imho. I see no reason why refactoring shall initialize anything on start, especially no CopyHandler, so I'd like to at least see an explanation."
Created attachment 70197 [details] Stacktraces
Misprint: Please don't load *these* *classes* during NetBeans startup.
This was introduced as a fix for issue #144640 - Copy classes to another package don't change the packages - which IMO is sever enough to justify a small performance penalty during startup. If nobody strongly objects (better yet provides a patch) I'm going to add these two classes to the whitelist.
http://hg.netbeans.org/main/rev/214e14334eef
I'd like to object. We know that refactoring wants to participate on the operations on files, however for that purpose Jan Bečička created hooks that get triggered when some action happen. Only then they are initialized, not during startup: http://bits.netbeans.org/dev/javadoc/org-openide-loaders/org/openide/loaders/FolderRenameHandler.html http://www.netbeans.org/issues/show_bug.cgi?id=53295 We want you to create similar APIs to fix also the issue #144640 and not invent new ModuleInstall tricks that load new Java classes on startup[1]. If you need deeper interaction with datasystems, feel free to enhance the APIs to suite you. If you want to fix this without an API change, you can rely on ExClipboard convertors. They will get triggered whenever one does Ctrl-C and Ctrl-V - still a bit too eager, but better than during startup. [1] In my personal view, I want this to be fixed, however I do not insist on have-to-fix for 6.5. I agree there are more important things to do to get 6.5 out of door.
I agree this should be fixed with a full copy refactoring support but not in NB 6.5. Issue 144640 is a temporary solution as it is mentioned in javadoc of CopyHandler http://hg.netbeans.org/main/rev/21b8ae9addc0. +/** + * This is a temporary solution to preserve old functionality of java data + * objects (disabled within #141093) until there will be full copy refactoring + * support (#74265) in the refactoring modules. + * + * The present implementation updates package and top level class declarations. FolderRenameHandler does not solve multi-selection of java files. I am not sure that investing time to ExClipboard convertors (another temporary solution) is worth time necessary to load 2 classes.
Ok, then I think we should send a waiver request and resolve this after 6.5 as part of the proper copy refactoring support. Agreed? If so, Honzo could you please send the waiver request? Thanks
Of course, the waiver requested.
Integrated into 'main-golden', will be available in build *200809231435* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/214e14334eef User: Vita Stejskal <vstejskal@netbeans.org> Log: #147849: updating the list of refactoring.java classes
no objections -> waiver approved
Integrated into 'main-golden', will be available in build *200810010201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/dcd31677aabd User: Alexander Kouznetsov <mrkam@netbeans.org> Log: Revert of 214e14334eef: '#147849: updating the list of refactoring.java classes' the issue is not fixed
Since the issue is not fixed I've removed classes from the whitelist: http://hg.netbeans.org/main/rev/dcd31677aabd
I think we have real P2s and P3s to fix for 6.7 especially after loosing Tomas and Lahvac.
Would be P4 if it was not a regression.
Resolving all issues with milestone "future" as LATER. If you feel strongly that it should be implemented please reopen and set the target milestone to "next".
NetBeans.org Migration: changing resolution from LATER to WONTFIX