Your SlideShare is downloading. ×
0
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 c...
Challenge: Evolving a Language


Q: What is it like trying to extend a mature
  language?


A: It is impossible, by defini...
Challenge: Evolving a Language


Q: What is it like trying to extend a widely de-
  ployed language?

A: Language change i...
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 ...
Existing APIs affect change


Some case studies:

  Generics (vs erasure)
  Wildcards (vs declaration-site variance)
  Aut...
Generics (vs erasure)




Adding reified generics is compatible
May not allow retrofitting existing code
 Collection
 Weak...
Wildcards (vs declaration-site
           variance)

There is a simpler alternative to wildcards:
  declaration-site varia...
Autoboxing, unboxing


Type systems form a lattice

       Object
     /        
Number Runnable
   |           /
Integer ...
Autoboxing, unboxing


Adding conversions can break the lattice

long <----------> Long
  |                 |
  |         ...
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 ...
Design Principles
Design Principles


Encourage desirable practices (that might
not otherwise be followed) my making them
easy
 synchronized...
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...
Design Principles


Encourage desirable practices
Isolate language from specific APIs
Prefer reading over writing
Prefer s...
Design Principles


Encourage desirable practices
Isolate language from specific APIs
Prefer reading over writing
Prefer s...
Short-term design Goals


Regularize Existing Language
 Improve diagnostics vs generics
 Fix type inference
 String switch...
Improve Diagnostics vs Generics

