Community
Participate
Working Groups
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 Build Identifier: I'm trying to improve the startup performance of Eclipse. It looks like even when the ResourcePerspective is set to be initial perspective when Eclipse launches, it will eagerly activate and start JDT. This is because JDT contributes several ViewerFilters. If the navigator is empty, it should not activate viewer filters. If possible, there should be a way to specify filters using enablement expressions so that the plugins that define these filters do not have to be loaded. Reproducible: Always
I like where you are going with this however I think this is covered in some other work. Bug 245105 addresses the issue of not enabling filters unless the NCE is active. That bug when fixed should cause the filter descriptors to not even be processed unless the NCE has been activated. However this alone will not solve your problem, as even if the resource perspective is active and all projects are closed, the JDT NCE is going to be activated because it is triggered by the workspace root. I actually think this is unnecessary and will attach a patch to the CNF configuration for JDT UI for their review. This should defer the start fo the JDT to when a Java project is actually expanded. However there maybe other work to do to make this work (I have not looked into the issue of action providers for example). Your use case is also not quite clear to me; presumably you have the JDT plugins available so at some point people want to work using JDT. If you can elaborate on your use case this could provide some additional motivation between the JDT UI folks and the platform to address this.
Created attachment 161847 [details] Patch for JDT UI CNF configuration This will have their NCE not loaded at the boot time for the project explorer. It has not been thoroughly tested, but the initial appearance is it seems to not break anything.
(In reply to comment #1) > Your use case is also not quite clear to me; presumably you have the JDT > plugins available so at some point people want to work using JDT. If you can > elaborate on your use case this could provide some additional motivation > between the JDT UI folks and the platform to address this. The use-case is making Eclipse start as quickly as possible. Since this is like peeling an onion, it must be done in layers. At first, Eclipse should be as fast as possible when starting in a brand new workspace. Layer, it should be done when opening an existing project. (I imagine some things could be done in those cases as well) When JDT is initialized - a lot of other things start to happen as well. So, by not activating it - you will also not activate a lot of dependencies as well. This isn't as important for an base Eclipse you download from this website - but it is more important as Eclipse adopters (IBM) add on a lot of additional contributions to the base.
Let's start this comment that I completely agree on this bug ;-) >It has not been thoroughly tested As a minimal test I would expect that you check whether JDT gets loaded. This is still the case with your patch even with a completely empty Project Explorer. There are two different issues here: 1. The patch needs more changes, so that also child content and action providers don't result in (JDT) loading (all IResource and IWorksapceRoot based extensions need to be reviewed and changed if needed). 2. Fundamental architectural issue in the CNF: the CNF loads bundles that contribute (enabled) filters eagerly, which makes changes made for item 1 useless. I filed bug for 306922 that problem. I'd be happy to get a new patch for 1 once bug is fixed 306922.
Another problem are label decorators and action providers.
*** Bug 352631 has been marked as a duplicate of this bug. ***
Bug #350881 has a patch that definitely resolves the "eager bundle loading" issue for Javascript (JSDT). After verifying that it works in the JSDT case, I tried adapting the patch for JDT (attached on bug 352631), and interestingly that patch worked for me but not for Dani. I'm not sure what could be different between our setups. As a product builder, I'm interested in avoiding bundle loading. If active filters are the only remaining problem, a plugin_customization.ini for my product could probably fix the issue for me even when bug 245105 is not yet resolved?
(In reply to comment #7) > Bug #350881 has a patch that definitely resolves the "eager bundle loading" > issue for Javascript (JSDT). > > After verifying that it works in the JSDT case, I tried adapting the patch for > JDT (attached on bug 352631), and interestingly that patch worked for me but > not for Dani. I'm not sure what could be different between our setups. I used a fresh Eclipse SDK install. Maybe you already disabled the filters and decorators? > As a product builder, I'm interested in avoiding bundle loading. If active > filters are the only remaining problem, a plugin_customization.ini for my > product could probably fix the issue for me even when bug 245105 is not yet > resolved? Why then install JDT in the first place? The right approach is to fix the CNF bugs.
(In reply to comment #8) > Why then install JDT in the first place? Others depend on JDT components (bug 350438) or drag in JDT without wishing to (bug 351830) so there's cases where one has to live with JDT being installed even if JDT functionality is not consumed. > The right approach is to fix the CNF Sure, and I'm much in favor of pursuing the right approach. To be honest in the concrete case I can wait since we're currently applying my bug 351830 patch and we got rid of JSDT debug bundles, so we don't ship JDT in our product. I guess what I wanted here in the first place was some confirmation that the approach limiting CNF expressions actually makes sense and is the longerterm strategy.
(In reply to comment #9) > (In reply to comment #8) > > Why then install JDT in the first place? > > Others depend on JDT components (bug 350438) or drag in JDT without wishing to > (bug 351830) so there's cases where one has to live with JDT being installed > even if JDT functionality is not consumed. OK, I see that. It will be confusing for users though if they really do want to use the JDT features and things like decorators and filters are not working as they normally do in JDT. > To be honest in the concrete case I can wait since we're currently applying my > bug 351830 patch and we got rid of JSDT debug bundles, so we don't ship JDT in > our product. I guess what I wanted here in the first place was some > confirmation that the approach limiting CNF expressions actually makes sense > and is the longerterm strategy. I think your patch fixes one scenario and might be needed in addition to fix the decorator and filter issue.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
