Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 148235 - Startup regression: CssModelUpdateTask$CssModelUpdateTaskFactory
Startup regression: CssModelUpdateTask$CssModelUpdateTaskFactory
Product: web
Classification: Unclassified
Component: CSS Visual Tools
PC Windows XP
: P3 (vote)
Assigned To: Marek Fukala
Jindrich Sedek
Depends on: 152965
  Show dependency treegraph
Reported: 2008-09-24 14:31 UTC by Alexander Kouznetsov
Modified: 2009-11-02 11:16 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT

Stacktrace (2.47 KB, text/plain)
2008-09-24 14:32 UTC, Alexander Kouznetsov

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Kouznetsov 2008-09-24 14:31:02 UTC
Performance whitelist test reports that the following class is being loaded on NetBeans startup:


This is considered as NetBeans performance regression. Please remove these classes from NetBeans startup.
Comment 1 Alexander Kouznetsov 2008-09-24 14:32:11 UTC
Created attachment 70473 [details]
Comment 2 Marek Fukala 2008-09-25 10:33:28 UTC
I do not know how, if even reasonably doable, I could lazy initialize the EditorAwareSourceTaskFactory implementation so
it won't be initialized during startup. The original code triggering the class load (SourceTaskFactoryManager) is taken
from Retouche and is a part of GSF infrastructure. 

Adding Jan Lahoda and Tor as authors of the code to cc. Can you guys please express your opinion on this issue? I am not
familiar with all the aspects. Thanks.
Comment 3 Jan Lahoda 2008-09-25 21:08:22 UTC
I think that not loading the class, but keeping the functionality at the same time (and doing it cleanly) would require
big changes (mainly on the infrastructure side), which will be rendered obsolete by the ParsingAPI.

For the record: it might be possible to merge the functionality of the task into an existing task (like
SemanticHighlighter), but I do not think that preventing loading a class is a good enough reason for such an ugliness.

So, I do not think it is reasonable to fix this for 6.5.
Comment 4 Marek Fukala 2008-09-26 06:58:08 UTC
I agree, the used solution is correct, I do not see any reason why an 'enhancement' (the original solution was a plain
hack) should be considered as an regression if other instances are ok.

jlahodas's workaround with using different EditorAwareSourceTaskFactory to handle the code is doable, but it similar to
the original unclear solution.

I personaly do not consider this as a problem especially when it is a subject to change in next version by the parsing api.
Comment 5 Tomas Zezula 2008-09-26 07:08:56 UTC
I fully agree with Marek's resolution.

Comment 6 Marek Fukala 2008-11-19 12:07:56 UTC
Comment 7 Quality Engineering 2009-11-02 11:16:16 UTC 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