2. Contracts for Java (work in progress) Matthias Felleisen Rice University Houston, Texas

3. Components and Contracts Components, Java, and Contracts Problems with Contracts The Meaning of Contracts Compiling Contracts

4. The Component Utopia

5. Programming in a Component World (1) The market delivers interchangeable components with external connectors, ready to be hooked up.

6. Programming in a Component World (2) Programmers wire together components.

7. Programming in a Component World (3) Sometimes they add some adapter code.

8. Programming in a Component World (4) They build new components from old ones and a few adapters for distribution.

9. What’s Needed for a Component World? need flexible means of programming and wiring components together need tools for finding components need quality assurance and “sanctions” against “black sheep”

10. Specifying and Wiring Components Classes are bad: –Mixins: connectors are external Modules are bad: –Functors: connectors are external –Units: connectors are external, graph-based Industry’s wiring standards –Objects –COM, DCOM, and/or CORBA

11. Finding Components Industry: “in documentation we trust” and “good luck” Academia: use types and module signatures to find the missing link –DiCosmo (1996 …) –Felleisen (1983)

12. “Warranties” for Components Industry: “We didn’t do anything.” Academia: Types Uber Alles Contracts: From Eiffel to iJava

13. Contracts for “Commercial” Components 8.NO WARRANTIES. Microsoft expressly disclaims any warranty for the SOFTWARE PRODUCT. THE SOFTWARE PRODUCT AND ANY RELATED DOCUMENTATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OR MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. THE ENTIRE RISK ARISING OUT OF USE OR PERFORMANCE OF THE SOFTWARE PRODUCT REMAINS WITH YOU.

14. “Warranties” for Contracts syntactic level: types semantic level 1: functionality semantic level 2: concurrency quality of service level: unexplored

15. Contracts: From Eiffel to iContract

16. Eiffel: Programming by Contract Components are classes Contracts are pre- and post- conditions (assertions) on methods Contract enforcement attempts to pinpoint the culprit for error signals iContract: Eiffel for Java

