Eclipse Day India 2015 - Keynote - Stephan Herrmann

8
Stephan Herrmann
Java 8 ready
NPE
Languages
Tools
Innovation

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
– modify
Java 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.String
Dependency K#3 = K#3
TypeBound K#3 = java.lang.String
TypeBound K#3 <: java.lang.Object
Dependency 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.Object
TypeBound T#2 :> Person
Dependency T#2 = T#2
TypeBound T#2 = Person
TypeBound T#2 <: java.lang.Object
Dependency 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#0
TypeBound Map<K#3,U#4>#6 <: java.lang.Object
TypeBound Map<K#3,U#4>#6 <: java.util.Map<java.lang.String,java.lang.Integer>
TypeBound A#1 = java.lang.Object
TypeBound A#1 <: java.lang.Object
TypeBound U#4 :> java.lang.Integer
TypeBound U#4 = java.lang.Integer
Dependency U#4 = U#4
TypeBound U#4 <: java.lang.Object
TypeBound ?#5 = java.lang.Object
Dependency ?#5 = A#1
TypeBound ?#5 <: java.lang.Object
TypeBound K#3 :> java.lang.String
Dependency K#3 = K#3
TypeBound K#3 = java.lang.String
TypeBound K#3 <: java.lang.Object
Dependency 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.Object
TypeBound T#2 :> Person
Dependency T#2 = T#2
TypeBound T#2 = Person
TypeBound T#2 <: java.lang.Object
Dependency 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#0
TypeBound Map<K#3,U#4>#6 <: java.lang.Object
TypeBound Map<K#3,U#4>#6 <: java.util.Map<java.lang.String,java.lang.Integer>
TypeBound A#1 = java.lang.Object
TypeBound A#1 <: java.lang.Object
TypeBound U#4 :> java.lang.Integer
TypeBound U#4 = java.lang.Integer
Dependency U#4 = U#4
TypeBound U#4 <: java.lang.Object
TypeBound ?#5 = java.lang.Object
Dependency ?#5 = A#1
TypeBound ?#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 capture
the 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”
PhotographbyRama,WikimediaCommons,Cc-by-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)
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)
arg is qualified to be non-null
@Target(ElementType.TYPE_USE)
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
Person
name
Employee
salary

Change
●
Properties
– Dynamism:
roles can come and go
(same base object)
– Multiplicities:
one base can play several roles
(different/same role types)
playedBy Relationship
Person
name
Employee
salary
«playedBy»
name=”joe”
joe: Person
:Student
matr=0815
«base»
:Employee
salary=100
«base»
:Employee
salary=2000
«base»
Employee
salary
Role Base
Person
name

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
:Person
phoneNo
getPhoneNo()
c :Companyc :Company
name
hire(Person p)
name
hire(Person p)
:Employee
officePhoneNo
getPhoneNo ← 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

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (11)

Similar to Eclipse Day India 2015 - Keynote - Stephan Herrmann

Similar to Eclipse Day India 2015 - Keynote - Stephan Herrmann (20)

More from Eclipse Day India

More from Eclipse Day India (20)

Recently uploaded

Recently uploaded (20)

Eclipse Day India 2015 - Keynote - Stephan Herrmann