Transcript FMuOS: Java PathFinder Model checking of Java programs Prepared by: dr. sc.

FMuOS: Java PathFinder
Model checking of Java programs
Prepared by: dr. sc. Alan Jović
Ac. year. 2014/2015
Contents
About Java PathFinder
 Structure of Java Pathfinder
 Program properties specification and
checking
 Advanced topics and extensions
 About 2nd homework

ABOUT JAVA PATHFINDER
P. Mehlitz
N. Rungta
C. Pasareanu
W.Visser
What is Java Pathfinder?


Java PathFinder (JPF) is a framework and tool set for formal verification
of programs written in Java programming language using model
checking
JPF is a very complex framework that offers many possibilites for
extensions
◦ “...the swiss army knife of JavaTM verification”





JPF is being developed by a team of NASA scientists in collaboration
with a significant number of universities, individuals and companies
throughout the world (alegedly more then two dozen of collaborators,
including the Fujitsu company)
At the moment, verification of Android application using several JPF
extensions is a hot research topic
JPF is an open source tool distributed under GPL license
The main project (jpf-core) 200+ kSLOC + extensions
The core of JPF is a virtual machine (VM) which is run on top of Java
VM in order to enable model checking of user programs
Development of JPF-a
1999 - the projekt started by development of JPF as a translator for a
subset of Java 1.0 language into the Promela language for the SPIN
tool used in formal verification
2000 - re-implemenation of the system as a virtual machine for
model checking (discovery of typical defects in concurrent
execution)
2003 - introduction of extensions interface
2005 - the system becomes open code on the SourceForge website
2008 + - code improvements by taking part in the Google Summer of
Code
2009 - the system was transfered to its own server that supports
various extensions as well as Wiki pages:
http://babelfish.arc.nasa.gov/trac/jpf
http://babelfish.arc.nasa.gov/trac/jpf/wiki/projects/start
2010+ - further improvements in system extensions and
documentation
Why was JPF developed in the first
place?
Code coverage is an important property to verify in critical applications – e.g.
orbiter launch (NASA)
 It was required that automatic encoding of UML statechart diagram into Java
programs and then testing in order to discover whether all parts of the code
are reachable
 If parts of the code are represented
as program states, then we talk about
reachability analysis
 In this particular case, the
action checkSensors() testing
sensors at the entrance of the state
EarthOrbit, however, the exact
variable earthSensorsOk/Failed
is checked later – it is entirely
possible that the action setMajorMode() resets sensors so that

SafeHold state becomes unreachable
Why was JPF developed in the first
place?
The event lasJetisson() – separation of launch abort system (LAS) from craft
 lsamRendevous() – connect with second craft – it won’t work if
lasJetisson()is not performed in the Second Stage state, however this is not
ensured in the diagram
 Ascent and EarthOrbit module may
have been developed by different
engineers
 Assertions are introduced that should
be satisfied:

class OrbitOps {…
void lsamRendezvous(){…
assert !spacecraft.contains(LAS) :
”lsamRendezvous with LAS attached”
…
} …
}
What can Java PathFinder do?


JPF performs model checking over compiled Java applications (in
the simplest case if checks only one class) – application that is being
checked is called “System under Test” (SUT)
SUT Java application can be written in three ways:
1.
2.
3.


independent of JPF (the most common case)
in support of JPF – contain certain annotations used by JPF
dependent of JPF – written exclusively for JPF (rare case)
Specification of properties that SUT should satisfy is done through JPF
configuration (a set of configuration files)
JPF generates a report in which the result of model checking is
provided
When to use JPF?
JPF is not suitable for use in sequential programs with small number of
well-defined input values – unit tests are more suitable!
 JPF is mainly used for 1) exploring alternative executions and 2)
execution inspection
1. Exploring alternative execution

◦ Scheduling sequences – concurrent applications are the most common reason
of use because:


