VDB format
Methods in the Framework for Frameworks API require Strings
representing
type names or method signatures to be in VDB format. VDB type names
are simply fully-qualified source-level names (for example, java.lang.String
)
- or, in the case of inner classes, represented with a dollar symbol
($
)(for example javax.swing.text.DefaultEditorKit$DefaultKeyTypedAction
).
For .NET
, short names such as int
and string
should
be avoided when using the Framework for Frameworks API. Instead, use
fully-qualified names such as System.Int32
and System.String
.
A VDB method signature consists of these two parts:
- The method name, including the fully-qualified name of the enclosing
class (for example,
java.lang.String.substring
). - A descriptor for the method, giving the parameter types and return
type. The parameter types are enclosed in parentheses and separated
by semicolons (
;
). The closing parenthesis is followed by a colon (:
), and then the return type.
An example VDB method signature is:
java.lang.String.substring(int;int):java.lang.String
An example VDB method signature from an inner class is:
javax.swing.text.DefaultEditorKit$DefaultKeyTypedAction.
actionPerformed(ActionEvent):void
For most API methods requiring a String
in VDB
format, there is often an equivalent method that takes an IClass
or IMethod
object
instead. For example, method F4FActions.addTaintedCallback(String,int)
requires
its first parameter to be a VDB-formatted method signature - while F4FActions.addTaintedCallback(IMethod,int)
identifies
the method with an IMethod
object. Using the API
methods that take IClass
and IMethod
objects
may be more convenient for these reasons:
- The user need not worry about VDB formatting for these methods as this is handled internally.
- In obtaining the
IClass
orIMethod
object (for example, viaF4FApp.getClassMethods()
), one ensures that the corresponding class or method actually exists in the application code.