eclipse day india 2015 - keynote - stephan herrmann

8

Stephan Herrmann

Java 8 ready

NPE

Languages

Too

ls

Inn

ova tio

n

Finding the best leverage

(How) Can I Move It?(How) Can I Move It?

Multiply the Available ForceMultiply the Available Force

Stephan Herrmann: Innovation through languages and tools? - Eclipse Day India 2015 # 3

Leverage

● Software re-shapes the world as we know it● Languages shape how we think about software● Tools shape how we work with languages

By empowering millions of software developers,we might indeed “move the world”?

By empowering millions of software developers,we might indeed “move the world”?


Agenda

● Java 8– supporting innovation in the Java world

● @NonNull– bringing quality assurance to the Java world

● Roles in Object Teams– extending the Object-Oriented paradigm

● Domain Specific Languages– abstractions for sustainable retail applications


JDT ready for Java 8

● Eclipse should „support“ Java 8:● Compiler should accept and compile Java 8

– analysis (resolve types, detect errors)

– produce class files

● JDT/UI should support working with Java 8– visualize

– modifyJava 8 ready

8

2013 / 2014


Java 8

● A big step in the evolution of Java!– λ

– default methods

– type annotations

– library enhancements

– …

8


Compiling λ

● „Just“ a bit new syntax

8

personList.setLabelProvider(new LabelProvider<Person>() {public String getLabel(Person p) {

return p.getFullName();}

});

personList.setLabelProvider(p -> p.getFullName());

personList.setLabelProvider(Person::getFullName);


λ Backstage

● Abbreviated code style relies on type inference● Challenges

– „guess“ all the types that have been omitted

– deterministic

– no 7½ million years Deep Thought pondering

8


Prior Art – Aggravated● Lambdas are typically arguments to

generic library functions– public static <T, K, U, M extends Map<K, U>>

Collector<T, ?, M> toMap(Function<? super T, ? extends K> keyMapper, Function<? super T, ? extends U> valueMapper, BinaryOperator<U> mergeFunction)

● Would you prefer to call:– Collectors.<Person,String,Integer,Map<String,Integer>>toMap(..)

● or:– Collectors.toMap(..)

● Similar for instantiation of a generic class (Java 7)– Collector<String,Integer> coll = new MyCollector<>();

● How does it work?

8


How it works

● Solving this little example– Map<String, Integer> test3(Stream<Person> persons) {

return persons.collect(Collectors.toMap(p -> p.getLastName(),p -> p.getAge(),(i1, i2) -> i1+i2));

}

● Produces these constraints:

8


How it works

● Solving this little example– Map<String, Integer> test3(Stream<Person> persons) {

return persons.collect(Collectors.toMap(p -> p.getLastName(),p -> p.getAge(),(i1, i2) -> i1+i2));

}

● Produces these constraints:

TypeBound K#3 :> java.lang.StringDependency K#3 = K#3TypeBound K#3 = java.lang.StringTypeBound K#3 <: java.lang.ObjectDependency R#0 = java.util.Map<K#3,U#4>Dependency R#0 = java.util.Map<java.lang.String,U#4>Dependency R#0 = java.util.Map<K#3,java.lang.Integer>TypeBound R#0 = java.util.Map<java.lang.String,java.lang.Integer>TypeBound R#0 <: java.util.Map<java.lang.String,java.lang.Integer>TypeBound R#0 <: java.lang.ObjectTypeBound T#2 :> PersonDependency T#2 = T#2TypeBound T#2 = PersonTypeBound T#2 <: java.lang.ObjectDependency Map<K#3,U#4>#6 = java.util.Map<K#3,U#4>Dependency Map<K#3,U#4>#6 = java.util.Map<java.lang.String,U#4>Dependency Map<K#3,U#4>#6 = java.util.Map<K#3,java.lang.Integer>TypeBound Map<K#3,U#4>#6 = java.util.Map<java.lang.String,java.lang.Integer>Dependency Map<K#3,U#4>#6 = R#0TypeBound Map<K#3,U#4>#6 <: java.lang.ObjectTypeBound Map<K#3,U#4>#6 <: java.util.Map<java.lang.String,java.lang.Integer>TypeBound A#1 = java.lang.ObjectTypeBound A#1 <: java.lang.ObjectTypeBound U#4 :> java.lang.IntegerTypeBound U#4 = java.lang.IntegerDependency U#4 = U#4TypeBound U#4 <: java.lang.ObjectTypeBound ?#5 = java.lang.ObjectDependency ?#5 = A#1TypeBound ?#5 <: java.lang.Object