Defects such as deadlocks and races are usually subtle and difficult to find
Job scheduler is usually difficult to control from the testing environment. JPF is essentially the
owner of job scheduler because JPF is a VM that explores all interesting scheduling
combinations
◦ Variations in input data – JPF allows exploration of the set of input values which
can be defined by heuristics (e.g. values on or above certain threshold), which is useful
for writing testing drivers
◦ Environment events – program types such as Swing or web applications usually
react to external events such as button press. These events can be simulated in JPF
◦ Program control flow choices - JPF systematically explores the control structure
of the programs (branching instructions) by calculating the input values required in
order to pass through every branch of code
2. Execution inspection
◦ In JPF, code coverage analyzers can be implemented or specific noninvasive tests can
be performed that can discover conditions which are usually difficult to find (e.g.
overflow, underflow)
What can JPF discover?
The core of JPF-a (jpf-core project) discovers so called
“nonfunctional properties” – defects which VM can
identify without the need for specification of any additional
program properties. This includes: deadlock, races, uncaught
exceptions (also Java’s assert checks). Manifestion of
nonfunctional properties should not occur in any application
 Extensions of JPF discover various properties specified by
the user – mainly using listeners – add-ons which enable
strict monitoring of all actions performed by JPF, e.g. certain
instruction executions, object creation, occurrence of certain
program states and far more. A typical example is a specific
race detector, which clearly identifies asynchronous access to
shared variable in concurrent programs
 JPF enables reporting of complete execution history –
trace, down to the level of single bytecode instruction, that
lead to defect detection. This is particularly useful for
understanding deadlock and similar situations that are
difficult to detect by common testing

An example of race detection
public class Racer implements Runnable {
int d = 42;
public void run () {
doSomething(1001);
d = 0;
// (1)
}
public static void main (String[] args){
Racer racer = new Racer();
Thread t = new Thread(racer);
t.start();
doSomething(1000);
int c = 420 / racer.d;
// (2)
System.out.println(c);
}
static void doSomething (int n) {
// not very interesting..
try { Thread.sleep(n); }
catch (InterruptedException ix) {}
}
}
Two threads are accessing the same variable
d.
Division by zero occurs when the second
thread (the one created from the first one
inside of main method) executes instruction
(1) before the first thread executes
instruction (2).
If the first thread executes instruction (2)
first, the division will be find (the result is 420
/ 42 = 10)
Without any additional configuration, JPF will
find the uncaught exception:
java.lang.ArithmeticException –
division by zero
With configuration (using
PreciseRaceDetector listener), JPF will
give exact code lines (1) and (2) that cause
the race.
How does Java PathFinder work?
JPF is a virtual machine which executes our SUT not only
once (as Java VM does), but in all possible ways, checking
whether deadlocks occur, or whether uncaught exceptions
happen
 If defect location is found, it will report about every step
from the start to the place of the defect
 In the common way JPF is used (jpf-core), JPF is an
explicit state model checking tool. This means that it
memorizes:

◦
◦
◦
◦

specific local variable values
thread stack frame
heap objects
thread states
Explicit state model checking leads to state explosion
problem
Java virtual machine internals
These two areas are shared by all threads
Java virtual machine internals



Class files – compiled code – intermediate code (bytecode) of
application classes with additional informations
Class loader subsystem – mechanism for loading types (classes and
interfaces) given with fully qualified names (e.g. java.awt.Rectangle)
Runtime data areas – memorijski prostori koje organizira JVM
(ovisno o implementaciji VM)
◦ Method area – contains information about class methods, attributes and
others
◦ Heap – a space in memory used for storing objects, reserved when
starting VM, garbage collector operates over it
◦ Java stacks and PC register – each thread, when it is created, it obtains
its own stack and program counter (PC register). The stack is organized
into stack frames, each frame is a single method call – arguments of the
call, return value, local variables and intermediate results are stored; PC
register shows the next instruction which will be executed
◦ Native method stack – threads that execute native methods (methods
dependent on the operating system), they have a separate stack reserved
for these methods

Execution engine – mechanism for bytecode instructions execution
Thread states in Java
Thread scheduler of JVM controls
thread execution sequence, here the
priority of the thread plays and
important role
The thread ends after exiting
its run()method
Thread states in Java

Critical section (monitor) in Java can be a method or a block of
instructions that have synchronized keyword written in front,
e.g.
synchronized(obj) {
while (<condition does not hold>) obj.wait(); ...
// Perform action appropriate to condition
}




Thread that calls wait() or notify() or notifyAll()
has to be found in the critical section (so called monitor owner)
By calling wait() , a thread stops being an owner of the monitor
and waits until another thread calls notify()
By calling notify() , a single thread is picked that was waiting for
the monitor and that thread will now continue to compete for
critical section execution when the current thread is done with it
By calling notifyAll() all threads are awoken that are waiting
over an object’ts monitor and then they continue to compete
“Solving” state explosion problem in JPF – state
space reduction

