Neal Gafter Java Evolution

33 %
67 %
Information about Neal Gafter Java Evolution

Published on March 16, 2008

Author: deimos

Source: slideshare.net

Evolving the Java Programming Language Neal Gafter

Overview The Challenge of Evolving a Language Design Principles Design Goals JDK7 and JDK8

Challenge: Evolving a Language “What is it like trying to extend a mature lan- guage?” -Brian Goetz

Challenge: Evolving a Language “What is it like trying to extend a mature lan- guage?” ma-ture: adjective 1. having completed natural growth and de- velopment. 2. completed, perfected, or elaborated in full. 3. (of an industry, technology, market, etc.) no longer developing or expanding.

Challenge: Evolving a Language Q: What is it like trying to extend a mature language? A: It is impossible, by definition.

Challenge: Evolving a Language Q: What is it like trying to extend a widely de- ployed language? A: Language change is influenced by existing code and APIs.

Existing APIs affect change Support retrofitting existing APIs: With compatible behavior

Existing APIs affect change Support retrofitting existing APIs: With compatible behavior Consistent with existing design Don't expose, create design flaws

Existing APIs affect change Some case studies: Generics (vs erasure) Wildcards (vs declaration-site variance) Autoboxing, unboxing (vs wrappers) Varargs (vs overloading) For-each (vs Iterator)

Generics (vs erasure) Adding reified generics is compatible May not allow retrofitting existing code Collection WeakReference

Wildcards (vs declaration-site variance) There is a simpler alternative to wildcards: declaration-site variance 'wildcards' appear on type definitions Use sites much simpler Can retrofit most APIs but not Collection

Autoboxing, unboxing Type systems form a lattice Object / Number Runnable | / Integer / / null

Autoboxing, unboxing Adding conversions can break the lattice long <----------> Long | | | | int <----------> Integer Existing boxed types don't have this relation.

Autoboxing, unboxing Solutions Introduce new boxing interfaces; or Patchwork specification

