This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 207815 - Create a framework to integrate static analysis tools
Summary: Create a framework to integrate static analysis tools
Status: NEW
Alias: None
Product: editor
Classification: Unclassified
Component: Hints & Annotations (show other bugs)
Version: 7.2
Hardware: PC Windows 8.1 x64
: P1 normal with 2 votes (vote)
Assignee: Milutin Kristofic
URL:
Keywords: PLAN
Depends on:
Blocks:
 
Reported: 2012-01-27 09:17 UTC by Jan Lahoda
Modified: 2016-10-03 08:20 UTC (History)
7 users (show)

See Also:
Issue Type: TASK
Exception Reporter:


Attachments
When any file is added and opened then the editor is not showing the programming space (156.87 KB, image/jpeg)
2016-10-03 08:19 UTC, Rahul_Bhat
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Lahoda 2012-01-27 09:17:51 UTC
A framework to integrate static code analysis tools, like FindBugs (#207814) should be created.
Comment 1 Vladimir Voskresensky 2012-01-27 11:52:07 UTC
Nice to see such activity. I hope it's general, not Java centric :-)
Could you, please, consider in infrastructure, that some static analysis engines provide "explanation of bug" which should be shown to user as set of connected annotated steps to prove that i.e. memory-leak error is real.
Have a look at the following as example of "annotated error paths":
http://developer.apple.com/library/mac/#featuredarticles/StaticAnalysis/FeaturedArticle.html
Comment 2 Jan Lahoda 2012-02-17 08:07:16 UTC
I have created an experimental branch, in http://hg.netbeans.org/prototypes called "code.analysis". I should start with saying that this is all preliminary/experimental. It has a basic support for running a static analysis tool over all opened projects. A build with javadoc is here:
http://deadlock.netbeans.org/hudson/job/prototypes-code_analysis/

Notes:
-it adds String id and CharSequence details into spi.editor.hints' ErrorDescription(Factory). Id is used for sorting and will be used for filtering. Details are shown in "Code Analyze" window when an entry is selected. I am also considering showing (although not sure if I will succeed) the details in the error tooltip in the editor under "More..." (so that errors can be short and if an explanation is needed, the user may expand it).
-is creates a new module and SPI, code.analysis ("Static Analysis Core"), which defines a dialog showing analysis result for the whole projects (menu: Source/Code Analysis).
-current, the Scope to analyze is inferred through (Scope is refactoring.api's Scope):
--looking into the Project's Lookup, looking for Scope, if there is one, it is used. (Which not project have.)
--using whatever source ClassPaths are registered for that project to the GlobalPathRegistry.
--using generic source group of the project as a fall back.
I am however thinking about possibility of a ScopeProvider:
interface ScopeProvider {
    Iterable<? extends Scope> create(Lookup l);
}
which could be registered to be both global, and project-local.

I am aware of analysis frameworks that record some kind of traces - I am not sure how to support them exactly.

If you would have a particular insight on the API, how to extend it to incorporate the trace (better than putting them into "details", of course) or even could try to integrate a static analysis tool, that would be awesome and would give us more experience needed to design the API.

Thanks.
Comment 3 Vladimir Voskresensky 2012-02-17 09:09:01 UTC
(In reply to comment #2)
> I am aware of analysis frameworks that record some kind of traces - I am not
> sure how to support them exactly.
> 
> If you would have a particular insight on the API, 
Probably we need Traces API/SPI for that.
It can be general enough to be used not only in code analysis.
I think Trace can be presented as annotated directed graph structure, where "nodes" and paths between nodes can have associated properties and actions.

Traces API would need Trace UI API/SPI.
For instance:
Editor infrastructure can help to visualize "nodes" by underlying [startNode,endNode] text range and paths can be visualized as painted arrow between [startPath, endPath] offsets in editor. 
https://developer.apple.com/library/mac/featuredarticles/StaticAnalysis/Art/uninitialized.jpg

Hovering mouse over path gives tooltip with details for that path.
Hovering text range of node gives tooltip with details for node.
There could be shortcut to show details for all paths; show details for all nodes; show details for nodes and paths.

Btw, as simple example of Trace and Trace UI we can consider debugger's callstack and it's current ui presentation as list.
Another example is CallHierarchy model and it's UI.
Comment 4 Jan Lahoda 2012-02-17 09:31:44 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > I am aware of analysis frameworks that record some kind of traces - I am not
> > sure how to support them exactly.
> > 
> > If you would have a particular insight on the API, 
> Probably we need Traces API/SPI for that.
> It can be general enough to be used not only in code analysis.
> I think Trace can be presented as annotated directed graph structure, where
> "nodes" and paths between nodes can have associated properties and actions.

Hm, my way of though so far was adding "sub-errors" into ErrorDescription (or something similar) - there is a problem with the direction between the "(sub-)errors". Anyway, this sounds like that we may need to gain real experience with this kind of stuff before designing the API, so I would rather implement something flexible enough for this to be done in the clients until we gain enough experience (with several tools) to design an API.
Comment 5 crazyjavahacking 2012-02-17 11:54:15 UTC
Will this be part of the NetBeans 7.2 (even like a development API) ?
Comment 6 Rahul_Bhat 2016-10-03 08:19:13 UTC
Created attachment 162313 [details]
When any file is added and opened then the editor is not showing the programming space