Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 149280 - JsLanguage and JsonLanguage classes are loaded on NetBeans startup with LimeWire project
JsLanguage and JsonLanguage classes are loaded on NetBeans startup with LimeW...
Status: RESOLVED DUPLICATE of bug 161179
Product: editor
Classification: Unclassified
Component: CSL (API & infrastructure)
6.x
PC Windows XP
: P3 (vote)
: 6.x
Assigned To: Vitezslav Stejskal
issues@editor
http://wiki.netbeans.org/FitnessViaWh...
: PERFORMANCE, SIMPLEFIX, TEST
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-06 19:07 UTC by Alexander Kouznetsov
Modified: 2009-06-03 13:43 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
Stacktrace (3.74 KB, text/plain)
2008-10-30 18:41 UTC, Alexander Kouznetsov
Details
Stacktraces (7.51 KB, text/plain)
2008-10-30 18:42 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-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 ***


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