JML Effort: Enabling Detailed Design Specifications for Modular Systems

1. Purpose and Principles of the JML Effort Gary T. LeavensUniversity of Central Florida Support from US National Science FoundationDagstuhl, July 13, 2009 jmlspecs.org www.eecs.ucf.edu/~leavens

2. Core Belief • Modularity is key to large, reliable systems • Specified interfaces are key to modularity Abstraction throughSpecification

3. Overall Purpose of JML Enable detailed design specifications for modules with tool support: • Practical (usable) • Effective (beneficial) for working software engineers Help: • working software engineers • specification language designers • software tool builders

4. Corollaries • We don’t want to stop anyone taking different research paths • Each researcher must benefit This leads to research diversity

5. JML’s Niche:BehavioralInterface Specification JML Specification Syntactic Interface Functional Behavior Java Code

6. JML’s Niche: Behavioral Interface Specification /*@ requires0 < yrs;@ensuresage == \old(age + yrs); @*/public void older(final int yrs); requiresyrs > 0;ensures age == \old(age + yrs); public void older(final int yrs); public void older(final int yrs){ age = age + yrs; }

7. JML • Common language for • Communicating research results • Extensions to Hoare-style specification • Tools • Testing • Education • Collecting the state of the art in specification • BISL to specify functional behavior • Sequential Java (mostly)

8. Benefits of Working with JML • Avoiding unnecessary work on syntax • Software basis for work on tools, etc. • Share (more) users, since users benefit from several tools • More case studies, since specifications port between tools

9. Open Research Community • 25 research groups, worldwide • Over 166 papers See jmlspecs.org for details

10. Many Tools, One Language Warnings JML Annotated Java ESC/Java2 public class Animal implements Gendered { // ... protected /*@ spec_public @*/ 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 jmlc JACK, Jive, Krakatoa,KeY,LOOP Kiassan Class file Correctness proof Symbolic Execution XVP

11. Language Design Principles • Practical, effective for detailed designs • Easily understandable by Java programmers • Assume basic undergraduate training in math • Readability more important than writability • Users must be able to under-specify • Support modularity • Support abstraction • Existing code (no imposed design methodology) • Wide range of tools • Capable of having a rigorous formal semantics

12. Language Design Principles How to avoid the “Kitchen Sink”? • Generalize separate ideas for simplicity • Look for underlying powerful ideas • Desugar to recover idioms • Use sugars, synonyms to avoid syntax wars How to handle competing theories/styles? • Wait for generalization to emerge • Support tool builders who have something workable

13. Tool Development Principles • Openness • Open source software • Open development and discussion • Consensus, based on technical merit • Testing before commit • Use Java + JML + tools on the source

14. Tool Principles • Parse all, ignore what isn’t used • Nested language levels (0, 1, …) • Extensibility (?)

15. Problems • Tension between • Common language • Need to make own extension for research • Perceived lack of academic rewards for basic infrastructure work • Keeping up • Java • Eclipse

16. Opportunities • Powerful static analysis engines • Multi-threading, concurrency • Programmers need more help • We have more computing resources • Lots of researchers from PL and SE headed where we already are • Many lessons learned • Simplifications? • Generalizations that add more power • Grand Challenge of “Verified Software”

17. JML • Purpose is to help working software engineers • Practical • Effective • Modularity • Wide range of tools • Openness and cooperation Thanks!