Your SlideShare is downloading. ×
0
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
Neal Gafter Java Evolution
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,565

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,565
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
17
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

×