1

ECOOP 2007 HighlightsA Personal Summary

Yishai Feldman

IBM Haifa Research Lab

2

Major Topics Type theories Contracts and invariants Functional languages

3

Main Conference (1st Day)Invited Talk: Erlang - Software for a Concurrent World, Joe ArmstrongTypes Gradual Typing for Objects, Jeremy Graham Siek, Walid Taha Generic Universe Types, Werner Dietl, Sophia Drossopoulou, Peter Müller Declarative Object Identity Using Relation Types, Mandana Vaziri, Frank Tip, Stephen Fink,

Julian DolbyRuntime Implementation Object-Relative Addressing: Compressed Pointers in 64-bit Java Virtual Machines, Kris

Venstermans, Lieven Eeckhout, Koen De Bosschere Generational Real-time Garbage Collection: A Three-part Invention for Young Objects,

Daniel Frampton, David Bacon, Perry Cheng, David Grove AS-GC: An Efficient Generational Garbage Collector for Java Application Servers, Feng

Xian, Witawas Srisa-an, ChengHuan Jiang, Hong JiangEmpirical Studies Exception Handling: A Field Study in Java and .NET, Bruno Cabral, Paulo Marques On the Impact of Aspectual Decompositions on Design Stability: An Empirical Study, Philip

Greenwood, Thiago Bartolomei, Eduardo Figueiredo, Marcos Dosea, Alessandro Garcia, Nelio Cacho, Claudio Sant'Anna, Uira Kulesza, Sérgio Soares, Paulo Borba, Awais Rashid

Panel: OOPS in the Next Five Years: The Hot Topics, Judith Bishop, Tiziana Margaria, Martin Odersky, Michael Stal, Dave Thomas, Gilad Bracha

Reception: Current Challenges for Industrial Software Development Tools and Languages,Axel Uhl

4

Main Conference (2nd Day)Dahl-Nygaard-Prize Senior laureate: Luca Cardelli (Microsoft Research Cambridge)

An Accidental Simula User Programs and Predicates Validity Invariants and Effects, Yi Lu, John Potter Non-null References by Default in Java: Alleviating the Nullity Annotation Burden, Patrice

Chalin, Perry James Efficiently Generating Structurally Complex Inputs with Thousands of Objects, Bassem

Elkarablieh, Sarfraz Khurshid, Yehia ZayourLanguage Design Matching Objects with Patterns, Burak Emir, Martin Odersky, John Williams DirectFlow: a Domain-Specific Language for Information-Flow Systems, Chuan-kai Lin,

Andrew P. Black A Relational Model of Object Collaborations and its Use in Reasoning about Relationships,

Stephanie Balzer, Thomas R. Gross, Patrick EugsterInheritance and Derivation JavaGI: Generalized Interfaces for Java, Stefan Wehr, Ralf Lämmel, Peter Thiemann Metaprogramming with Traits, John Reppy, Aaron Turon Morphing: Safely Shaping a Class in the Image of Others, Shan Shan Huang, David Zook,

Yannis Smaragdakis A Higher Abstraction Level using First-Class Inheritance Relations, Marko van Dooren, Eric

Steegmans

5

Main Conference (3rd Day)Dahl-Nygaard-Prize Junior laureate: Jonathan Aldrich (Carnegie Mellon University)

Assuring Object-Oriented Architecture

Aspects MAO: Ownership and Effects for more Effective Reasoning about Aspects,

Curtis Clifton, Gary T. Leavens, James Noble Joinpoint Inference from Behavioral Specification to Implementation, Thomas

Cottenier, Aswin van den Berg, Tzilla Elrad A Machine Model for Aspect-Oriented Programming, Michael Haupt, Hans

Schippers A Staged Static Program Analysis to Improve the Performance of Runtime

Monitoring, Eric Bodden, Laurie Hendren, Ondrej Lhoták

Language about Language Tracking Linear and Affine Resources with Java(X), Markus Degen, Peter

Thiemann, Stefan Wehr Attribute Grammar-based Language Extensions for Java, Eric Van Wyk, Lijesh

Krishnan, August Schwerdfeger, Derek Bodin Metamodel Adaptation and Model Co-adaptation, Guido Wachsmuth

