1 / 15

Extended Static Checking for JAVA

Jonathan Kuhn Robin Mange EPFL-SSC. Extended Static Checking for JAVA. Compaq Systems Research Center Flanagan, Leino, Lillibridge, Nelson, Saxe and Stata. Software developement and maintenance are expensive tasks

vidar
Download Presentation

Extended Static Checking for JAVA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Jonathan Kuhn Robin Mange EPFL-SSC ExtendedStaticChecking for JAVA Compaq Systems Research Center Flanagan, Leino, Lillibridge, Nelson, Saxe and Stata

  2. Software developement and maintenance are expensive tasks Detecting errors at early stage using static checkers can improve productivity This paper discusses about one of those, called ESC/Java Introduction

  3. ESC/Java is a compile time checker featuring VC generation and automatic TP techniques It provides a simple annotation language to users It is a « static » and « extended » checker Introduction

  4. Objectives: To produce a cost-effective tool that catches as many errors as possible In between common type checkers and full program verifiers Providing Modular Checking Introduction

  5. ModularCheckingallowschecking of single pieces of code Annotations are required to providespecifications IdealStaticCheckerattributes: Soundness Completeness Introduction • Trade-off on both to remain cost-effective

  6. 1: class Bag { 2: int size ; 3: Int[ ] elements; 4: 5: Bag(int[ ] input) { 6: size = input .length ; 7: elements = new int[size] ; 8: System.arraycopy(input , 0, elements, 0, size) ; 9: } 10: 11: int extractMin() { 12: int min = Integer.MAX VALUE ; 13: intminIndex = 0; 14: for (inti= 1; i <= size ; i++) { 15: if (elements[i ] < min) { 16: min = elements[i] ; 17: minIndex = i ; 18: } 19: } 20: size−−; 21: elements[minIndex]= elements[size] ; 22: return min ; 23: } 24: } Example

  7. 6: Warning: Possible nulldeference 15: Warning: Possible nulldeference / Array index possiblytoo large 21: Warning: Possible nulldeference / Possible negativeArray index 1: class Bag { 2: int size ; 3: Int[ ] elements; 4: 5: Bag(int[ ] input) { 6: size = input .length ; 7: elements = new int[size] ; 8: System.arraycopy(input , 0, elements, 0, size) ; 9: } 10: 11: int extractMin() { 12: int min = Integer.MAX VALUE ; 13: intminIndex = 0; 14: for (inti= 1; i <= size ; i++) { 15: if (elements[i ] < min) { 16: min = elements[i] ; 17: minIndex = i ; 18: } 19: } 20: size−−; 21: elements[minIndex]= elements[size] ; 22: return min ; 23: } 24: } Example

  8. //@ invariant 0<=size && size<=elements.length /*@non_null*/ int[] elements; //@requires input!=null 6: Warning: Possible nulldeference 15: Warning: Possible nulldeference / Array index possiblytoo large 21: Warning: Possible nulldeference / Possible negativeArray index 1: class Bag { 2: int size ; 3: Int[ ] elements; 4: 5: Bag(int[ ] input) { 6: size = input .length ; 7: elements = new int[size] ; 8: System.arraycopy(input , 0, elements, 0, size) ; 9: } 10: 11: int extractMin() { 12: int min = Integer.MAX VALUE ; 13: intminIndex = 0; 14: for (inti= 1; i <= size ; i++) { 15: if (elements[i ] < min) { 16: min = elements[i] ; 17: minIndex = i ; 18: } 19: } 20: size−−; 21: elements[minIndex]= elements[size] ; 22: return min ; 23: } 24: } Example

  9. Front End: act like normal compiler Translator: AST => guarded commands (modular checking, loop unrolling) VC Generator: generate verification conditions for each guarder commands. Theorem Prover: TP is invoked for each routine using UBP & SBP Here is a schema of the steps performed by ESC/Java Architecture

  10. Design • Made as Java-like as possible • Captures design decision of the user • Similar as JML annotations • Work similary as Jahob specification (ghost vars, routine specifications, invariant, …) Annotation Language

  11. Potential problem: Could be too slow for interactive usage • Annoting appropriately during developpement saves time and catches errors earlier • Optimization made its use satisfactory and sufficient • Require about 50-100 annotations per thousand lines of code Performance

  12. Mercator: A part of the code failed on a null pointer array. This was missed during code review and took 6h for ESC/Java to catch it. • JavaFE: 3 weeks spent annoting the code permited to catch dozens of previouly undetected errors. Experiences

  13. Can be extended static checker made automatic? • How simple can the annotation language be? RelatedWork

  14. ESC/Java iseasy to use and candetectsignificant software errors The concept and the usage issimilar to jahob Conclusion

  15. Comparison of ESC/Java and Jahob Thomas Wies (Software Engineering) Albert-Ludwigs-University Freiburg

More Related