Community
Participate
Working Groups
In the cold startup tests, JSDT is loading three plugins on startup. The list below is formatted as "[plugin id] - [total startup with dependencies] - [direct plugin startup]": org.eclipse.wst.jsdt.ui - 600 ms - 319 ms org.eclipse.wst.jsdt.manipulation - 3 ms - 3 ms org.eclipse.wst.jsdt.core - 278 ms - 278 ms It appears these plugins are being loaded whether or not any JSDT tooling is invoked by the user. This function should be lazy loaded when the user touches JSDT-related function for the first time. In testing it appears that there is a Navigator filter that's causing the early startup: org.eclipse.wst.jsdt.internal. ui.JavaScriptPlugin.start(Unknown Source) at org.eclipse.osgi.framework.internal.core. BundleContextImpl$1.run(Unknown Source) at java.security.AccessController.doPrivileg ed(Unknown Source) at org.eclipse.osgi.framework.internal.core. BundleContextImpl.startActivator(Unknown Source) at org.eclipse.osgi.framework.internal.core. BundleContextImpl.start(Unknown Source) at org.eclipse.osgi.framework.internal.core.BundleHost. startWorker(Unknown Source) at org.eclipse.osgi.framework.internal.core. AbstractBundle.start(Unknown Source) at org.eclipse.osgi.framework.util.SecureAction. start(Unknown Source) at org.eclipse.core.runtime.internal.adaptor. EclipseLazyStarter.postFindLocalClass(Unk nown Source) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager. findLocalClass(Unknown Source) at org.eclipse.osgi.internal.baseadaptor.Def aultClassLoader.findLocalClass(Unknown Source) at org.eclipse.osgi.internal.loader.BundleLoader. findLocalClass(Unknown Source) at org.eclipse.osgi.internal.loader.BundleLoader. findClassInternal(Unknown Source) at org.eclipse.osgi.internal.loader.BundleLoader. findClass(Unknown Source) at org.eclipse.osgi.internal.loader.BundleLoader. findClass(Unknown Source) at org.eclipse.osgi.internal.baseadaptor.Def aultClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at org.eclipse.osgi.internal.loader.BundleLoader. loadClass(Unknown Source) at org.eclipse.osgi.framework.internal.core.BundleHost. loadClass(Unknown Source) at org.eclipse.osgi.framework.internal.core. AbstractBundle.loadClass(Unknown Source) at org.eclipse.core.internal.registry.osgi.R egistryStrategyOSGI.createExecutableExten sion(Unknown Source) at org.eclipse.core.internal.registry.ExtensionRegistry. createExecutableExtension(Unknown Source) at org.eclipse.core.internal.registry.Config urationElement.createExecutableExtension( Unknown Source) at org.eclipse.core.internal.registry.Config urationElementHandle.createExecutableExte nsion(Unknown Source) at org.eclipse.ui.internal.navigator.filters. CommonFilterDescriptor.createFilter(Unkno wn Source) at org.eclipse.ui.internal.navigator.Navigat orFilterService.getViewerFilter(Unknown Source) at org.eclipse.ui.internal.navigator.Navigat orFilterService.getVisibleFilters(Unknown Source) at org.eclipse.ui.navigator.CommonNavigator. createPartControl(Unknown Source) at com.ibm.etools.ui.navigator.SDNavigator.c reatePartControl(Unknown Source) at org.eclipse.ui.internal.ViewReference.cre atePartHelper(Unknown Source) at org.eclipse.ui.internal.ViewReference.cre atePart(Unknown Source) at org.eclipse.ui.internal.WorkbenchPartReference. getPart(Unknown Source) at org.eclipse.ui.internal.PartPane.setVisib le(Unknown Source) at org.eclipse.ui.internal.ViewPane.setVisib le(Unknown Source) at org.eclipse.ui.internal.presentations.Pre sentablePart.setVisible(Unknown Source) at org.eclipse.ui.internal.presentations.util. PresentablePartFolder.select(Unknown Source) at org.eclipse.ui.internal.presentations.util. LeftToRightTabOrder.select(Unknown Source) at org.eclipse.ui.internal.presentations.util. TabbedStackPresentation.selectPart(Unknow n Source) at org.eclipse.ui.internal.PartStack.refresh PresentationSelection(Unknown Source) at org.eclipse.ui.internal.PartStack.createC ontrol(Unknown Source) at ...
This is actually caused by a CommonNavigator problem, dupping against a bug against that component. *** This bug has been marked as a duplicate of bug 323440 ***
Turns out there is an issue with the JSDT trigger point which we inherited from JDT.
Created attachment 180692 [details] Fix Patch Fixes the org.eclipse.ui.navigator.navigatorContent extension point enablement clauses so that JSDT does not get activated until it needs too. Right now this extension point causes the JSDT plugins to load as soon as the workspace loads. These changes fixes it so the JSDT plugins do not load until a project that uses JSDT exists in the workspace.
Committed, thanks, Ian!