6

Workshops (1st Day) M-ADAPT — Model-Driven Software Adaptation ADI 2007 — Workshop on Aspects, Dependencies, and Interactions WOOR 2007 — 8th International Workshop on Object-Oriented

Reengineering EOOLT 2007 — 1st International Workshop on Equation-Based Object-

Oriented Languages and Tools ELW — 4th European Lisp Workshop Roles'07 — Roles and Relationships, in Object Oriented Programming,

Multiagent Systems and Ontologies OT4AmI — 3rd Workshop on Object Technology for Ambient Intelligence ICOOOLPS — Implementation, Compilation, Optimization of Object-

Oriented Languages, Programs and Systems IWACO — 2nd International Workshop on Aliasing, Confinement and

Ownership in Object-Oriented Programming Eleventh Workshop on Pedagogies and Tools for the Teaching and

Learning of Object Oriented Concepts

7

Workshops (2nd Day) Third Workshop on Models and Aspects - Handling Crosscutting

Concerns in MDSD RAM-SE'07 — Reflection, AOP and Meta-Data for Software

Evolution WCOP 2007 — Twelfth International Workshop on Component-

Oriented Programming MPOOL'07 — Multiparadigm Programming with OO Languages Dyla'07 — 3rd Workshop on Dynamic Languages and Applications WRT'07 — 1st Workshop on Refactoring Tools WCAT'07 — 4th International Workshop on Coordination and

Adaptation Techniques for Software Entities QAOOSE 2007 — 11th ECOOP Workshop on Quantitative

Approaches in Object-Oriented Software Engineering FTfJP 2007 — Formal Techniques for Java-like Programs

8

Main Conference

9

Invited Talk: Erlang: Software for a Concurrent WorldJoe Armstrong (Ericsson Telecom AB, Sweden) Problem: How do we build systems that run forever, are scalable,

fault-tolerant, evolve with time and work reasonably well works despite errors in the software? (planetary scale – giga-year operations – no loss of service)

“Shared memory and fault tolerance is incredibly difficult” “Sharing is the property that prevents fault tolerance”

Concurrency Oriented Programming A style of programming where concurrency is used to structure the

application Large numbers of processes Complete isolation of processes No sharing of data Location transparency Pure message passing

How do we program multicores? Hint: “Erlang has no mutable state and processes”

10

Erlang (2)

11

Erlang (3) Programming Multicore computers is difficult

because of shared mutable state. Functional programming languages have no

shared state and no mutable state. Concurrent FPLs have the right intrinsic

