Community
Participate
Working Groups
N20080423-2000 - paste to Package Explorer: package xy; public interface I { } package xy; public class C /*implements I*/ { } - in C.java, remove the /* and */ around "implements I" - do NOT save - select I - F4 => type hierarchy on I, no subtypes => I thought the TH works on working copies, but working on saved state is also acceptable - Ctrl+S => type hierarchy not updated (should show C as child of I) - F4 on I does not refresh the hierarchy. Need to open hierarchy on another type first or press F5 in Hierarchy view to get correct hierarchy.
Already broken in 3.3.2.
Actually the problem comes from the fact that the primary working copies are not taken into account when building the hierarchy, i.e. the hierarchy notification assumes that the working copies were taken into account, and thus save will not notify a need to refresh the hierarchy since it is not needed. Changing the title to better reflect the issue.
Srikanth, please have a look at this issue. To debug it, I would start by putting a breakpoint in org.eclipse.jdt.internal.core.CreateTypeHierarchyOperation.executeOperation() and debug from there.
1. When the type hierarchy browser is opened while there are some pertinent unsaved changes to the editor's working copy, then those changes don't appear upon the type hierarchy being opened up. (as reported in the bug) 2. A subsequent save also doesn't refresh the view (also as reported in the bug) In addition, 3. Reconcilation strategy driven changes never seem to be taken into account w.r.t type hierarchy. i.e, while the TH window is open, making any changes to the working copy don't show up at all in TH. (until you save the changes) It appears the latter behavior is a conscious design choice (from a performance p.o.v) - In browsing the change history of TypeHierarchy.isAffectedByOpenable() one see comments to the effect either that (a) working copy changes are altogether ignored in type hierarchy browser or (b) that we don't immediately act on them and instead batch up the changes (in the latter case, I couldn't see how/when the batched up changes get acted upon (other than a resource change triggered by ctrl-s) - they seem to be dropped otherwise) Discussion with team members with more history, confirms this intent (that changes to working copy are not intended to be reflected spontaneously.) So the one thing that is broken and needs fixing is the lack of refresh upon ctrl-s. I have a fix for this that is under test - stay tuned.
Created attachment 118370 [details] Patch with code changes and test Type hierarchy *creation* now takes into account any changes that may exist in primary working copies. However, once a type hierarchy window is open, changes to working copies will not automatically reflect spontaneously - A user will have to use ctrl-s or F5 to have the view refresh itself. As discussed earlier, this has always been the intent. Jerome, Please review the changes and help take to this to commit, Thanks.
Fix and test are good. However we should have the same fix (and a corresponding test) for BinaryType (that also implements IType).
Created attachment 118648 [details] Patch incorporating review comments Now we take primary working copies into consideration while a type hierarchy view is created out of a binary type.
Comment on attachment 118648 [details] Patch incorporating review comments Fixes and tests are good
Fixes and tests released for 3.5M4
Verified for 3.5M4 using I20081208-1800
I raised a follow up fix here: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?h=BETA_JAVA8&id=76226936180e26d9e682e909ba765fff61d327d9 that covers local types from working copy not showing up in hierarchy.
