Introduction to JML Erik Poll, Joe Kiniry, David Cok University of - - PowerPoint PPT Presentation

▶
introduction to jml
SMART_READER_LITE
LIVE PREVIEW

Introduction to JML Erik Poll, Joe Kiniry, David Cok University of - - PowerPoint PPT Presentation

Feb 01, 2024 759 likes •1.23k views

Introduction to JML Erik Poll, Joe Kiniry, David Cok University of Nijmegen; Eastman Kodak Company Erik Poll - ESC/Java2 Tutorial - June 2004 - JML p.1/34 Outline of this talk What this set of slides aims to do introduction to JML

slide-1
SLIDE 1

Introduction to JML

Erik Poll, Joe Kiniry, David Cok

University of Nijmegen; Eastman Kodak Company

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.1/34

slide-2
SLIDE 2

Outline of this talk

What this set of slides aims to do

  • introduction to JML
  • provide overview of tool support for JML (jmlrac,

jmlunit, escjava)

  • explain idea of extended static checking and difference

with runtime assertion checking

  • some more ESC/Java2 tips

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.2/34

slide-3
SLIDE 3

The Java Modeling Language JML

www.jmlspecs.org

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.3/34

slide-4
SLIDE 4

JML by Gary Leavens et al.

Formal specification language for Java

  • to specify behaviour of Java classes
  • to record design &implementation decisions

by adding assertions to Java source code, eg

  • preconditions
  • postconditions
  • invariants

as in Eiffel (Design by Contract), but more expressive.

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.4/34

slide-5
SLIDE 5

JML by Gary Leavens et al.

Formal specification language for Java

  • to specify behaviour of Java classes
  • to record design &implementation decisions

by adding assertions to Java source code, eg

  • preconditions
  • postconditions
  • invariants

as in Eiffel (Design by Contract), but more expressive. Goal: JML should be easy to use for any Java programmer.

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.4/34

slide-6
SLIDE 6

JML

To make JML easy to use:

  • JML assertions are added as comments in .java file,

between /*@ . . . @*/, or after //@,

  • Properties are specified as Java boolean expressions,

extended with a few operators (\old, \forall, \result, . . . ).

  • using a few keywords (requires, ensures,

signals, assignable, pure, invariant, non null, . . . )

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.5/34

slide-7
SLIDE 7

requires, ensures

Pre- and post-conditions for method can be specified.

/*@ requires amount >= 0; ensures balance == \old(balance)-amount && \result == balance; @*/ public int debit(int amount) { ... }

Here \old(balance) refers to the value of balance before execution of the method.

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.6/34

slide-8
SLIDE 8

requires, ensures

JML specs can be as strong or as weak as you want.

/*@ requires amount >= 0; ensures true; @*/ public int debit(int amount) { ... }

This default postcondition “ensures true” can be

  • mitted.

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.7/34

slide-9
SLIDE 9

Design-by-Contract

Pre- and postconditions define a contract between a class and its clients:

  • Client must ensure precondition and may assume

postcondition

  • Method may assume precondition and must ensure

postcondition Eg, in the example specs for debit, it is the obligation of the client to ensure that amount is positive. The requires clause makes this explicit.

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.8/34

slide-10
SLIDE 10

signals

Exceptional postconditions can also be specified.

/*@ requires amount >= 0; ensures true; signals (ISOException e) amount > balance && balance == \old(balance) && e.getReason()==AMOUNT_TOO_BIG; @*/ public int debit(int amount) { ... }

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.9/34

slide-11
SLIDE 11

signals

Exceptions are allowed by default, i.e. the default signals clause is

signals (Exception) true;

To rule them out, add an explicit

signals (Exception) false;

  • r use the keyword normal_behavior

/*@ normal behavior requires ... ensures ... @*/

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.10/34

slide-12
SLIDE 12

invariant

Invariants (aka class invariants) are properties that must be maintained by all methods, e.g.,

