The Heads and Tails of Project Coin

Size: px

Start display at page:

Download "The Heads and Tails of Project Coin"

Abraham Hill
5 years ago
Views:

2 The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle s products remains at the sole discretion of Oracle. 2 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

6 Project Coin benefits Remove extra text to make programs more readable Encourage writing programs that are more reliable Integrate well with past and future changes 6 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

7 Project Coin design constraints Small language changes Specification Implementation Testing Coordinate with larger language changes, both past (generics) and future (Lambda) Manage complex language interactions Specification Implementation 7 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

8 The Six Coin Features and How They Help Consistency and clarity Strings in switch Numeric literal improvements More concise error handling Multi-catch with more precise rethrow try-with-resources Easier to use generics Diamond Safe varargs 8 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

10 Project Coin features Binary literals and underscores in numeric literals Strings in switch Diamond Multi-catch and more precise rethrow try-with-resources Safe varargs 10 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

11 Safe Varargs Summary: no longer receive uninformative unchecked warnings from calling platform library methods: <T> List<T> Arrays.asList(T... a) <T> boolean Collections.addAll(Collection<? super T> c, T... elements) <E extends Enum<E>> EnumSet<E> EnumSet.of(E first, E... rest) void javax.swing.swingworker.publish(v... chunks) New annotation type SafeVarargs 11 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

12 Profitable to use! Retrofitted Project Coin features in the JDK code base Improve the existing code base by coinification Validate the design of features through use Detectors / converters applied for diamond, try-with-resources Coin features also in new library and test code, including NIO.2 (JSR 203) utility methods 12 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

http://www.usmint.gov/about_the_mint/coinlibrary/ How Coins were Minted Easy for the programmer, more work for the compiler!

13 How Coins were Minted Easy for the programmer, more work for the compiler! Internal compiler desugaring strings in switch try-with-resources Coordinated library changes java.lang.{autocloseable, SafeVarargs} Throwable.addSuppressed Serialized form of Throwable, new constructors Systematic application of new library features 13 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

14 // Original sugared switch(s) { case "a": case "b": return 10; } case "c": case "d": return 20;... // s mapped to offset switch($t) { case 1: case 2: return 10; } case 3: case 4: return 20; Copyright 2012, Oracle and/or its affiliates. All rights reserved.

15 // Original sugared switch(s) { case "a": case "b": return 10; } case "c": case "d": return 20;... // // Desugared int $t = -1; switch(s.hashcode()) { case 0x61: // "a".hashcode() if(s.equals("a")) $t = 1; break; case 0x62: if(s.equals("b")) $t = 2; break;... } s mapped to offset switch($t) { case 1: case 2: return 10; } case 3: case 4: return 20; Copyright 2012, Oracle and/or its affiliates. All rights reserved.

