Eclipse Day India 2015 - Keynote - Stephan Herrmann

Stephan Herrmann

Java 8 ready

Languages

ova tio

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”?

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

2013 / 2014

Java 8

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

– default methods

– type annotations

– library enhancements

– …

Compiling λ

● „Just“ a bit new syntax

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

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?

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:

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

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

abstractly capturethe concepts

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

deviation

compare behavior

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“

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

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?

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”

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?

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

1. Flow Analysis

+1– high precision

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

– (slightly) incomplete analysis of loops

– no inter procedural analysis!

1. Flow Analysis

+1– high precision

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

– (slightly) incomplete analysis of loops

– no inter procedural analysis!

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)

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)

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)

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

@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

@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

● @NonNull and @Nullable „Everywhere“ 2014

4. External Annotations

● Attach annotations to libraries 2015

● 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)

Contribution

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

– to the tiniest, most embarrassing problem in Java

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

Player Token

Move Rule validate(Move m)

Player Token

Move Rule validate(Move m)

BoardGame

Chess ≙ Chess.Move

≙ BoardGame.Move

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

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?

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

● 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

Move Rule

Move the World?

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.

Eclipse Day India 2015 - Keynote - Stephan Herrmann

Technology

JOÃO HERRMANN NETO

Tics Modelling Damy Herrmann

IGNÁT HERRMANN - Rodon

Capillary forces in assemblies of three spherical particles fileRoman Mani (3) Hans Herrmann (3) Ciro Semprebon (1) Stephan Herminghaus (1) Capillary forces in assemblies of three

CASE STUDY - Herrmann

Srikanth Sankaran - EclipseCon France2018 · PDF fileEclipseCon NA 2014 | JDT Embraces Lambda Expressions 1 Srikanth Sankaran IBM India Stephan Herrmann GK Software Noopur Gupta IBM

Herrmann 1989

Angela Herrmann

Herrmann STAT3 2008

MENAKER HERRMANN - uscourts.gov

Forschungsberichte der Fakultät IV – Elektrotechnik und ... · ObjectTeams/Java Language Definition — version 1.0 Bericht-Nr. 2007/03 Stephan Herrmann stephan@cs.tu-berlin.de

Bernard Herrmann - The Egyptian

Jürgen Herrmann, MdB Deutschland (k)ein Sozialstaat !? Vortrag Jürgen Herrmann, MdB

Hans Herrmann

Hans C. Herrmann

Ringvorlesung 24.6.2004Stefan Jähnichen, Stephan Herrmann, Katharina Mehner Aspekte in der Softwareentwicklung Stefan Jähnichen, Stephan Herrmann, Katharina

Herrmann Ultrasonics_2007_01

Ulrike Herrmann

Vertriebskonzeptionelle Ansätze im Bereich der finanziellen Altersvorsorge Von Stephan Niemand und René Erik Herrmann Referat: Vertriebskonzeptionelle

Bernard Herrmann: An Annotated Index of Materialsfolk.uib.no/smkgg/midi/soundtrackweb/herrmann/articles/index_of...Bernard Herrmann: An Annotated Index of Materials Introduction This