The first way: state matching
◦ Each time JPF gets to branching instruction, it checks whether it has already explored
the same program state. If it has, then it can safely abort further search and backtrack
to a point in which there are still unexplored paths (nondeterminism) and resume
execution. In this way, JPF actually restores previous program state completely, which
would be similar to a debugger going backwards by N instructions!

The second way: partial order reduction
◦ Namely, in concurrent execution of transition between states, it is possible that
different sequences of program execution lead to the same states. In that case, JPF
tries to reduce the number of context switching between threads that do not lead to
new interesting states by grouping in the same transition all instruction sequences
which do not cause effects outside of a single thread. This is performed without
prior analysis, at execution time, by tracking instructions that could lead to problems
in threads interaction – these are those that are relevant for scheduling (e.g.
synchronized methods) or the ones that simulate non-determinism
◦ More at: http://babelfish.arc.nasa.gov/trac/jpf/wiki/devel/partial_order_reduction

The third way: delegation of method execution to JVM, the ones
that are known to not influence the verification procedure (e.g.
System.out.println())
STRUCTURE OF JAVA
PATHFINDER
JPF and program execution



JPF can be understood as a separate VM performed above our
installed JVM for a specific operating system (OS) (host JVM)
JPF determines by itself which parts of our program it processes,
and which parts are being delegated to the host JVM
Effectively, JPF significantly slows down the execution of our
program (SUT), because it adds a layer above the existing JVMa
SUT – a collection of our *.class files
with compiled bytecode + any libraries
inside JPF that our files use. Our
application uses standard Java
installation in order to work, just like
JPF.
rt.jar ends up both in JPF classpath and
in host JVM classpath. Both VM and JPF
execute their own class instances. Some
of them are different in JPF in relation
to host JVM (e.g. Java.lang.String)
Structure of JPF
JPF libraries
used by our
application
Standard JPF
packages (part of
jpf-core)
Extensions to jpf-core
(e.g. jpr-aprop)
Our
application
(*. class)
files
The set of
configuration files
Principal
structure of
jpf-core
folders
Structure of src folder


Folder that contains JPF source code
Divided into subfolders:
◦ Main
 Packets containing classes essential for jpf-core functioning (e.g. state space search
packets, VM execution, listeners, etc.). These are performed on the host JVM (as
specified in JPF native_classpath)
◦ Peers
 Native peer classes – Packets with other classes that contain methods implementation
that redirect execution to host JVM (as specified in JPF native_classpath)
◦ Classes
 Model classes – Classes performed directly on the JPF VM, these can be used
(imported) by our application (these are specified in JPF classpath)
◦ Annotations
 These contain Java annotations (starting with “@”) that should be processed by JPF.
Our programs can use these annotations (e.g. @JPFConfig, @FilterField).
◦ Examples
 Contains SUTs and the corresponding specification (configuration) files
◦ Tests
 Constains typical test cases for a large number of standard Java classes and JPF classes
themselves
Structure of build folder
Similar to src folder (division into six subfolders)
The build folder is created by building – compiling
and combining all source files (*.java) from the src
directory
 For that purpose, the Ant build system is used – there
is an already written Ant build script for building JPF
that is just executed; the best way is directly from the
IDE (e.g. NetBeans) or from the Ant itself
 The most significant file for starting JPF is the Javaexecutable file RunJPF.jar which can be found in
the root of the build folder


Other significant folders



Folders nbproject and eclipse
◦ Contain files for configuration and starting jpfcore in Eclipse and NetBeans IDEs
Folder lib
◦ Here can be put additional libraries to be used aside
jpf-core (e.g. JUnit for testing)
Folder doc
◦ Documentation of jpf-corea in textual format
(*.md readme files)
The main content of the main
subfolder – the core part of jpf-core

Classes Search and JVM are the most important ones
JVM produces program states

Search is a driver

over JVM which
enables program state
search
 For searching, various
strategies (e.g. DFSearch,
RandomSearch) and
heuristics are used,
depending on
the specification
PROGRAM PROPERTIES
SPECIFICATION AND
CHECKING
Program properties specification
and checking





