1. JML: Expressive, Modular Reasoning for Java
Gary T. Leavens Iowa State University Support from US National Science Foundation Stanford University, March 5, 2007
For details related to this talk, see my paper JML's Rich, Inherited Specifications for Behavioral Subtypes. In Zhiming Liu and He Jifeng (eds), Formal Methods and Software Engineering: 8th International Conference on Formal Engineering Methods (ICFEM), Macao, China, pages Volume 4260 of Lecture Notes in Computer Science, Springer-Verlag, The original publication is available at springerlink.com or directly from Also Department of Computer Science, Iowa State University, TR #06-22, August 2006.
For more technical details, see reference [LN06] (references at the end of the talk).
jmlspecs.org

2. Java Modeling Language—JML
Formal specification language for Java
Functional behavior
Sequential
Goals:
Practical, effective for detailed designs
Existing code
Wide range of tools
Hoare-style
Method pre- and postconditions
Type invariants
Extensions for concurrency under development

3. Example JML Specification
public class Animal implements Gendered { protected int age = 0;
requires 0 < yrs; @ ensures age == \old(age + yrs); @*/ public void older(final int yrs) { age = age + yrs; }
/* … */ }
field specification
method behavior specification
Explain the notation.
Readers can see the paper “Preliminary Design of JML” available from jmlspecs.org, or the JML Reference manual for details.

4. Behavioral Interface Specification
JML Specification
Syntactic Interface
Functional Behavior
2 parts…
Java Code

5. Behavioral Interface Specification
requires 0 < yrs; @ ensures age == \old(age + yrs); @*/ public void older(final int yrs);
requires yrs > 0; ensures age == \old(age) + yrs;
public void older(final int yrs);
public void older(final int yrs) { age = age + yrs; }

6. Like … But for Java and… VDM, but Eiffel, but Spec#, but OO features
Features for formal verification
Spec#, but
Different invariant methodology
More features for formal verification
Add the Spec#, being developed at Microsoft Research, is patterned after JML.

7. Research Community 23 groups, worldwide Over 125 papers
Open
Join us
Over 125 papers
See jmlspecs.org for details
Initially, Iowa State, DEC SRC, and Nijmegen. Mention anecdote of my IFIP VSTTE conference talk and 50 some people working on JML.
To count papers, do: grep '<li' papers.shtml |wc -l

8. Many tools, One Language
Warnings
JML Annotated Java
ESC/Java2
public class Animal implements Gendered {
// ...
protected int age = 0;
requires 0 <= a && a <= 150; @ ensures age == a; @ also @ requires a < 0; @ ensures age == \old(age); @*/ public void setAge(final int a) { if (0 <= a) { age = a; } } }
jmldoc
Web pages
Daikon
jmlunit
Data trace file
Unit tests
Say JML is central to all the tools, mention that it’s JML annotated Java code in the middle
jmlc
JACK, Jive, Krakatoa, KeY, LOOP
Bogor
Class file
Correctness proof
Model checking
XVP

9. Problems for this Talk Modular Specification, Verification
Recording detailed designs
Specifying subtypes
Verification with OO features
Modularity is important for scalability, components, dynamic/mobile code, evolution.
The OO features are references, subtyping, and dynamic dispatch.
Readers can use the hyperlinks to jump within the talk.

10. Problem 1: Recording Detailed Designs
Precise, sequential behavior
Hide details
Approach
Model fields
Assertions
Besides interface specifications, use…

11. Model Fields, Ensures public interface Gendered {
model instance String gender; ensures \result == gender.equals(“female”); boolean isFemale(); }
Mention this is the top type of our examples.

