Your SlideShare is downloading. ×
Neal Gafter Java Evolution
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Neal Gafter Java Evolution

1,545
views

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,545
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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