Specification of properties that should be checked
(model checking) in JPF is not as simple as in other
systems (e.g. NuSMV)
Specifications in temporal logics are not given, but
rather program properties that should be checked
are given (e.g. Nonnull, Deadlock...)
JPF is highly configurable, which allows great
extendability of the system, however the main
disadvantage is the high complexity of configuration
Different parts of the system can have their own
different parameters (e.g. search strategy, listeners,
instruction sets...)
With this, a configuration object having predefined
input parameters is deemed impossible
Program properties specification
and checking

The idea is to have a configuration object that:
◦ is based on Strings
◦ is expandable at will
◦ Is transfered in a top-down manner in a hierarchical process so that
each component extracts only its own requested parameters



The configuration object is achieved by the
classgov.nasa.jpf.Config, and it uses notification of further
classes when any of the parameters is added / changed
Further classes check the parameters, and if they assert that they
are responsible for their processing, they continue with their work
using the parameters
The system configuration is achieved on four levels:
◦
◦
◦
◦

The whole installation on the computer
The project installation (for each JPF component installed)
Application specific (SUT)
Command line arguments (if needed)
A lower level can always overpower the properties of a
higher level!
Configuring the whole installation
The file with parameters for the whole JPF installation is
called site.properties and it should be found at the
default location <user.home>/.jpf/site.properties
 It is a usual Java properties file, which means that most
properties are defined based on the principle:
<key> = <value>
 This file describes to the JPF during startup where to look
for for the projects related to JPF that are installed in order
to set their corresponding classpaths, so that a user would
not have to write each of them down every time at startup
 site.properties file has to be written manually during
first installation of JPF, because otherwise JPF simply would
not work

Configuring the whole installation
An example of site.properties file:
# JPF site configuration

We define the location
jpf.home
jpf.home = ${user.home}/projects/jpf
# can only expand system properties
jpf-core = ${jpf.home}/jpf-core
extensions=${jpf-core}
Locations of other project that need to be considered
# annotation properties extension
jpf-aprop = ${jpf.home}/jpf-aprop
extensions+=,${jpf-aprop}
The location of jpf.core
installation
extensions defines
all extension (all
installed projects). In
newer versions of JPF
extensions is not
necessary to include
explicitly in
site.properties.
# numeric extension
jpf-numeric = ${jpf.home}/jpf-numeric
extensions+=,${jpf-numeric}
Notice: other projects can be listed in site.properties even though they are
not installed. JPF will simply ignore them. Our SUT project does not have to be listed
in the site.properties file, it is only used for JPF!
Configuring project installation






Each project in JPF (including jpf-core and all extension),
contains in its root folder the jpf.properties file
In this file, all parameters and specification characteristic to the
project as a whole are listed
Typically, here we find classpaths to all JPF applications that the
project contains, and other project specific parameters
Project made by a user that will be SUT can also contain the file,
but it is not obligatory
The files jpf.properties are executed in the sequence that is
determined by the site.properties file, with the exception if
JPF is started within a specific project, in which case, the
jpf.properties file of the project takes precedence
jpf.properties specification can always overpower the
specification given in site.properties, but the relevant thing
is that the two files are mutually consistent, which means that the
project names are equal (e.g. “jpf-aprop” has to be the same
both in site.properties and jpf.properties)
Configuring project installation

An example of the jpf.properties file:
jpf-aprop = ${config_path}
#--- path specifications
The first property always defines the name of
the project, {config_path} is always expanded
with the name of the folder where
jpf.properties is found
jpf-aprop.native_classpath = build/jpf-aprop.jar;lib/antlr-runtime-3.1.3.jar
jpf-aprop.classpath = build/examples
jpf-aprop.test_classpath = build/tests
jpf-aprop.sourcepath = src/examples
Path to classes that will execute programs,
It has to be visible to the host JVM
Path to folder with examples (SUT)
Path to folder with common tests
Path to folder that contains source code, which
is used if JPF needs to generate program trace
#--- other project specific settings
listener.autoload=${listener.autoload},javax.annotation.Nonnull,...
listener.javax.annotation.Nonnull=gov.nasa.jpf.aprop.listener.NonnullChecker
Setting additional project specific properties for the jpf-aprop
project, specifically in this case, a listener will be loaded that will check
@Nonnull annotation property. Now, it is not necessary to include in the
application (SUT) configuration files this particular listener!
Configuring application specific
(SUT) properties






