An overview of JML tools and applications L. Burdy, Y. Cheon, D. Cok, M. Ernst, J.R. Kiniry, G.T. Leavens, K.R.M. Leino, E. Poll Nijmegen Institute for Computing and Information Sciences/

NIII-R0309 March 2003

Nijmegen Institute for Computing and Information Sciences Faculty of Science Catholic University of Nijmegen Toernooiveld 1 6525 ED Nijmegen The Netherlands

An overview of JML tools and appli ations www.jmlspe s.org

a

Lilian Burdy , Mi hael Ernst

d,

Yoonsik Cheon

e

Joe Kiniry ,

f

K. Rustan M. Leino ,

;1,

David Cok

Gary T. Leavens Erik Poll

e;2

b,

;1,

a

GEMPLUS Resear h Lab, Gemenos, Fran e Eastman Kodak Company, R&D Laboratories, Ro hester, New York, USA

Dept. of Computer S ien e, Iowa State University, Ames, Iowa, USA d MIT Lab for Computer S ien e, Cambridge, Massa husetts, USA Dept. of Computer S ien e, University of Nijmegen, Nijmegen, the Netherlands f Mi rosoft Resear h, Redmond, WA, USA b

e

Abstra t

The Java Modeling Language (JML) an be used to spe ify the detailed design of Java lasses and interfa es by adding annotations to Java sour e les. The aim of JML is to provide a spe i ation language that is easy to use for Java programmers and that is supported by a wide range of tools for spe i ation type- he king, runtime debugging, stati analysis, and veri ation. This paper gives an overview of the main ideas behind JML, the dierent groups

ollaborating to provide tools for JML, and the existing appli ations of JML. Thus far, most appli ations have fo used on ode for programming smart ards written in the Java Card diale t of Java. Key words: formal methods, formal spe i ation, Java, runtime assertion he king, stati he king, program veri ation

