JDT embraces lambda expressions

8
8
Srikanth Sankaran
IBM India
Stephan Herrmann
GK Software
BETA_JAVA8

8 Eclipse and Java™ 8
● Java 8 features available in early access builds:
– JSR308 - Type Annotations.
– JEP120 - Repeating Annotations.
– JEP118 - Method Parameter Reflection.
– JSR269 - Pluggable Annotation Processor API &
javax.lang.model API enhancements for Java 8.
– Support for “code carrying” interface methods.
● Partial support for
– Lambda Expressions & Method/Constructor references
– Overload resolution & Type inference changes still evolving
● had been blocked by incomplete specification until late September
Srikanth Sankaran, Stephan Herrmann: Eclipse and Java 8 - EclipseCon Europe 2013 # 3

8 Eclipse and Java™ 8
● IDE features available in early access builds:
– Type annotations based static null analysis
● substantially complete, open issues exist
– Code completion, code selection/navigation, search engine
● for completed features
– Code formatter and code “reconciler”
– IDE enablement support:
● AST API's, programmatic AST rewriting API support etc
● Full fledged IDE support work in high gear:
– Early access build refreshes very soon.
● JDT team:
– 12 committers + 1 contributor + 1 GSOC student
+ 2 past committers on consulting role.
Java8
Java8

8 New Kinds of Methods
● defender methods
● virtual extension methods
● static interface methods
● default methods

8 New Kinds of Methods
Those are only 2 kinds :)
● Code carrying methods in interfaces:
– static methods
● non-OO programming even in interfaces
– default methods
previous names:
● defender methods
● virtual extension methods

8 Default Methods - Intention
● Intention
– support evolution of interfaces in libraries:
add methods to an interface w/o breaking implementors
– still legal:

8
Default Methods - Consequences
● Consequences
– Java 8 has multiple inheritance, sort-of
– but little help for corner cases
Root
m()
Both
Left
D m()
Right
D m()
resolve:

8
Default Methods - Consequences
● Consequences
– Java 8 has multiple inheritance, sort-of
– but little help for corner cases
Both
Left
D m()
Right
m()
The default method m() inherited from Left conflicts
with another method inherited from Right
Advice: Don't!

8 Default Methods - Compatibility
● Designed for compatibility during evolution
● For the price of compatibility
– Recipe for disaster:
● implement java.util.List → compile against JRE 7 → OK
● upgrade to JRE 8 but compile as 1.7
The type MyList<E> must implement the inherited abstract method Collection<E>.stream()
– Undefined compiler behavior
● 1.7 compiler cannot handle default methods (from .class)
● ecj and javac differ – no plans to assimilate
● depending on compiler implementation details, not specification

8 Default Methods - Compatibility
● Designed for compatibility during evolution
● For the price of compatibility
– Recipe for disaster:
● implement java.util.List → compile against JRE 7 → OK
● upgrade to JRE 8 but compile as 1.7
The type MyList<E> must implement the inherited abstract method Collection<E>.stream()
– Undefined compiler behavior
● 1.7 compiler cannot handle default methods (from .class)
● ecj and javac differ – no plans to assimilate
● depending on compiler implementation details, not specification
Advice: Don't mix -source 1.7 & JRE8!

8
λ
(JSR 335)