17. A Simple Example class Q implements Queue { Queue enq(Object X) {... // post: !this.empty() … Queue deq() { … // pre: !this.empty() … boolean empty() { … } … } // Good Client: Queue q = new Q(); q.enq(X).deq() … // Bad Client: Queue q = new Q; q.deq().enq(X) … Eiffel blames this call

18. Problems with Call-backs AB some_b.m(some_a) some_a.m2() “Java is higher-order”

19. A Complex Example (1) class Q implements Queue { Queue enq(Object X) {... // post: !this.empty() // effect: o.onEnq(this) Queue deq() { … // pre: !this.empty() // effect: o.onDeq(this) void register(Observer o) {... // effect: o.init() // please: a “good” Observer … class GoodO implements Observer { void init() { … } Queue onEnq(Queue q){... // post: !q.empty() Queue onDeq(Queue q){... // pre: q.empty() … }

20. A Complex Example (2) class BadO implements Observer { void init() { … display … } Queue onEnq(Queue q) { q.deq() … } Queue onDeq(Queue q) { q.enq(X) … } … } No Warranty on state of q after call ! class Q implements Queue { Queue enq(Object X) {... // post: !this.empty() // effect: o.onEnq(this) Queue deq() { … // pre: !this.empty() // effect: o.onDeq(this) void register(Observer o) {... // effect: o.init() // please: a “good” Observer …

21. A Complex Example (3) Client BadObserver Queue Who’s to blame? puts bad observer together with queue iContract blames Q … but BadObserver violates the “informal” contract

22. What We Learned Contracts should be a part of the class interface Contracts should have a semantics so that we can determine whether a run-time system blames the appropriate component

23. Contracts for Java Interfaces

24. Contract Java extend Java interfaces keep Java semantics inter-operate with existing Java (easily)

25. The Language of Contracts: Pre/Post Conditions interface DoubleRoot { double getValue(); double sqrt(); @pre { this.getValue () >= 0.0 } @post { abs(sqrt * sqrt - this.getValue()) < 0.01 } this refers to the current object contracts are boolean Java expressions sqrt refers to the result of the method call

26. Incompleteness of Assertion Language interface Stack { void push(Object o); @post “o is at top of stack” Object pop(); @pre { !this.empty() } boolean empty(); } interface Stack { void push(Object o); @post: { this.top() == o } Object pop(); @pre { !this.empty() } boolean empty(); Object top(); @pre { !this.empty() } }

27. Completeness: … neither possible nor necessary some properties aren’t computable for some, the interfaces are too poor state important invariants (safety) [see Rosenblum1995]

28. What are the Design Problems? classes implement multiple interfaces substitutability weakening & strengthening conditions implied interface inheritance

29. Multiple Interfaces: Meet one Pre class C implements I, J {} interface I { void out(int in); @pre { in < 0 } } interface J { void out(int in); @pre { in > 0 } } class Client { C c = new C(); ……... … ((I)c).m(xxx); … ……… … ((J)c).m(yyy); … }

30. Multiple Interfaces: Meet one Post class C implements I, J {} interface I { int out(); @post { out < 0 } } interface J { int out(); @post { out > 0 } } class Client { C c = new C(); ……... … ((I)c).m(); … ……… … ((J)c).m(); … } deal with objects on a per interface basis -- principle of least astonishment!

31. Substitutability (1) interface SimpleCounter { int getValue(); void dec(); void inc(); } interface PositiveCounter { int getValue(); void dec(); @pre { this.getValue() > 0 } void inc(); } class Counter implements SimpleCounter, PositiveCounter

32. Substitutability (2) class Factory { SimpleCounter make() { return new Counter(); } class Client { void m(SimpleCounter sc) { sc.dec(); } class Main { … Client c = new Client(); Factory f = new Factory(); c.m((PositiveCounter) c.make() ); … } undetected violation

33. Substitutability (3) class Proxy_Counter extends Counter { PositiveCounter c; Proxy_Counter(PositiveCounter x) { c = x; } void dec() { if (theValue < 0) Violation.error(“Main violated PositiveCounter”); super.dec(); } Who is guilty? How do we detect it?

34. Substitutability (4) proxy classes violate object equality (==) of (explicit and implicit) casts fixing this turns object equality into an expensive method a true fix requires class loader modifications in addition (legacy libraries)

35. Weakening & Strengthening “Post-s” interface I { I make(); } class C implements I { … } interface J extends I { I make(); @post { make instanceof J } } class D extends C implements J { … } it’s desirable it’s okay weakening could be done, too factory pattern

36. Weakening & Strengthening “Pre-s” interface I { Object visit(Visitor_I t); } interface J extends I { Object visit(Visitor_I t); @pre { t instanceof Visitor_J } } it’s desirable it causes trouble: require all implementations of J to satisfy pre use proxies as before weakening should be done; also causes problems extensible visitor pattern

37. Implied Interface Inheritance (1) class C implements I { … } class D extends C implements J { … } class C implements I { … } class D extends C implements J, I { … }

38. Implied Interface Inheritance (2) interface Array { … void update(int ix, Object o) @pre { x < this.getSize() } } interface Resize_Array { … void update(int x, Object o) } class AC implements Array class Resize_AC extends AC implements Resize_Array Java forces a precondition on Resize_AC’s update if viewed as an Array --- better: eliminate implied interface inheritance from Java

39. Compiling Contracts

40. The Idea elaborate contracts away check interface hierarchy contracts in interfaces become methods in implementations method calls are re-directed

41. Source with Contracts interface Queue { boolean empty(); Queue enq(Object X); @post { !this.empty() } Queue deq(); @pre { !this.empty() } void register(Observer o); } class Q implements Queue { boolean empty(); Queue enq(Object X) { … } Queue deq() { … } void register(Observer o) { … } }

42. Elaborated Target (1) interface Queue { boolean empty(); Queue enq(Object X); @post { !this.empty() } Queue deq(); @pre { !this.empty() } void register(Observer o); } class Q implements Queue { boolean empty(); Queue enq_Queue(Object X) { Object o = this.enq(X); if (this.empty()) error(“Queue violated”); return o; } Queue enq(Object X) { … } …

43. Elaborated Target (2) interface Queue { boolean empty(); Queue enq(Object X); @post { !this.empty() } Queue deq(); @pre { !this.empty() } void register(Observer o); } … Queue deq_Queue(String source) { if (this.empty()) error(source); this.deq(); } … }

44. Elaborated Target (3) class O implements Observer { void onEnq(Queue q) { q.deq(); } … } class O implements Observer { void onEnq(Queue q) { q.deq_Queue (“O violates Queue”); } … }

45. Elaboration with Multiple Interfaces interface J { S m(T x); @pre… @post … } interface I { S m(T x); @pre … @post … } class C implements I, J { … } class C implements I, J { S m_I(T x, String source) { … } S m_J(T x, String source) { … } S m(T x) { … } … }

46. Combining Multiple “Post-s” interface J extends I { S m(T x); @post post_J } interface I { S m(T x); @post post_I } class C implements J { … } class C implements J { S m_J(T x, String source) { … test post_I and post J … } S m(T x) { … } … }

47. Summary and Conclusion Adding contracts to Java is a compromise. It brings out weaknesses in Java design. Future work is to design a variant of Java that is more accommodating to contracts.

48. The End Joint work with Robby Findler Thanks to Matthew Flatt and Clemens Szyperski for discussions.