Thinking in Java
Java(TM) Language Specification, The (3rd Edition) (Java (Addison-Wesley))
Java(TM) Language Specification, The (3rd Edition) (Java (Addison-Wesley))
A Formal Connection between Security Automata and JML Annotations
FASE '09 Proceedings of the 12th International Conference on Fundamental Approaches to Software Engineering: Held as Part of the Joint European Conferences on Theory and Practice of Software, ETAPS 2009
JACK: a tool for validation of security and behaviour of Java applications
FMCO'06 Proceedings of the 5th international conference on Formal methods for components and objects
ESC/Java2: uniting ESC/Java and JML
CASSIS'04 Proceedings of the 2004 international conference on Construction and Analysis of Safe, Secure, and Interoperable Smart Devices
On the interplay of exception handling and design by contract: an aspect-oriented recovery approach
Proceedings of the 13th Workshop on Formal Techniques for Java-Like Programs
| Hi-index | 0.00 |
This paper discusses how a subtle interaction between the semantics of Java and the implementation of the JML runtime checker can cause the latter to fail to report errors. This problem is due to the well-known capability of finally clauses to implicitly override exceptions. We give some simple examples of annotation violations that are not reported by the run-time checker because the errors are caught within the program text; even without any explicit reference to them. We explain this behaviour, based on the official Java Language Specification. We also discuss what are the consequences of this problem, and we sketch different solutions to the problem (by adapting the implementation of the JML run-time checker, or by adopting a slightly different semantics for Java).