8
Introducing Lambda Expressions
● Lambda Expressions, Closures, Anonymous Methods
– what is in a name ?
● A function + “captured state” (may have non-locals)
– accessible even when outside of defining lexical scope
● Theoretical framework dates back several decades:
– Lambda (1930's – Church, Lisp – 1958)
– Closure (1960's - Landin, Scheme - 1975)
– Common idiomatic device in functional programming.
● Paradigm of passing a "code block as data"

8
Java 7 Style of “Code as Data”
● Via anonymous classes

8
Java 7 Style of “Code as Data”
● Via anonymous classes
So if lambda expressions
help model "code as data"
are they just
old wine in a new bottle?
No!

8 Lambda Expressions
● Eliminate thorny issues with anonymous classes
– Verbose/clunky Syntax
– Scoping
● anonymous classes introduce their own scopes
● interplay between names in enclosing scope ↔ inherited names
– Capture
● can only capture explicitly final outer locals
● necessarily capture enclosing class instance (memory leaks)
● Lambdas
– address the above, designed to be flexible & optimizable
– much more pleasing & efficient to program with call backs
– With default methods, enabled Collections overhaul.

8 λ Syntax and Examples

8 Target typing
● Lambda expression is basically
– an anonymous method
– with possibly "captured" enclosing state
● At the grammar level, lambdas are expressions (duh!)
– Can occur anywhere an expression can
– Introduces severe complications in parsing.
● Legally however,
– Lambda needs a context that defines a "target type"
– Everywhere else will have to rejected by the compiler.
– Assignment, initialization, casts, method/ctor invocation,
lambda expression body, conditional expressions and return
statements are contexts that provide target type.

8 Target Typing Examples

8 Functional Interfaces
● The target type must be a functional interface
● Functional interface
– Declares a single abstract method
– Some methods don't count:
● Default & static methods - they are not abstract
● May freely redeclare java.lang.Object's methods
– May be tagged with @FunctionalInterface to express intent
● So the lambda object implements the functional interface
● Another way of constructing objects
– apart from the SE7 ways
(new, reflection, serialization, clone ...)

8 Lambda Syntax examples
– Parameter types
● explicit, or
● inferred from target functional interface methods
– Body
● expression, or
● block.
– ()
● can be omitted if a singleton parameter

8 Lambda Syntax examples
– Parameter types
● explicit, or
Trade-off between
conciseness of expression
● inferred from target functional interface methods
– Body
● expression, or
● block.
– ()
● can be omitted if a singleton parameter
vs
clarity of code
-
in the hands of the programmer

8 Variable capture
● A lambda can refer to enclosing method's locals
– Captured state constitutes the "referencing environment"
– Compiler can infer finality
– Captured state is not mutable.
● Properly: capture of "immutable outer local's value"
– Mutability of outer locals implies race conditions
– Mutability would necessarily impose serial execution.
– Lambda creation & invocation could be far apart.
● may be in different threads, may be after enclosing method return
● This "constraint" actually enables parallelism.
● Enclosing class instance captured only if referred to.

8 Method References
● Similar to lambda expressions
– Require a target type that must be a functional interface
– Serve as instances of the functional interface
– Rather than providing a method body,
they refer to an existing method
– Several variants offered.

8
Lambda code generation
● Not lowered into anonymous classes - i.e not just syntactic sugar
● What does the following print ?
● Lambda object creation under the hood:
– Handled by "Lambda metafactory" API in JRE.
– Compilers generates suitable calls to the metafactory.
– Enables various optimizations.

8 Putting it all together
● Here is a nice example from SOTL[*]
[*] http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-final.html

JDT features in the works 8

8
@
(JSR 308)

8 Annotations in more Places
● Java 5: annotate declarations
– ElementType: packages, classes, fields, methods, locals …
● Java 8: annotate types
– ElementType.TYPE_USE
– ElementType.TYPE_PARAMETER
So what?

8 Why Care About Types?
● Type = Constraints on values
To detect anomalies
– missing capability
– incompatible assignment
– undeclared capability
● Constraint checking avoids errors
– No Such Method / Field
● Basic statically typed OO
– ClassCastException
● Generics
– ??ExcepMtioyn pet example: NullPointerException

Let the Type System 8
Handle Nullity
● Ideally: Java would force explicit choice
– String definitely a String, never null
– String? either a String or null
– Type system ensures: no dereferencing of null
● Nullity as a language feature?
– Heavy weight, incompatible change
– Language change for each new constraint?

8 Pluggable Type System
● Make it easier to add new constraints
– Only one new syntax for all kinds of constraints
● Make it easier to add new type checkers
– Checker Framework (Michael Ernst – U of Washington)
● Examples
– @NonNull
– @Interned equals(== , equals)
– @Immutable value cannot change (Java 5 ?)
– @ReadOnly value cannot change via this reference
– @UI code requires to run on the SWT UI thread

Can't Java 5 Do All This?
@Target(ElementType.PARAMETER)
@interface NonNull5 {}
void java5(@NonNull5 String arg);
arg is qualified to be non-null
@Target(ElementType.TYPE_USE)
void java8(@NonNull8 String arg);
String is qualified to be non-null
String is qualified to be non-null
@Target(ElementType.METHOD)
@NonNull5 String java5();
java5 is qualified to be non-null
8
@Target(ElementType.TYPE_USE)
@NonNull8 String java8();
● We've been lying about the method result
– but we can't lie about everything, e.g.:
void printFirstDog(@NonNull List<Dog> dogs) {
dogs.get(0).bark();
}
NPE?

l1 cannot contain
null elements
Null type mismatch: required '@NonNull String'
but the provided value is null
8
void bad(List<String> unknown, List<@Nullable String> withNulls) {
@NonNull List<@NonNull String> l1 = new ArrayList<>();
l1.add(null);
String first = l1.get(0);
if (first == null) return;
l1 = unknown;
l1 = withNulls;
String canNull = withNulls.get(0);
System.out.println(canNull.toUpperCase());
}
@NonNull List<@Nullable String> l2 = new ArrayList<>();
l2 can contain
null elements
Annotated Generics
void good() {
l1.add("Hello");
for (String elem : l1)
System.out.println(elem.toUpperCase());
l2.add(null);
for (String unknown : l2)
if (unknown != null)
System.out.println(unknown.toUpperCase());
}
Null type mismatch: required '@NonNull String'
but the provided value is null

l1 cannot contain
null elements
Null comparison always yields false:
The variable first cannot be null at this location
8
l1.add(null);
l1 = unknown;
l1 = withNulls;
}
l2 can contain
null elements
Annotated Generics
void good() {
l1.add("Hello");
l2.add(null);
}
Null comparison always yields false:
The variable first cannot be null at this location

l1 cannot contain
null elements
Null type safety (type annotations): The expression of type 'List<String>'
needs unchecked conversion to conform to '@NonNull List<@NonNull String>'
8
l1.add(null);
l1 = unknown;
l1 = withNulls;
}
l2 can contain
null elements
Annotated Generics
void good() {
l1.add("Hello");
l2.add(null);
}
Null type safety (type annotations): The expression of type 'List<String>'
needs unchecked conversion to conform to '@NonNull List<@NonNull String>'