1 Introdu tion JML [23,24℄, whi h stands for \Java Modeling Language", is useful for spe ifying detailed designs of Java lasses and interfa es. JML is a behavioral interfa e spe i ation language for Java; that is, it spe i es the behavior and the synta ti interfa e of Java ode. The synta ti interfa e of Java ode, a

lass or interfa e's method signatures, attribute types, et ., is augmented with JML annotations that more pre isely indi ate the orre t usage of the API so that programmers an use it as do umentation. In terms of behavior, JML 1 2

Supported in part by US NSF grants CCR-0097907 and CCR-0113181. Partially supported by EU-IST proje t Veri Card www.verifi ard.org

Burdy et al

an detail, for example, the pre onditions and post onditions for methods as well as lass invariants. An important design goal is that JML be easy to understand for any Java programmer. This is a hieved by staying as lose as possible to Java syntax and semanti s. Another important design goal is that JML not impose any parti ular design method on users; instead, JML should be able to do ument existing Java programs designed in any manner. The work on JML was started by Gary Leavens and his olleagues and students at Iowa State University, but has grown into a ooperative, open eort. Several groups worldwide are now building tools that support the JML notation and are involved with the ongoing design of JML. The open, ooperative nature of the JML eort is important both for tool developers and for potential users, and we wel ome parti ipation by others. For potential users, the fa t that there are several tools supporting the same notation is learly an advantage. For tool developers, using a ommon syntax and semanti s

an make it mu h easier to get users interested. After all, one of the biggest hurdles to using a new tool is often the la k of familiarity with the asso iated spe i ation language. The next se tion introdu es the JML notation. Se tion 3 then dis usses the tools for JML in more detail. Se tion 4 dis usses the appli ations of JML in the domain of Java Card, the Java diale t for programming smart ards. Se tion 5 dis usses some related languages and tools, su h as OCL and other runtime assertion he kers, and we on lude in Se tion 6.

2 The JML notation JML blends Eiel's design-by- ontra t approa h [31℄ with the Lar h [17℄ tradition (and others whi h spa e pre ludes mentioning). Be ause JML supports quanti ers su h as \forall and \exists, and be ause JML allows \model" (i.e., spe i ation-only) elds, spe i ations an be more pre ise and omplete than those typi ally given in Eiel. JML uses Java's expression syntax in assertions, thus JML's notation is easier for programmers to learn than one based on a language-independent spe i ation language like the Lar h Shared Language [24,25℄ or OCL [39℄. Figure 1 gives an example of a JML spe i ation that illustrates its main features. JML assertions are written as spe ial omments in the Java ode, either after // or between /* ... */, so that they are ignored by Java

ompilers but an be used by tools that support JML. JML extends the Java syntax with several keywords|in the example in Figure 1, invariant, requires, assignable, ensures, and signals. It also extends Java's expression syntax with several operators | in the example \forall, \old, and \result; these begin with a ba kslash so they do not lash with existing Java identi ers. 2

Burdy et al publi lass Purse { final int MAX_BALANCE; int balan e; // invariant 0 5;

rather than the OCL: inv: b null and b->size() > 5

JML supports all the Java modi ers su h as stati , private, publi , et ., and these an be used to re ord detailed design de isions. Furthermore, there are legal Java expressions that an be used in JML spe i ations but that

annot be expressed in OCL. More signi ant than these limitations, or dieren es in syntax, are dieren es in semanti s. JML builds on the (well-de ned) semanti s of Java. So, for instan e, equals has the same meaning in JML and Java, as does ==, and the same rules for overriding, overloading, and hiding apply. One annot expe t this for OCL. In fa t, a semanti s for OCL was only re ently proposed [6℄. In all, we believe that a language like JML, whi h is tailored to Java, 11

Burdy et al is better suited for re ording the detailed design of a Java programs than a generi language like OCL. Even if one uses UML in the development of a Java appli ation, it may be better to use JML rather than OCL for the spe i ation of obje t onstraints, espe ially in the later stages of the development.

6 Con lusions We believe that JML presents a promising opportunity to introdu e formal spe i ation to industry. It has the following strong points: (i) JML is easy to learn for any Java programmer, sin e its syntax and semanti s are very lose to Java. We believe this a ru ial advantage, as the biggest hurdle to introdu ing formal methods in industry is often that people are not willing, or do not have the time, to learn yet another language. (ii) There is no need to invest in the onstru tion of a formal model before one an use JML. Or rather: the sour e ode is the formal model. This brings two further advantages:  It is easy to introdu e the use of JML gradually, simply by adding the odd assertion to some Java ode.  JML an be used for existing (lega y) ode and APIs. Indeed, most appli ations of JML and its tools to date (e.g., [5,8,37℄) have involved existing APIs and ode. (iii) There is a (growing) availability of a wide range of tool support for JML. Be ause JML does not impose a parti ular design method on its users, unlike B, and be ause it is tailored to spe ifying both the synta ti interfa e of Java ode and its behavior, unlike UML, VDM, or Z, JML is better suited than these alternative languages for do umenting the detailed design of existing Java programs. As a ommon notation shared by many tools, JML oers users multiple tools supporting the same notation. This frees them from having to learn a whole new language before they an start using a new tool. The shared notation also helps the e onomi s both for users and tool builders. Any industrial use of formal methods will have to be e onomi ally justi ed, by omparing the osts (the extra time and eort spent) against the bene ts (improvements in quality, number of bugs found). Having a range of tools, oering dierent levels of assuran e at dierent osts, makes it mu h easier to start using JML. One an begin with a te hnique that requires the least time and eort (perhaps runtime assertion he king) and then move to more labor-intensive te hniques if and when that seems worthwhile, until one has rea hed a ombination of tools and te hniques that is ost-ee tive for a parti ular situation. There are still many opportunities for further development of both the JML language and its tools. For instan e, we would also like to see support 12

Burdy et al for JML in IDEs and integration with other kinds of stati he kers. We believe that, as a ommon language, JML an provide an important vehi le to transfer more tools and te hniques from a ademia to industry. More generally, there are still many open issues involving the spe i ation of obje t-oriented systems. When exa tly should invariants hold? How should

on urren y properties be spe i ed? JML supports only behavioral subtyping, but subtyping in Java is used for implementation inheritan e as well; how an we spe ify non-behavioral inheritan e? There are also semanti s issues with frame axioms, pure methods, and aliasing. Su h subtleties are eviden ed by the slightly dierent ways in whi h dierent tools approa h these problems. As witnessed by the development of the JACK tool by Gemplus, Java Card smart ard programs may be one of the ni he markets where formal methods have a promising future. Here, the ost that ompanies are willing to pay to ensure the absen e of ertain kinds of bugs is quite high. It seems that, given the urrent state of the art, using stati he king te hniques to ensure relatively simple properties (e.g., that no runtime ex eption ever rea hes the top-level without being aught) seems to provide an a

eptable return-oninvestment. It should be noted that the very simpli ity of Java Card is not without its drawba ks. In parti ular, the very primitive ommuni ation with smart ards (via a byte array buer) does not allow any abstra t modelization. It will be interesting to investigate if J2ME (Java 2 Mi ro Edition), whi h targets a wider range of ele troni onsumer produ ts, su h as mobile phones and PDAs, is also an interesting appli ation domain for JML. A knowledgments

Despite the long list of authors, still more people have been involved in developing the tools dis ussed in this paper, in luding Joa him van den Berg, CeesBart Breunesse, Nestor Cata~no, Corma Flanagan, Mark Lillibridge, Marieke Huisman, Bart Ja obs, Jean-Louis Lanet, Todd Millstein, Greg Nelson, Antoine Requet, Clyde Ruby, and James B. Saxe. Thanks to Raymie Stata for his initiative in getting the JML and ESC/Java proje ts to agree on a ommon syntax. Work on the JML tools at Iowa State builds on the MultiJava

ompiler written by Curtis Clifton as an adaptation of the Kopi Java ompiler.

Referen es [1℄ J.-R. Abrial. The B-Book: Assigning Programs to Meanings. Cambridge University Press, 1996. [2℄ Sergio Antoy and Di k Hamlet. Automati ally he king an implementation against its formal spe i ation. IEEE Transa tions on Software Engineering, 26(1):55{69, January 2000. [3℄ D. Bartetzko, C. Fis her, M. Moller, and H. Wehrheim. Jass - Java with

13

Burdy et al assertions. In Workshop on Runtime Veri ation at CAV'01, 2001. Published in ENTCS, K. Havelund and G. Rosu (eds.), 55(2), 2001. [4℄ Kent Be k and Eri h Gamma. Test infe ted: Programmers love writing tests. Java Report, 3(7):37{50, 1998. [5℄ Cees-Bart Breunesse, Joa him van den Berg, and Bart Ja obs. Spe ifying and verifying a de imal representation in Java for smart ards. In H. Kir hner and C. Ringeissen, editors, AMAST'02, number 2422 in LNCS, pages 304{318. Springer, 2002. [6℄ A him D. Bru ker and Burkhart Wol. A proposal for a formal OCL semanti s in Isabelle/HOL. In Cesar Mu~noz, Sophiene Tahar, and V tor Carre~no, editors, TPHOL'02, volume 2410 of LNCS, pages 99{114. Springer, 2002. [7℄ Lilian Burdy, Jean-Louis Lanet, and Antoine Requet. JACK (Java Applet Corre tness Kit). At http://www.gemplus. om/smart/r_d/trends/ja k.html, 2002. [8℄ Nestor Cata~no and Marieke Huisman. Formal spe i ation of Gemplus's ele troni purse ase study. In L. H. Eriksson and P. A. Lindsay, editors, FME 2002, volume LNCS 2391, pages 272 { 289. Springer, 2002. [9℄ Nestor Cata~no and Marieke Huisman. CHASE: A stati he ker for JML's assignable lause. In Lenore D. Zu k, Paul C. Attie, Agostino Cortesi, and Supratik Mukhopadhyay, editors, VMCAI: Veri ation, Model Che king, and Abstra t Interpretation, volume 2575 of LNCS, pages 26{40. Springer, 2003. [10℄ Yoonsik Cheon and Gary T. Leavens. A runtime assertion he ker for the Java Modeling Language (JML). In Hamid R. Arabnia and Youngsong Mun, editors, the International Conferen e on Software Engineering Resear h and Pra ti e (SERP '02), pages 322{328. CSREA Press, June 2002. [11℄ Yoonsik Cheon and Gary T. Leavens. A simple and pra ti al approa h to unit testing: The JML and JUnit way. In Boris Magnusson, editor, ECOOP 2002, volume 2374 of LNCS, pages 231{255, Berlin, June 2002. Springer. [12℄ Krishna Kishore Dhara and Gary T. Leavens. For ing behavioral subtyping through spe i ation inheritan e. In 18th International Conferen e on Software Engineering, pages 258{267. IEEE Computer So iety Press, 1996. [13℄ Mi hael D. Ernst, Jake Co krell, William G. Griswold, and David Notkin. Dynami ally dis overing likely program invariants to support program evolution. IEEE Transa tions on Software Engineering, 27(2):1{25, 2001. [14℄ Corma Flanagan and K. Rustan M. Leino. Houdini, an annotation assistant for es /java. In J. N. Oliveira and P. Zave, editors, FME 2001, volume LNCS 2021, pages 500 { 517. Springer, 2001. [15℄ Corma Flanagan, K. Rustan M. Leino, Mark Lillibridge, Greg Nelson, James B. Saxe, and Raymie Stata. Extended stati he king for Java. In ACM SIGPLAN 2002 Conferen e on Programming Language Design and Implementation (PLDI'2002), pages 234{245, 2002.

14

Burdy et al [16℄ Lisa Friendly. The design of distributed hyperlinked programming do umentation. In S. Frasse, F. Garzotto, T. Isakowitz, J. Nanard, and M. Nanard, editors, IWHD'95, pages 151{173. Springer, 1995. [17℄ John V. Guttag, James J. Horning, et al. Lar h: Languages and Tools for Formal Spe i ation. Springer, New York, NY, 1993. [18℄ Marieke Huisman. Reasoning about Java Programs in higher order logi with PVS and Isabelle. IPA dissertation series, 2001-03, University of Nijmegen, Holland, February 2001. [19℄ Bart Ja obs. Weakest pre ondition reasoning for Java programs with JML annotations. JLAP, 2002. To appear. [20℄ Bart Ja obs and Erik Poll. A logi for the Java Modeling Language JML. In H. Hussmann, editor, Fundamental Approa hes to Software Engineering (FASE), volume 2029 of LNCS, pages 284{299. Springer, 2001. [21℄ Bart Ja obs, Joa him van den Berg, Marieke Huisman, Martijn van Berkum, Ulri h Hensel, and Hendrik Tews. Reasoning about Java lasses (preliminary report). In OOPSLA'98, volume 33(10) of ACM SIGPLAN Noti es, pages 329{ 340. ACM, O tober 1998. [22℄ Reto Kramer. iContra t { the Java design by ontra t tool. TOOLS 26: Te hnology of Obje t-Oriented Languages and Systems, Los Alamitos, California, pages 295{307, 1998. [23℄ Gary T. Leavens, Albert L. Baker, and Clyde Ruby. JML: A notation for detailed design. In Haim Kilov, Bernhard Rumpe, and Ian Simmonds, editors, Behavioral Spe i ations of Businesses and Systems, pages 175{188. Kluwer A ademi Publishers, Boston, 1999. [24℄ Gary T. Leavens, Albert L. Baker, and Clyde Ruby. Preliminary design of JML: A behavioral interfa e spe i ation language for Java. Te hni al Report 98-06t, Iowa State University, Department of Computer S ien e, June 2002. [25℄ Gary T. Leavens, Yoonsik Cheon, Curtis Clifton, Clyde Ruby, and David R. Cok. How the design of JML a

ommodates both runtime assertion he king and formal veri ation. Te hni al Report 03-04, Department of Computer S ien e, Iowa State University, Ames, Iowa, 50011, Mar h 2003. To appear in the pro eedings of FMCO 2002. [26℄ K. Rustan M. Leino, Greg Nelson, and James B. Saxe. ESC/Java user's manual. Te hni al Note 2000-002, Compaq SRC, O tober 2000. [27℄ K. Rustan M. Leino, James B. Saxe, and Raymie Stata. Che king Java programs via guarded ommands. Te hni al Note 1999-002, Compaq SRC, May 1999. [28℄ Barbara Liskov and Jeannette Wing. A behavioral notion of subtyping. ACM Transa tions on Programming Languages and Systems, 16(6):1811{1841, November 1994.

15

Burdy et al [29℄ Claude Mar he, Christine Paulin, and Xavier Urbain. The Krakatoa tool for JML/Java program erti ation. Available at http://krakatoa.lri.fr, 2003. [30℄ Renaud Marlet and Daniel Le Metayer. Se urity properties and Java Card spe i ities to be studied in the Se Safe proje t. Te hni al Report SECSAFE-TL-006, Trusted Logi , August 2001. Available from http://www.do .i .a .uk/~siveroni/se safe/do s.html. [31℄ Bertrand Meyer. Obje t-oriented Software Constru tion. Prenti e Hall, New York, NY, se ond edition, 1997. [32℄ Jeremy W. Nimmer and Mi hael D. Ernst. Automati generation of program spe i ations. In ISSTA 2002, International Symposium on Software Testing and Analysis, pages 232{242, Rome, Italy, 2002. [33℄ Jeremy W. Nimmer and Mi hael D. Ernst. Invariant inferen e for stati

he king: An empiri al evaluation. In ACM SIGSOFT 10th International Symposium on the Foundations of Software Engineering (FSE 2002), pages 11{20, 2002. [34℄ S. Owre, S. Rajan, J.M. Rushby, N. Shankar, and M. Srivas. PVS: Combining spe i ation, proof he king, and model he king. In R. Alur and T.A. Henzinger, editors, Computer Aided Veri ation, number 1102 in LNCS, pages 411{414. Springer, 1996. [35℄ Dennis K. Peters and David Lorge Parnas. Using test ora les generated from program do umentation. IEEE Transa tions on Software Engineering, 24(3):161{173, 1998. [36℄ Erik Poll, Pieter Hartel, and Eduard de Jong. A Java referen e model of transa ted memory for smart ards. In Smart Card Resear h and Advan ed Appli ation Conferen e (CARDIS'2002), pages 75{86. USENIX, 2002. [37℄ Erik Poll, Joa him van den Berg, and Bart Ja obs. Formal spe i ation of the Java Card API in JML: the APDU lass. Computer Networks, 36(4):407{421, 2001. [38℄ Jim Rumbaugh, Ivar Ja obson, and Grady Boo h. The Uni ed Modeling Language Referen e Manual. Addison-Wesley Publishing Company, 1998. [39℄ Jos Warmer and Anneke Kleppe. The Obje t Constraint Language: Pre ise Modeling with UML. Addison-Wesley Publishing Company, 1999.

16