for-each (vs iterator) Iterator has a vestigal remove method. Introduce java.lang.Iterator without it? Cannot retrofit Collection without requiring recompile (existing implementations don't implement iterator() that returns the new type)

Design Principles

Design Principles Encourage desirable practices (that might not otherwise be followed) my making them easy synchronized Annotations isolate configuration data Generics for typesafe APIs

Design Principles Encourage desirable practices Isolate language from specific APIs

Design Principles Encourage desirable practices Isolate language from specific APIs Prefer reading over writing clarity over conciseness

Design Principles Encourage desirable practices Isolate language from specific APIs Prefer reading over writing Prefer static typing

Design Principles Encourage desirable practices Isolate language from specific APIs Prefer reading over writing Prefer static typing Remain backward compatible

Short-term design Goals Regularize Existing Language Improve diagnostics vs generics Fix type inference String switch Limited operator overloading Improved catch clauses Modularity

Improve Diagnostics vs Generics interface Box<T> { T get(); void put(T t); } class Tmp { static void test(Box<? extends Number> box) { box.put(box.get()); } } Error: put(capture#417 of ? extends java.lang.Number) in Box<capture#417 of ? extends java.lang.Number> cannot be applied to (java.lang.Number) box.put(box.get()); ^

Improve Diagnostics vs Generics interface Box<T> { T get(); void put(T t); } class Tmp { static void test(Box<? extends Number> box) { box.put(box.get()); } } Error: cannot call put(T) as a member of in Box<? ex- tends java.lang.Number> box.put(box.get()); ^

Fix Type Inference: constructors Today: Map<String, List<String>> anagrams = new HashMap<String, List<String>>();

Fix Type Inference: constructors Proposed: Map<String, List<String>> anagrams = new HashMap<>();

Fix Type Inference: arguments Today: public <E> Set<E> emptySet() { … } void timeWaitsFor(Set<Man> people) { … } // * Won't compile! timeWaitsFor(Collections.emptySet());

Fix Type Inference: arguments Today: public <E> Set<E> emptySet() { … } void timeWaitsFor(Set<Man> people) { … } // OK timeWaitsFor(Collections.<Man>emptySet());

Fix Type Inference: arguments Proposed: public <E> Set<E> emptySet() { … } void timeWaitsFor(Set<Man> people) { … } // OK timeWaitsFor(Collections.emptySet());

String Switch Today static boolean booleanFromString(String s) { if (s.equals(quot;truequot;)) { return true; } else if (s.equals(quot;falsequot;)) { return false; } else { throw new IllegalArgumentException(s); } }

String Switch Proposed static boolean booleanFromString(String s) { switch(s) { case quot;truequot;: return true; case quot;falsequot;: return false; default: throw new IllegalArgumentException(s); } }

Limited Operator Overloading Today enum Size { SMALL, MEDIUM, LARGE } if (mySize.compareTo(yourSize) >= 0) System.out.println(“You can wear my pants.”);

Limited Operator Overloading Proposed enum Size { SMALL, MEDIUM, LARGE } if (mySize > yourSize) System.out.println(“You can wear my pants.”);

Improved Catch Clauses: multi Today: try { return klass.newInstance(); } catch (InstantiationException e) { throw new AssertionError(e); } catch (IllegalAccessException e) { throw new AssertionError(e); }

Improved Catch Clauses: multi Proposed: try { return klass.newInstance(); } catch (InstantiationException | IllegalAccessException e) { throw new AssertionError(e); }

Improved Catch Clauses: rethrow Today: try { doable.doit(); // Throws several types } catch (Throwable ex) { logger.log(ex); throw ex; // Error: Throwable not declared }

Improved Catch Clauses: rethrow Proposed: try { doable.doit(); // Throws several types } catch (final Throwable ex) { logger.log(ex); throw ex; // OK: Throws the same several types }

Others? Properties? Serialization annotations?

Long-term goals Regularize Existing Language Reification Further Generics simplification Concurrency support Immutable data Control Abstraction Closures Actors, etc.

JDK7 jsrs 277 + 294 (modularity) Maintenance review of jsr14 “Small” language issues Possibly jsr308 (limited by time, resources)

JDK8 Reification Control Abstraction Further out: Immutable data, pattern match- ing, further operator overloading?

Q&A

Add a comment

Related presentations

Related pages

Neal Gafter's Home Page - Gafter Family Web Host

Neal M Gafter, Ph.D. I currently ... I previously worked on Google Calendar and the Java Programming Language. ... homepg@neal.gafter.com
Read more

Neal Gafter's blog

Neal Gafter Neal Gafter works for Microsoft on the evolution of the .NET platform languages. He also has been known to Kibbitz on the evolution of the Java ...
Read more

Java Library Evolution Puzzlers | JavaWorld

Java gurus Joshua Bloch and Neal Gafter took this tactic to heart when they ... The Java Library Evolution Puzzlers focus on source and binary code ...
Read more

Evolving the Java Language - InfoQ: Software Development ...

Bio. Neal Gafter is a software engineer and Java evangelist at Google. Previously, at Sun Microsystems, he designed and implemented the Java ...
Read more

e g a u g n a L g er t n af i l o h m Neal G E a r o r P a J

E x i s t i n g A P I s a f f e c t c h a n g e S om e c a s e s tudi es: G ene r i c s (v s er as ur e) W i l dc ar d s (v s dec l ar ati on-s i te v a r ...
Read more

Neal Gafter (@gafter) | Twitter

157 tweets • 2 photos/videos • 4,057 followers. Check out the latest Tweets from Neal Gafter (@gafter)
Read more

Resume for Neal M Gafter - Gafter Family Web Host

Resume for Neal M Gafter, Ph.D. 13608 SE 7th St, Bellevue, WA 98005 (425) 835 - 3734 ... and goals for future Java language evolution, ...
Read more

A Discussion With Neal Gafter on the Future of Java

Microsoft's Neal Gafter, who was primary designer and implementer of the Java SE 4 and 5 language enhancements and now works for Microsoft on ...
Read more

Neal Gafter's blog: Reified Generics for Java

Neal Gafter works for Microsoft on the evolution of the .NET platform languages. He also has been known to Kibbitz on the evolution of the Java ...
Read more