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 149280

Summary: JsLanguage and JsonLanguage classes are loaded on NetBeans startup with LimeWire project
Product: editor Reporter: Alexander Kouznetsov <mrkam>
Component: CSL (API & infrastructure)Assignee: Vitezslav Stejskal <vstejskal>
Status: RESOLVED DUPLICATE    
Severity: blocker CC: issues, jtulach, mfukala, pjiricka, saubrecht
Priority: P3 Keywords: PERFORMANCE, SIMPLEFIX, TEST
Version: 6.x   
Hardware: PC   
OS: Windows XP   
URL: http://wiki.netbeans.org/FitnessViaWhiteAndBlackList
Issue Type: DEFECT Exception Reporter:
Attachments: Stacktrace
Stacktraces

Description Alexander Kouznetsov 2008-10-06 19:07:39 UTC
Performance test reports that the following classes are loaded on NetBeans startup with LimeWare project:

    org.netbeans.modules.javascript.editing.JsLanguage
    org.netbeans.modules.javascript.editing.JsonLanguage

Please don't load these classes unless they are really necessary.

Comment from issue 148179:
Those two classes are loaded because the tasklist is visible. And Task Providers are initialized with their display name
(must be passed to superclass constructor), the display name isn't requested when needed. And the GSF tasklist is
initialized with the name of its languages such that the filter makes sense to users. And the language display names are
provided by language config classes - the two classes this issue is about. Yes, this could be done separately
(declaratively) but that isn't the case yet. This definitely doesn't feel like a P2 for a handful of classes.
Comment 1 Jaroslav Tulach 2008-10-07 10:32:33 UTC
This is something that may require help from Standa.
Comment 2 Petr Jiricka 2008-10-30 14:30:08 UTC
Sounds like this should be against JavaScript, shouldn't it?
Comment 3 Alexander Kouznetsov 2008-10-30 18:38:39 UTC
Please also eliminate loading of the following class:

org.netbeans.modules.css.gsf.CSSLanguage

According to the following jtulach's comment the class is loaded due to the same reason: "This class is loaded by
tasklist, and we have some bug related to this problem in general already."
Comment 4 Alexander Kouznetsov 2008-10-30 18:41:27 UTC
Created attachment 72941 [details]
Stacktrace
Comment 5 Alexander Kouznetsov 2008-10-30 18:42:26 UTC
Created attachment 72942 [details]
Stacktraces
Comment 6 Marek Fukala 2009-04-30 13:12:27 UTC
All CSL based languages suffers with this problem. To be able to properly initialize the super class the
GsfHintsProvider needs to gather displaynames of all registered languages. The achieve this we need to create the
language instance.

Solution can be:
1) store the displayname as a file attribute in layer and read it from there instead of the language instance
2) do try to gather the list of the languages names at all and just pass some generic displayName and description in the
PushTaskScanner constructor.

#2 is super simple and acceptable I think. Keeping the decision on CSL owner where this issue belongs.
Comment 7 Marek Fukala 2009-04-30 13:14:18 UTC
type correction: GsfHintsProvider ---> GsfTaskProvider
Comment 8 Stanislav Aubrecht 2009-04-30 13:33:10 UTC
solution #2 sounds good to me
Comment 9 Vitezslav Stejskal 2009-06-03 13:43:37 UTC

*** This issue has been marked as a duplicate of 161179 ***