JPred-P 2. Josh Choi, Michael Welch {joshchoi,

Size: px

Start display at page:

Download "JPred-P 2. Josh Choi, Michael Welch {joshchoi,"

Aubrey Henderson
5 years ago
Views:

1 JPred-P 2 Josh Choi, Michael Welch {joshchoi, mjwelch}@cs.ucla.edu 1. Introduction Precondition and postcondition checking on methods aids the development process by explicitly notifying the programmer of what is causing a runtime method failure, and helps eliminate difficult to detect runtime errors that may not cause an immediate program termination. JPred provides predicate dispatch support in a backwards-compatible extension to Java. Using JPred, a programmer can annotate method declarations with predicates, which are used to dynamically dispatch method calls. Our work, JPred-P 2, complements JPred by adding precondition and postcondition checking to JPred s method declarations. Our work can also be used as a base for extending JPred s static checking capabilities. The rest of this paper is laid out as follows. Section 2 presents motivation for our extension. In Section 3 we briefly discuss JPred and the annotations added in JPred-P 2, while Section 4 describes the semantics and implementation of JPred-P 2 in detail. We describe our evaluation techniques and results in Section 5, and conclude the paper, including some ideas on further work to be done to extend JPred-P 2, in Section Motivation Programmers often use comments around a method declaration to describe the method s preconditions and postconditions. While these comments provide good documentation for a reader of the code, they do not provide any runtime guarantees that the caller will meet those preconditions. As a result, the method may fail to ensure the postconditions to the caller. Such failures can result in program errors, either in the form of a runtime crash, or in some semantic misbehavior of the program. While runtime exceptions are undesirable, the latter case is often considered worse, since its results are unpredictable and sometimes undetectable. To avoid potentially unpredictable runtime errors, we have implemented JPred-P 2, a set of method annotations for Java that allows the programmer to explicitly declare preconditions and postconditions of a method. These conditions will be dynamically verified at the runtime method invocation. Failure to meet preconditions or postconditions results in an explicit runtime error, avoiding the situation of unpredictable errors. Our extension to Java is written as a complement 1 to JPred [1] using the Polyglot extensible Java compiler [2]. 3. Overview In this section, we will briefly discuss JPred[1] and how the precondition and postcondition annotations and checks of JPred-P 2 serve as a direct complement to JPred. JPred is a backwards-compatible extension language to Java for dynamic dispatch. It allows the programmer to specify predicates for method dispatch, and provides modular 1 While JPred-P 2 is implemented as part of the JPred compiler framework, it is not necessary to use any of JPred s features to use our annotations.

2 static checking using CVC Lite [3] to ensure absence of ambiguity and incompleteness. The reader is encouraged to read [1] for a complete discussion of JPred. JPred-P 2 adds to JPred s method declaration when clause by supporting two additional predicate statements: requires and ensures. A requires predicate clause indicates a requisite precondition predicate for the method that must be true at runtime invocation. Figure 1 shows a simple example of a method with a requires clause. An ensures predicate clause indicates what is guaranteed to be true upon return to the caller. Figure 2 shows an example of a method with an ensures clause. Both requires and ensures predicates may contain numeric or Boolean literals, as well as reference any variable that is in the static scope of the method declaration, namely any formal parameters or static member variables of the class. The method s local variables cannot be used in precondition or postcondition predicates. 2 QuickTimeª and a QuickTimeª and a 4. Implementation JPred-P 2 is implemented as part of the JPred compiler, which is written using the Polyglot compiler framework [4]. Polyglot is an extensible Java compiler, written in Java, which produces Java source code that can be compiled on any standard Java compiler, such as javac. Implementation of JPred-P 2 required several design choices and additions to JPred, which we will now discuss in more detail. Our extension to JPred requires modification to the source grammar in order to accept method declarations which contain any combination of requires, ensures, and 2 And for good reason. A local variable is undefined at the time it would require precondition verification, and is out of scope where the postcondition is enforced.

3 when predicates. During parsing, method declarations that contain any such predicates are parsed into PredJPredMethodDecl nodes, with the applicable predicate expressions stored as PredicateNode objects, within the Abstract Syntax Tree (AST). Method declarations that contain no predicates are parsed and handled by the default Polyglot methods. Once parsing has completed, Polyglot make several passes over the AST. A majority of our work is done though visits to PredJPredMethodDecl nodes. During the code generation phase, JPred-P 2 inserts dynamic checks on the precondition and postcondition predicates using if-else statements. For example, the code for a basic precondition shown in Figure 1 is translated into the code shown in Figure 3. Likewise, the code segment from Figure 2 is translated into the code shown in Figure 4. We chose to use simple println() and exit() calls, rather than throwing Java exceptions, due to time constraints. Throwing an exception would require the programmer to explicitly decide and declare that they will either throw the exception from the method, or they will catch it within the method. If they did neither, we would be required to make a decision for them during compile time. If we chose to throw the exception, the source code would show no throws clause on the method declaration, and yet require the caller to catch the possible exception. If we instead chose to catch the exception within the method, our resulting error handling code would be the same error report and exit as with the if-else style we use now. QuickTimeª and a

4 5. Evaluation To evaluate the effectiveness of our precondition and postcondition checks, we have written several small test classes and compiled them using the JPred-P 2 compiler. We focus here on a simple test case to demonstrate using the JPred-P 2 compiler to process JPred-P 2 code to standard Java code, using javac to generate bytecode, and execution of the resulting class using the standard Java JVM. Figure 5(a) shows the input JPred-P 2 source code file. Figure 5(b) shows the resultant Java source file (with un-necessary Polyglot constants removed for brevity). Figure 5(c) shows the results of excuting the class with the standard Sun JVM [6]. We next consider the overhead incurred by using JPred-P 2. Specifically, there are two overheads to consider. We have briefly evaluated the additional compile time necessary for JPred-P 2 compared to standard JPred code. Currently we perform one additional pass over the AST, and have added a few extra nodes that must be visited on existing passes. The running time of the compiler does not change noticeably with our added passes. Runtime overhead is difficult to measure in practice, due to inconsistent background factors of the system. It is our belief, however, that the single additional if-else clause inserted by JPred-P 2 precondition and postcondition checks do not produce any significant overhead, and that performance is comparable to JPred s. It is also worth noting that any omitted clauses will produce no additional overhead.

7 6. Conclusion and Future Work JPred-P 2 offers a Java developer a simple and straightforward method for enforcing preconditions and postconditions. By adding requires and ensures clauses to the language, JPred-P 2 is able to insert runtime checks automatically. Evaluation shows that our simple runtime checks using if-else statements are able to precisely enforce the specified requirements. Where an un-annotated program would generate a runtime exception, we similarly terminate the program with a more specific error message. We also terminate the program with a specific condition error where an un-annotated program may silently fail and produce unpredictable results. This enables the softwaretesting phase to catch such errors much easier. The experience of developing JPred-P 2 has taught us several important lessons. Perhaps the most noticeable hurdle we had to combat was the lack of sufficient documentation in Polyglot. We found it very difficult to determine the control flow through Polyglot, making it a chore to determine where and when to add our additional code. As one particular example of our difficulties with Polyglot, we still do not know how to simply create a node corresponding to the statement int x; It seems in Polyglot, you must initialize the variable to a value, even though it is not required in Java. Unfortunately, the project became more of a compiler construction project than we initially anticipated. We would have enjoyed a project that allowed us to concentrate more on development of some of our initial goals, some of which is listed below as potential future work, rather than adding the prerequisite framework to the compiler. Perhaps in future quarters we can use the framework we have developed to continue some of the following (and noticeably more interesting) improvements. Another shortcoming worth noting is that currently, our postcondition checks are inserted during the PredJTranslator phase. Unfortunately this means we must walk through the entire method body, searching for return statements. Polyglot nests statements within statements. For example, an If-Else statement is considered only one statement at the highest level. If a return statement is nested within any of these statements, we currently miss them, and do not enforce postconditions on them. This kind of nested return statement can be avoided with proper coding, and so it is a nuisance, but not an insurmountable obstacle to using JPred-P 2. Looking back, a better design choice would have been to insert the proper code checks during entry to the AST node, not upon exit.

8 Our work, however, only scratches the surface of JPred-P 2 s potential. We feel there are several additions yet to be made to JPred-P 2. First, we feel it would likely be more useful to throw a runtime PreconditionNotMet or PostconditionNotMet exception. This would allow 3 the programmer to handle the exception in a catch block within the method or from within the caller around the method call, and potentially avoid terminating the program, or at least do so more gracefully. As mentioned earlier, throwing exceptions creates the difficulty of handling those exceptions. Our default choice would be to throw both PreconditionNotMet and PostconditionNotMet exceptions to the caller, who would be required to catch them accordingly. This provides the most useful scenario, since many different callers may call a given JPred-P 2 method, each with different error handling requirements. Next, it would be a useful to use requires notations to aid JPred s logical space checking. Currently, JPred requires the full logical space of all when clauses of a given set of methods to be complete. For example, consider Figure 5. Currently, JPred will fail, claiming that the method declarations are incomplete because the case when denom == 0 is not handled. But, with our given preconditions, we should notice that this case is not valid, and allow the method specification to be considered complete. We would also like to perform some static checking on preconditions and postconditions. Through some form of dataflow analysis, we believe it is possible to determine statically whether a given precondition or postcondition is always true, never true, or unknown. If a condition is always true, the runtime check can be removed. If it is never true, it can statically be detected as an error to the programmer. If it is unknown, then the runtime checks are necessary. Lastly, our original proposal called for a static validation of preconditions and postconditions under inheritance. In order to be sound, an overriding method s preconditions can be weakened, and its postconditions st rengthened [5]. Figure 6 shows an example of the necessary conditions for soundness. Verifying these conditions requires reading the annotations from the superclass, either through the source code or byte code. The predicate conditions must be read and converted to a JPred PredicateNode expression in order to use the theorem prover to perform a validity check on the implication. Unfortunately, this is out of the scope (and time constraints) of our current project, and we leave it as the subject of future work for JPred-P 2. 3 And require

9 QuickTimeª and a 8. References [1]. T. Millstein, Practical Predicate Dispatch [2]. N. Nystrom, M. Clarkson, and A. Myers, Polyglot: An Extensible Compiler Framework for Java, Proceedings of the 12 th International Conference on Compiler Construction, Warsaw, Poland, April 2003 [3]. CVC Lite home page, [4]. Polyglot home page, [5]. C. Flanagan, K. R. M. Leino, M. Lillibridge, G. Nelson, J. B. Saxe, and R. Stata, Extended Static Checking for Java, ACM, PLDI 02, Berlin, Germany, June 17-19, 2002 [6]. Java Technology,

Objectives for this class meeting. 1. Conduct review of core concepts concerning contracts and pre/post conditions

CSE1720 Click to edit Master Week text 01, styles Lecture 02 Second level Third level Fourth level Fifth level Winter 2015! Thursday, Jan 8, 2015 1 Objectives for this class meeting 1. Conduct review of