Find usages - taking into consideration type parameters

Dmitry said:

By the way, a less intrusive solution to this would be grouping/filtering usages by type parameter value in the Find Usages results. What do you think about it?

Some refactorings rely on find usages.
I know rename is one of them, but I always want to rename the class regardless of the type parameter.

What other refactorings are affected by find usages?

If none of them need to be performed differently depending on the type parameter, then the grouping/filtering idea is very good.

The refactoring question is actually somewhat irrelevant; although the underlying logic is the same, the top-level UI is different, and implementing the originally requested feature would not mean that you will get an extra prompt when invoking Rename or a similar refactoring.

There is already a "Find usages" dialog for classes with option checkboxes like "Search for text occurrences". What about adding 2 new checkboxes:

• "Restrict results to usages with matching type parameters" (or something like that)
• "Also search for raw type usages"

The checkboxes would be disabled if the actual type parameter(s) cannot be determined at the search site.

To get a taste for the commercial value this feature would have I'll tell a story. This would be a serious benefit for developers on our codebase. At a ballpark this would save us tens of thousands of dollars in lost productivity per year, greatly increasing the (already significant) value we get from our org-wide IntelliJ Ultimate Toolbox subscription. We have over one hundred seats now and that is only increasing.

We have a lot of generically bound implementations of very few highly generic interfaces and it makes finding implementations quite difficult in the current implementation of Find Usages. This is exacerbated by our use of dependency injection. If we could find usages with type parameters it would dramatically speed time to resolution on certain issues because we'd be able to quickly find dependency binding sites at minimum.

We inject implementations of Function in many places. To make matters worse they are bound in Guice modules to ComposedFunction classes that generically depend on other pairs of injected Functions. The lack of type parameter resolution in Find Usages makes finding either bindings or implementations quite difficult.

The alternative is writing explicit interfaces for all of the various combinations we have in play. The error-prone code duplication that would result is the reason why generics were introduced in the first place.

This problem would disappear entirely if Find Usages took type parameters into consideration. For the encouragement this gives to using generics to improve quality to the serious bottom line dollars benefit to your customers I think this is worth doing.

@Alain: I may be wrong, but I think structural search may be a workaround.

@Christian: Thank you. I think it can work, but it's tricky to use. In the meantime I'll try that and document clear directions for doing it quickly.

Thinking of productivity, constant use during the day would be much faster with Find Usages. My colleagues are doing these searches dozens of times per day and the difference between 1 second (Find Usages) and 1 minute (Structural Search) per search would dramatically improve their day. For a while I'm not sure Structural Search would outperform their existing search approach.

@Christian: I just tried Search Structurally and it does work really well for this now. It's been a long time since I used it. I was able to copy a generically typed injected field and find the bindings for it. Thank you!

Procedure for using Structural Search to find usages of generically typed code:

1. Select the type with generic type parameters you want to find usages of
2. Invoke "Search Structurally.."
3. Click Search
4. Expand "Type parameter" grouping to find type usages like Guice DI bindings

This is almost as fast as Find Usages. Binding Search Structurally... to a key is probably a good idea if you do this a lot.