Community
Participate
Working Groups
Several types of changes do not notify the listener of the specific element that was modified. The listener only receives the modified class. Our plugin provides warning markers when elements with @generated have been modified. Without the specific element, we can only generate a warning for the class, and not also for the element as we would prefer. The cases where we would like to receive the specific element modified: 1) modifying field initializer 2) modifying method body 3) modifying method throws clause 4) changing parameter name
We provide fine grain deltas during reconcile operations. We do not provide more than a converted platform delta in case the file got changed as a result of regular resource changes. Providing a fine grain delta in all cases would require holding an entire picture of the workspace before a change so as to tell how different it became. Please explain better your testcase, to see if there is more we can do to help.
Closing since there was no response
This would be helpful for all clients that compute and cache their own state based on an analysis of method content (e.g. for interprocedural analysis). Currently, they just get this change event: [Working copy] Try.java[*]: {CONTENT | FINE GRAINED} But when e.g. a local class is added (a structural change), then they get: [Working copy] Try.java[*]: {CHILDREN | FINE GRAINED | AST AFFECTED} Try[*]: {CHILDREN | FINE GRAINED} foo(String, int)[*]: {CHILDREN | FINE GRAINED} Local[+]: {} It would be nice if they could get a delta like this if the content of a method changed (but the method didn't change structurally): [Working copy] Try.java[*]: {CHILDREN | FINE GRAINED | AST AFFECTED} Try[*]: {CHILDREN | FINE GRAINED} foo(String, int)[*]: {FINE GRAINED} Since existing element delta listeners don't expect such events, I guess we need a new ElementChangedEvent constant so that clients can explicitly request the additional information, e.g. #FINE_GRAINED_CONTENT_CHANGE. (In reply to comment #1) > We do not provide more than a converted platform delta in case the file got > changed as a result of regular resource changes. Yes, I guess we have to live with that.
(In reply to comment #3) > > Since existing element delta listeners don't expect such events, I guess we > need a new ElementChangedEvent constant so that clients can explicitly request > the additional information, e.g. #FINE_GRAINED_CONTENT_CHANGE. Markus, what problem do you see with this? A.java[*]: {CHILDREN | FINE GRAINED | PRIMARY RESOURCE} A[*]: {CHILDREN | FINE GRAINED} foo(String, int)[*]: {CONTENT | FINE GRAINED}
(In reply to comment #4) > Markus, what problem do you see with this? It breaks the contracts of IJavaElementDelta#F_CONTENT and #F_FINE_GRAINED. The latter is mentioned in the IJavaElementDelta Javadoc, where it talks about "structural changes". Changing that silently to also also include non-structural changes would be a breaking change. Furthermore, it can be a performance problem or just reveal other problems in existing listeners that don't expect these additional child elements in deltas. > A.java[*]: {CHILDREN | FINE GRAINED | PRIMARY RESOURCE} > A[*]: {CHILDREN | FINE GRAINED} > foo(String, int)[*]: {CONTENT | FINE GRAINED}
I don't know if this is a stupid question and I think I should have asked 'this' first. Why isn't a simple IJavaElementDelta#F_CONTENT enough to cover the cases mentioned in comment #0? e.g., A.java[*]: {CHILDREN | FINE GRAINED | PRIMARY RESOURCE} A[*]: {CHILDREN | FINE GRAINED} foo(String, int)[*]: {CONTENT}
Since we can report the modified elements only when listeners are registered with a new flag, it will be OK to reuse the existing F_CONTENT and F_FINE_GRAINED flags. The Javadoc just has to tell about the additional meaning of the reused flags for ElementChangedEvent#FINE_GRAINED_CONTENT_CHANGE listeners. Since all changes below a CU currently have F_FINE_GRAINED set, I think it would be best to keep this. The Javadoc of F_FINE_GRAINED already tells that this flag doesn't indicate a change -- it just tells that the analysis has been made. Setting F_CONTENT to an element delta that doesn't have F_CHILDREN set would be OK, but it's redundant: The absence of F_CHILDREN and the fact that the delta node exists already tell that. Every F_CHILDREN change is also a content change.
