1 Javari: Adding Reference Immutability to Java Matthew Tschantz & Michael Ernst (MIT) OOPSLA’05 Presented by Tali Shragai.

Slides:



Advertisements
Similar presentations
Optional Static Typing Guido van Rossum (with Paul Prescod, Greg Stein, and the types-SIG)
Advertisements

Identity and Equality Based on material by Michael Ernst, University of Washington.
A subclass can add new private instance variables A subclass can add new public, private or static methods A subclass can override inherited methods A.
Composition CMSC 202. Code Reuse Effective software development relies on reusing existing code. Code reuse must be more than just copying code and changing.
Object and Reference Immutability using Java Generics Yoav Zibin, Alex Potanin(*), Mahmood Ali, Shay Artzi, Adam Kiezun, and Michael D. Ernst MIT Computer.
Interface & Abstract Class. Interface Definition All method in an interface are abstract methods. Methods are declared without the implementation part.
Overview of Java (continue). Announcements You should have access to your repositories and HW0 If you have problems getting HW0, let me know If you’ve.
Java Generics.
Liang, Introduction to Java Programming, Sixth Edition, (c) 2005 Pearson Education, Inc. All rights reserved Chapter 9 Inheritance and.
1 More on Inheritance Overview l Object: The father of all classes l Casting and Classes l Object Cloning l Importance of Cloning.
Java Generics. 2 The Dark Ages: Before Java 5 Java relied only on inclusion polymorphism  A polymorphism code = Using a common superclass Every class.
Object and Reference Immutability using Java Generics Yoav Zibin(1), Alex Potanin(2), Shay Artzi(1), Adam Kiezun(1), and Michael D. Ernst(1) 1) MIT Computer.
1 Evan Korth New York University Inheritance and Polymorphism Professor Evan Korth New York University.
Java 1.5 & Effective Java Fawzi Emad Chau-Wen Tseng Department of Computer Science University of Maryland, College Park.
1 Inheritance and Polymorphism. 2 Motivations Suppose you will define classes to model circles, rectangles, and triangles. These classes have many common.
C++ Training Datascope Lawrence D’Antonio Lecture 1 Quiz 1.
Declaring and Checking Non-null Types in an Object-Oriented Language Authors: Manuel Fahndrich K. Rustan M. Leino OOPSLA’03 Presenter: Alexander Landau.
1 Type Type system for a programming language = –set of types AND – rules that specify how a typed program is allowed to behave Why? –to generate better.
Mutable, Immutable, and Cloneable Objects Chapter 15 Slides by Steve Armstrong LeTourneau University Longview, TX  2007,  Prentice Hall.
Javari: Adding Reference Immutability to Java Matthew Tschantz and Michael Ernst MIT CSAIL.
CSE341: Programming Languages Lecture 11 Type Inference Dan Grossman Winter 2013.
Appendix A.2: Review of Java and Object-Oriented Programming: Part 2 “For the object-oriented project, remember that the primary unit of decomposition.
“is a”  Define a new class DerivedClass which extends BaseClass class BaseClass { // class contents } class DerivedClass : BaseClass { // class.
EECE 310: Software Engineering Lecture 2: Understanding Objects in Java and Types.
Java Implementation: Part 3 Software Construction Lecture 8.
2000 Jordan Anastasiade. All rights reserved. 1 Class In this lesson you will be learning about: Class. Inheritance. Polymorphism. Nested and.
APCS Java AB 2004 Review of CS1 and CS2 Review for AP test #1 Sources: 2003 Workshop notes from Chris Nevison (Colgate University) AP Study Guide to go.
Objects and Classes Chapter 6 CSCI CSCI 1302 – Objects and Classes2 Outline Introduction Defining Classes for Objects Constructing Objects Accessing.
Ownership and Immutability in Generic Java (OIGJ) Yoav Zibin +, Alex Potanin * Paley Li *, Mahmood Ali ^, and Michael Ernst $ Presenter: Yossi Gil + +
Announcements  If you need more review of Java…  I have lots of good resources – talk to me  Use “Additional Help” link on webpage  Weekly assignments.
CSE 425: Data Types I Data and Data Types Data may be more abstract than their representation –E.g., integer (unbounded) vs. 64-bit int (bounded) A language.
Java 5 Part 1 CSE301 University of Sunderland Harry Erwin, PhD.
User-defined type checkers for error detection and prevention in Java Michael D. Ernst MIT Computer Science & AI Lab
Chapter 9 Interfaces and Polymorphism. Chapter Goals To learn about interfaces To be able to convert between class and interface references To understand.
OOP: Encapsulation,Abstraction & Polymorphism. What is Encapsulation Described as a protective barrier that prevents the code and data being randomly.
Polymorphism. 3 main programming mechanisms that constitute OOP: 1. Encapsulation 2. Inheritance 3. Polymorphism.
Chapter 3 Inheritance and Polymorphism Goals: 1.Superclasses and subclasses 2.Inheritance Hierarchy 3.Polymorphism 4.Type Compatibility 5.Abstract Classes.
Programming in Java CSCI-2220 Object Oriented Programming.
C# Classes and Inheritance CNS 3260 C#.NET Software Development.
Advanced C# Types Tom Roeder CS fa. From last time out parameters difference is that the callee is required to assign it before returning not the.
COP INTERMEDIATE JAVA Designing Classes. Class Template or blueprint for creating objects. Their definition includes the list of properties (fields)
Inheritance. Inheritance - Introduction Idea behind is to create new classes that are built on existing classes – you reuse the methods and fields and.
Chapter 5 Objects and Classes Inheritance. Solution Assignments 3 & 4 Review in class…..
Liang, Introduction to Java Programming, Sixth Edition, (c) 2007 Pearson Education, Inc. All rights reserved Chapter 9 Inheritance and.
Liang, Introduction to Java Programming, Seventh Edition, (c) 2009 Pearson Education, Inc. All rights reserved Chapter 10 Inheritance and.
Javari: Adding Reference Immutability to Java Rauno Ots Matthew S. Tschantz Michael D. Ernst MIT CSAIL 2005.
CMSC 330: Organization of Programming Languages Java Generics.
Difficult Specifications in Javari Immutability Inference Jaime Quinonez Program Analysis Group April 20, 2007.
SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler
Object and Reference Immutability using Java Generics Yoav Zibin(1), Alex Potanin(2), Shay Artzi(1), Adam Kiezun(1), and Michael D. Ernst(1) 1) MIT Computer.
1 Chapter 4 Inheritance and Polymorphism. 2 Objectives u To develop a subclass from a superclass through inheritance. u To invoke the superclass’s constructors.
Quick Review of OOP Constructs Classes:  Data types for structured data and behavior  fields and methods Objects:  Variables whose data type is a class.
(c) University of Washington06-1 CSC 143 Java Inheritance Tidbits.
CMSC 202 Polymorphism. 10/20102 Topics Binding (early and late) Upcasting and downcasting Extensibility The final modifier with  methods  classes.
Zach Tatlock / Winter 2016 CSE 331 Software Design and Implementation Lecture 13 Generics 1.
ReIm & ReImInfer: Checking and Inference of Reference Immutability and Method Purity Wei Huang 1, Ana Milanova 1, Werner Dietl 2, Michael D. Ernst 2 1.
Chapter 7 Constructors and Other Tools Copyright © 2010 Pearson Addison-Wesley. All rights reserved.
1 Chapter 2 Inheritance and Polymorphism. 2 Objectives u To develop a subclass from a superclass through inheritance. u To invoke the superclass’s constructors.
Liang, Introduction to Java Programming, Seventh Edition, (c) 2009 Pearson Education, Inc. All rights reserved Chapter 10 Inheritance and Polymorphism.
Preventing bugs with pluggable type-checking Michael Ernst MIT
 Description of Inheritance  Base Class Object  Subclass, Subtype, and Substitutability  Forms of Inheritance  Modifiers and Inheritance  The Benefits.
