1 / 20

Disscussion: Semantic Issues for JML

This document summarizes discussions held on July 14, 2009, regarding the semantics of the Java Modeling Language (JML). Key decisions were made on various issues, including the representation of specifications, syntax changes, and the treatment of generics. Controversial topics were identified, including privacy restrictions, modular reasoning, and the usability of comprehensions. The discussions also addressed method specifications, the handling of constructors, and proposed changes to improve understanding and implementation of JML.

alden-smith
Download Presentation

Disscussion: Semantic Issues for JML

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. Disscussion: Semantic Issues for JML Gary T. LeavensUniversity of Central Florida Support from US National Science FoundationDagstuhl, July 14, 2009 jmlspecs.org www.eecs.ucf.edu/~leavens

  2. Decisions and Discussions In email of 11 July: • Decisions made and implemented • Decisions, documented, but not fully implemented • Decisions made but not documented or implemented • Discussions on open issues • Rejections

  3. Discussions Procedure we’ll follow: • Non-controversial, passed if no one objects, someone documents… • Controversial,we’ll pass along discussion & recommendation • approved --> non-controversial (see above) • rejected --> report that

  4. Discussions, non-controversial (?) • Drop <- from syntax for represents, use = protected represents x =_x/2; • Use <# and <#= for lock ordering • Allow comprehension expressions to use contains(), not just has() • \elemtype(null) is a null pointer exception,\elemtype(nonArray) is illegal arg exception,both technically undefined.

  5. Discussions, non-controversial (?) • New expression \let spec-var-declarators\in spec-expression Examples: \letint fv = \old(theThing(v+y).f) \in fv + fv \letint fv = \old(x.f) \in fv + fv

  6. Discussions, non-controversial (?) • Allow all specification expressions in model methods publicmodel sum2(int[] a) { return 2 * (\sum int j; 0<=j && j<a.length; a[j]); } Hard to implement in RAC?

  7. Discussions, non-controversial (?) • Invariant enforcement for method calls that occur in constructor’s cflow • Object “dented” until construction finished • invariant implicitly !dented ==> inv Against this: you could program it yourself… (Same as “raw”?)

  8. Discussions, non-controversial (?) • Privacy restrictions on specifications for modular reasoning (Leavens & Müller 2007) • For maintenance, don’t expose code details • For soundness, document obligations Specifications visible to module M: • Can only mention members visible to M • For maintenance • For understandability • Must contain all of M’s obligations • For sound modular verification

  9. Discussions, non-controversial (?) • Use relevant semantics for framing, invariants(Müller, et al., various papers) • If you don’t use universes, same as current • Using universes, only object’s universe and owned objects relevant, higher abstraction levels aren’t • Can only refer to rep fields in invariants Alternatives: • Boogie methodology in Spec# • Others?

  10. Discussions What user-visible syntax for JML? • Classic JML with /*@ … @*/ and //@ • Taylor’s annotation syntax (with dollar signs) @SpecCase(header="public normal_behavior", ensures=“$result <==> size == MAX_SIZE;") @Pure public boolean isFull(); • Alagic’s XVP annotations: @JML(“…”) • …

  11. Discussions What user-visible syntax for JML? • … • Java contracts public abstract @Pure boolean isFull(); … public @Pure void isFull$jc(boolean $result) { $specCase(PUBLIC, NORMAL); { $ensures($result == (size() == MAX_SIZE())); } } • Some combination?

  12. Possible Combination Syntax • Start with Classic JML syntax • Replace all modifiers (pure, spec_public, …)with Java annotations (@Pure, @SpecPublic,…) • Replace model fields and represents clauseswith @Pure @Model 0-argument Java methods • Replace model features with @Model Java features • Replace \oper(…) with JML.$oper() • Replace method specification annotations with @JML(“…”) Java 5 annotations. • More? Variations?

  13. Discussions • General method for adding extensions? ext_KeY_... keywords?

  14. Discussions • Simplify the set of suffixes we use for JML specification files?

  15. Discussions • Method caller must satisfy precondition ofreceiver’s static type.

  16. Discussions • Prohibit using instance fields of object being constructed in constructor preconditions?

  17. Discussions • Loosen the rules on the \sum and \product quantifier expressions, to allow other types in the body. • Loosen the rules on the \max and \min quantifier expressions, to allow any Comparable type in the body

  18. Discussions • How should Java's generics be handled? • Should \TYPE still be equal to java.lang.Class

  19. Discussions • Are \TYPE, \bigint, and \real, primitive types? • If so do they autobox and what to?

  20. Rejected Proposals • Generalized applicability of the helper modifier to all methods.

More Related