Community
Participate
Working Groups
We need to track changes to java classes in our project, so we use the java model notification scheme. The problem is that we need to know not just that the working copy has been changed, but in addition we need to know that the change has been committed to the file system. The java model notification scheme doesn't do this. This is a big problem for us because the change is not really important to us until it has been committed to a file. (Because when committed, we will start a new remote vm for that project after the build has completed, which we can wait for). If there was one more notification indicating that the java class working copy changes have been committed we could know this. The only workaround is painful, we need to listen to both working copy java model changes and the system IResource changes, and mark in some hashtable that the underlying resource is dirty from the working copy notifications, and then when we get the save notification from the IResource notification we know it has been committed. The big problem with this is there is no way of knowing that working copy changes have been reverted and not saved so that we can clear this dirty flag. At least none that I can track down. We wouldn't have to do any of this if we just knew (a) changes have been committed and (b) changes have been reverted. Thanks, Rich
This question was already debated. With the gap being closed in between units and working copies, this information is no longer available to clients. Maybe we could generate an extra delta with special flags...
Thinking more of it, we could offer a CHANGED delta with special flag set, like PRIMARY_RESOURCE or something like that. The fact we use the CHANGED delta could impact other clients. Will cc some to get their feel on it.
Erich, Dirk & Darin - would this be a fair change for you ?
This should not effect the debugger. We listen to resource changes to perform HCR, and we only react to element changes when an element is removed (to update our breakpoints).
I think the change should be fine. But we should have Martin's opinion as well since he did the JDT/UI conversion to the new working copy model. Side node: refactoring uses the same work-around (listen to resource changes).
When you say special flag of PRIMARY_RESOURCE do you mean that it would be sent when the file has actually been saved or in other words that PRIMARY_RESOURCE means that this change delta for the java element means that the physical file (resource) was physically changed? Thanks, Rich
Yes, the intent is to send a CHANGE delta with the PRIMARY_RESOURCE flag set whenever the file changes on disk.
Does this mean that an existing view registered as a listener will refresh once too often since it doesn't handle the PRIMARY_RESOURCE flag?
Erich, I'm not sure who your question is directed at, but that's what Philippe was trying to find out in comment #3.
sorry, here are some more words... Consider the package explorer view as an example. It is already tracking changes to the working copies. Now when the file is saved then the package explorer receives another delta. Unless the delta notification code is updated (which we can do for the package explorer) then you would do another update/analysis when you receive the PRIMARY_RESOURCE notification. A minor variation would be to have clients which are interested in this notification express their interest when they register the listener in the event mask.
The event mask is reserved for different type of events (think POST_CHANGE, POST_RECONCILE, etc...). It is not meant to tell us which information it wants in a delta. If we were still going along that path, this means our code building deltas, would have to construct different ones to feed each listener. This is a no go. Since we closed the gap between working copies and units, some clients feel the lost some information (since 2.1); this is the same as some of the needs JDT UI expressed, and for which we added special flags. The only difference now is that the request did not come from JDT UI... <g>
Per listener deltas are not an option in particular in the case of batching. Since you politely mentioned the request origin <g>... There are indeed other flag additions in 3.0 which are similar. There is the F_PRIMARY_WORKING_COPY flag which is almost symmetrical to F_PRIMARY_RESOURCE. Clients should precisely analyze the delta flags (like the package explorer) and not react on flags they don't expect. Clients which precisely analyze a delta will not be affected by the additional flag and hence my concern isn't valid.
In the following scenario: 1. A .java file is opened in a Java editor (the corresponding primary ICompilationUnit is in working copy mode) 2. One goes to the Navigator and deletes the .java file -> no delta is currently notified since the primary compilation working exists in the Java model until it is discarded. However I suspect that one would like to be notified that the resource has disapeared. Rich, would notifying a CHANGED delta with the PRIMARY_RESOURCE flag set be good enough for you in this scenario ?
Wouldn't it be better to have "REMOVED" type with the PRIMARY_RESOURCE flag on the ICompilationUnit indicating the PRIMARY_RESOURCE is now deleted? But that begs the question, then there should also be an "ADDED" with PRIMARY_RESOURCE when either the working copy is saved (thereby recreating it).
From the Java model point of view, the ICompilationUnit is not removed since you can still navigate to it using its IPackageFragment's getChildren() method. Only the resource is removed. (And symetrically with the resource added case).
But we're talking about that the PRIMARY_RESOURCE flag says the file is gone. Not that the compilation unit working copy is gone. That isn't much different then the CHANGED w/PRIMARY_RESOURCE indicates that the file has been changed, and not that the working copy has been changed. If we used CHANGED for add/changed/delete of file, it would get confusing. I would have to then go check is the primary resource still there or gone to know what happened. I do see that in the IJavaElement the comments indicate the changed flags (where PRIMARY_RESOURCE would be defined) is only available for the CHANGED status, so I can see adding it for ADDED/REMOVED could be problematical. It would be sort of changing the API because users wouldn't be checking the flags for status ADDED/REMOVED. So I guess that's why it wouldn't be feasible at this time to use ADDED/REMOVED with PRIMARY_RESOURCE. I do need to know add/changed/delete of the primary resource, but if all that can be accepted is the CHANGED flag w/PRIMARY_RESOURCE, I can live with it. I would need to do more checking, otherwise you would run out of flag bits if I asked for PRIMARY_RESOURCE_ADDED/REMOVED/CHANGED as individual flags. ---------------------------------------------- Another question having to do with this notification. If the ICompilationUnit was not a working copy and file was deleted, there would be a REMOVED notification sent, right? So I actually need to continue to listen to the REMOVED notification to know that it is gone in case it was just straight deleted, right? What happens in the case the file was deleted and there was a working copy. If the working copy was eventually discarded, would a REMOVED notification go out then? (That would be too late for me, but I'm curious on the seq. of notifications that would happen so I know what to expect). Same question if it was saved, would an ADDED notification go out at that time? Thanks
> I do see that in the IJavaElement the comments indicate the changed flags > (where PRIMARY_RESOURCE would be defined) is only available for the CHANGED > status, so I can see adding it for ADDED/REMOVED could be problematical. It > would be sort of changing the API because users wouldn't be checking the > flags for status ADDED/REMOVED. So I guess that's why it wouldn't be feasible > at this time to use ADDED/REMOVED with PRIMARY_RESOURCE. Your analysis is right on. > I do need to know add/changed/delete of the primary resource, but if all that > can be accepted is the CHANGED flag w/PRIMARY_RESOURCE, I can live with it. I > would need to do more checking, otherwise you would run out of flag bits if I > asked for PRIMARY_RESOURCE_ADDED/REMOVED/CHANGED as individual flags. If you can live with it, that's great. > Another question having to do with this notification. If the ICompilationUnit > was not a working copy and file was deleted, there would be a REMOVED > notification sent, right? Right. > So I actually need to continue to listen to the > REMOVED notification to know that it is gone in case it was just straight > deleted, right? Right. > What happens in the case the file was deleted and there was a working copy. If > the working copy was eventually discarded, would a REMOVED notification go out > then? (That would be too late for me, but I'm curious on the seq. of > nofications that would happen so I know what to expect). Actually, when the Java editor notices that the resource has been removed (and the editor is not dirty), it closes itself, thus it discards the working copy and a REMOVED notification goes out. > Same question if it was saved, would an ADDED notification go out at that > time? Yes, an ADDED notification would go out.
Added changed flag IJavaElementDelta#F_PRIMARY_RESOURCE. A Java element delta of type CHANGED with this flag set is notified when the underlying resource of a primary working copy changes (or is added or removed). It is also notified if a primary compilation unit's content changes (since its resource also changes).
Verified for 3.0 M9 with build I200405180816.
