Community
Participate
Working Groups
Created attachment 110145 [details] Stack traces of add() and remove() calls of CommonViewer When looking into bug 242762 I put some printlns in CommonViewer.remove() and .add() and discovered that the .remove call was being made both by the JDT code and the CNF resource code each time the Java Project was removed (I was using the new project wizard and going back and forth between where it actually creates the project (as instructed in bug 242762). The attachment shows the stack traces. This seems wrong, seems like the JDT should not call remove when the project is removed for the Project Explorer case as this is already taken care of. I note that I did not see the same behavior in when adding the project. The add() call was made only by the CN resource code.
This is how it works since day one of CN and removing the same element more than once shouldn't do any harm. The registered content provider does too much (not only on remove but also on add) because it cannot assume what the main common navigator content provider does and whether there are other more specific content providers registered. Now, if the owners of CN tell us how clients can resolve that we will be more than happy do fix it. For now I see no way for us to do this. Note that one way might be to do existence checks but that's normally more expensive than removing it twice. So - I can either mark this as WONTFIX (but rather it's CANTFIX ;-), or move back to Platform UI to provide API and/or guidelines how clients can fix this problem.
(In reply to comment #1) > This is how it works since day one of CN and removing the same element more > than once shouldn't do any harm. The registered content provider does too much > (not only on remove but also on add) because it cannot assume what the main > common navigator content provider does and whether there are other more > specific content providers registered. Now, if the owners of CN tell us how > clients can resolve that we will be more than happy do fix it. For now I see no > way for us to do this. Yes, I agree with you, you should not have to assume what the other content providers are doing, and it's hard to check (which is not what I first thought when filing this bug). Oh, and I'm the current (and only) owner of the CN (Michael is no longer working on it)
