Created attachment 70421 [details]
Stacktraces

What is "the LimeWare project" ? Is it this: http://www.limeware-cms.com ?

If so, I downloaded the source code (version 0.6.7). I see the project is full of JavaScript files. When you open up a
PHP project, it's normal that it will scan the whole project for JavaScript files and index them (for later fast
retrieval for features like code completion, go to declaration, go to symbol, etc).

Therefore, I believe it is correct for the below classes to be loaded after project open of a PHP project containing
JavaScript -- or even containing just PHP files (but with <script> tags in the PHP files).

By the way, can you define what it means to start up NetBeans with an open LimeWare project? Is it the first open, or
does it first open the project, then close the IDE, then restart the IDE and measure the loaded classes? I believe that
in the second case, assuming no files are actually open in the editor, and the tasklist window is not open, then
(provided no files have changed on disk) there will be no JavaScript parsing so the classes don't have to be loaded.

I'm closing this as not a but - please reopen if I misunderstood something.

Sorry for incorrect project name. I've already sent you the link to the project.

How do I reproduce this problem?

I downloaded the lime6 project, and started the IDE with a clean user directory and the startup flag -J-verbose:class to
see classes loaded.

./netbeans --userdir /tmp/whatever -J-verbose:class > /tmp/classes-loaded.txt

I opened the project, and waited for the Tasklist to finish its complete scan.

At that point, there were a lot of classes loaded:
 % wc classesloaded.txt
9519   38044 1446573 classes-loaded.txt

However, almost none of them were related to JavaScript:

% grep javascript classes-loaded.txt | grep -v javascript.refactoring
[Loaded org.netbeans.modules.javascript.editing.JsLanguage from
jar:file:/Users/tor/netbeans/hg/main/nbbuild/netbeans/gsf1/modules/org-netbeans-modules-javascript-editing.jar!/]
[Loaded org.netbeans.modules.javascript.editing.JsonLanguage from
jar:file:/Users/tor/netbeans/hg/main/nbbuild/netbeans/gsf1/modules/org-netbeans-modules-javascript-editing.jar!/]

(There were 8 classes related to refactoring that showed up which is why I filtered it down to non-refactoring classes
above). These two classes are loaded because the tasklist is open; without it they would not be.

The point here is that none of the JavaScript classes shown in this bug report are part of the loaded classes for the
LimeWire project.

Am I using the wrong diagnostics flags? If so, can you tell me how to reproduce the problem? (The wiki link,
http://wiki.netbeans.org/FitnessViaWhiteAndBlackList would be a good place to include this info).

*** Issue 148079 has been marked as a duplicate of this issue. ***

List of classes from issue 148079:

    org.mozilla.nb.javascript.Callable
    org.mozilla.nb.javascript.CompilerEnvirons
    org.mozilla.nb.javascript.ConstProperties
    org.mozilla.nb.javascript.Context
    org.mozilla.nb.javascript.ContextFactory
    org.mozilla.nb.javascript.Decompiler
    org.mozilla.nb.javascript.DefaultErrorReporter
    org.mozilla.nb.javascript.ErrorReporter
    org.mozilla.nb.javascript.Function
    org.mozilla.nb.javascript.IRFactory
    org.mozilla.nb.javascript.Interpreter
    org.mozilla.nb.javascript.Kit
    org.mozilla.nb.javascript.Node
    org.mozilla.nb.javascript.ObjArray
    org.mozilla.nb.javascript.ObjToIntMap
    org.mozilla.nb.javascript.Parser
    org.mozilla.nb.javascript.Parser$NoOpDecompiler
    org.mozilla.nb.javascript.ScriptOrFnNode
    org.mozilla.nb.javascript.ScriptRuntime
    org.mozilla.nb.javascript.Scriptable
    org.mozilla.nb.javascript.ScriptableObject
    org.mozilla.nb.javascript.ScriptableObject$Slot
    org.mozilla.nb.javascript.TokenStream
    org.mozilla.nb.javascript.UniqueTag
    org.mozilla.nb.javascript.debug.DebuggableObject
    org.mozilla.nb.javascript.optimizer.Codegen

I updated wiki page (http://wiki.netbeans.org/FitnessViaWhiteAndBlackList) with instructions.

We use slightly different scenario in our test. We open LimeWire project, stop IDE and then start it measuring classes.
Classes are measured using test described on wiki.

I see the problem now.  Even though this project is a Java project, it looks like the Groovy project listens on the
project open hook, and registers the Java classpath with GSF as well. As a result, GSF goes and looks at the classpath,
and finds HTML files in the project. HTML files can contain JavaScript, so they are processed by the embedding model and
JavaScript parser.

Martin/Matthias/Tomas -- is this correct behavior? Is having Groovy support installed going to mean that all Java
projects will get treated as potentially Groovy (and therefore GSF) projects? I would have thought there would be some
setting on the project that you could use to enable this (which would also control whether the Groovy runtime is
included, whether the Groovy compiler is used by the build step, and so on). If there is such a setting, then the
GsfClasspathHook in groovy.support should probably use it to only register Java paths for Groovy enabled projects.

If this is as intended, then this seems problematic - and the extra runtime checking (directory scanning) is a bigger
performance problem than extra loaded classes.

It's bug for sure, something like that should happen only if groovy is enabled for the J2SE project.

Should be fixed in #122bb32e53b3 later today

Integrated into 'main-golden', will be available in build *200810031107* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/122bb32e53b3
User: Martin Adamek <martin_adamek@netbeans.org>
Log: #148179: org.netbeans.modules.javascript.editing classes are loaded on NetBeans startup with LimeWire project

Thanks for the fix. Almost all classes are gone, but there are two that are still being loaded:

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

Should I file a separate issue for them?

Created attachment 71194 [details]
Stacktraces

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.

Verified. Filed another issue 149280 to track these two files.