The path to the folder containing SUT .class files is usually
defined in the jpf.properties file (.classpath property)
Configuration of properties specific for particular SUT is given in a
*.jpf file which can be found anywhere, but is usually placed in the
same folder where the program source that is being checked is found
It is common to give the name to this file so that it corresponds to
the name of the application class that is checked, e.g.
oldclassic.jpf and oldclassic.java, but this is not a
necessary condition
In order to start the JPF, in the *.jpf file, it is obligatory to
define which is the main class of the application (the one that
contains the main method) that has to be executed (the key
target)
Arguments of the static method main of the main class can be
provided (key target_args)
Beside that, a set of properties is listed that specify in what way do
we wish to check our application (listeners, search strategies, way and
order of reporting...)
Configuring application specific
(SUT) properties

Example of the SUT properties file (shortened) RobotManager.jpf
#--- dependencies on other JPF modules
@using = jpf-awt
@using = jpf-shell
#--- what JPF should run
target = RobotManager
“@using=<project_name>” is instruction to JPF to load
jpf.properties file of the given project (which has
to be defined in file site.properties). In this way,
the need for listing extensions in the file
site.properties
Defining main target class of the application that is
started in order to perform model checking
Additional listeners to the ones in jpf.properties files taken into consideration. This particular
listener is found in jpf-core: gov.nasa.jpf.listener.OverlappingMethodAnalyzer
#--- other stuff that defines how to run JPF
listener+=,.listener.OverlappingMethodAnalyzer
cg.enumerate_random=true
Specification of properties to enumerate all possibilities during random choice that appears
insider a program(e.g. Random.nextInt(2); will give two options: 0 or 1). The key
cg.enumerate_random is tested in Native peer JPF_java_util_Random of jpf-core
Configuring properties through
command line





All upper hierarchy parameters can be overpowered
In this case, the most common is to add properties using
notation <key>+=<value> , but other notations are also
possible, see:
http://babelfish.arc.nasa.gov/trac/jpf/wi
ki/user/config (the part: Special Property syntax)
The most flexible, but mostly unnecessary solution except in
the case of debugging of JPF itself
You should know what you are doing 
An overview diagram of
configuration files (with examples)
Reports

For generating the final report about model checking of programs JPF uses:
◦ The Reporter class
◦ The Publisher classes, which types depend on specification of the type of reporting
◦ Classes that extend publishers – PublisherExtensions – specific publishers for specific
properties
Reports
Reporter controls and notifies publishers when certain report stage is reached
(start, property_violation, finish)
 Stage property_violation has specific reporting topics:

◦
◦
◦
◦

error – shows type and and details of property violation that is found
trace – shows program trace which leads to property violation
snapshot – provides a list of states for each thread at the moment of property violation
output – shows the program output for the trace
Stage finish has set, by default, reporting topics:
◦ results – shows whether property violation happened and gives a short list of defects
◦ statistics – shows overall statistics of JPF execution on the SUT
Publishers produce system output depending on the wanted form (e.g. text,
XML). The common publisher is ConsolePublisher
(report.console.* for reporting into the console in the textual form)
 For each symbolic name of the publisher and report stage, one has to specify in
which order are the topics shown (in *.jpf file):
Primjer:
report.console.property_violation=error,trace,snapshot

ADVANCED TOPICS AND
EXTENSIONS
Advanced topics and JPF extensions
Listeners
 Choice generators
 Anotation properties checking – jpfaprop

Listeners






The most important mechanism of extension in JPF
They enable a way for observing, interaction with and extending JPF execution
There is a larger number of developed listeners for various purposes so an average
user usually has no need to develop their own listeners, just include them in the
configuration files
The listeners are Observers that react to specific event during search
(SearchListener) or JVM funcioning of JPF (VMListener)
They are configured by listing properties listener in jpf.properties file if they are
valid for the whole project, or in *.jpf file (most commonly), or through the
command line
JPF also starts the corresponding listener when it encounters @JPFConfig
annotation in the source file
Listeners
In implementational sense, specific listeners usually inherit a single Adapter class
which contains empty implementations of corresponding methods of interfaces
VMListener, SearchListener and others (e.g. NullTracker
extends ListenerAdapter) and then override those methods for which
they are interested in
 ListenerAdapter is used for collecting information about JPF execution so it
will be used by listeners such as CoverageAnalyzer, DeadlockAnalyzer
and NullTracker
 PropertyListenerAdapter is used when a listener implements certain
