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.

Bug 140394 - NetBeans startup regression: org.netbeans.modules.web.client.javascript.debugger.attach
Summary: NetBeans startup regression: org.netbeans.modules.web.client.javascript.debug...
Status: VERIFIED FIXED
Alias: None
Product: debugger
Classification: Unclassified
Component: Code (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Martin Entlicher
URL: http://wiki.netbeans.org/FitnessViaWh...
Keywords: PERFORMANCE, REGRESSION, TEST
Depends on:
Blocks:
 
Reported: 2008-07-16 19:12 UTC by Alexander Kouznetsov
Modified: 2008-09-16 10:23 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Stacktraces (251.41 KB, text/xml)
2008-07-16 19:13 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-07-16 19:12:52 UTC
Performance whitelist test reports that the following classes are being loaded on NetBeans startup:

org.netbeans.modules.web.client.javascript.debugger.attach.URLAttachPanel
org.netbeans.modules.web.client.javascript.debugger.attach.URLAttachType

This is considered as NetBeans performance regression. Please remove these classes from NetBeans startup.

This issue is based on jtulach's comment:
Please report a bug to debugger and make them justify this. My guess is that 
this is not needed, the 
org.netbeans.modules.debugger.ui.actions.ConnectAction.isEnabled()
could always return true. Maybe they can use Actions.alwaysEnabled as well...
Comment 1 Alexander Kouznetsov 2008-07-16 19:13:39 UTC
Created attachment 64747 [details]
Stacktraces
Comment 2 _ sandipchitale 2008-07-17 00:59:16 UTC
I have simply registered the org.netbeans.modules.web.client.javascript.debugger.attach.URLAttachType in:

web.client.tools.impl/src/META-INF/debugger/org.netbeans.spi.debugger.ui.AttachType

which return org.netbeans.modules.web.client.javascript.debugger.attach.URLAttachPanel from one of it's methods.

What can I do to fix this problem?
Comment 3 _ sandipchitale 2008-07-17 01:03:22 UTC
I am using the standard mechanism of registering org.netbeans.spi.debugger.ui.AttachType impls.
Comment 4 _ sandipchitale 2008-07-17 01:56:36 UTC
I see analogous in the whitelist:

org.netbeans.modules.cnd.debugger.gdb.attach.GdbAttachPanel
org.netbeans.modules.cnd.debugger.gdb.attach.GdbAttachType
org.netbeans.modules.bpel.debugger.ui.BpelAttachType
org.netbeans.modules.bpel.debugger.ui.BpelConnectPanel
org.netbeans.modules.debugger.jpda.ui.JPDAAttachType

in the whitelist at ide.kit/test/qa-functional/data/whitelist.txt

Am I supposed to add my classes to this file manually?
Comment 5 Samaresh Panda 2008-09-03 19:52:10 UTC
Adding yarda. Can someone answer this or point to any page if exists?
Comment 6 Jaroslav Tulach 2008-09-04 13:39:29 UTC
Maybe this is a bug in
org.netbeans.modules.debugger.ui.actions.ConnectAction.isEnabled(ConnectAction.java:97)
which instantiates all the classes in its isEnabled method. Samaresh, feel free to negotiate with Martin Entlicher who 
will fix the system to not load your class.
Comment 7 Martin Entlicher 2008-09-04 15:07:56 UTC
ConnectAction.isEnabled() need to check whether there are some implementations of AttachType registered in the system or
not.
It's true that it does not need to create the instances to find this out, but we do not have a better way of doing that
with the current APIs. We'd need to add something like:
int DebuggerManager.lookupCount(String folder, Class<T> service)
which would return the count of services without creating instances.

But this is not a regression, this behavior is there for ages already.

If you think this is really a problem and that it justifies a new API, please reassign to debuggercore module.
Comment 8 Samaresh Panda 2008-09-04 16:26:23 UTC
Thanks Martin. Assigned to debuggercore.
Comment 9 Jaroslav Tulach 2008-09-04 20:13:38 UTC
I know this is not regression in debugger. However it is regression in 'big IDE' caused by a scalability problem in 
debugger.

Easy fix, yet not perfect one, is to use lookupFirst, as you need at least one service to enable the action. 

Better fix, even without changing the API, is to create the List<?> from lookup([1]) without actually instantiating 
the classes, just by reading the registrations. That will give you chance to compute lookup(...).size() without 
instantiating anything.

[1] 
http://bits.netbeans.org/dev/javadoc/org-netbeans-api-debugger/org/netbeans/api/debugger/DebuggerManager.html#lookup(java.lang.String, 
java.lang.Class)
Comment 10 Martin Entlicher 2008-09-12 11:14:25 UTC
List with lazy content instantiation is possible, of course. We already have a special list implementation, thus it
needs to be merged into it's logic...
I agree that this is an elegant way how to fix this.
Comment 11 Martin Entlicher 2008-09-13 11:19:57 UTC
LazyArrayList class added, which seems to fixed the problem.
changeset:   101932:cff59ab75a95, 101934:2d3ae264b162
http://hg.netbeans.org/main/rev/cff59ab75a95
http://hg.netbeans.org/main/rev/2d3ae264b162
Comment 12 Quality Engineering 2008-09-13 17:12:10 UTC
Integrated into 'main-golden', will be available in build *200809131401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/cff59ab75a95
User: mentlicher@netbeans.org
Log: #140394 - LazyArrayList introduced and used by LookupList so that instanced defined from META-INF are created lazily when they are really needed.
Comment 13 Alexander Kouznetsov 2008-09-16 10:23:58 UTC
Verified with 080915