12. Represents Clauses public class Animal implements Gendered {
protected boolean gen; in gender;
protected represents gender @ <- (gen ? “female” : “male”); @*/
// ...

13. Use of Model Fields public class Animal implements Gendered {
protected boolean gen; in gender;
protected represents gender @ <- (gen ? “female” : “male”); @*/
public boolean isFemale() { return gen; }
// ...

14. Correctness with Model Fields
isFemale’s specification
gender:
“female”
true
represents ==
Basic idea goes back to Hoare72
isFemale’s code
gen:
true
true

15. Requires Clauses public class Animal implements Gendered {
protected boolean gen; in gender;
protected represents gender @ <- (gen ? “female” : “male”); @*/
requires g.equals(“female”)||g.equals(“male”); ensures gender.equals(g); public Animal(final String g) { gen = g.equals(“female”); }

16. Model of Method Specifications
public interface T { requires pre; ensures post; void m(); }
T ⊳ (pre, post)

17. Model of Method Specifications
output
post
post-state
m()
This kind of graph seems to be original with this talk. It shows what satisfaction of a pre/post specification means.
pre
input pre-state

18. spec_public Shorthand
Instead of:
public model int age; protected int _age = 0; in age; protected represents age <- _age;
Write:
protected int age = 0;

19. Specification Cases, ‘also’
public class Animal implements Gendered { protected int age = 0;
requires 0 <= a && a <= 150; @ ensures age == a; @ also @ requires a < 0; @ ensures age == \old(age); @*/ public void setAge(final int a) { if (0 <= a) { age = a; } }

20. Join of Specification Cases
requires 0 <= a && a <= 150; ensures age == a; also requires a < 0; ensures age == \old(age);
means
requires (0 <= a && a <= 150) || a < 0 ; ensures (\old(0 <= a && a <= 150) ==> age == a) && (\old(a < 0) ==> age == \old(age)) ;
Explain what ==> means (implication).

21. Join of Specification Cases
post && post′
post
pre′
pre
pre && pre′

22. Join of Specification Cases, ⊔S
If T′ ⊳ (pre′, post′ ), T ⊳ (pre, post ), S ≤ T′, S ≤ T,
then
(pre′, post′ ) ⊔S (pre, post ) = (p, q)
where p = pre′ || pre and q = (\old(pre′ ) ==> post′ ) && (\old(pre) ==> post ) and S ⊳ (p, q)
This technical form of the definition shows how the join depends on the type at which it’s made, but the only important thing is the notation for a join.

23. Type Specifications: Invariants
import java.util.*;
public class Patient extends Animal {
public invariant 0 <= age && age <= 150;
protected List log;
public invariant (\forall int i; @ <= i && i < log.size(); @ log.get(i) instanceof String); @*/
// …
Technically we need to have rep in the declaration of log, but I’m suppressing that to not interfere with the talk…

24. Invariants Hold in visible states Obeyed by subtypes
Method pre- & post-, Constructor post-states
Obeyed by subtypes

25. Invariants: Obeyed by Subtypes Not a Sugar [LW94]
Animal
Tortoise
Patient
invariant 0 <= age && age <= 150;
FemalePatient

26. Initially public class Patient extends Animal { // ...
protected List log;
public initially log.size() == 0;
True in constructor post-states
Basis for datatype induction
Not a sugar

27. History Constraints [LW94]
public class Patient extends Animal { // ...
public constraint @ \old(log.size()) <= log.size();
@ public constraint @ (\forall int i; @ <= i && i < \old(log.size()); @ log.get(i).equals(\old(log.get(i))));
@*/

28. History Constraints Relate pre-states and post-states
Inductive step for datatype induction
Not a sugar

29. Problem 2: Specifying Subtypes
Avoid repetition
(Force behavioral subtyping)
Approach
Specification Inheritance
Fields, type specifications
Method specification cases
Say behavioral subtyping means no surprises.
Go slower from this point on.

30. T’s Added Specifications
Declared in T (without inheritance):
added_invT invariant
added_hcT history constraint
added_initT initially predicate
m’s specification
Other Notations
supers(T ) = {U | T  U }
methods(T ) = { m | m declared in TT }
added_spec T m
The added_ notations are for what is actually written in the type specifications, not considering inheritance.

31. Specification Inheritance’s Meaning: Extended Specification of T
Methods: for all m  methods(supers(T))
= ⊔T { | Usupers(T) }
Invariant:
ext_invT = ⋀ { added_invU | Usupers(T) }
History constraint:
ext_hcT = ⋀ { added_hcU | Usupers(T) }
Initially:
ext_initT = ⋀ { added_initU | Usupers(T) }
ext_spec T m
added_spec U m
The ext_ notations are for the meaning, taking inheritance into account.

32. Invariant Inheritance
public class FemalePatient extends Patient {
public invariant gender.equals(“female”); // … }
Extended invariant:
added_invGendered && added_invAnimal
&& added_invPatient
&& added_invFemalePatient
An example of invariant inheritance.

33. Invariant Inheritance
public class FemalePatient extends Patient {
public invariant gender.equals(“female”); // … }
Extended invariant:
true && true
&& 0 <= age && age <= && (\forall int i; 0 <= i && i < log.size();
log.get(i) instanceof String)
&& gender.equals(“female”)

34. Invariant Inheritance
public class FemalePatient extends Patient {
public invariant gender.equals(“female”); // … }
Extended invariant:
0 <= age && age <= && (\forall int i; 0 <= i && i < log.size();
log.get(i) instanceof String)
&& gender.equals(“female”)

35. Method Specification Inheritance: Supertype’s added_spec
public class Animal implements Gendered { // …
requires 0 <= a && a <= 150; @ ensures age == a; @ also @ requires a < 0; @ ensures age == \old(age); @*/ public void setAge(final int a) { /* … */ }
Supertype is not patient, but Animal!

36. Method Specification Inheritance: Subtype’s added_spec
public class Patient extends Animal { // …
protected boolean ageDiscount = false; in age; also @ requires 0 <= a && a <= 150 || a < 0; @ ensures 65 <= age ==> ageDiscount; @*/ public void setAge(final int a) { super.setAge(a); if (65 <= age) { ageDiscount = true; } }

37. Method Specification Inheritance: Extended Specification
= ⊔Patient { , }
ext_spec
Patient
setAge
added_spec
Animal
setAge
added_spec
Patient
setAge
What this formula means is shown on the next slide.

38. Method Specification Inheritance: Extended Specification
requires 0 <= a && a <= 150; ensures age == a; also requires a < 0; ensures age == \old(age); also requires 0 <= a && a <= 150 || a < 0; ensures 65 <= age ==> ageDiscount;

39. Problem 3: Verification with OO features
Subtyping
Dynamic Dispatch
Approach [LN06]
Supertype abstraction
Validity:
Assumptions about Invariants, etc.,
Behavioral subtyping
Behavioral subtyping from specification inheritance

40. Supertype Abstraction
Reasoning about dynamic dispatch:
Gendered e = (Gendered)elems.next(); if (e.isFemale()) { assert e.gender.equals(“female”); // ... }
Supertype abstraction:
Static type of e is Gendered
Use specification from Gendered

41. Static Type’s Specification
public interface Gendered {
model instance String gender; ensures \result == gender.equals(“female”); boolean isFemale(); }
Mention this is the top type of our examples.

42. Supertype Abstraction in General
Use static type’s specifications to reason about:
Method calls,
Invariants,
History constraints,
Initially predicates

43. Supertype Abstraction in General
T o = /* create a new object */;
assume o.ext_initT && o.ext_invT;
/* … */
assert ; o.m(); assume ; assume o.ext_invT && o.ext_hcT;
o.ext_pre T m
o.ext_post T m

44. Reasoning without Supertype Abstraction?
Case analysis:
Case for each potential dynamic type
Can exploit dynamic type’s specifications

45. Case Analysis + Supertype Abstraction
Use instanceof for case analysis
Downcast, use supertype abstraction
requires p instanceof Doctor @ || p instanceof public boolean isHead(final Staff p) { if (p instanceof Doctor) { Doctor doc = (Doctor) p; return doc.getTitle().startsWith(“Head”); } else { Nurse nrs = (Nurse) p; return nrs.isChief(); } }

46. Supertype Abstraction’s Soundness
Valid if:
Invariants etc. hold as needed, and
Each subtype is a behavioral subtype

47. Assumption about Invariants
assert Pre;
assume Pre && Inv;
assert Post && Inv;
assume Post;

48. Invariant Methodology
Potential problems:
Representation exposure
Reentrance
Relevant invariant semantics [Mül02,MPHL06]:
Ownership type system
Re-establish invariant when call
Guarantees:
invariant holds at start of method
Others, like the Boogie methodology achieve the same guarantee.

49. Initially Predicates, History Constraints
Similar problems?
Similar solutions?

50. Behavioral Subtypes Subtypes obey supertype specification Subtypes:
Refine method specifications
Strengthen invariants, etc.

51. Method Specification Refinement with respect to T′
Notation:
(pre′, post′ ) ⊒T′ (pre, post )

52. Refinement with respect to T′
post
pre

53. Refinement with respect to T′
post
pre′
pre

54. Refinement with respect to T′
post′
post
pre′
pre

55. Proving Method Refinements
Theorem 1. Suppose T′ ≤ T, and T′ ⊳ (pre′, post′ ), T ⊳ (pre, post ) specify m.
Then (pre′, post′ ) ⊒T′ (pre, post )
if and only if:
Spec(T′ ) |- pre && (this instanceof T′ )  pre′,
and
Spec(T′ ) |- \old(pre && (this instanceof T′ ))  (post′  post ).
This is theorem 1 of LN06.

56. Validity of Supertype Abstraction: Client (Supertype) view
T o = /* create a new object */;
assume o.ext_initT && o.ext_invT;
/* … */
assert ; o.m(); assume ; assume o.ext_invT && o.ext_hcT;
o.ext_pre T m
o.ext_post T m

57. Validity of Supertype Abstraction: Implementation (Subtype) View
T o = new T′ ();
assert o.ext_initT′ && o.ext_invT′;
/* … */
assume ; o.m(); assert ; assert o.ext_invT′ && o.ext_hcT′ ;
o.ext_pre T′ m
o.ext_post T′ m

58. Behavioral Subtyping for JML
Definition. Suppose T′ ≤ T. Then T′ is a strong behavioral subtype of T if and only if:
for all instance methods m in T, ⊒T′
whenever this has type T′ : ext_invT′  ext_invT, ext_hcT′  ext_hcT, and ext_initT′  ext_initT.
ext_spec T′ m
ext_spec T m

59. Ensuring Validity
Method specification inheritance must make refinements
`also’ must make refinements

60. also Makes Refinements
Theorem 2. Suppose \old is monotonic. Suppose T′ ≤ T, and T′ ⊳ (pre′, post′ ), T ⊳ (pre, post ) specify m.
Then
(pre′, post′ ) ⊔T′ (pre, post ) ⊒T′ (pre, post ).

61. also Makes Refinements
post && post′
post
post′
pre′
pre
pre && pre′

62. Specification Inheritance Forces Behavioral Subtyping
Theorem 3. Suppose T′ ≤ T . Then the extended specification of T′ is a strong behavioral subtype of the extended specification of T.
Proof: Use Theorem 2 and definition of extended specification.
Proof: Use Theorem 2 and the definition of extended specification.

63. Discussion Every subtype inherits
Every subtype is a behavioral subtype
Not all satisfiable
Supertype must allow refinement

64. Unsatisfiable Refinements
post && post′
post
post′
Specification inheritance always makes a subtype, but it may not be satisfiable… This can also arise due to invariants, etc., in several ways.
pre′
pre
pre && pre′

65. Unrefinable Binary Method Specification
also @ ensures obj instanceof Gendered @ ==> (\result @ == gender.equals( @ ((Gendered)obj).gender)); @*/ public boolean Object obj);
Says only gender matters
Refinements can’t use other attributes

66. Unrefinable Binary Method Specification
true
false
The pre-states are entire sets of objects with these genders, the post states summarize the result only
(f,f)
(m,m)
(f,m)
(m,f)

67. Better, Refinable Binary Method Specification
also @ ensures obj instanceof Gendered @ ==> (\result @ ==> gender.equals( @ ((Gendered)obj).gender)); @*/ public boolean Object obj);
Says gender must be equal
Refinements can use other attributes

68. Better, Refinable Binary Method Specification
true
false
Allowed result
(f,f)
(m,m)
(f,m)
(m,f)

69. Related Work
Work with Naumann [LN06], basis for this talk. Proved exact conditions on behavioral subtyping for validity of supertype abstraction
Liskov and Wing [LW94] “subtype requirement” like supertype abstraction. Abstraction functions implicit in JML.
Several program logics for Java, [Mül02] [Par05] [Pie06] [PHM99], use supertype abstraction.
Work with Dhara [DL96] proved specification inheritance forces behavioral subtyping.

70. More Related Work
Wills’s Fresco [Wil92] introduced specification inheritance.
Wing’s dissertation [Win83] combined specification cases like also.
Eiffel [Mey97] has behavioral subtyping and a form of specification inheritance.
America [Ame87] [Ame91] first proved soundness with behavioral subtyping.
See survey with Dhara [LD00].

71. Future Work Warn if attempt to strengthen preconditions [FF01].
Warn if subtype is unsatisfiable.
Methodology for
history constraints and
initially predicates

72. Conclusions Supertype abstraction allows modular reasoning.
Supertype abstraction is valid if:
methodology enforced, and
subtypes are behavioral subtypes.
JML’s also makes refinements.
Specification inheritance in JML forces behavioral subtyping.
Supertype abstraction automatically valid in JML.

73. Acknowledgments
Thanks to David Naumann, William Weihl, Krishna Kishore Dhara, Cesare Tinelli, Don Pigiozzi, Barbara Liskov, Jeannette Wing, Yoonsik Cheon, Al Baker, Clyde Ruby, Tim Wahls, Patrice Chalin, Curtis Clifton, David Cok, Joseph Kiniry, Rustan Leino, Peter Müller, Arnd Poetzsch-Heffter, Erik Poll, and the rest of the JML community.
Join us at...
jmlspecs.org

74. Future Work on JML Tools Documentation Concurrency support
Java 1.5 support
Eclipse support
Documentation
Concurrency support
Semantic details
Theorem proving tie-ins, Static analysis tie-ins
Inference of specifications
Tools that give more benefits

75. References
[Ame87] Pierre America. Inheritance and subtyping in a parallel object-oriented language. In Jean Bezivin et al., editors, ECOOP ’87, European Conference on Object-Oriented Programming, Paris, France, pages 234–242, New York, NY, June Springer-Verlag. Lecture Notes in Computer Science, volume 276.
[Ame91] Pierre America. Designing an object-oriented programming language with behavioural subtyping. In J. W. de Bakker, W. P. de Roever, and G. Rozenberg, editors, Foundations of Object-Oriented Languages, REX School/Workshop, Noordwijkerhout, The Netherlands, May/June 1990, volume 489 of Lecture Notes in Computer Science, pages 60–90. Springer-Verlag, New York, NY, 1991.
[BCC+05] Lilian Burdy, Yoonsik Cheon, David R. Cok, Michael D. Ernst, Joeseph R. Kiniry, Gary T. Leavens, K. Rustan M. Leino, and Erik Poll. An overview of JML tools and applications. International Journal on Software Tools for Technology Transfer, 7(3):212–232, June 2005.
[DL96] Krishna Kishore Dhara and Gary T. Leavens. Forcing behavioral subtyping through specification inheritance. In Proceedings of the 18th International Conference on Software Engineering, Berlin, Germany, pages 258–267. IEEE Computer Society Press, March A corrected version is ISU CS TR #95-20c, rlhttp://tinyurl.com/s2krg.
[FF01] Robert Bruce Findler and Matthias Felleisen. Contract soundness for object-oriented languages. In OOPSLA ’01 Conference Proceedings, Object-Oriented Programming, Systems, Languages, and Applications, October 14-18, 2001, Tampa Bay, Florida, USA, pages 1–15, October 2001.
[Hoa69] C. A. R. Hoare. An axiomatic basis for computer programming. Communications of the ACM, 12(10):576–580,583, October 1969.
[Hoa72] C. A. R. Hoare. Proof of correctness of data representations. Acta Informatica, 1(4):271–281, 1972.
[LD00] Gary T. Leavens and Krishna Kishore Dhara. Concepts of behavioral subtyping and a sketch of their extension to component-based systems. In Gary T. Leavens and Murali Sitaraman, editors, Foundations of Component-Based Systems, chapter 6, pages 113–135. Cambridge University Press, 2000.
[Lei98] K. Rustan M. Leino. Data groups: Specifying the modification of extended state. In OOPSLA ’98 Conference Proceedings, volume 33(10) of ACM SIGPLAN Notices, pages 144–153. ACM, October 1998.
[LN06] Gary T. Leavens and David A. Naumann. Behavioral subtyping, specification inheritance, and modular reasoning. Technical Report 06-20b, Department of Computer Science, Iowa State University, Ames, Iowa, 50011, September 2006.
[LW94] Barbara H. Liskov and Jeannette M. Wing. A behavioral notion of subtyping. ACM Transactions on Programming Languages and Systems, 16(6):1811–1841, November 1994.
[Mey97] Bertrand Meyer. Object-oriented Software Construction. Prentice Hall, New York, NY, second edition, 1997.
[MPHL06] Peter Müller, Arnd Poetzsch-Heffter, and Gary T. Leavens. Modular invariants for layered object structures. Science of Computer Programming, 62(3):253– 286, October 2006.
[Mül02] Peter Müller. Modular Specification and Verification of Object-Oriented Programs, volume 2262 of Lecture Notes in Computer Science. Springer-Verlag, 2002.
[Par05] Matthew J. Parkinson. Local reasoning for Java. Technical Report 654, University of Cambridge Computer Laboratory, November The author’s Ph.D. dissertation.
[PHM99] A. Poetzsch-Heffter and P. Müller. A programming logic for sequential Java. In S. D. Swierstra, editor, European Symposium on Programming (ESOP ’99), volume 1576 of Lecture Notes in Computer Science, pages 162–176. Springer-Verlag, 1999.
[Pie06] Cees Pierik. Validation Techniques for Object-Oriented Proof Outlines. PhD thesis, Universiteit Utrecht, 2006.
[SBC92] Susan Stepney, Rosalind Barden, and David Cooper, editors. Object Orientation in Z. Workshops in Computing. Springer-Verlag, Cambridge CB2 1LQ, UK, 1992.
[Wil92] Alan Wills. Specification in Fresco. In Stepney et al. [SBC92], chapter 11, pages 127–135.
[Win83] Jeannette Marie Wing. A two-tiered approach to specifying programs. Technical Report TR-299, Massachusetts Institute of Technology, Laboratory for Computer Science, 1983.