MQP:Netbeans API Overview
|
Why Netbeans?
There are a few reasons why taking the security analysis tool and integrating it with Netbeans would be effective. Netbeans already supports plugins for developing Glassfish applications, so development help could be available in the IDE for writing secure applications for Glassfish specifically. Netbeans uses a version of the javac representation of the parse tree and source model, which could be leveraged in static analysis. This representation can also be easily used to display information back to developers that could come from the security tool.
Existing Features
A few existing features of Netbeans seem they could be relevant for this project. The idea of doing a reverse lookup (like finding usages of a variable or method) is similar to the way our tool traverses call graphs (by looking for methods that call a given method). Netbeans also does several steps in the parsing of source code that could be useful in static analysis, in addition to compiling source files to bytecode. The classpath of library classes that are in jar files are also easily available through Netbeans' project structure.
Netbeans Source Model
Netbeans uses the structural model of Java bytecode found in the package javax.lang.model. This includes information about classes, their method signatures, and fields of the methods, and is specified by JSR 269. There is also a more fine-grain model of source that Netbeans uses in the package com.sun.source.tree. This package models more detailed information about the bodies of methods and the statements enclosed within. Were we to use this source model entirely (instead of another option like Soot's), this would be the model we would start with to represent a call graph.
While Netbeans is running, a plugin can request access to these source models at different levels of completeness in the parsing and compiling process. If a tool or plugin is running in the background of Netbeans, it should only request access to the level of information that it needs to perform its computation. If a user updates code while our tool is running, we would almost always need full information to update our analysis, since any method calls that are added or removed could affect the call graph.
Communicating Results
An important reason for doing IDE integration in the first place is to allow the tool to communicate with developers in a simple way and without having to switch environments. Netbeans would allow the tool to markup code or show information to developers in the editor window or with dialog boxes (say during a simulation mode). Things like the syntax highlighting that Netbeans already does, as well as graphical output of code coverage or other profiling tools, are good examples of ways that information can be quickly shown to a developer without leaving the IDE or being overly intrusive.
