Community
Participate
Working Groups
MarkerHelpRegistry.hasResolutions is used to get the enablement state for the 'quick fix' menu entry in the task view as well as to evaluate if a light bulb needs to be shown in the (Java) editor. The current implementation of MarkerHelpRegistry.hasResolutions is MarkerHelpRegistry.getResolutions().length; creating all proposals, which can be very expensive as it involves evaluating the problem context and returning the full and exact number of proposals. It would be better if the IMarkerResolutionGenerator would also offer a 'hasResolutions', so the implementor of the genenator can do a cheap guess, and do the more expensive proposal creations only when the dialog is shown. We do the same thing with the quick fixes in the editor, where the light bulb shows up on all error types that are handles, even it is still possible that the exact evaluation will find out that for this particular scenario, no corrections can be offered. Supporting now also contributed MarkerResultions, the performance problem of MarkerHelpRegistry.hasResolutions will show up as more and more contributions are coming. The problem is already now showing up for the context menu of the task bar for Java errors, as for calculating the resolution an AST has to be built.
*** Bug 31311 has been marked as a duplicate of this bug. ***
Also, when stepping across tasks in the task list, it should not trigger resolution computation until I activate the contextual menu.
I would suggest to increase the priority of the bug. If we have no solution for 2.1, we (JDT-UI) have to disable - the showing of lightbulbs for markers that have contributed resolutions for non-Java markers - Quick fix proposals in the task list for Java problems due to performance problems. A suggested fix is to add a new extension interface IMarkerResolutionGenerator2 (or IMarkerResolutionGeneratorExtension) that contains a method 'boolean hasResolutions'. All contributers of a IMarkerResolutionGenerator can additionally implement IMarkerResolutionGenerator2. (The usual extension story)
There is nothing in the contract for IMarkerResolution or IMarkerResolutionGenerator stating that the resolutions returned by getResolutions(IMarker) have to be complete and exact. IMarkerResolutionGenerator states: * Creates resolutions for a given marker. * When run, a resolution would typically eliminate * the need for the marker. IMarker states: * Resolution for a marker. When run, a resolution would * typically eliminate the need for the marker. Note the "typically" in the above. It should be possible to return the list of possible resolutions, and then determine later when run that it does not apply. While I agree that it would be more elegant if IMarkerResolutionGenerator had a hasResolutions(IMarker) method, the only way we could add this now is by defining a new interface, e.g. IMarkerResolutionGenerator2. For 2.1, I don't see the need to do this if the current contract already allows what you want though.
This is on the "hot list" of PRs to address for 2.1 based on input from the other teams, so I'm tagging it for RC1. Please let me know if it's possible to get by with the current interfaces for 2.1.
No guess is most time not possible. It is like a code assist. The number of proposals and even the proposal label depends on the analysis. Let me illustrate: E.g. 'a.b= 1;' 'a.b' can not be resolved: -> if 'a' is an existing field: - Create b in A (type of 'a') - Offer renames to fields in A that are similar to 'b' -> if 'a' is an existing type: - Create b in 'a' - Offer renames to fields in 'a' that are similar to 'b' -> if 'a' can't be resolve, look if there's a type called 'a' - Add an import for 'a' -> look if there's a type similar to 'a' -> look if there's a field similar to 'a' All renames have a open number of proposals. Even if it's possible to evaluate a typical set of proposals that could be offered without evaluation, to change all my code to now offer proxies would take over a week, so I would strongly favor an extension interface.
For 2.1, couldn't Platform/UI avoid calling #hasResolutions until I expand the right click menu ? Bug 31311 was actually stressing that point (resolutions are invoked while stepping across tasks). I agree though that #hasResolution is highly desirable, but shouldn't prevent to insist on the fact that clients should provide lightweight IMarkerResolutions in response, where the *hard* work is only supposed to be lazily performed when run is invoked. So these further improvements could be budgeted for 2.2, IMHO.
Martin, would Philippe's proposal work for you? To try this out, in TaskList.java, move the resolveMarkerAction.setEnabled... code from selectionChanged to fillContextMenu.
Philippe's proposal works well for the task list but does not solve the problem for the Java Editor's vertical ruler. As Martin points out, we use a special icon to indicate the presence of a quick fix resolution. For Java problem markers we can control how the icon is determined. For any other problem marker we are out of control. As the vertical ruler determines the icons on demand, it could happen that scrolling in the editor freezes the editor for the time that is needed to compute the proposals. Nevertheless, Phillipe's proposal would still make sense. What is the problem with introducing a new interface?
Just want to ensure there's a real need for new API. Looks like there is.
Added IMarkerResolutionGenerator2, made Philippe's suggested change to only update enablement when popping up menu, and upated Readme example to use the new interface. In I20030213.