program property related to search (e.g. PreciseRaceDetector,
NoStateCycles)

Choice generators




Model checking has the assignment to arrive at interesting program
states constrained by scarce resources that it has at its disposal
ChoiceGenerators is a JPF mechanism that it systematically explores
state space in order to found solution
Many existing choice options: thread scheduling, data values,
control flow of the programs
Mechanism of corresponding choice generator and heuristic
parameters is detached from the SUT – it is listed in the configuration
file as a property with the corresponding name together with other
properties
Choice generators

In order to reduce the number of possibilities
when checking int, double and other variable
types, search heuristics are introduced
Choice generators
Caution: using heuristics moves one away from the fundamental
(but idealistic) request in model checking: that all paths through
the program are being checked, in this case only the interesting
paths are checked (interest is a subjective criterion!!!)
 Internally, in JPF, choice generators enable choice in the process
of thread scheduling of our program that is performed in JPF as
bytecode (ChoiceGenerator and
ThreadChoiceGenerator)
 More details:
http://babelfish.arc.nasa.gov/trac/jpf/wiki/devel/choicegenerator

Checking annotation properties





Project jpf-aprop represents jpf-core extension with the
purpose of model checking of specific program annotation
properties
A general idea is that SUT can be executed aside from JPF,
entirely independent of JPF, because annotating certain program
properties would not prevent program compilying and program
build
If, in a certain moment, one wants to check annotation
properties, the corresponding listeners will be given in *.jpf
configuration file and the program will be able to be checked
In ideal case, these annotations are useful even for program
documentation and it can be processed with certain tools for
static code analysis
In implementation, before SUT compiling, one has to import
corresponding classes for given annotations and include a
program library called jpf-aprop-annotations.jar in
which a list of annotation classes is given
Checking annotation properties
Structure of jpf-aprop is similar to jpfcore project, only jpf-aprop is significantly
smaller and has a simpler file
jpf.properties
 Annotation properties cover the following tasks:

◦
◦
◦
◦
◦
Unallowed assignment of null values (@Nonnull)
Contracts (@Requires, @Ensures, @Invariant)
Field access thread safety properties (@GuardedBy)
Object mutability (@Const)
and others…
INSTALLATION
Instalacija JPF-a
Installation of Java and NetBeans IDE
2. Installation of Mercurial DVCS
3. Cloning repository (jpf-core) from
Mercurial
4. Building project jpf-core using Ant
script build.xml
5. Making of site.properties file
6. Installation of NetBeans plugin for model
checking (“Verify...”)
7. Ready! 
1.
About 2nd homework

JPF installation

The homework is divided into 4 sections:

“The purpose of the 1. part of the 2. homework is acquainting
oneself with the jpf-core project and starting model
checking of simple program examples. In the 2. part of the
homework additional listeneres are introduced that extend
basic functionality of jpf-core project. The 3. part of the
homework covers model checking over examples from jpfaprop project, which is the additional project that can be used
for model checking various annotations in programs. Finally, in
the 4. part of the homework the students will make their
project from scratch, include the use of jpf-core project and
jpf-aprop projects and check the model of the given
program with constant changes to the program.”
What we did not talk about

Model Java Interface (MJI)
◦ Mechanism for redirecting method execution from JPF to JVM and within JPF.
◦ http://babelfish.arc.nasa.gov/trac/jpf/wiki/devel/mji

Bytecode factories
◦ How JPF internally processes program bytecode instructions
◦ http://babelfish.arc.nasa.gov/trac/jpf/wiki/devel/bytecode_factory

Logging
◦ Recording errors with respect to severity in a log
◦ http://babelfish.arc.nasa.gov/trac/jpf/wiki/user/output
◦ http://babelfish.arc.nasa.gov/trac/jpf/wiki/devel/loggin

Symbolic Pathfinder
◦ Executing programs using simbolic (limited numeric) values of input variables
based on code analysis – it is mostly used for automation of testing
◦ http://babelfish.arc.nasa.gov/trac/jpf/wiki/projects/jpf-symbc

A large number of other extensions:
◦ http://babelfish.arc.nasa.gov/trac/jpf/wiki/projects/start
Conclusion
JPF is an advanced and extendable framework for
model checking Java programs
 It extends Java VM with its own VM, which enables
undisturbed transiting through program states
 It uses several techniques for state search
 Relatively complex project configuration which
enables extensibility, but also complicates use
