Community
Participate
Working Groups
N20031029, but was able to reproduce with JDT/Core v_379a as well. What I see is that I get the delta of adding a field to a type is sent out when manipulating the type a second time. Here are steps to reproduce: - set two breakpoints in AllTypesCacheTest:testNewElementCreation (please make sure that the suite method of the test either executes all tests or that the testNewElementCreation method is passed to the constructor. Otherwise you will never execute the test). first at line(210): type.createField("public int fCount;", null, true, null); second at line(212): res1.clear(); - run the test case under debugger - when hitting the first breakpoint set a break point in TypeCacheDeltaListener#elementChanged which is a inner type of the AllTypesCache - resume. The delta sent out by adding the field is: org.eclipse.jdt.core.ElementChangedEvent[source=Java Model[*]: {CHILDREN} TestProject2[*]: {CHILDREN} src[*]: {CHILDREN} <default>[*]: {CHILDREN} A.java[*]: {CONTENT}] - resume - now "slowly" step over including the statment type.createType("public class AInner {}", null, true, null); This seems to be important. Sometime when directly resuming the second delta contained the newly added type and field. - the break point in the element change listener is hit again - the delta sent out by adding the type is org.eclipse.jdt.core.ElementChangedEvent[source=Java Model[*]: {CHILDREN} TestProject2[*]: {CHILDREN} src[*]: {CHILDREN} <default>[*]: {CHILDREN} A.java[*]: {CHILDREN | FINE GRAINED} A[*]: {CHILDREN | FINE GRAINED} fCount[+]: {}] which is the delta from adding the field. - debugging further shows that the delta adding the type is sent out when deleting the test projects.
Problem due to a change in the behavior of IWorkspace.isTreeLocked(). It returns true even if the tree is not locked. May want to undo the workaround described in bug 29585.
If the behaviour of isTreeLocked has changed, it is a bug. Please enter a bug with platform core if this is the case.
After further investigation, it appears that the tree is marked as locked because another thread is in the middle of notifying resource changes after a build: 1. A resource is changed in thread 't1'. 2. Another thread 't2' is spawn to do the build. 3. At the end of the build, a POST_CHANGE notification occurs. 4. During the POST_CHANGE notification, the tree is locked. 5. In 't1' testing for isTreeLocked() returns true. However IWorkspace.run(...) can still be used. It doesn't throw a CoreException. 6. Tree modifications made in this IWorkspaceRunnable will just wait for the POST_CHANGE notification in 't2' to finish to proceed. So the question is how do we know that using IWorkspace.run(...) will throw a CoreException before calling it?
Comment #3 should have been added to bug 29585. Moving it there.
Workaround described in bug 29585 was wrong. If the operation is read only, then IWorkspace.run(...) should not be used. If it is not read only, IWorkspace.run(...) should be used. If the tree is locked, it will throw a CoreException which is fine because the operation will attempt to modify the tree. Removed call to isTreeLocked() in JavaElement.run(...). This fixes this bug.
Build N20031105 failed showing the same behaviour as described in this PR. Did anything change again in this area.
Might be a consequence of the last change in bug 29624
The problem again nshowed up in I20031111
Cannot reproduce following the orignal steps.
This time we are getting wrong deltas when adding a type to a compilation unit. Due to Philippe this is caused by background autobuilding. For the test case we have disabled autobuild.
The affected statements are: ICompilationUnit newCU= pack.getCompilationUnit("A.java"); IType type= newCU.createType("public class A {\n}\n", null, true, null);
Same problem as described in bug 46428: a resource delta is fired too early even if it is run in an IWorkspaceRunnable.
Dirk, can this be closed now?
We are still getting wrong deltas on class path changes. But I think this is covered by a different PR. So OK to close
Closing