properties for programming multicore computers (concurrency maps to the multiple CPUs, non-mutability means we don't get any problems with memory corruption)

12

Panel: OOPS in the Next Five Years: The Hot Topics Gilad Bracha: Convergence of OOP & Functional Programming:

Erlang, Scala There is no contradiction between OOP & FP Democratization: More and more people are

programming, and they are less and less qualified to do so, which means we won’t see elaborate type systems for static checking in extensive use

Expect to see something ugly with braces that is functional

Luca Cardelli (in Dahl-Nygaard Prize Invited Talk): OOP will soon have ML-style type inference

13

Reception: Current Challenges for Industrial Software Development Tools and Languages Axel Uhl (Chief Development Architect, SAP) Demystifying Language Approaches

“We could embed a DSL into a suitable host language.” Are tooling concerns addressed appropriately? How do you restrict the host language infrastructure to use only your

DSL? “Let’s build a new scripting language, and we’ll be doing fine.”

But what distinguishes scripting in the first place? “Ok, so we’re going to use a model-driven approach.”

But what’s the difference between an executable model and a piece of code?

And where is a graphical syntax more appropriate than an ASCII text? Is a model transformation or a code generator different from a compiler? Can I debug my models when the system doesn’t behave as expected?

© Copyright 2007 SAP AG All Rights Reserved

14

Axel Uhl (2) Scripting ↔ Non-Scripting

Scripting is about eliminating the compilation step using flexible type systems to make developer more productive

Blurring boundaries short compile/run/debug cycles even for compiled languages JIT compilation (Java byte code native; JSP to Java to byte code; ...) type system qualities (static vs. dynamic vs. duck typing; inference) memory management and bounds checking in compiled languages lifecycle management requirements for scripting solutions difficult auto-completion and refactorings in IDEs due to lack of type

information Core values

quick roundtripping easy to learn making change easy good integration capabilities

© Copyright 2007 SAP AG All Rights Reserved

15

Axel Uhl (3) Modeling ↔ Coding

There are many commonalities in what we call programming language and modeling language. Both

have abstract and concrete syntax can be of rather declarative or imperative nature can use different types of representation (though we usually think of

programming language artifacts as ASCII strings) strive for adequate abstractions, concern separation and aspect

localization Many issues of classical “programming” also exist for “modeling”

physical partitioning of artifacts dependencies teamwork aspects (change management, versioning, ...)

What’s the difference between a code generator / model transformer and a compiler? a piece of C++ code and a sequence chart?

© Copyright 2007 SAP AG All Rights Reserved

16

Axel Uhl (4) Environmental factors to consider

number of developers working on a software product may require good collaborative features (e.g., partitioning,

diff/merge) size of the software

may require good modularization, as well as flexible delivery and deployment options

supporting IDE features enabled by the language design auto-completion (“intellisense”), refactoring, static checks, type

inference debugging capabilities

life cycle of a piece of software from small to large from local to central from prototype to product from one-off to commercial success

© Copyright 2007 SAP AG All Rights Reserved

17

Axel Uhl (5) Why Representation May Matter

State of the art for textual languages lexer / parser generators come off the shelf auto-complete and refactoring frameworks maturing diff/merge is understood well text-based “model” editing (TEF, Intentional Domain Workbench)

becoming available developer-type people love this

State of the art for graphical languages different approaches to specifying the notation (GMF, MetaEdit+, ...) model partitioning and diffing not addressed by generic “meta case”

frameworks hence, model merge not reasonably addressed partial views raise question where to find an abstract piece of

information in a concrete artifact non-developer people love this; relations and flow sometimes even

liked by developers

© Copyright 2007 SAP AG All Rights Reserved

18

Axel Uhl (6) Lifecycle Issues of Multiple (Graphical) Views

Changing a model through one view may update another

views may be versioned and access-controlled artifacts extensions to models may be provided in multiple layers of

the system Changes in graphical views may be for viewing only...

toggle expanded/collapsed setting on a diagram entity change the zoom level and panning position

...but should not necessitate checkout/versioning operation

user may not have the permissions required creation of a new version not justified by minor changes of

settings

© Copyright 2007 SAP AG All Rights Reserved

19

Gradual Typing for ObjectsJeremy Graham Siek, Walid Taha

Combining static and dynamic typing in a single language, under programmer control

Type-theoretic foundation for gradual typing in object-oriented languages

“Type consistency and subtyping are orthogonal and can be naturally superimposed”

class Point { var x = 0 function move(dx) { this.x = this.x + dx }}var a : int = 1var p = new Pointp.move(a)

20

Declarative Object Identity Using Relation Types Mandana Vaziri, Frank Tip, Stephen Fink, Julian Dolby

Object identity can be defined by overriding equals() and hashCode()

“The contract is unenforced and at times impossible to satisfy, and its implementation requires tedious and error-prone boilerplate code.”

Subtle bugs when objects that change cannot be found in hash-based collections

“Relation types are a programming model in which object identity is defined declaratively, obviating the need for equals() and hashCode() methods.”

“This entails a stricter contract: identity never changes during an execution.”

21

Dependence on Mutable Stateclass Point { int x; int y;

public boolean equals(Object o){ if (!(o instanceof Point)) return false; return ((Point)o).x == this.x

&& ((Point)o).y == this.y; }

public int hashCode() { return 13 * x + 17 * y; }

public void setX(int n) { x = n; }

}

main(String[] args) { Set<Point> s = new HashSet<Point>(); Point p1 = new Point(3, 4); s.add(p1); Point p2 = new Point(3, 4); //s.contains(p2) == true p1.setX(5); //s.contains(p2) == false }

p2 seems to disappear from the setOdd behavior and no violation of equality contract

22

Java’s Equality Contract: Problems Observation of several open-source Java applications revealed:

Dependence on mutable state equals refers to a field that is not final Highly error-prone & hard to debug, when used for collections Not forbidden by contract

ant, bcel, hsqldb, javacup, jfreechart, lucene, pmd, shrike Violations of the equals/hashCode contract

ant, bcel, javacup, jfreechart Violations of symmetry/transitivity requirement

Cannot always be satisfied

hsqldb, jfreechart, pmd Violations of the requirement that o.equals(null) is false

pmd Under-specified: throwing of exceptions in equals/hashCode

lucene, pmd Correct implementations have a very specific structure

Much boiler-plate code required, esp. when hash-consing is performed

23

Relation Types Define object identity declaratively

Programmer declares which fields define identity (called key fields) An instance of a relation type is a tuple The identity of a tuple is determined by its type and the identities of its

keys Implementation

equals/hashCode methods generated automatically by the compiler Code implementing hash-consing also generated automatically by the

compiler An implicitly defined, stricter and enforced equality contract

Identity is immutable Disallow defining object identity in terms of mutable state

Equality is an equivalence relation Objects of different types are never equal Explicit conversion methods

24

main(String[] args) { Person p1 = Person.id(123); Person p2 = Person.id(123); Person p3 = Person.id(456); // p1 == p2 // p1 != p3 // p1.SSN = 789 ==> compile error

relation Person { key int SSN; Name name;}relation Name { key String first; key String last;}relation FullName extends Name { key String middle; String nickName;}

Name n1 = Name.id(“Alice”,“Jones”);Name n2 = FullName.id(“Alice”, “Jones”, “Leah”);p1.name = n1;// n1 != n2// n1 == ((FullName)n2).toName()// p2.name.first == “Alice”// p2.name.last == “Jones”

class Policy { ... }

relation CarInsurance { key Person person; key Car car; Policy policy; int computePremium(){ ... }}

relation Car { key String model; key int year; key String plate;} Policy pol1 = new Policy();

Policy pol2 = new Policy();// pol1 != pol2Car c1 = Car.id(“Kia”,2004,“DZN”);CarInsurance carIns = CarInsurance.id(p1, c1);carIns.policy = pol1;carIns.computePremium();}

25

Relation Types

...relation PolicyMgr { // no key fields public void add(Policy p){ policies.add(p); } List<Policy> policies = new ArrayList<Policy>(policy);}

main(String[] args) { ... PolicyMgr pm = PolicyMgr.id(); pm.add(pol1); pm.add(pol2);

Set<Person> people = new HashSet<Person>(); people.add(p1); people.add(p3); // people.contains(p2) is true p2.name = n2; // people.contains(p2) is still true }

26

Non-null References by Default in Java: Alleviating the Nullity Annotation BurdenPatrice Chalin, Perry James

“A marked increase in tools that statically detect potential null dereferences”

JSR 305 will “work to develop standard annotations (such as @NonNull) that can be applied to Java programs to assist tools that detect software defects.”

Empirical study of 5 open source projects totaling 700 KLOC

On average, 3/4 of declarations are meant to be non-null, by design

Customized version of the Eclipse 3.3 JDT Core which supports non-null types Edit-time, compile-time and runtime checking of nullity

annotations Propose adopting a non-null-by-default semantics.

27

28

Other Papers Object-Relative Addressing: Compressed Pointers in 64-bit Java

Virtual Machines Reduce memory consumption by ~10% by compressing 64-bit raw pointers into

32-bit offsets relative to the referencing object’s virtual address Exception Handling: A Field Study in Java and .NET

“Exceptions are not being correctly used as an error recovery mechanism. Exception handlers are not specialized enough for allowing recovery and, typically, programmers just do one of the following actions: logging, user notification and application termination.”

On the Impact of Aspectual Decompositions on Design Stability: An Empirical Study

“AO implementations tend to have a more stable design particularly when a change targets a crosscutting concern”

“changes tended to be much less intrusive and more simplistic to apply in the AO implementations”

“aspect decomposition narrows the boundaries of concern dependencies, however, with more tight and intricate interactions”

JavaGI: Generalized Interfaces for Java An experimental language that extends Java 1.5 by generalizing the interface

concept to incorporate the essential features of Haskell’s type classes

29

IWACO — 2nd International Workshop on Aliasing, Confinement and Ownership in Object-Oriented

Programming

David Clarke (CWI, The Netherlands)

James Noble (VU Wellington, New Zealand)

Tobias Wrigstad (U Stockholm, Sweden)

30

IWACO ProgramInvited speaker Vijay Saraswat, IBM TJ Watson Research Lab and Penn State UniversityPapers Ownership Meets Java, Christo Fogelberg, Alex Potanin & James Noble Simple and Flexible Stack Types, Frances Perry, Chris Hawblitzel & Juan Chen Maintaining Invariants Through Object Coupling Mechanisms, Eric Kerfoot & Steve

McKeever See the Pet in the Beast: How to Limit Effects of Aliasing, Franz Puntigam Ownership, Uniqueness and Immutability, Johan Östlund, Tobias Wrigstad, Dave Clarke &

Beatrice Åkerblom Iterators can be Independent “from” Their Collections, John Boyland, William Retert & Yang

Zhao Using ownership types to support library aliasing boundaries, Luke Wagner, Jaakko Järvi &

Bjarne Stroustrup Ownership Domains in the Real World, Marwan Abi-Antoun & Jonathan Aldrich Compile-Time Views of Execution Structure Based on Ownership, Marwan Abi-Antoun &

Jonathan Aldrich Class Invariants: The end of the road?, Matthew Parkinson Annotations for (more) Precise Points-to Analysis, Mike Barnett, Manuel Fähndrich, Diego

Garbervetsky & Francesco Logozzo Runtime Universe Type Inference, Werner Dietl & Peter Müller 2007 State of the Universe Address, Werner Dietl & Peter Müller Primitive Associations, Erik Ernst Formalizing Composite State Encapsulation, Adrian Fiech & Ulf Schuenemann

31

Issues “Representation exposure” How to manage interconnected object structures in the

presence of aliasing Objects can be modified through any alias, possibly

breaking other objects’ contracts This makes it difficult to reason about and optimize

programs, obscures the flow of information between objects, and introduces security problems

A

f: B

B

g: A

Inv: … f.g …

C

h: B

32

Solutions Ownership: restricting modification rights through certain

aliases A strict ownership hierarchy; only owners are allowed to modify

owned objects Invariants can only depend on owned objects Can be checked statically (and encoded with generics) Owners as dominators vs. owners as modifiers

Challenges Circular (and recursive) data structures

Colleagues (Kerfoot & McKeever) Dynamic associations

Primitive associations (Ernst); borrowing (Boyland & al.) Callbacks (invariants temporarily violated)

Aggregate invariants (Parkinson) Who will annotate?

Discover rep/peer/any relationships dynamically (Dietl & Müller)

33

Annotations for (more) Precise Points-to Analysis (Barnet & al.)

Method annotations for .NET

Summarize non-analyzable methods (e.g., interface methods, native calls)

Enable modular analysis Documentation and contracts

to impose restrictions on eventual implementations

class List<T> {

[GlobalAccess(false)]

public List<T>();

[GlobalAccess(false)]

public void Add(T t);

...

}

interface IEnumerable<T>{

[return: Fresh]

[Escapes(true)] // receiver spec

[GlobalAccess(false)]

IEnumerator<T> GetEnumerator();

}

interface IEnumerator<T> {

[WriteConfined] bool MoveNext();

T Current { [GlobalAccess(false)] [Pure] get; }

[WriteConfined] void Reset();

}

34

See the Pet in the Beast: How to Limit Effects of Aliasing (Puntigam)

Limit modifiability through aliases by associating tokens with references

Methods can require specific tokens to be associated with the reference through which they are invoked

These are removed; other tokens can be added on return

Similar to typestates (a state is a set of tokens)

interface Window { [init -> shown,ready] void initialize(...); [ready -> ready] void update(...); [shown -> icon] void iconify(); [icon -> shown] void uniconify(); [shown,ready ->] void close (); int getCreationTime();}