Community
Participate
Working Groups
build 20030211 JDT is in the process of implementing the IContainmentAdapter for Java elements. The task list should leverage this for the filter option that displays markers in the selected resource and its children. It is already used when the markers are filtered on a working set. This would fix the problem of seeing markers that are in packages other than the selected package, e.g., when selecting org.eclipse.ui.internal you also see markers that are in org.eclipse.ui.internal.actions.
*** Bug 32292 has been marked as a duplicate of this bug. ***
Knut, can you make this change since you added this support for working sets?
I don't think we can use the IContainmentAdapter for the TaskList, at least not without API changes to the task list. The problem is that the task list uses the ITaskListResourceAdapter to get the resource that provides markers for the selection (e.g., a type in the package explorer). If the adapter were to provide just the adaptable it would work. I could get the containment adapter for my purposes and the resource for compatibility with existing API. We would need something like an ITaskListAdapter that returns an IAdaptable instead of an IResource. CCing Chris for a second opinion, to make sure I didn't miss anything.
ITaskListResourceAdapter is used to obtain the resource from which to obtain markers. It is used in cases where the model does not want to adapt to IResource. For example, java methods don't want object contributions against IResource (e.g. the Team actions), but do want to show tasks. Could you not obtain the corresponding resource using ITaskListResourceAdapter, then check the child resources using IContainmentAdapter?
In the Java type/method case the containment check could not validly return true when I pass in the file that contains the markers. I'm asking the type whether it contains the file or whether it's equal to it. The marker file/resource is a parent of the containment context. In general, if an element does not want to adapt to IResource directly then the resource it returns in the task list adapter may not be contained by the element.
I see.
Defer
The suggestion to use the logical rather than physical structure for marker searches is good, but IContainmentAdapter is too slow for this purpose (see bug 44443). It will probably be necessary to back out of IContainmentAdapter support in working sets eventually. Using the JDT's current IContainmentAdapter, it takes over 10 minutes to test if 10,000 markers are contained in a Java working set of 100 elements. If this were to be done for every selection change, it would need to run in under 100ms (keep in mind that this might be done independently by the task, problems, and bookmark views)... so it would need to be about 10,000 times faster. Assuming this degree of optimization is possible, IContainmentAdapter can only determine whether or not a particular marker is within the selection. It cannot direct the search. This means that every marker in the workspace needs to be tested against every object in the selection, for a best case runtime of at least O(m * s), where m is the number of markers and s is the selection size. This will grow unreasonably with large workspaces. We should investigate describing the logical structure using an interface that can be used to direct the search.
I think it's reasonable to assume that you only need to query the markers for the resources underlying the selected object(s), then filter using the containment adapter. Could you please investigate this for M7? Does the JDT team know about the problem with their current implementation if IContainmentAdapter?
Re: comment 9 This has several problems. 1. This assumes that the selection is an IResource. It is possible (even likely) that the logical structure will be represented using a different class than the physical structure. The JDT's package explorer is a special case. 2. This makes the assumption that the logical parent is always a physical ancestor. This is true for the JDT, but may not be true in general. 3. This will only work if the JDT speeds up their IContainmentAdapter by several orders of magnitude, assuming this is possible. 4. With the optimization, IContainmentAdapter still needs to check all the markers below the selected resource. An interface that directs the marker search does not need to process irrelevant subtrees. Even in the JDT (which is probably the best case for this optimization), this slows down processing by several times. It is quite common to have Java projects contianing 10 or packages. Assuming markers are evenly distributed among the packages, an IContainmentAdapter filter would need to examine 10 times as many markers when the root package is selected. If we were only talking about a few milliseconds, I would agree that optimization probably isn't so important -- but this enhancement suggests performing an operation on every mouseclick that currently takes 10 to 30 minutes ("minutes" is not a typo). This is completely unreasonable. The runtime can be easily verified. Install an integration build from 20031208 or earlier, create 10,000 or more markers, open the Problems View filter dialog and create a Java working set filter containing 100 distinct files (and not their enclosing packages). Measure the time between clicking "okay" and when Eclipse starts processing mouseclicks again. Bug 6904 has an excellent suggestion for an IMarkerProvider interface that returns the markers contained within some other object. This (or a similar interface) could be used to direct the marker search without filtering. It would remove the performance bottleneck, remove the Marker View ties to IResource, and solve this logical-to-physical problem. This would be a much more productive line of investigation. Bug 8043 reports the original logical-versus-physical problem.
