Package list findbugs / debian/3.0.1-2 design / DecouplingFromBCEL.txt
debian/3.0.1-2

Tree @debian/3.0.1-2 (Download .tar.gz)

DecouplingFromBCEL.txt @debian/3.0.1-2raw · history · blame

Decoupling FindBugs from BCEL

Document history:
DHH 7/3/2006: Created

Goals:

- eliminate tight coupling between FindBugs and BCEL

- Allow other bytecode frameworks (such as ASM and maybe Soot) to
  be used by detectors

   *** Detectors could even do their own scanning on the raw classfile
       data, without any bytecode framework
       (on either stream or byte array)

- Allow visitor-based detectors to use information from
  dataflow analysis framework.


Issues:

- We are reliant on BCEL's Constants and Visitor classes

- The bytecode analysis (ba) package makes heavy use of
  BCEL tree-based reprentation (generic package) and also
  the BCEL Repository and type classes (both of which have
  significant shortcomings).  The detectors which use
  the bytecode analysis package are also tightly coupled
  to these classes.


Strategy:

- Change the basic visitation strategy to remove dependence
  on the BCEL Repository and JavaClass classes.

  *** We should develop our own CodeBase and Repository abstractions

- The visitor classes and detectors will probably be the easiest
  to convert.  We can develop our own Visitor/DismantleBytecode
  interfaces, which can be concretely implemented using ASM,
  (or any other bytecode framework).  Obviously the detectors
  should not be aware which bytecode framework is being used.

  We will probably need to add our own equivalent of the
  BCEL Constants interface.   We will need some kind of
  general classfile representation package (to hide framework-specific
  details).

- After visitor-based detectors are working using new visitor framework,
  start work on developing new classes/APIs for more sophisticated
  (e.g., dataflow) analysis.  We should try to separate WHAT information
  is computed (types, values, nullness, etc.) from HOW the
  information is computed.  Clients (Detectors) should only be coupled
  to the classes representing WHAT is computed.

Notes:

- We should standardize on VM (slashed) type descriptors in all places
  where a JVM type is being referred to.  Dotted classnames should
  go away except when displaying such types to the user.
  
  *** This is how ASM represents types -> efficient

  *** We should probably develop a richer type abstraction eventually
      for the dataflow-based detectors, etc.