Bug 147849 - Performance startup regression: org.netbeans.modules.refactoring.java
Performance startup regression: org.netbeans.modules.refactoring.java
Status: RESOLVED WONTFIX
Product: java
Classification: Unclassified
Component: Refactoring
6.x
All All
: P3 (vote)
: 6.x
Assigned To: issues@java
issues@java
http://wiki.netbeans.org/FitnessViaWh...
: PERFORMANCE, REGRESSION, TEST
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-22 11:08 UTC by Alexander Kouznetsov
Modified: 2009-11-02 11:14 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Stacktraces (3.04 KB, text/plain)
2008-09-22 11:09 UTC, Alexander Kouznetsov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Kouznetsov 2008-09-22 11:08:19 UTC
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."
Comment 1 Alexander Kouznetsov 2008-09-22 11:09:19 UTC
Created attachment 70197 [details]
Stacktraces
Comment 2 Alexander Kouznetsov 2008-09-22 11:11:09 UTC
Misprint: Please don't load *these* *classes* during NetBeans startup.
Comment 3 Vitezslav Stejskal 2008-09-22 14:00:46 UTC
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.
Comment 4 Vitezslav Stejskal 2008-09-22 14:13:51 UTC
http://hg.netbeans.org/main/rev/214e14334eef
Comment 5 Jaroslav Tulach 2008-09-22 16:16:37 UTC
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.
Comment 6 Jan Pokorsky 2008-09-22 18:45:06 UTC
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.
Comment 7 Vitezslav Stejskal 2008-09-23 12:02:41 UTC
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
Comment 8 Jan Pokorsky 2008-09-23 14:09:37 UTC
Of course, the waiver requested.
Comment 9 Quality Engineering 2008-09-23 17:55:06 UTC
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
Comment 10 Jan Pokorsky 2008-09-26 17:15:49 UTC
no objections -> waiver approved
Comment 11 Quality Engineering 2008-10-01 05:47:17 UTC
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
Comment 12 Alexander Kouznetsov 2008-10-03 12:40:16 UTC
Since the issue is not fixed I've removed classes from the whitelist: http://hg.netbeans.org/main/rev/dcd31677aabd
Comment 13 David Strupl 2009-03-19 21:51:35 UTC
I think we have real P2s and P3s to fix for 6.7 especially after loosing Tomas and Lahvac.
Comment 14 Tomas Pavek 2009-03-20 10:37:32 UTC
Would be P4 if it was not a regression.
Comment 15 David Strupl 2009-03-31 15:54:45 UTC
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".
Comment 16 Quality Engineering 2009-11-02 11:14:43 UTC
NetBeans.org Migration: changing resolution from LATER to WONTFIX


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo