Re: Contributing SQE project to NB repository

On 01/18/2012 05:44 AM, Jan Lahoda wrote:
> our ability to make the scans "fast" and "unobtrusive" are certainly going to be
> limited, compared to our own technologies.

Of course. Will need to be investigated how flexible FB's setup is. Ideally we would be able to supply a custom class file provider (so that existing *.sig could be 
loaded directly, rather than copied to *.class first, which is quite wasteful); and we would be able to monitor detailed progress of the various detectors and cleanly 
interrupt the scan within a few msec of noticing that some higher-priority task is coming in. I think we could get patches into FB core if we needed them.

> I would prefer if there would be one "Static Analysis Result"
> window, into which various tools could provide warnings.

The question is whether the existing Task List window should be used for this purpose, or whether we want a separate window with a specialized UI. The obvious tradeoffs: 
a separate window could show richer information (such as the bug explanation in SQE's FindBugsTopComponent); the Task List window can show a consolidated view with other 
kinds of warnings (making better use of screen space) and has an integrated navigation system.

> There are quite a few tools that analyze the code, including domain-specific ones

Do you have some examples of other tools (that would be in 7.2) which would perform some kind of analysis that would naturally fit in the same window? Something in EE 
perhaps? Creating a generic infrastructure (UI, API) for displaying analysis results makes sense if there are several known tools which would be offered in the standard 
7.2 distribution, so we have a good feel for what the possible variations are. If it is just FB in 7.2, it seems premature to create an abstraction for this.

One consideration is that FB (a) operates on class files, not sources, (b) can perform cross-class analysis (though a resulting warning generally points to a single 
source line). This contrasts with Checkstyle and PMD which scan individual source files; and with existing Java editor hints which scan a source file after it has been 
parsed and decorated with semantic information.

The UI needs to consider what the user does to request, acknowledge, and handle warnings. There are four styles of workflow I know of:

1. Editor hints of all kinds, which are refreshed automatically as you type (or in the case of SQE FB, when you save, since it needs class files). May be shown in Task 
List as well as editor. If the hint is a false positive, there is a "fix" offered of adding @SuppressWarnings, or of just disabling the detector. (Obviously there may be 
true fixes offered as well; FB itself does not help at all here.)

2. The classic FB standalone UI, and SQE's FindBugsTopComponent, where you explicitly run the tool e.g. with a button click, and it shows all results typically per 
project. Less sensitive to performance issues, but less convenient to run, and fails to alert you to mistakes as you code. No good way to deal with false positives.

3. The FB 2.0 bug classifier UI, which is like #2 but offers ways of categorizing warnings and sharing them with other developers so you do not repeatedly see false 
positives.

4. Analysis run on a server like Hudson, and results displayed as in #2. Good for getting an overview of the health of a project as a whole, and pointing out regressions. 
Has the big drawback that you cannot easily check whether a code change clears up a warning.

Sven Reimers wrote:
> this was one of the goals of SQE - to
> make integration easier by providing hooks and infrastructure into the
> complicated hints and java editor infrastructure.

That makes sense as a goal for an external project prioritizing ease of integration of lots of tools, but it is not necessarily the right goal for a feature maintained as 
a standard product feature where tight UI integration and performance are the priorities and implementors can be expected to use the full power of the standard hint APIs.

> It is probably not good if every plugin writer starts with same
> problems, e.g. accessing maven config info from NetBeans/Maven API's.

Every new API brings its own problems. In the case you mention, I am looking at core.maven and most of it is just serving as a wrapper for APIs already defined in the 
IDE's Maven modules. The only real added code is findDependencyArtifacts, which (if cleaned up and tested) might be useful in the Maven modules themselves; anyway it is 
not used by the FB integration.