Transcript ECOOP 2007 Highlights -

ECOOP 2007 Highlights
A Personal Summary
Yishai Feldman
IBM Haifa Research Lab
1
Major Topics
Type theories
 Contracts and invariants
 Functional languages

2
Main Conference (1st Day)
Invited Talk: Erlang - Software for a Concurrent World, Joe Armstrong
Types

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 Dolby
Runtime 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 Jiang
Empirical 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
3
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 Zayour
Language 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 Eugster
Inheritance 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
4
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
5
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 ObjectOriented 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 ObjectOriented 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
6
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 ComponentOriented 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
7
Main Conference
8
Invited Talk: Erlang: Software for a
Concurrent World
Joe 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”


Concurrency Oriented Programming







“Sharing is the property that prevents fault tolerance”
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”
9
Erlang (2)
10
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, nonmutability means we don't get any problems with
memory corruption)

11
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
12
© Copyright 2007 SAP AG
All Rights Reserved
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.”



“Let’s build a new scripting language, and we’ll be doing fine.”


Are tooling concerns addressed appropriately?
How do you restrict the host language infrastructure to use only your
DSL?
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?
13
© Copyright 2007 SAP AG
All Rights Reserved
Axel Uhl (2)

Scripting ↔ Non-Scripting

Scripting is about



Blurring boundaries







eliminating the compilation step
using flexible type systems to make developer more productive
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
14
© Copyright 2007 SAP AG
All Rights Reserved
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)


Many issues of classical “programming” also exist for “modeling”




strive for adequate abstractions, concern separation and aspect
localization
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?
15
© Copyright 2007 SAP AG
All Rights Reserved
Axel Uhl (4)

Environmental factors to consider

number of developers working on a software product


size of the software


may require good modularization, as well as flexible delivery and
deployment options
supporting IDE features enabled by the language design



may require good collaborative features (e.g., partitioning,
diff/merge)
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
16
© Copyright 2007 SAP AG
All Rights Reserved
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
17
© Copyright 2007 SAP AG
All Rights Reserved
Axel Uhl (6)

Lifecycle Issues of Multiple (Graphical) Views

Changing a model through one view may update
another



Changes in graphical views may be for viewing only...



views may be versioned and access-controlled artifacts
extensions to models may be provided in multiple layers of
the system
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
18
Gradual Typing for Objects
Jeremy Graham Siek, Walid Taha



Combining static and dynamic typing in a single
language, under programmer control
Type-theoretic foundation for gradual typing in objectoriented 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 = 1
var p = new Point
p.move(a)
19
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.”
20
Dependence on Mutable State
class 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;
}
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
}
public int hashCode() {
return 13 * x + 17 * y;
}
public void setX(int n) {
x = n;
}
p2 seems
}
to disappear from the set
Odd behavior and no violation of equality contract
21
Java’s Equality Contract: Problems

Observation of several open-source Java applications revealed:

Dependence on mutable state





ant, bcel, hsqldb, javacup, jfreechart, lucene, pmd, shrike
Violations of the equals/hashCode contract
ant, bcel, javacup, jfreechart
Violations of symmetry/transitivity requirement




equals refers to a field that is not final
Highly error-prone & hard to debug, when used for collections
Not forbidden by contract
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
22
Relation Types

Define object identity declaratively




Implementation



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
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
23
relation Person {
key int SSN;
Name name;
}
relation Name {
key String first;
key String last;
}
relation FullName
extends Name {
key String middle;
String nickName;
}
relation Car {
key String model;
key int year;
key String plate;
}
class Policy { ... }
relation CarInsurance {
key Person person;
key Car car;
Policy policy;
int computePremium(){ ... }
}
main(String[]
Person p1 =
Person p2 =
Person p3 =
// p1 == p2
// p1 != p3
// p1.SSN =
args) {
Person.id(123);
Person.id(123);
Person.id(456);
789 ==> compile error
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”
Policy pol1 = new Policy();
Policy pol2 = new Policy();
// pol1 != pol2
Car c1 = Car.id(“Kia”,2004,“DZN”);
CarInsurance carIns =
CarInsurance.id(p1, c1);
carIns.policy = pol1;
carIns.computePremium();
}
24
Relation Types
...
relation PolicyMgr {
main(String[] args) {
// no key fields
...
public void add(Policy p){
PolicyMgr pm = PolicyMgr.id();
policies.add(p);
pm.add(pol1);
}
pm.add(pol2);
List<Policy> policies =
new ArrayList<Policy>(policy); 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
}
25
Non-null References by Default in Java:
Alleviating the Nullity Annotation Burden
Patrice 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 nonnull, 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.
26
27
Other Papers

Object-Relative Addressing: Compressed Pointers in 64-bit Java
Virtual Machines


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




Reduce memory consumption by ~10% by compressing 64-bit raw pointers into
32-bit offsets relative to the referencing object’s virtual address
“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
28
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)
29
IWACO Program
Invited speaker

Vijay Saraswat, IBM TJ Watson Research Lab and Penn State University
Papers

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
30
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
C
g: A
h: B
Inv: … f.g …
31
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


Dynamic associations


Primitive associations (Ernst); borrowing (Boyland & al.)
Callbacks (invariants temporarily violated)


Colleagues (Kerfoot & McKeever)
Aggregate invariants (Parkinson)
Who will annotate?

Discover rep/peer/any relationships dynamically (Dietl & Müller)
32
Annotations for (more) Precise Pointsto 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();
}
33
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();
}
34