interface Box<T> {
    T get();
    void put(T t);
}
class Tmp {
    static void test(Box...
Improve Diagnostics vs Generics

interface Box<T> {
    T get();
    void put(T t);
}
class Tmp {
    static void test(Box...
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) { … }

// ...
Fix Type Inference: arguments


  Today:

public <E> Set<E> emptySet() { … }
void timeWaitsFor(Set<Man> people) { … }

// ...
Fix Type Inference: arguments


  Proposed:

public <E> Set<E> emptySet() { … }
void timeWaitsFor(Set<Man> people) { … }

...
String Switch


   Today

static boolean booleanFromString(String s) {
    if (s.equals(quot;truequot;)) {
        return ...
String Switch


   Proposed

static boolean booleanFromString(String s) {
    switch(s) {
      case quot;truequot;:
     ...
Limited Operator Overloading


   Today

enum Size { SMALL, MEDIUM, LARGE }

if (mySize.compareTo(yourSize) >= 0)
    Syst...
Limited Operator Overloading


   Proposed


enum Size { SMALL, MEDIUM, LARGE }

if (mySize > yourSize)
    System.out.pri...
Improved Catch Clauses: multi


   Today:

try {
    return klass.newInstance();
} catch (InstantiationException e) {
    ...
Improved Catch Clauses: multi


   Proposed:

try {
    return klass.newInstance();
} catch (InstantiationException | Ille...
Improved Catch Clauses: rethrow


   Today:

try {
  doable.doit(); // Throws several types
} catch (Throwable ex) {
  log...
Improved Catch Clauses: rethrow


   Proposed:

try {
  doable.doit(); // Throws several types
} catch (final Throwable ex...
Others?


Properties?
Serialization annotations?
Long-term goals


Regularize Existing Language
 Reification
 Further Generics simplification

Concurrency support
 Immutab...
JDK7


jsrs 277 + 294 (modularity)
Maintenance review of jsr14
“Small” language issues
Possibly jsr308

(limited by time, ...
JDK8


  Reification
  Control Abstraction



Further out: Immutable data, pattern match-
 ing, further operator overloading?
Q&A
Upcoming SlideShare
Loading in...5
×

Neal Gafter Java Evolution

1,584

Published on

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,584
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Neal Gafter Java Evolution"

  1. 1. Evolving the Java Programming Language Neal Gafter
  2. 2. Overview The Challenge of Evolving a Language Design Principles Design Goals JDK7 and JDK8
  3. 3. Challenge: Evolving a Language “What is it like trying to extend a mature lan- guage?” -Brian Goetz
  4. 4. 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.
  5. 5. Challenge: Evolving a Language Q: What is it like trying to extend a mature language? A: It is impossible, by definition.
  6. 6. 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.
  7. 7. Existing APIs affect change Support retrofitting existing APIs: With compatible behavior
  8. 8. Existing APIs affect change Support retrofitting existing APIs: With compatible behavior Consistent with existing design Don't expose, create design flaws
  9. 9. 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)
  10. 10. Generics (vs erasure) Adding reified generics is compatible May not allow retrofitting existing code Collection WeakReference
  11. 11. 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
  12. 12. Autoboxing, unboxing Type systems form a lattice Object / Number Runnable | / Integer / / null
  13. 13. Autoboxing, unboxing Adding conversions can break the lattice long <----------> Long | | | | int <----------> Integer Existing boxed types don't have this relation.
  14. 14. Autoboxing, unboxing Solutions Introduce new boxing interfaces; or Patchwork specification
  15. 15. 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)
  16. 16. Design Principles
  17. 17. Design Principles Encourage desirable practices (that might not otherwise be followed) my making them easy synchronized Annotations isolate configuration data Generics for typesafe APIs
  18. 18. Design Principles Encourage desirable practices Isolate language from specific APIs
  19. 19. Design Principles Encourage desirable practices Isolate language from specific APIs Prefer reading over writing clarity over conciseness
  20. 20. Design Principles Encourage desirable practices Isolate language from specific APIs Prefer reading over writing Prefer static typing
  21. 21. Design Principles Encourage desirable practices Isolate language from specific APIs Prefer reading over writing Prefer static typing Remain backward compatible
  22. 22. Short-term design Goals Regularize Existing Language Improve diagnostics vs generics Fix type inference String switch Limited operator overloading Improved catch clauses Modularity
  23. 23. 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()); ^
  24. 24. 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()); ^
  25. 25. Fix Type Inference: constructors Today: Map<String, List<String>> anagrams = new HashMap<String, List<String>>();
  26. 26. Fix Type Inference: constructors Proposed: Map<String, List<String>> anagrams = new HashMap<>();
  27. 27. Fix Type Inference: arguments Today: public <E> Set<E> emptySet() { … } void timeWaitsFor(Set<Man> people) { … } // * Won't compile! timeWaitsFor(Collections.emptySet());
  28. 28. Fix Type Inference: arguments Today: public <E> Set<E> emptySet() { … } void timeWaitsFor(Set<Man> people) { … } // OK timeWaitsFor(Collections.<Man>emptySet());
  29. 29. Fix Type Inference: arguments Proposed: public <E> Set<E> emptySet() { … } void timeWaitsFor(Set<Man> people) { … } // OK timeWaitsFor(Collections.emptySet());
  30. 30. 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); } }
  31. 31. 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); } }
  32. 32. Limited Operator Overloading Today enum Size { SMALL, MEDIUM, LARGE } if (mySize.compareTo(yourSize) >= 0) System.out.println(“You can wear my pants.”);
  33. 33. Limited Operator Overloading Proposed enum Size { SMALL, MEDIUM, LARGE } if (mySize > yourSize) System.out.println(“You can wear my pants.”);
  34. 34. Improved Catch Clauses: multi Today: try { return klass.newInstance(); } catch (InstantiationException e) { throw new AssertionError(e); } catch (IllegalAccessException e) { throw new AssertionError(e); }
  35. 35. Improved Catch Clauses: multi Proposed: try { return klass.newInstance(); } catch (InstantiationException | IllegalAccessException e) { throw new AssertionError(e); }
  36. 36. Improved Catch Clauses: rethrow Today: try { doable.doit(); // Throws several types } catch (Throwable ex) { logger.log(ex); throw ex; // Error: Throwable not declared }
  37. 37. 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 }
  38. 38. Others? Properties? Serialization annotations?
  39. 39. Long-term goals Regularize Existing Language Reification Further Generics simplification Concurrency support Immutable data Control Abstraction Closures Actors, etc.
  40. 40. JDK7 jsrs 277 + 294 (modularity) Maintenance review of jsr14 “Small” language issues Possibly jsr308 (limited by time, resources)
  41. 41. JDK8 Reification Control Abstraction Further out: Immutable data, pattern match- ing, further operator overloading?
  42. 42. Q&A
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×