Offline-only Inspections - can Selena's background processing change this?

I take it that "(available for Analyze|Inspect Code) " means that an Inspection is not available as an in-editor inspection. What is this restriction based on? Performance? API? Logical? Other? For those that the restriction is related to heavy processing, can that calculus change now with Selena ready put more in the background & take advantage of multi-core development machines?

8 comments
Comment actions Permalink

It's all about performance, in it's most brutal big-O-notation sense. Editor inspections should be linear in the size of the file, off-line only inspections may not be. Occasionally this is fudged (a few editor inspections are linear in the number of subclasses or superclasses of the current file), but mostly that's the rule. The canonical example of inspections not available in the editor is dead code analysis, which requires a full connectivity analysis of the method call tree, a process which theoretically implies looking at every file in the project. Adding more cores does only a limited amount to make that potentially very expensive analysis feasible. One could theoretically develop an IDE which caches a bunch of intermediate dependency calculations and recursive traversal answers, keeps them up to date as editing occurs, and is thus able to answer those questions in real-time, but IDEA isn't there yet, and nothing else is even close.

Now you can make batch inspections visible in the editor, but only with a fair amount of effort and ritual. You need to run the inspections off-line in TeamCity (which process still has a fairly harsh learning curve, I'm afraid), and then import them into your project via the TeamCity plugin. It's impressive, but the interactive usability you are used to with other inspections is obviously sacraviced. Like the dancing bear, the fact that it works at all makes you forget to question that it works well. Ask again in a few more years, and the cutting-edge of technology will have presumably changed, but until then that's the state of the art.

--Dave Griffith

0
Comment actions Permalink

Interesting & insightful. Is there any way the "Unused method parameters" inspection-- or a less clever version of it-- could run online?

0
Comment actions Permalink

"Unused Method Parameters" would require time linear in the number related classes (subclassessuperclasses subclasses of superclasses + any combination thereof) of the class, making it one of those fuzzy edge cases that could be implemented in the editor but is risky.
Note that the analysis is actually linear for private methods, static methods, and constructors, and that inspection already is implemented in the editor. A slightly smarter version of that, which checks all methods that aren't overridden/overriding, would also be linear time, and probably very useful. I would suggest submitting a JIRA for that, if you are interested.

--Dave Griffith

0
Comment actions Permalink

A case I ran into was a method implementing an interface but otherwise not overridden/overriding - I assume that would qualify as well? New feature request:
http://www.jetbrains.net/jira/browse/IDEA-11265

Strange....I didn't know that some inspections do a subset of their inspecting online. The UI in Errors doesn't really indicate it, just makes it seem like Unused Method Parameters runs off-line only.

0
Comment actions Permalink

Depends. If that interface had other implementations, then it wouldn't be linear time. You need to catch not only ancestor and descendent implementations, but also sibling and cousin implementations as well.

--Dave Griffith

0
Comment actions Permalink

Is that so that the inspection can put the warning on the original interface? If there were multiple implementations, why wouldn't you want to warn when a particular implementation has an unused parameter? I could see not warning when the implementation does nothing other than throw some sort of RuntimeException like UnsupportedOperationException.

0
Comment actions Permalink

The reason to have the inspection (to my mind at least) is to indicate places where the parameter could be removed. You can't remove the parameter if it used in a sibling or cousin, even if you don't use it yourself. There are valid design patterns like that, the Null Object pattern in particular.

--Dave Griffith

0
Comment actions Permalink

True. Bug situations that I've run into are simple, local analysis-only to note that by accident the parameter isn't being used locally. For example, here's a bug where allCars isn't used and the member variable cars is where allCars should be.
private Car cars;
protected List filter(List allCars) { List filteredCars = new ArrayList]]>();
for (Car car : cars) { // <---- this should be allCars and not cars
if (!car.isSelectedForDda()) {
filteredCars.add(car);
}
}
return filteredCars;
}
This situation wouldn't be one where you'd want to remove the param - just be aware that it isn't used.

So, could a local-only version of this run online? Only if it finds a local problem, then perhaps it could run more broadly in the way you intend or perhaps only with the user using an Intention to accept a deep, non-local analysis?

0

Please sign in to leave a comment.