Copyright © 2002 Pearson Education, Inc. Slide 1.
Copyright © 2002 Pearson Education, Inc. Slide 1.
EECE 309: Software Engineering
Polymorphism in Methods
Javarifier: inference of reference immutability
Chapter 9 Inheritance and Polymorphism
Extending Classes.
Object and Reference Immutability using Java Generics
CMPE212 – Reminders Assignment 2 due next Friday.
Presentation transcript:

1 Javari: Adding Reference Immutability to Java Matthew Tschantz & Michael Ernst (MIT) OOPSLA’05 Presented by Tali Shragai

2 Extension to Javari2004 [Birka]  Javari: Java + (C++ const) + more… Two new keywords: readonly, mutable  OOPSLA’04: Initial Javari implementation  Experience: 160,000 code lines Better documentation Error detection and prevention Compatible with Java & existing JVMs  But: No Generics, serialization, reflection Confuses mutability & assignability  Javari 05: More keywords: assignable, romaybe Genericity, reflection, serialization Most important (?): mutability vs. assignability

3 Protecting method arguments  A library routine does not modify its arguments: static void print(readonly Date d) {... // Cannot modify d } String toString() readonly {... // Cannot modify the receiver }

4 Protecting abstract state: observer methods class Class { private Object[] signers; Object[] getSigners() { return signers; // JDK 1.1 security hole } myClass.getSigners()[0] = “Sun”;

5 Protecting abstract state: observer methods (revised) class Class { private Object[] signers; readonly Object[] getSigners() { return signers; // Fixes JDK 1.1 bug } myClass.getSigners()[0] = “Sun”; // Error

6 Reference vs. Object immutability  Reference immutability Object modification:  Readonly reference: no!  Other reference: yes. Deep: cannot modify transitively reachable state Static type checking!  Dynamic checking for mutability downcasts  Object immutability : write protect from any reference Graph temp = new Graph(); // construct the graph readonly Graph g = temp; temp = null; // further usage through read only reference…  Javari : object immutability emulated by reference immutability

7 Related work  Old trick: pass/return by value pain for large objects  C++: const, const_cast Unsound (unchecked casts) Non-transitive! No immutability-based parameterization Leads to code duplication (const methods) No support for multidimensional arrays?  JAC [Kniesel 2001]: Implementation requires rewriting the code Unsound (subtyping, arrays) Return type mutability equals receiver's

8 Protection methods LevelJavaC++Javari Level 1 assignment final Foo aconst Foo *afinal Foo a Level 2 mutability  Foo const *areadonly Foo a Level 3  const Foo const *afinal readonly Foo a … Level ∞  Transitive protection!

9 Yield protection LevelJavaC++Javari Level 1  mutable Foo *aassignable Foo a Level 2  mutable Foo a

10 Readonly readonly Date rd = new Date(); rd.year = 2005; // Compile-time error rd.incrementDay(); // Compile-time error rd = new Foo(); // OK

11 Mutability vs. Assignability final Date fd = null; readonly Date rd = null; fd = new Date(); // Error: final rd = null; // OK Date d1 = fd; // OK Date d2 = rd; // Error: wrong type MutabilityAssignability part of the typenot part of the type may abstract state mutate? can be lvalue in assignment? readonlyfinal

12 Type system Every type (mutable) T has readonly T as a supertype readonly Object readonly Date /*mutable*/ Object /*mutable*/ Date

13 Immutable classes  A class/interface can be declared immutable using readonly in its class declaration. Non-static fields & methods  readonly (default) Reference to its objects  implicitly read-only Subclasses must be immutable too! readonly class String{…} /*readonly*/ String s1 = new String(); readonly String s2 = new String(); S1 = s2;// OK S2 = s1;// OK

14 Assignability  May a reference be assigned to? class Appointment { final Date time; // Same as in Java assignable int room; } Appointment appoint; appoint.time = new Date(); // Error appoint.room = 250; // OK

15 Assignability modifiers final: May never be assigned assignable: May always be assigned (default for locals) this-assignable: May be assigned through a mutable reference May not be assigned through a readonly reference Only applicable to fields (the default) The assignability depends on the mutability of the enclosing object: “this”

16 Assignability example class Bicycle { final int id; // Never changes assignable int hashCode; // A cache /*this-assign*/ int gear; // Abstract state } /*mutable*/ Bicycle b; readonly Bicycle rb;

17 final class Bicycle { final int id; // Never changes assignable int hashCode; // A cache /*this-assign*/ int gear; // Abstract state } /*mutable*/ Bicycle b; readonly Bicycle rb; b.id = 5; // Error rb.id = 5;// Error Resolved assignability of ref.f Declared assignability of f Resolved mutability of ref mutablereadonly final unassignable

18 assignable class Bicycle { final int id; // Never changes assignable int hashCode; // A cache /*this-assign*/ int gear; // Abstract state } /*mutable*/ Bicycle b; readonly Bicycle rb; b.hashCode = 5; // OK rb.hashCode = 5; // OK Resolved assignability of ref.f Declared assignability of f Resolved mutability of ref mutablereadonly finalunassignable assignable

19 this-assignable class Bicycle { final int id; // Never changes assignable int hashCode; // A cache /*this-assign*/ int gear; // Abstract state } /*mutable*/ Bicycle b; readonly Bicycle rb; b.gear = 5; // OK rb.gear = 5; // Error Resolved assignability of ref.f Declared assignability of f Resolved mutability of ref mutablereadonly finalunassignable assignable this-assignableassignableunassignable

20 Mutability  May the object’s transitive abstract state be modified? class Date { /*this-assignable*/ int year; } /*mutable*/ Date d; readonly Date rd; d.year = 2005; // OK rd.year = 2005; // Error

21 Mutability modifiers readonly: May never be mutated mutable: May always be mutated, the default for locals this-mutable: May be mutated through mutable reference May not be mutated through readonly references Only applicable to fields (the default) The mutability depends on the mutability of the enclosing class: “this”

22 Mutability example class Account { readonly Customer owner; mutable RequestLog requests; /*this-mut*/ Balance bal; } /*mutable*/ Account a; readonly Account ra;

23 readonly class Account { readonly Customer owner; mutable RequestLog requests; /*this-mut*/ Balance bal; } /*mutable*/ Account a; readonly Account ra; a.owner.setName(“Bob”); // Error ra.owner.setName(“Bob”); // Error Mutability of ref.f Declared mutability of f Resolved mutability of ref mutablereadonly

24 mutable class Account { readonly Customer owner; mutable RequestLog requests; /*this-mut*/ Balance bal; } /*mutable*/ Account a; readonly Account ra; a.requests.add(“checkBalance”); // OK ra.requests.add(“checkBalance”); // OK Mutability of ref.f Declared mutability of f Resolved mutability of ref mutablereadonly mutable mutable excludes requests from the abstract state of the object

25 this-mutable class Account { readonly Customer owner; mutable RequestLog requests; /*this-mut*/ Balance bal; } /*mutable*/ Account a; readonly Account ra; a.balance.withdraw(1000); // OK Declared mutability of f Resolved mutability of ref mutablereadonly mutable this-mutablemutable?

26 this-mutable class Account { readonly Customer owner; mutable RequestLog requests; /*this-mut*/ Balance bal; } /*mutable*/ Account a; readonly Account ra; a.balance.withdraw(1000); // OK ra.balance.withdraw(1000); // Error Mutability of ref.f Declared mutability of f Resolved mutability of ref mutablereadonly mutable this-mutablemutablereadonly?

27 this-mutable fields reached through a readonly reference readonly, right?

28 this-mutable fields reached through a readonly reference readonly, right? NO, would result in type loophole allowing one to convert a readonly reference to a mutable reference:

29 this-mutable fields reached through a readonly reference class Student { assignable /*this-mut*/ GradeReport grades; } /*mutable*/ Student s = new Student(); readonly Student rs = s; readonly GradeReport rg; /*mutable*/ GradeReport g; rs.grades = rg; //readonly assigned to this-mutable g = s.grades; //this-mutable assigned to mutable Downcast rs s grades Non-readonly Readonly Readonly?? assignable

30 this-mutable fields reached through a readonly reference  Solution: Disallow readonly references to be assigned to a this-mutable field  this-mutable fields through readonly reference are: readonly as rvalue (may only be assigned to a readonly reference) mutable as lvalue (may only be assigned with mutable reference)  Notation:

31 Uses of parametric classes  Local variable declarations: /*mut*/ List a; // add, mutate /*mut*/ List b; // add readonly List c; // mutate readonly List d; // neither

32 Inside parametric classes  Type arguments include mutability  Library cannot write: class C { mutable T x; } C y; // Conflicting types  Library can force a mutable type using a bound: ; class C { T x; }

33 this-mutable type arguments class Device { /*this-mut*/ List drivers; } /*mutable*/ Device d; readonly Device rd; d.drivers has type /*mut*/ List /*mut*/ List dl = d.drivers; // OK

34 this-mutable type arguments class Device { /*this-mut*/ List drivers; } /*mutable*/ Device d; readonly Device rd; rd.drivers has type ? readonly List readonly List x = rd. drivers; //OK readonly List y = rd. drivers; //Error readonly List z = rd. drivers; //Error

35 Serialization  Add a readonly-ness bit to the serialized form.  De-serialization done using 2 versions of ObjectInputStream.readObject : readObjectReadonly – returns a read-only object, without checking. readObject – returns a mutable objects, but throws an exception if the readonly-ness bit is set.

36 Reducing code duplication  In Java, each class definition defines exactly one type. In Javari, by contrast, a class C actually denotes 2 type: C and readonly C.  romaybe keyword templates over methods class Conference { /*this-mutable*/ Date d;  We wish to write two (overloaded) methods: readonly Date getDate() readonly { return d;} /*mutable*/ Date getDate() /*mutable*/{ return d;}  Syntactic sugar: romaybe Date getDate() romaybe { return d;} }

37 Downcasts  Javari guarantees that a readonly reference cannot be used, directly or indirectly, to modify its referent.  Down-casting a reference from readonly to mutable triggers run- time checks, which disallow any modifications done through the casted reference.

38 Downcast example class Foo{ Date d; void setD() /*mutable*/{ d = new Date(); } Foo f1 = new Foo(); readonly Foo rf = f1; Foo f2 = (mutable)rf; f1.d = new Date();// OK f2.d = new Date();// run-time error f1.setD();// OK F2.setD();// run-time error

39 Contributions  Transitive reference immutability  Distinguishes assignability and mutability  Formal model (not shown here)  Type system for full Java 5.0 including parametric polymorphism, reflection, and serialization  Templates to reduce code duplication  Interoperable with Java  Still to come: type inference…

40 The End! Thank you for listening…