Bug 198133 - IJavaelementDelta does not contain of CompilationUnit changes when adding/removing packages
Summary: IJavaelementDelta does not contain of CompilationUnit changes when adding/rem...
Status: VERIFIED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.4 M2   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-27 13:02 EDT by Tom Mutdosch CLA
Modified: 2007-09-17 08:34 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Mutdosch CLA 2007-07-27 13:02:38 EDT
Using eclipse 3.3.

I have a JavaElementChangeListener and I am trying to listen to when new CompilationUnits are added and removed (I'm keeping a list of Java files with a particular annotation in them).  This works fine when I add/remove a Java file.  But if I remove a whole package or copy an existing package to a new location, my listener gets a Delta that ends with IJavaElement.PACKAGE_FRAGMENT.  That is, there are no affected children elements there.  So I can not act on IJavaElement.COMPILATION_UNIT as I can in the normal case.  

I realize that I can get the compilation units from the IPackageFragment, but that only works for an IJavaElement.ADDED scenario.  If a package is deleted, I can't seem to get notified of the deleted compilation units that were within the package.  I expected them to be in the IJavaElementDetla.
Comment 1 Jerome Lanneluc CLA 2007-08-10 06:24:42 EDT
This is per design. We don't keep the list of all compilation units in the workspace for performance reason.

For you particulat problem, can't you go through your list of Java files and remove the ones whose parent is the deleted package ?
Comment 2 Tom Mutdosch CLA 2007-08-10 09:11:49 EDT
Yes, I can do that.  It's just not as nice, since I have to have duplicated logic in my changeListener (handleCompilationUnitDelete, handlePackageDelete) and instead of just removing the deleted compilation units from my list, I have to iterate through the entire list looking for matching paths (I actually just store the Java file path, not the compilation unit).  

So I just thought it would be easier; I didn't realize it was done for performance.  I guess the performance hit goes to the clients instead of the JavaModel, which is probably better :)  So I still think it would be good to have this functionality, but if there's no real good way performance-wise, then I'm fine with closing this out.

Thanks for your reply.
Comment 3 Jerome Lanneluc CLA 2007-08-10 09:51:57 EDT
You're welcome. We have no plan to change this behavior for now, so I'm closing this bug.
Comment 4 Maxime Daniel CLA 2007-09-17 08:34:41 EDT
Verified for 3.4 M2 using build I20070917-0010.