Community
Participate
Working Groups
3.0.1 1. Install CoreTools (found at http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/downloads/tools/org.eclipse.core.tools_1.1.0.zip) 2. Start a new workspace 3. Switch to Java perspective 4. Create a Java project Test 5. Create a Java class X.java in Test (leave the Java editor open) 6. Switch to the Plugin Dependency perspective Notice that the Java editor is hidden 7. Exit/restart the Workbench on the same workspace Observe: The org.eclipse.jdt.core is activated when it should not.
Out of curiosity have you tried tracking this down at all? Your steps seem to indicate you think the problem is on restoring editors...
Sorry I forgot to mention that I indeed put a breakpoint in JavaCore#start and the stack showed that the editor was being reactivated.
This is a known problem. The workbench restores the active editor, whether the editor area is shown or not.
I view this as a minor problem, as it seems like a pretty obscure case. Please feel free to disagree.
I believe this is an issue; especially when scaling with Eclipse-based products. Activating JDTCore during startup with no reasons can trigger a lot of work.
I think it's a corner case, not a major performance problem. Isn't this perspective provided by PDE, which already depends on JDT?
I saw originally the defect in another product, and startup took a very long time; during which editors proved to be recreated. Interestingly, when it finally did show up, there was no visible editor. I asked Jerome to recreate a similar testcase, using Eclipse SDK or close. I would not consider it a minor issue, when we now our startup story needs improvement to perform ok.
Adding my name to the cc list as we are now tracking performance issues more closely. Please remove the performance keyword if this is not a performance bug.
I believe this is a dup of bug 85005
Maybe, but in my case here, there was not even one editor intended to be visible in perspective after startup.
see also bug 75558
Also see bug 83316 for consequences of triggering Java editor opening.
Why did it get downgraded to P4 ? Is it deferred altogether ? This is key to some products.
See also bug 31621
*** Bug 31621 has been marked as a duplicate of this bug. ***
Michael and I discussed this. We feel that bug 85005 is the important one to address for 3.1. This one is not critical, although if it's straightforward to fix while looking at bug 85005, we will do so. Comment #12 is a self-reference.
I was meaning bug 89411
I think the 2 are as important, but I agree independant. Starting up a workbench with zero visible editor should cost nothing in editor refreshing.
I have no plans to address this bug for 3.1. While I agree it is a problem, I believe that it will be triggered infrequently.
It seems like there might be more scenarios in the RCP space where no editors will be opened.
FYI, I came across this when refactoring the workbench page. Part of the problem lies in the fact that we need a concrete IWorkbenchPart in order to fire the IPartService events (which includes deactivate/activate). We could fix it like this: - IWorkbenchPage.getActivePartReference() becomes the definitive pointer to the active part. - IWorkbenchPage.getActivePart() points to a non-null part iff the active part reference has been created. The IPartService events will continue to track the getActivePart() pointer, but we will no longer force creation of the part. This means that if the active part reference moves between two parts that haven't been lazily activated, then getActivePart will be null, getActivePartReference will change, and no DEACTIVATE/ACTIVATE events will be fired. We have two choices for IPartService2: either it will continue to fire events at the same time as IPartService, or the ACTIVATE/DEACTIVATE events will follow the active part reference... and will be fired at different times from the IPartService events in the case where the active part hasn't been created. I believe that the safest option may be the former, and that we should create a new IPartService3 that truly monitors part references and not parts. There would be some minor behavioral changes if we made this change. As far as an action contribution is concerned, there would be no active part until it gets lazily instantiated. Currently, if you follow the steps in the original PR, you would be able to access menu items associated with the Java editor even though it is invisible (the source menu, for example). If we made this change, then the items in the source menu will be invisible until the first time we make a Java editor visible. This seems reasonable to me, but it is a behavioral change we should be aware of.
Actually, comment 21 describes the solution to a more general problem (removing the assumption that the active part really exists). We could also support a (simpler) specific-purpose solution for this PR if we added a heuristic that insisted that a null editor is always selected if the editor area is hidden... but it would only fix this exact scenario.
Re: comment 20 If no editors are opened, the problem won't occur. This problem only occurs if editors are both open and invisible.
I don't think part activation is the issue here. When the workbench is shut down, the editor is not active, although there is a hidden, selected editor, that we should avoid materializing if we can. To me, requiring that the part be materialized if it is active is a pretty reasonable invariant.
Moving Dougs bugs
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
Remy is now responsible for watching the [EditorMgmt] component area.
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.
