Community
Participate
Working Groups
Current behavior: The maximum frequency at which JavaModel deltas are currently sent is whenever the user saves. For interactive code modification tools that have to keep their own AST updated in real-time, this isn't the most ideal frequency. I have many reasons to desire finer-grained updates. One fairly simple example is when a GUI builder (that reverse-engineers Java code) wants to update its GUI editor view in real-time as the developer types Java code. In this case, the optimum time to receive JavaModel deltas is immediately after the Java incremental builder runs. Then the GUI builder's AST and editor can be updated with the new information and can intelligently respond to syntax errors in the code as it is typed. Why not just create your own incremental builder to handle this case? Because incremental builders get resource change notifications, not JavaModel change notifications, so an incremental builder would in effect have to reinvent the Java incremental compiler. This is wasteful in terms of precious processor cycles in between the user's keystrokes, not to mention duplicated coding effort. Again, it would make much more sense for the JavaModel deltas to be made available as the user types, removing the need to duplicate all this effort.
The incremental builder will only see changes if they got saved. Thus, this would provide the same granularity of refresh as today, except that the model is currently refreshed just after the incremental builder has run. We would like to change our updating story to be more frequent, but we need some notion of incremental deltas from the platform, so as to avoid refreshing more than once amongst the various notification stages (pre-build, post-build, post-change,...). If you are interested in fine-grain deltas as user types, then these aren't dependant on the incremental builder (which as I said before only see saved changed). The JavaModel already reconciles changes performed on working copies (which the editor is based onto), and will notify them as they are detected. You could simply listen to these fine grain deltas, and notice very detailed information there (fyi, this is how the outliner is refreshing itself).
Is it ok to close ?
Jerome, pls indicate to Dave how to enable fine-grain listening.
For the record, this is from a private e-mail exchange: > Did you register a listener using > JavaCore.addElementChangedListener(...) ? JavaCore.addElementChangedListener(listener); That should do it... :-) > If you did you > should get a delta each time the working copy is reconciled. > A working copy is reconciled about half a second after you > stopped typing. You can see the Outline react to these delta. > Of course if there are no structure changes in the source, > then no delta will be sent out. > > If this is not the behavior you're seeing, then I will need > more information from you, such as the build number you're > using, a test case that shows no working copy delta is sent out, etc. Okay, I think I figured out what's going on. I only see working copy deltas if an IMethod or IField was added or removed. I'm not seeing anything if a statement was added to a method. But in the scenario I report in bug 39570, I need deltas for statement additions/removals/changes as well. Is what I'm saying making sense or am I missing something still?
Sorry Dave, but only changes to the structure of the working copy are reported. Changes inside method bodies are not reported. I'm afraid this would be too costly to compute.
No plan to fix. Closing.
Okay; thanks.