l1 cannot contain
null elements
Null type mismatch (type annotations):
required '@NonNull List<@NonNull String>'
but this expression has type 'List<@Nullable String>'
8
l1.add(null);
l1 = unknown;
l1 = withNulls;
}
l2 can contain
null elements
Annotated Generics
void good() {
l1.add("Hello");
l2.add(null);
}
Null type mismatch (type annotations):
required '@NonNull List<@NonNull String>'
but this expression has type 'List<@Nullable String>'

l1 cannot contain
null elements
Potential null pointer access:
The variable canNull may be null at this location
8
l1.add(null);
l1 = unknown;
l1 = withNulls;
}
l2 can contain
null elements
Annotated Generics
void good() {
l1.add("Hello");
l2.add(null);
}
Potential null pointer access:
The variable canNull may be null at this location

8 Framework Development (1)
● So you want to be smart:
public interface ILib<E> {
@NonNull E work(@Nullable E e);
}
● But will clients like it?
public class LibImpl implements ILib<String> {
@Override
public @Nullable String work(@NonNull String e) { return null; }
● If thou usest annotations know thy co/contravariance
– @Nullable parameter is irreversible
– Design bug in guava's Predicate / Function
}

8 Framework Development (2)
● Avoid overspecification, make interfaces null-generic:
public interface Function<I,O> {
O apply(I in);
}
● Let clients decide
class ToString implements Function<@NonNull Object, @Nullable String> {
@Override
public @Nullable String apply(@NonNull Object o) { return o.toString(); }
No NPE!
}
● Putting the pieces together
<@NonNull I, @Nullable O> Collection<O> map1(Collection<I> in, Function<I, O> f) { … }
<@Nullable I, @NonNull O> Collection<O> map2(Collection<I> in, Function<I, O> f) { … }
...
List<@NonNull Object> in = new ArrayList<>();
Collection<@Nullable String> out = map1(in, new ToString());

8 Caveat: Arrays
void test (@NonNull String [] stringsOrNulls) {
System.out.println(stringsOrNulls[0]);
● Semantics are changing from Java 7 to Java 8
}
array of nonnull elements the array can still be null Þ NPE
void test (String @NonNull [] stringsOrNulls) {
System.out.println(stringsOrNulls[0]);
}
nonnull array NPE- safe (but may print “null”)

8
Status: Annotated Type Analysis
● Implemented EA: @NonNull, @Nullable
– Much analysis already performed
● known & unknown bugs
– Editor may show more bogus errors
● Project > Clean and Problems View
● Planned: @Uninterned
● Proposed: @UiEffect, @Ui …
– by [Colin S. Gordon, Werner Dietl, Michael D. Ernst, and Dan Grossman]
– SWT: bye, bye, “Invalid thread access”

8 Status: Type Annotations
● Supported by
– Compiler
– DOM AST
– APT
● Work in progress
– respect during
CCttrrll CCttrrll 1 CAtlrtl T
● Not yet supported by
– Java model

8 TypeBinding Backstage Story
aka “Symbol”
● Type bindings are “interned”
– OK to use ==
● Broken by encoding type annotations in type bindings
● Solution
– Find/replace == comparisons for T <: TypeBinding
– Tweak our compiler to do this
– Plan: publish the tweak, controlled by @Uninterned

8
Dramatis personæ
● Jay Arthanareeswaran
● Anirban Chakarborty
● Manoj Palat
● Shankha Banerjee
● Manju Mathew
● Noopur Gupta
● Deepak Azad
● Srikanth Sankaran
● Olivier Thomann
● Andy Clement
● Michael Rennie
● Jesper S. Møller
● Walter Harley
● Stephan Herrmann
● Dani Megert
● Markus Keller
● Early Access:
– http://wiki.eclipse.org/JDT_Core/Java8
● We invite you to test - defect reports welcome !

JDT embraces lambda expressions

More Related Content

What's hot (20)

Similar to JDT embraces lambda expressions (20)

More from Eclipse Day India (20)

Recently uploaded (20)

JDT embraces lambda expressions