public class Wallet { public static final short MAX_BAL = 1000; private short balance; /*@ invariant 0 <= balance && balance <= MAX_BAL; @*/ ...

Invariants are implicitly included in all pre- and postconditions. Invariants must also be preserved if exception is thrown!

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.11/34

slide-13
SLIDE 13

invariant

Invariants document design decisions, e.g.,

public class Directory { private File[] files; /*@ invariant files != null && (\forall int i; 0 <= i && i < files.length; ; files[i] != null && files[i].getParent() == this); @*/

Making them explicit helps in understanding the code.

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.12/34

slide-14
SLIDE 14

non_null

Many invariants, pre- and postconditions are about references not being null. non_null is a convenient short-hand for these.

public class Directory { private /*@ non null @*/ File[] files; void createSubdir(/*@ non null @*/ String name){ ... Directory /*@ non null @*/ getParent(){ ...

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.13/34

slide-15
SLIDE 15

assert

An assert clause specifies a property that should hold at some point in the code, e.g.,

if (i <= 0 || j < 0) { ... } else if (j < 5) { //@ assert i > 0 && 0 < j && j < 5; ... } else { //@ assert i > 0 && j > 5; ... }

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.14/34

slide-16
SLIDE 16

assert

JML keyword assert now also in Java (since Java 1.4). Still, assert in JML is more expressive, for example in

... for (n = 0; n < a.length; n++) if (a[n]==null) break; /*@ assert (\forall int i; 0 <= i && i < n; a[i] != null); @*/

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.15/34

slide-17
SLIDE 17

assignable

Frame properties limit possible side-effects of methods.

/*@ requires amount >= 0; assignable balance; ensures balance == \old(balance)-amount; @*/ public int debit(int amount) { ...

E.g., debit can only assign to the field balance. NB this does not follow from the post-condition. Default assignable clause: assignable \everything.

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.16/34

slide-18
SLIDE 18

pure

A method without side-effects is called pure.

public /*@ pure @*/ int getBalance(){... Directory /*@ pure non null @*/ getParent(){...

Pure method are implicitly assignable \nothing. Only pure methods can be used in specifications.

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.17/34

slide-19
SLIDE 19

visibility

JML supports the standard Java visibilities:

public int pub; private int priv; //@ requires i <= pub; public void pub1 (int i) { ... } //@ requires i <= pub && i <= priv; private void priv1 (int i) ... //@ requires i <= pub && i <= priv; // WRONG !! public void pub2(int i) { ... }

Specs of public methods may not refer to private fields.

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.18/34

slide-20
SLIDE 20

visibility: spec_public

Keyword spec public loosens visibility for specs. Private spec public fields are allowed in public specs, e.g.:

public int pub; private /*@ spec public @*/ int priv; //@ requires i <= pub && i <= priv; // OK public void pub2(int i) { ... }

Exposing private details is ugly, of course. A nicer, but more advanced alternative in JML is to use public model fields to represent (abstract away from) private implementation details.

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.19/34

slide-21
SLIDE 21

Tools for JML

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.20/34

slide-22
SLIDE 22

tools for JML

  • parsing and typechecking

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.21/34

slide-23
SLIDE 23

tools for JML

  • parsing and typechecking
  • runtime assertion checking:

test for violations of assertions during execution jmlrac

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.21/34

slide-24
SLIDE 24

tools for JML

  • parsing and typechecking
  • runtime assertion checking:

test for violations of assertions during execution jmlrac

  • extended static checking:

prove that contracts are never violated at compile-time ESC/Java2 This is program verification, not just testing.

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.21/34

slide-25
SLIDE 25

runtime assertion checking

jmlrac compiler by Gary Leavens et al. at Iowa State Univ.

  • translates JML assertions into runtime checks:

during execution, all assertions are tested and any violation of an assertion produces an Error.

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.22/34

slide-26
SLIDE 26

runtime assertion checking

jmlrac compiler by Gary Leavens et al. at Iowa State Univ.

  • translates JML assertions into runtime checks:

during execution, all assertions are tested and any violation of an assertion produces an Error.

  • cheap & easy to do as part of existing testing practice
  • better testing, because more properties are tested, at

more places in the code

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.22/34

slide-27
SLIDE 27

runtime assertion checking

jmlrac compiler by Gary Leavens et al. at Iowa State Univ.

  • translates JML assertions into runtime checks:

during execution, all assertions are tested and any violation of an assertion produces an Error.

  • cheap & easy to do as part of existing testing practice
  • better testing, because more properties are tested, at

more places in the code Of course, an assertion violation can be an error in code or an error in specification.

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.22/34

slide-28
SLIDE 28

runtime assertion checking

jmlrac compiler by Gary Leavens et al. at Iowa State Univ.

  • translates JML assertions into runtime checks:

during execution, all assertions are tested and any violation of an assertion produces an Error.

  • cheap & easy to do as part of existing testing practice
  • better testing, because more properties are tested, at

more places in the code Of course, an assertion violation can be an error in code or an error in specification. The jmlunit tool combines jmlrac and unit testing.

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.22/34

slide-29
SLIDE 29

runtime assertion checking

jmlrac can generate complicated test-code for free. E.g., for

/*@ ... signals (Exception) balance == \old(balance); @*/ public int debit(int amount) { ... }

it will test that if debit throws an exception, the balance hasn’t changed, and all invariants still hold.

jmlrac even checks \forall if the domain of quantification is finite.

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.23/34

slide-30
SLIDE 30

extended static checking

ESC/Java(2)

  • tries to prove correctness of specifications,

at compile-time, fully automatically

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.24/34

slide-31
SLIDE 31

extended static checking

ESC/Java(2)

  • tries to prove correctness of specifications,

at compile-time, fully automatically

  • not sound: ESC/Java may miss an error that is actually

present

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.24/34

slide-32
SLIDE 32

extended static checking

ESC/Java(2)

  • tries to prove correctness of specifications,

at compile-time, fully automatically

  • not sound: ESC/Java may miss an error that is actually

present

  • not complete: ESC/Java may warn of errors that are

impossible

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.24/34

slide-33
SLIDE 33

extended static checking

ESC/Java(2)

  • tries to prove correctness of specifications,

at compile-time, fully automatically

  • not sound: ESC/Java may miss an error that is actually

present

  • not complete: ESC/Java may warn of errors that are

impossible

  • but finds lots of potential bugs quickly

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.24/34

slide-34
SLIDE 34

extended static checking

ESC/Java(2)

  • tries to prove correctness of specifications,

at compile-time, fully automatically

  • not sound: ESC/Java may miss an error that is actually

present

  • not complete: ESC/Java may warn of errors that are

impossible

  • but finds lots of potential bugs quickly
  • good at proving absence of runtime exceptions (eg

Null-, ArrayIndexOutOfBounds-, ClassCast-) and verifying

relatively simple properties.

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.24/34

slide-35
SLIDE 35

static checking vs runtime checking

Important differences:

  • ESC/Java2 checks specs at compile-time,

jmlrac checks specs at run-time

  • ESC/Java2 proves correctness of specs,

jml only tests correctness of specs. Hence

  • ESC/Java2 independent of any test suite,

results of runtime testing only as good as the test suite,

  • ESC/Java2 provides higher degree of confidence.

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.25/34

slide-36
SLIDE 36

static checking vs runtime checking

One of the assertions below is wrong:

if (i <= 0 || j < 0) { ... } else if (j < 5) { //@ assert i > 0 && 0 < j && j < 5; ... } else { //@ assert i > 0 && j > 5; ... }

Runtime assertion checking may detect this with a comprehensive test suite. ESC/Java2 will detect this at compile-time.

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.26/34

slide-37
SLIDE 37

modular reasoning (1)

ESC/Java2 reasons about every method individually. So in

class A{ byte[] b; public void n() { b = new byte[20]; } public void m() { n(); b[0] = 2; ... }

ESC/Java2 warns that b[0] may be a null dereference here, even though you can see that it won’t be.

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.27/34

slide-38
SLIDE 38

modular reasoning (1)

To stop ESC/Java2 complaining: add a postcondition

class A{ byte[] b; //@ ensures b != null && b.length = 20; public void n() { a = new byte[20]; } public void m() { n(); b[0] = 2; ... }

So: property of method that is relied on has to be made explicit. And: subclasses that override methods have to preserve these.

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.28/34

slide-39
SLIDE 39

modular reasoning (2)

Similarly, ESC/Java will complain about b[0] = 2 in

class A{ byte[] b; public void A() { b = new byte[20]; } public void m() { b[0] = 2; ... }

Maybe you can see that this is a spurious warning, though this will be harder than in the previous example: you’ll have to inspect all constructors and all methods.

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.29/34

slide-40
SLIDE 40

modular reasoning (2)

To stop ESC/Java2 complaining here: add an invariant

class A{ byte[] b; //@ invariant b != null && b.length == 20; // or weaker property for b.length ? public void A() { b = new byte[20]; } public void m() { b[0] = 2; ... }

So again: properties you rely on have to be made explicit. And again: subclasses have to preserve these properties.

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.30/34

slide-41
SLIDE 41

assume

Alternative to stop ESC/Java2 complaining: add an assumption:

... //@ assume b != null && b.length > 0; b[0] = 2; ...

Especially useful during development, when you’re still trying to discover hidden assumptions, or when ESC/Java2’s reasoning power is too weak. (requires can be understood as a form of assume.)

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.31/34

slide-42
SLIDE 42

more JML tools

  • javadoc-style documentation: jmldoc
  • Other red verification tools:
  • LOOP tool + PVS (Nijmegen)
  • JACK (Gemplus/INRIA)
  • Krakatoa tool + Coq (INRIA)

These tools (also) aim at interactive verification of complex properties, whereas ESC/Java2 aims at automatic verification of relatively simple properties.

  • runtime detection of invariants: Daikon (Michael Ernst,

MIT)

  • model-checking multi-threaded programs: Bogor

(Kansas State) See www.jmlspecs.org

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.32/34

slide-43
SLIDE 43

Acknowledgements

Many people and groups have contributed to JML and related tools.

  • Gary Leavens led the JML effort at Iowa St. Contributors

include Albert Baker, Clyde Ruby, Curtis Clifton, Yoonsik Cheon, Anand Ganapathy, Abhay Bhorkar, Arun Raghavan, Kristina Boysen, David Behroozi. Katie Becker, Elisabeth Seagren, Brandon Shilling, Katie Becker, Ajani Thomas, and Arthur Thomas.

  • The ESC project at SRC included K. Rustan M. Leino,

Cormac Flanagan, Mark Lillibridge, Greg Nelson, Raymie Stata, and James Saxe.

  • Bart Jacobs led the LOOP (now SoS) group at Nijmegen.

Contributors include Erik Poll, Joachim van den Berg, Marieke Huisman, Cees-Bart Breunesse, and Joe Kiniry.

  • David Cok is a primary contributor to JML and ESC/Java2.

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.33/34

slide-44
SLIDE 44

More information

These websites and mailing lists can provide more information (and have links to even more):

  • JML: www.jmlspecs.org
  • mailing lists: jmlspecs-interest@lists.sourceforge.net

jmlspecs-developers@lists.sourceforge.net

  • ESC/Java2: www.cs.kun.nl/sos/research/escjava
  • ESC/Java: www.research.compaq.com/SRC/esc/
  • mailing list: jmlspecs-escjava@lists.sourceforge.net

Erik Poll - ESC/Java2 Tutorial - June 2004 - JML – p.34/34