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.
Summary: | org.netbeans.modules.javascript.editing classes are loaded on NetBeans startup with LimeWire project | ||
---|---|---|---|
Product: | groovy | Reporter: | Alexander Kouznetsov <mrkam> |
Component: | Editor | Assignee: | martin_adamek <martin_adamek> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | issues, jtulach, martin_adamek, schmidtm, tor, tzezula |
Priority: | P2 | Keywords: | PERFORMANCE, TEST |
Version: | 6.x | ||
Hardware: | PC | ||
OS: | Windows XP | ||
URL: | http://wiki.netbeans.org/FitnessViaWhiteAndBlackList | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
Stacktraces
Stacktraces |
Description
Alexander Kouznetsov
2008-09-24 10:20:34 UTC
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. |