16 try-with-resources desugaring try ResourceSpecification Block { final VariableModifiers_minus_final R #resource = Expression; Throwable #primaryexception = null; 16 Copyright 2012, Oracle and/or its affiliates. All rights reserved. } try ResourceSpecification tail Block catch (Throwable #t) { #primaryexception = t; throw #t; } finally { if (#resource!= null) { if (#primaryexception!= null) { try { #resource.close(); } catch(throwable #suppressedexception) { #primaryexception.addsuppressed(#suppressedexception); } } else { #resource.close(); } } }

17 Library support for try-with-resources Not just a language feature! New superinterface java.lang.autocloseable All AutoCloseable and by extension java.io.closeable types usable with try-with-resources Retrofit Closeable/AutoCloseable to Java SE API JDBC 4.1 retrofitted as AutoCloseable too Suppressed exceptions are recorded using a new facility Throwable.addSuppressed Suppressed exception info included in stack trace, etc. 17 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

18 Throwable New field added to store suppressed exception data Serial compatibility must be kept with older releases IIOP serialization matters too! HotSpot specially creates certain exception objects Allow stack traces for OutOfMemoryError Need to document and follow a VM libraries protocol Exception objects should be able to be immutable New constructors added to Throwable Preserve immutability on serialize deserialize cycle 18 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

19 A Systematic Update Ran annotation processors over the JDK Types to be retrofitted as Closeable/AutoCloseable: Project Coin: Bringing it to a Close(able), See Methods and constructors to be annotated Project Coin: Safe Varargs in JDK Libraries, See Can run the same processors over your own code 19 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

20 Retrospective In the beginning A small language change needs to be small in all of: Specification Implementation Testing Not the only relevant dimensions 20 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

21 for (Coin coin : jdk7coins){ } Project Coin specification as a whole Design issues, alternatives, surprises Size of implementation Specification and implementation evolution Bug tail 21 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

26 JLS sections changed by Project Coin Improved Numeric Literals Integer Literals Floating-Point Literals Strings in Switch The switch Statement Safe varargs 4.8 Raw Types Variables of Reference Type Formal Parameters SafeVarargs (New!) Evaluate Arguments Diamond 15.9 Class Instance Creation Expressions Determining the Class being Instantiated Choosing the Constructor and its Arguments 18 Syntax 26 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

27 More JLS sections changed by Project Coin Multi-catch / more precise rethrow final Variables Exception Analysis of Statements Exception Checking Superclasses and Superinterfaces The try statement 18 Syntax try-with-resources final Variables 6.3 Scope of a Declaration 6.4 Shadowing and Obscuring Exception Analysis of Statements The try statement try-with-resources (New!) 18 Syntax 27 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

28 1. Improved numeric literals Grammar changes a bit tricky to get right; multiple underscores between digits: Digits: Digit Digit DigitsAndUnderscores opt Digit DigitsAndUnderscores: DigitOrUnderscore DigitsAndUnderscores DigitOrUnderscore 28 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

30 What about the octal base? If these are illegal integer literals 0x_abcd 0b_0101 should 0_1234 be legal? (Yes, because the leading 0 is more a digit than a base specifier) 30 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

32 2. Strings in switch: specification change JLS The switch Statement The type of [the switch] Expression must be char, byte, short, int, Character, Byte, Short, Integer, String, or an enum type ( 8.9), or a compile-time error occurs. 32 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

33 Strings in switch proposal form PROJECT COIN SMALL LANGUAGE CHANGE PROPOSAL FORM v1.0 AUTHOR(S): Joseph D. Darcy OVERVIEW Provide a two sentence or shorter description of these five aspects of the feature: FEATURE SUMMARY: Should be suitable as a summary in a language tutorial. Add the ability to switch on string values analogous to the existing ability to switch on values of the primitive types. MAJOR ADVANTAGE: What makes the proposal a favorable change? More regular coding patterns can be used for operations selected on the basis of a set of constant string values; the meaning of the new construct should be $take_default = false; boolean $fallthrough = false; $default_label: { switch(s.hashcode()) { // cause NPE if s is null case : // "quux".hashcode() if obvious to Java developers. (!s.equals("quux")) { $take_default = true; break $default_label; } processquux(s); $fallthrough = true; case : // "foo".hashcode() if (!$fallthrough && MAJOR BENEFIT: Why is the platform better if the proposal is adopted?!s.equals("foo")) { $take_default = true; break $default_label; } $fallthrough = true; case 97299: // "bar".hashcode() if (!$fallthrough &&!s.equals("bar")) { Potentially better performance for string-based dispatch code. $take_default = true; break $default_label; } processfooorbar(s); break; case 97307: // "baz".hashcode() if (!s.equals("baz")) { $take_default = true; break MAJOR DISADVANTAGE: There is always a cost. $default_label; } processbaz(s); $fallthrough = true; default: $take_default = true; break $default_label; } } if($take_default) processdefault(s); } Some increased implementation and testing complexity for the compiler. In the advanced example, the boolean "fallthrough" variable is needed to track whether a fall-through has occurred so the string equality checks can be ALTERNATIVES: Can the benefits and advantages be had some way without a language change? skipped. If there are no fall-throughs, this variable can be removed. Likewise, if there is no default label in the original code, the $take_default variable is not No; chained if-then-else tests for string equality are potentially expensive and introducing an enum for its switchable constants, one per string value of needed and a simple break can be used instead. interest, would add another type to a program without good cause. In a translation directly to bytecode, the synthetic state variables can be replaced with goto's; expressing this in pseudo Java source with goto: EXAMPLES // Advanced example in pseudo Java with goto switch(s.hashcode()) { // cause NPE if s is null case : // "quux".hashcode() if (!s.equals("quux")) goto Show us the code! $default_label; goto $fooorbarcode_label; case : // "foo".hashcode() if (!s.equals("foo")) goto $default_label; goto $fooorbarcode_label; case SIMPLE EXAMPLE: Show the simplest possible program utilizing the new feature : // "bar".hashcode() if (!s.equals("bar")) goto $default_label; $fooorbarcode_label: processfooorbar(s); break; case 97307: // "baz".hashcode() if String s =... switch(s) { case "foo": processfoo(s); break; } (!s.equals("baz")) goto $default_label; processbaz(s); default: $default_label: processdefault(s); break; } ADVANCED EXAMPLE: Show advanced usage(s) of the feature. Related to compilation, a compiler's existing diagnostics around falling through switches, such as javac's -Xlint:fallthrough option and String s should work identically on switch statements based on Strings. switch(s) { TESTING: How can the feature be tested? case "quux": Generating various simple and complex uses of the new structure and verifying the proper execution paths occur; combinations to test include switch processquux(s); // fall-through statements with and without fall-throughs, with and without collisions in the hash codes, and with and without default labels. case "foo": LIBRARY SUPPORT: Are any supporting libraries needed for the feature? case "bar": No. processfooorbar(s); REFLECTIVE APIS: Do any of the various and sundry reflection APIs need to be updated? This list of reflective APIs includes but is not limited to core break; case "baz": reflection (java.lang.class and java.lang.reflect.\*), javax.lang.model.\*, the doclet API, and JPDA. processbaz(s); // fall-through Only reflective APIs that model statements in the source language might be affected. None of core reflection, javax.lang.model.\*, the doclet API, and JDPA default: processdefault(s); model statements; therefore, they are unaffected. The tree API in javac, does model statements, but the existing API for switch statements is general break; } enough to model the revised language without any API changes. DETAILS OTHER CHANGES: Do any other parts of the platform need be updated too? Possibilities include but are not limited to JNI, serialization, and output of the SPECIFICATION: Describe how the proposal affects the grammar, type system, and meaning of expressions and statements in the Java Programming javadoc tool. Language as well as any other known impacts. No. The lexical grammar is unchanged. String is added to the set of types valid for a switch statement in JLSv3 section Since Strings are already included MIGRATION: Sketch how a code base could be converted, manually or automatically, to use the new feature. in the definition of constant expressions, JLSv3 section 15.28, the SwitchLabel production does not need to be augmented. The existing restrictions in Look for sequences of if ("constant string".equals(foo)) or if (foo.equals("constant string")) and replace accordingly. on no duplicate labels, at most one default, no null labels, etc. all apply to Strings as well. The type system is unchanged. The definite assignment analysis COMPATIBILITY of switch statement, JLSv3 section , is unchanged as well. BREAKING CHANGES: Are any previously valid programs now invalid? If so, list one. COMPILATION: How would the feature be compiled to class files? Show how the simple and advanced examples would be compiled. Compilation can be All existing programs remain valid. expressed as at least one of a desugaring to existing source constructs and a translation down to bytecode. If a new bytecode is used or the semantics of an EXISTING PROGRAMS: How do source and class files of earlier platform versions interact with the feature? Can any new overloadings occur? Can any existing bytecode are changed, describe those changes, including how they impact verification. Also discuss any new class file attributes that are introduced. new overriding occur? Note that there are many downstream tools that consume class files and that they may to be updated to support the proposal! One way to support this change would be to augment the JVM's lookupswitch instruction to operate on String values; however, that approach is not recommended or necessary. It would be possible to translate the switches to equivalent if-then-else code, but that would require unnecessary equality comparisons which are potentially expensive. Instead, a switch should occur on a predictable and fast integer (or long) function value computed from the string. The most natural choice for this function is String.hashCode, but other functions could also be used either alone or in conjunction with hashcode. (The specification of String.hashCode is assumed to be stable at this point.) If all the string labels have different lengths, String.length() could be used instead of hashcode. Generally a String.equals() check will be needed to verify the candidate string's identity in addition to the evaluation of the screening function because multiple string inputs could evaluate to the same result. A single case label, a single case label with a default, and two case labels can be special-cased to just equality checks without function evaluations. If there are collisions in String.hashCode on the set of case labels in a switch block, a different function without collisions on that set of inputs should be used; for example ((long)s.hashcode<<32 ) + s.length()) is another candidate function. Here are desugarings to currently legal Java source for the two examples above where the default hash code do not collide: // Simple Example if (s.equals("foo")) { // cause NPE if s is null processfoo(s); } // Advanced example { // new scope for synthetic variables boolean The semantics of existing class files and legal source files and are unchanged by this feature. REFERENCES EXISTING BUGS: Please include a list of any existing Sun bug ids related to this proposal Using Strings and Objects in Switch case statements. URL FOR PROTOTYPE (optional): No prototype at this time. 33 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

34 Strings in switch spec and implementation What is there to discuss? What does switching on a null do? Can null be a case label? JDK 7 implementation relies on a particular algorithm be used for String.hashCode Many other implementation options Secondary hash if collisions on primary hash Perfect hash functions Labeled-break 34 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

35 Project Coin: Taking a Break for Strings in Switch static void f(string s) { // Original sugared code switch (s) { case "azvl": System.out.println("azvl: "+s); // fallthrough case "quux": System.out.println("Quux: "+s); // fallthrough case "foo": int i = 5; //fallthrough case "bar": System.out.println("FooOrBar " + (i = 6) + ": "+s); break; case "bmjrabc": // same hash as "azvl" System.out.println("bmjrabc: "+s); break; case "baz": System.out.println("Baz " + (i = 7) + ": "+s); // fallthrough default: System.out.println("default: "+s); } } 35 Copyright 2012, Oracle and/or its affiliates. All rights reserved. static void f(string s) { // Desugared code $exit: { int i$foo = 0; $default_label: { $baz: { $bmjrabc: { $bar: { $foo: { $quux: { $azvl: { switch(s.hashcode()) { // cause NPE if s is null case : // "azvl" and "bmjrabc".hashcode() if (s.equals("azvl")) break $azvl; else if (s.equals("bmjrabc")) break $bmjrabc; else break $default_label; case : // "quux".hashcode() if (!s.equals("quux")) // inequality compare break $default_label; break $quux; case : // "foo".hashcode() if (s.equals("foo")) // equality compare break $foo; break $default_label; case 97299: // "bar".hashcode() if (!s.equals("bar")) break $default_label; break $bar; case 97307: // "baz".hashcode() if (!s.equals("baz")) break $default_label; break $baz; default: break $default_label; }//switch }//azvl System.out.println("azvl: "+s); // fallthrough } //quux System.out.println("Quux: "+s); // fallthrough } //foo i$foo = 5; }//bar System.out.println("FooOrBar " + (i$foo = 6) + ": "+s); break $exit; }//bmjrabc System.out.println("bmjrabc: " + s); break $exit; } //baz System.out.println("Baz " + (i$foo = 7) + ": "+s); // fallthrough }//default_label System.out.println("default: "+s); }//exit }

36 Strings in switch implementation history Original changeset quickly followed by small refinement Bug fix in JDK 7u2: switch(s) { case("a"): // Extra parentheses // would crash javac 36 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

37 3. SafeVarargs Background Often preferable to have a sound system of warnings No missed cases (no false negatives) But may have false positives 37 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

38 the [Java] language is designed to guarantee that if your entire application has been compiled without unchecked warnings [ ], it is type safe. Generics in the Java Programming Language Gilad Bracha 38 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

39 Unchecked warnings To make sure that potential violations of the typing rules are always flagged, some accesses to members of a raw type will result in compile-time unchecked warnings. The rules for compile-time unchecked warnings when accessing members or constructors of raw types are as follows: JLS 4.8 Raw Types 39 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

40 Heap Pollution Heap pollution can only occur if the program performed some operation involving a raw type that would give rise to a compile-time unchecked warning [ ] or if the program aliases an array variable of non-reifiable element type through an array variable of a supertype which is either raw or non-generic. JLS Variables of Reference Type 40 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

41 Unchecked Warnings and Soundness Unchecked warnings are intended to be a sound analysis From a certain point of view, it is correct to always emit an unchecked warning (but unhelpful!) Pre-JDK 7, always got an unchecked warning when calling certain varargs library methods Bad, and complicated interaction between generics and arrays But usually nothing dangerous really happens! 41 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

42 Limits of SafeVarargs Impractical to standardize a sufficiently powerful sound analysis in JDK 7 Just read-only not sufficient Just invariant not sufficient Aliasing complicates analysis Definite assignment/unassignment is tricky Leave such standardization for future work; quality of implementation issue in the meantime 42 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

43 Designing the SafeVarargs annotation type Annotations on methods are not can therefore only be applied to Static methods Constructors final instance methods Additional checks on varargs status, etc. Runtime retention policy 43 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

44 4. Diamond <> Diamond uses type inference to figure out types so the programmer doesn t have to write them Type inference is a constraint satisfaction problem What are the constraints? How can they be satisfied? Want a unique answer returned by the algorithm 44 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

45 Experiments Two inference schemes proposed, differing in how they gathered constraints Each sometimes more useful than the other Use quantitative analysis to help resolve the issue Prototype both schemes Analyze results on millions of files of code 45 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

46 Quantitative Results Both schemes equally effective Each could eliminate a different 90% of the explicit type parameters to constructor calls We verified diamond was a worthwhile feature! Choose inference scheme with better evolution and maintenance properties Language designer's notebook: Quantitative language design 46 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

47 Hofstadter s Law: It always takes longer than you expect, even when you take into account Hofstadter s Law. Douglas Hofstadter Gödel, Escher, Bach: An Eternal Golden Braid 47 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

48 Law of Evolving the Java Language: There are always more interactions than you expect, even when you expect lots of interactions. CUSTOMER LOGO 48 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

49 Diamond and anonymous classes public class Box<T> { private T value; Object o; List<?> arg =...; o = new Box<>(arg); } public Box(T value) { this.value = value; } T getvalue() { return value; } 49 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

52 Object o; List<?> arg =...; o = new a$1(arg); Anonymous classes translate into a new class file with a full set of attributes. class a$1 extends Box<List<capture of?> >{ } 52 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

53 Diamond and generic constructors class Foo<T extends Number> { // The rare generic constructor! <S extends T> Foo(S s) {super();} } Class Constructor Supported Example Explicit Explicit Yes new <Integer> Foo<Number>(null); Explicit Inferred Yes new Foo<Number>(null); Inferred Inferred Yes new Foo<>(null); Inferred Explicit No new <Integer> Foo<>(null); // compile error Project Coin: Diamond and Generic Constructors 53 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

54 5. Multi-catch and more precise rethrow Does it matter if this code doesn t compile in JDK 7? try { throw new DaughterOfFoo(); } catch (Foo exception) { try { // Pre-JDK 7 throws Foo, now throws DaughterOfFoo throw exception; } catch (SonOfFoo anotherexception) { ; // Reachable? } } 54 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

55 Multi-catch evolution Reformulated rules for can-throw computation Developed effectively final analysis What is the meaning of catch(foo SonOfFoo e) { } Explicitly disallowed in JDK 7 Could be added later 55 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

56 6. try-with-resources Largest of the Coins Syntax changes Allow trailing ; in resource list Require full declaration of resource variable inside try( ) Changes to semantics of desugaring Suppress only Exceptions or all Throwables? Null handling Throwable changes for suppression AutoCloseable and InterruptedException 56 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

60 JSR 334 in the Java Community Process Expert Group Formation Early Draft Review Public Review Jan 11, 2011 March 24, 2011 Proposed Final Draft June 24, 2011 JSR Approval Ballot Dec 06, 2010 July 5, 2011 Final Approval Ballot JSR Proposal Nov 16, 2010 July 18, 2011 Final Release 60 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

61 Project Coin changes in JDK 7 Methodical and quantitative approach Decide today what needs to be decided today Consciously leave room for future decisions Language + library co-evolution Smooth transition to new features Widespread tool support Use of new features reads well What about JDK 8? 61 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

62 (Very) Small Language changes Under consideration for JDK 8 Only opportunistic changes given scope of Lambda and Jigsaw Refinements to JDK 7 Project Coin features try-with-resources on an effectively final variable? Remove some restrictions on on a private method? Repeating annotations Parameter names available at runtime 62 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

63 The way ahead JDK Enhancement-Proposal & Roadmap Process Proposed JDK 8 language changes will appear as JEPs Any future full-scale Coin effort would interface with the JEP process 63 Copyright 2012, Oracle and/or its affiliates. All rights reserved.

Oracle Corporation

1 2011 Oracle Corporation Making heads and tails of Project Coin, Small language changes in JDK 7 Joseph D. Darcy Presenting with LOGO 2 2011 Oracle Corporation Project Coin is a suite of language and