TypeBound K#3 :> java.lang.StringDependency K#3 = K#3TypeBound K#3 = java.lang.StringTypeBound K#3 <: java.lang.ObjectDependency R#0 = java.util.Map<K#3,U#4>Dependency R#0 = java.util.Map<java.lang.String,U#4>Dependency R#0 = java.util.Map<K#3,java.lang.Integer>TypeBound R#0 = java.util.Map<java.lang.String,java.lang.Integer>TypeBound R#0 <: java.util.Map<java.lang.String,java.lang.Integer>TypeBound R#0 <: java.lang.ObjectTypeBound T#2 :> PersonDependency T#2 = T#2TypeBound T#2 = PersonTypeBound T#2 <: java.lang.ObjectDependency Map<K#3,U#4>#6 = java.util.Map<K#3,U#4>Dependency Map<K#3,U#4>#6 = java.util.Map<java.lang.String,U#4>Dependency Map<K#3,U#4>#6 = java.util.Map<K#3,java.lang.Integer>TypeBound Map<K#3,U#4>#6 = java.util.Map<java.lang.String,java.lang.Integer>Dependency Map<K#3,U#4>#6 = R#0TypeBound Map<K#3,U#4>#6 <: java.lang.ObjectTypeBound Map<K#3,U#4>#6 <: java.util.Map<java.lang.String,java.lang.Integer>TypeBound A#1 = java.lang.ObjectTypeBound A#1 <: java.lang.ObjectTypeBound U#4 :> java.lang.IntegerTypeBound U#4 = java.lang.IntegerDependency U#4 = U#4TypeBound U#4 <: java.lang.ObjectTypeBound ?#5 = java.lang.ObjectDependency ?#5 = A#1TypeBound ?#5 <: java.lang.Object

8


Chicken and Egg

● Type inference– Infers types of arguments

● based on a given method signature

● Overloading– Selects method

● e.g., based on types of arguments

<U> void m(Listener<U> l);<T> void m(Consumer<T> c);

…m(a -> print(a));


Genesis of a new Java Feature

spec

abstractly capturethe concepts

ecj

implement the spec,the full spec,and nothing but the spec

deviation

bug?

bug?

bug?

compare behavior

javac

8


Take-Away Java 8

● Second implementation improves quality● Java is a Monster

– E.g.: overloading conflicts with type inference ...

– „Orthogonality in Language Design – Why and how to fake it.“ [Herrmann 2003]

● ECJ is an enabler– used by implementations for „working with Java 8“

8


Contribution

● No own invention: Don't interpret!– No influence on the direction of change

– Some influence on the quality

● Interact with users / bug reporters● Be part of a big step for the Java world

– Acknowledged in the JLS 8 preface

8


Quality

● Quality of Java as a Language– governed by a specification (JLS)

● Quality of Java Programs?– can JDT help developers avoiding problems / bugs?

– which problems?


An Old Problem

● 1965– Tony Hoare introduced Null references in ALGOL W

– “simply because it was so easy to implement”

– “The Billion Dollar Mistake”

Photo

gra

ph

by

Ram

a, W

ikim

ed

ia C

om

mon

s, C

c-b

y-sa

-2.0

-fr


An Old Problem

● 1965– Tony Hoare introduced Null references in ALGOL W

– “simply because it was so easy to implement”

– “The Billion Dollar Mistake”

● Today– All Java software is threatened by risk of NPE

– Can we bid „bye-bye“ to NPE?

NPE

NPE


2005

1. Flow Analysis

● Flow Analysis in the Compiler– needed to check „definite assignment“

– was extended for null information in Eclipse 3.1

– gradually improved ever since

NPE


2005

1. Flow Analysis




NPE


1. Flow Analysis




+1– high precision

-1– some warnings can be perceived as „false positives“

– (slightly) incomplete analysis of loops

– no inter procedural analysis!

NPE


1. Flow Analysis




+1– high precision

-1– some warnings can be perceived as „false positives“

– (slightly) incomplete analysis of loops

– no inter procedural analysis!

NPE

NPE


2. Null Annotations

● Use @NonNull and @Nullable– declare contracts for methods (and fields)

● Use @NonNullByDefault– to alleviate the annotation burden

● (70% of „good API“ are @NonNull by intention)

2012

NPE


2. Null Annotations




2012

NPE


2. Null Annotations




+1– detect contract violations

● definition, usage and specialization

– feed context information into flow analysis

-1– does not cover: generics (type parameters, type variables)

2012

NPE


2. Null Annotations




+1– detect contract violations

● definition, usage and specialization

– feed context information into flow analysis

-1– does not cover: generics (type parameters, type variables)

2012

NPE

NPE


3. Null Type Annotations

● @NonNull and @Nullable „Everywhere“– JSR 308: Annotations on Java Types

● „Make nullness a part of the type system“

Two kinds of types● those that include null● those that don't

2014

NPE

+1

@Target(ElementType.PARAMETER)@interface NonNull5 {}

void java5(@NonNull5 String arg);

arg is qualified to be non-null

@Target(ElementType.TYPE_USE)@interface NonNull8 {}


String is qualified to be non-null



● @NonNull and @Nullable „Everywhere“– JSR 308: Annotations on Java Types

● „Make nullness a part of the type system“

Two kinds of types● those that include null● those that don't

2014

NPE

+1

@Target(ElementType.PARAMETER)@interface NonNull5 {}


arg is qualified to be non-null

@Target(ElementType.TYPE_USE)@interface NonNull8 {}


String is qualified to be non-null


NPE


● @NonNull and @Nullable „Everywhere“ 2014

NPE

+1


4. External Annotations

● Attach annotations to libraries 2015

NPE



● Attach annotations to libraries 2015

NPE



● The bad news:– No more excuse

– You've got some home work to do● Existing code:

– who is responsible for handling null?– recover design that probably has decayed?

● New code: – start by saying @NonNullByDefault– always be explicit about null (or avoid it)

NPE


Contribution

● Not the only tool for null analysis● But the most complete main-stream solution

– to the tiniest, most embarrassing problem in Java

NPE

NPE


Paradigm Shift?

● Paradigms connect ...– metaphors (intuition)

– technical solution (precise semantics)

● „Languages shape how we think about software“– null annotations

● not a paradigm

– functional programming● the shift happened before my time

● Object-oriented programming– a paradigm shift in the 1980s

– is this the end of evolution?


Reconsider Inheritance

+1– Derive a new concept from an existing one

– Describe only the differences

– May coincide with subtyping

-1– Doesn't scale

– Cannot model changes over time


Scale

Player Token

Move Rule validate(Move m)

Player Token

Move Rule validate(Move m)

BoardGame

Chess ≙ Chess.Move

≙ BoardGame.Move

Token

Move Rule


Introducing Object Teams

● team class Chess– package (namespace) & class (instances)

● team class Chess extends BoardGame– aka Family Polymorphism

● propagating specialization● typesafe covariance


Change

Personname

Employeesalary


Change

● Properties– Dynamism:

roles can come and go(same base object)

– Multiplicities:one base can play several roles(different/same role types)

playedBy Relationship

Personname

Employeesalary

«playedBy»

name=”joe”

joe: Person:Student

matr=0815

«base»

:Employeesalary=100

«base»

:Employeesalary=2000

«bas

e»

Employeesalary

Role Base

Personname


Introducing Object Teams

● team class Chess– package (namespace) & class (instances)

● team class Chess extends BoardGame– aka Family Polymorphism

● class Student playedBy Person– „inheritance“ among instances

● sharing of common properties● overriding

Arbitrary mix of language features?Synergy?

Arbitrary mix of language features?Synergy?


Roles & Teams

● Roles depend on context– contexts are reified as Teams

● Each team instance can be (de)activated– active team instances contribute to the system state

– dispatch considers system state

:PersonphoneNogetPhoneNo()

c :Company c :Company

namehire(Person p)namehire(Person p)

:EmployeeofficePhoneNogetPhoneNo ← getPhoneNo

«playedBy»

getPhoneNo()

Off On

if (c.isActive())

getPhoneNo()


Contribution

● Ingredients– years of research (since 1999)

– years of engineering

– new paradigm?● powerful new metaphors● precise underpinning

● Move the world?– big step

– few adopters


SIMPLY RETAIL


Goals

● Separation of concerns …– … can we identify the pure business logic?

– … how do you port your app to a new platform?

● Software product line– Many mechanisms to offer extensibility

– Shortage of extensibility on demand


Business Logic

● Domain Objects– Entities

● attributes ● references

● Flow / Processes– States / Steps

– Transitions● event● condition● action


Domain Specific Languages

● Textual modeling languages (9)– syntax

● grammar

– semantics● name resolution, validation

– IDE functions● navigation, outline, search, hover, quick fix, …

● Separate but connected– Inter-language integration

– Diagrams are derived

– Light-weight documentation● tightly integrated with Mylyn WikiText

Mix-n-match plug-in integration


Separate, but Connected


Safe for any Future

● Generate source code– for new target platforms

● Interpret models @ runtime– cool for monitoring, debugging …

● Migrate existing models– to new versions of the language

● Thanks to EMF underpinning!


Draw from Experience

● Full type checking– all types are nonnull by default

– optional types are marked, e.g., Item?

● Customization on demand– all models can be specialized

– propagating specialization

Player Token

Move Rule

Player Token

Move Rule

BoardGame

Chess

Token

Move Rule

NPE


Move the World?

spec

ecjjavac

It's the taking part that counts

Resolving the tiniest, most embarrassing problem in Java

Big progress, at a low multiplication factor.

Mix-n-match paradigm shift, for one mid-sized company.

NPE

eclipse day india 2015 - keynote - stephan herrmann

Technology