Small Language Changes in JDK™ Release 7: …...> Modularity – aid writing and managing large...

Small Language Changes in JDK™ Release 7:Project Coin

Joseph D. DarcySun Microsystems, Inc.

2

Safe Harbor

During this presentation, we will make forward-looking statements, which involve risks and uncertainties such that actual results may differ materially.

3

Small Language Changes: Project Coin

“Making things programmers do everyday easier.”Support other platform featuresNew VM facilities with JSR 292 (invokedynamic)

4

Big(ger) Language Changes – modules> Modularity –

aid writing and managing large programs● The Modular Java™ Platform and Project Jigsaw

(TS-5359)Mark Reinhold, Wednesday, 09:45-10:45

● Modularity in the Java™ Programming Language: JSR 294 and Beyond (TS-4954)Alex Buckley, Wednesday, 11:05-12:05

● The Modular Java™ Platform: Q&A (BOF-5360)Mark & Alex, Wednesday, 7:45-8:35

5

Big(ger) Language Changes – JSR 308> Annotations on types –

enable pluggable type systems like null-checkers● Preventing Bugs with Pluggable Type Checking

(TS-3798)Michael Ernst, Today, 4:40-5:40

6

Better Integer LiteralsSubmitted by Bruce Chapman and Derek Foster> Support binary literalsint mask = 0b1010;> with underscoresint bigMask = b0011_1100;

long Big = 9_223_372_036_854_775_807L;> and unsigned literalsbyte b = 0xFFu;

7

Elvis and Other Null-Safe OperatorsSubmitted by S. Colebourne, written by Neal Gafter

> Binary "Elvis" operator Exp1 ?: Exp2

> If Exp1 is non-null, use that, otherwise evaluate and use Exp2

Integer i = returnIntOrNull() ?: ultimateAnswer();

8

Simplified Varargs Method InvocationSubmitted by Bob Lee> Some var-args warnings are unavoidable from a

library's design:

> Warn at declaration site too

static <T> List<T> asList(T... elements) { ... } static List<Callable<String>> stringFactories() { Callable<String> a, b, c; ... return asList(a, b, c); *Warning:"uses unchecked

or unsafe operations"* }

9

Strings in SwitchSubmitted by Joe Darcy> Can switch on constant integral values> Strings are constants too!

String s = ...;switch (s) {case "foo": return 1;case "bar": return 2;}

10

Strings in switch, specification change

JLS §14.11 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.”

11

Strings in switch, Coin Proposal FormPROJECT COIN SMALL LANGUAGE CHANGE PROPOSAL FORM v1.0

AUTHOR(S): Joseph D. Darcy

OVERVIEWProvide 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 obvious to Java developers.

MAJOR BENEFIT: Why is the platform better if the proposal is adopted?

Potentially better performance for string-based dispatch code.

MAJOR DISADVANTAGE: There is always a cost.

Some increased implementation and testing complexity for the compiler.

ALTERNATIVES: Can the benefits and advantages be had some way without a language change?

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 interest, would add another type to a program without good cause.

EXAMPLESShow us the code!SIMPLE EXAMPLE: Show the simplest possible program utilizing the new feature.String s = ...switch(s) { case "foo": processFoo(s); break;}

ADVANCED EXAMPLE: Show advanced usage(s) of the feature.String s = ...switch(s) { case "quux": processQuux(s); // fall-through

case "foo": case "bar": processFooOrBar(s); break;

case "baz": processBaz(s); // fall-through

default: processDefault(s); break;}

DETAILSSPECIFICATION: Describe how the proposal affects the grammar, type system, and meaning of expressions and statements in the Java Programming Language as well as any other known impacts.

The lexical grammar is unchanged. String is added to the set of types valid for a switch statement in JLSv3 section 14.11. Since Strings are already included in the definition of constant expressions, JLSv3 section 15.28, the SwitchLabel production does not need to be augmented. The existing restrictions in 14.11 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 of switch statement, JLSv3 section 16.2.9, is unchanged as well.

COMPILATION: How would the feature be compiled to class files?

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 assume 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 Exampleif (s.equals("foo")) { // cause NPE if s is null processFoo(s);}

// Advanced example{ // new scope for synthetic variables boolean $take_default = false; boolean $fallthrough = false; $default_label: { switch(s.hashCode()) { // cause NPE if s is null case 3482567: // "quux".hashCode() if (!s.equals("quux")) { $take_default = true; break $default_label; } processQuux(s); $fallthrough = true; case 101574: // "foo".hashCode() if (!$fallthrough && !s.equals("foo")) { $take_default = true; break $default_label; } $fallthrough = true; case 97299: // "bar".hashCode() if (!$fallthrough && !s.equals("bar")) { $take_default = true; break $default_label; } processFooOrBar(s); break;

case 97307: // "baz".hashCode() if (!s.equals("baz")) { $take_default = true; break $default_label; } processBaz(s); $fallthrough = true;

default: $take_default = true; break $default_label; } } if($take_default) processDefault(s);}

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 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 needed and a simple "break" can be used instead.

In a translation directly to bytecode, the synthetic state variables can be replaced with goto's; expressing this in pseudo Java source with goto:

// Advanced example in pseudo Java with gotoswitch(s.hashCode()) { // cause NPE if s is nullcase 3482567: // "quux".hashCode() if (!s.equals("quux")) goto $default_label; goto $fooOrBarCode_label;

case 101574: // "foo".hashCode() if (!s.equals("foo")) goto $default_label; goto $fooOrBarCode_label;

case 97299: // "bar".hashCode() if (!s.equals("bar")) goto $default_label;

$fooOrBarCode_label: processFooOrBar(s); break;

case 97307: // "baz".hashCode() if (!s.equals("baz")) goto $default_label; processBaz(s);

default:$default_label: processDefault(s); break;}

Related to compilation, a compiler's existing diagnostics around falling through switches, such as java's -Xlint:fallthrough option and @SuppressWarnings("fallthrough"), should work identically on switch statements based on Strings.

TESTING: How can the feature be tested?

Generating various simple and complex uses of the new structure and verifying the proper execution paths occur; combinations to test include switch statements with and without fall-throughs, with and without collisions in the hash codes, and with and without default labels.

LIBRARY SUPPORT: Are any supporting libraries needed for the feature?

No.

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 reflection (java.lang.Class and java.lang.reflect.*), javax.lang.model.*, the doclet API, and JPDA.

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 model statements; therefore, they are unaffected. The tree API in javac, http://java.sun.com/javase/6/docs/jdk/api/javac/tree/index.html, does model statements, but the existing API for switch statements is general enough to model the revised language without any API changes.

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 javadoc tool.

No.

MIGRATION: Sketch how a code base could be converted, manually or automatically, to use the new feature.

Look for sequences of if ("constant string".equals(foo)) or if (foo.equals("constant string")) and replace accordingly.

COMPATIBILITYBREAKING CHANGES: Are any previously valid programs now invalid? If so, list one.

All existing programs remain valid.

EXISTING PROGRAMS: How do source and class files of earlier platform versions interact with the feature? Can any new overloadings occur? Can any new overriding occur?

The semantics of existing class files and legal source files and are unchanged by this feature.

REFERENCESEXISTING BUGS: Please include a list of any existing Sun bug ids related to this proposal.

5012262 Using Strings and Objects in Switch case statements.http://bugs.sun.com/view_bug.do?bug_id=5012262

URL FOR PROTOTYPE (optional):

No prototype at this time.

12

Possible Language Enhancements4032740: (Reflection)Accessibilities of members should be ACCESS-LEVEL sensitive.4041479: String conversion needs another index entry4071299: Compilation spec needed: should state if private should imply final for a method4088441: long double support4093687: Extension of 'Interface' definition to include class (static) methods.4171368: VerifyError vs. ArrayStoreException for aastore4191243: Method forwarding - Subclassing without subtyping4206170: Cloning inner classes4213096: A Proposal for User-Defined Lightweight Value-Semantics Objects4223287: Suggestion for "atomic" keyword for try {} blocks4228585: Explicit (language) support for properties4230600: Ease the JLS to allow mathematical symbols in indentifiers4260488: RFE: Please add nested /* */ comments4262078: Maximum method size is too small (64Kb)4269827: Allow multiple constants and ranges in case labels4300222: RFE: Object Oriented Callbacks4344759: Allow Unicode versions of operators4351453: `final' variables and inner classes4364486: Innocuous comment text can appear as ill-formed Unicode escape4384324: java really needs a complex (number) primitive type4395264: Allow this/super in certain static contexts4396260: misleadingly incomplete xref in JLS2 15.28 Constant Expression4421728: Specification required for mapping from class names to file names4432337: Catching multiple exceptions simultaneously4449383: Support For 'Design by Contract', beyond "a simple assertion facility"4456057: package access for interface methods4472509: Add support for vertabim string literals4487555: Java Generics Support should support primitive types4617197: RFE: Add Immutable types to Java4630147: silly JLS rule that restricts the throw clause in a hiding method4632701: Add extensible arrays and dictionaries to the syntax4649007: Document classfile attributes for compilation date/time + debugging4652857: Rethink Java FP spec4662939: wanted: constant pool entries for arrays4713248: spurious constraint in 8.8.5.1 re: anon classes and enclosing instances4726340: RFE: Tail Call Optimization4728767: Inner Classes Need to Support Static4748349: Multiple return values from a method4750181: javac should use grammar from JLS sections 4, 6-10, 14, 154809540: RFE: permit allocation of new objects on stack4877954: RFE: Special syntax for core interfaces4879776: Constructor type inference (JSR14 + JSR65 ++)4888664: RFE: syntactic sugar to simulate C++ stack-allocted object destructor semantics4905919: RFE: Operator overloading4963452: RFE: 64 bit pointers needed4983159: Typedef (alias)4988583: AutomaticException chaining for exception in try and exception thrown in finally4998315: JVM should allow nested classes free access to private members5008260: @Override should be generalized from 'superclass' to 'supertype'5009476: Compound assignments don't work well with Byte, Short5012262: Using Strings and Objects in Switch case statements.5014235: Closures support instead of annonymous inner classes5025288: Language support for literal numbers in binary and other bases5025326: Clarification needed around subroutine recursive calls5043025: Access to Field, Method and Constructor without the use of Strings5044723: imports versus erasure of inner classes

5052951: Wildcard should have multiple bounds similar to type variables5052956: Type variables should have lower/super bounds5060259: Please introduce a name for the "null" type5061325: Add language support for functors (function objects)5066813: Allow annotations to appear more than once on the same element5092615: RFE: Expression Class Support5092855: RFE:Change language specification for easier writing of Regular Expressions5098163: Add reification of generic type parameters to the Java programming language5108147: Extending finally to allow optional Throwable exception parameter6176774: arrays should implement Iterable6179333: Allow guaranteed disposing of iterators in enhanced for loop6184881: Object.getClass() typing rule could be improved6193725: Improved method forwarding (requires change to JVM)6207924: Non-null types6260924: JLS 15.12.1 should specify that type of Primary may not be primitive6264216: Overly agressive application of JLS3 rules to cyclic type references in annotation by javac6312085: The for/in statement should support Iterators6324535: Allow static anonymous classes6350706: Multiply-bounded reference type expressions6350731: Annotation system prohibits certain annotations, drops others6371674: inference: Inferred types' bounds should help infer unconstrained type variables6407464: BigInteger should support Autoboxing.66412514: Message "except.never.thrown.in.try" have to be reported in extra cases6427253: Support for Method Level Annotation Inheritance6433012: A simplified syntax for using Runnable6444738: need access to method parameter names when processing annotations at runtime6463976: Add Lambda, Thunk, Predicate, etc., to complement Runnable6469144: RFE: consider adding traits to Java6479372: Add self types (type of 'this' aka ThisClass) to the language6480391: JLS3 5.1.10 ? means ? extends Object6488666: inference: lub of typevariables does not yield expected results6500704: Add language support for converting methods to interfaces6512103: Annotation-qualified optional disallowance of raw generic types6514490: final fields can be read before being definitely assigned6519124: RFE: Add Keyword Management6534270: Support "suppresses" new keyword in method signatures6557326: Generics RFE: allow <X,Y>foo(), instead of this.<X,Y>foo()6569520: Omit 'return null;' for Void methods (or allow void as a type parameter)6570766: Support for public abstract enum declaration6594979: JVMS 2ed 4.9.4 is overly broad on restricting uninitialized objects in backward jumps6602336: instanceof bytecode instruction is too strict6640435: inference: propagate >> and == constraints to help uninferred type vars6643818: Eager-linking VMs should be prohibited to perform early error throwing6644562: Re-specify membership of intersection types6674900: Clarify the difference between a Type Variable and a Type Parameter6674901: Please clarify ReferenceType6690688: Enhanced-for-loop translation as described in JLS 14.14.2 is not type-safe6707036: Need SE Platform Spec to list supported classfile versions6718388: Missing rules for intersection types6719603: Require NoClassDefFoundError to chain original exception, add JCK test6720843: Clarify that the throw statement can take null6742436: Improved Parallelism in the Java Runtime Environment6746458: writing libraries in Java for non-Java languages requires support for exotic identifiers6754038: writing libraries in Java for non-Java languages requires support for invokedynamic sites6775422: OSGi & Dependency Injection6785114: Return type inference (15.12.2.8) doesn't work with autoboxing6785612: Generifying a class breaks compatibility wrt >1.5 clients

13

The Six Blind Dukesand theElephant

14

Elephant Conclusions> Locally accurate information not enough

> Need broad perspective for good global decisions● Compromises to maintain a single general

purpose language

15

Filling a knapsack> Limited space/weight that will fit and be carried> Choose among a subset of objects with different

sizes and values> Goal is to maximize value of items in knapsack> NP-hard problem!> Surprising result:

“Greedy” algorithm of choosing highest value/size first can give a far from optimal result

16

Greed is not Always Good

10 kg sack

7 kg$21

$3/kg

$21 $21 totaltotal

6 kg$15

4 kg$10

$2.5/kg

$25 $25 totaltotal

17

Coins for a Knapsack> Language features have discrete units of work

● Can't easily trade-off % effort and % functionality> Maximize value of features included in a release

given resource constraints> Can be a hard selection problem!> Language features

● Imprecise costs● Hard to quantify benefits

18

What is a small language change?> Simultaneously small enough in

● Specification● Implementation● Testing

> Knapsack filling in 3 dimensions!> If small in all those ways, should be at most a

small barrier to developer adoption

19

Changes aren't for expressiveness!> From a certain point of view, all

Turing complete languages are equivalent > But they aren't:

● Efficiency● What does the text for a computation look like?

● Length● Structure

> Want “similar” programs to have similar text> Improve readability

20

Possible Language Enhancements4032740: (Reflection)Accessibilities of members should be ACCESS-LEVEL sensitive.4041479: String conversion needs another index entry4071299: Compilation spec needed: should state if private should imply final for a method4088441: long double support4093687: Extension of 'Interface' definition to include class (static) methods.4171368: VerifyError vs. ArrayStoreException for aastore4191243: Method forwarding - Subclassing without subtyping4206170: Cloning inner classes4213096: A Proposal for User-Defined Lightweight Value-Semantics Objects4223287: Suggestion for "atomic" keyword for try {} blocks4228585: Explicit (language) support for properties4230600: Ease the JLS to allow mathematical symbols in indentifiers4260488: RFE: Please add nested /* */ comments4262078: Maximum method size is too small (64Kb)4269827: Allow multiple constants and ranges in case labels4300222: RFE: Object Oriented Callbacks4344759: Allow Unicode versions of operators4351453: `final' variables and inner classes4364486: Innocuous comment text can appear as ill-formed Unicode escape4384324: java really needs a complex (number) primitive type4395264: Allow this/super in certain static contexts4396260: misleadingly incomplete xref in JLS2 15.28 Constant Expression4421728: Specification required for mapping from class names to file names4432337: Catching multiple exceptions simultaneously4449383: Support For 'Design by Contract', beyond "a simple assertion facility"4456057: package access for interface methods4472509: Add support for vertabim string literals4487555: Java Generics Support should support primitive types4617197: RFE: Add Immutable types to Java4630147: silly JLS rule that restricts the throw clause in a hiding method4632701: Add extensible arrays and dictionaries to the syntax4649007: Document classfile attributes for compilation date/time + debugging4652857: Rethink Java FP spec4662939: wanted: constant pool entries for arrays4713248: spurious constraint in 8.8.5.1 re: anon classes and enclosing instances4726340: RFE: Tail Call Optimization4728767: Inner Classes Need to Support Static4748349: Multiple return values from a method4750181: javac should use grammar from JLS sections 4, 6-10, 14, 154809540: RFE: permit allocation of new objects on stack4877954: RFE: Special syntax for core interfaces4879776: Constructor type inference (JSR14 + JSR65 ++)4888664: RFE: syntactic sugar to simulate C++ stack-allocted object destructor semantics4905919: RFE: Operator overloading4963452: RFE: 64 bit pointers needed4983159: Typedef (alias)4988583: AutomaticException chaining for exception in try and exception thrown in finally4998315: JVM should allow nested classes free access to private members5008260: @Override should be generalized from 'superclass' to 'supertype'5009476: Compound assignments don't work well with Byte, Short5012262: Using Strings and Objects in Switch case statements.5014235: Closures support instead of annonymous inner classes5025288: Language support for literal numbers in binary and other bases5025326: Clarification needed around subroutine recursive calls5043025: Access to Field, Method and Constructor without the use of Strings5044723: imports versus erasure of inner classes

5052951: Wildcard should have multiple bounds similar to type variables5052956: Type variables should have lower/super bounds5060259: Please introduce a name for the "null" type5061325: Add language support for functors (function objects)5066813: Allow annotations to appear more than once on the same element5092615: RFE: Expression Class Support5092855: RFE:Change language specification for easier writing of Regular Expressions5098163: Add reification of generic type parameters to the Java programming language5108147: Extending finally to allow optional Throwable exception parameter6176774: arrays should implement Iterable6179333: Allow guaranteed disposing of iterators in enhanced for loop6184881: Object.getClass() typing rule could be improved6193725: Improved method forwarding (requires change to JVM)6207924: Non-null types6260924: JLS 15.12.1 should specify that type of Primary may not be primitive6264216: Overly agressive application of JLS3 rules to cyclic type references in annotation by javac6312085: The for/in statement should support Iterators6324535: Allow static anonymous classes6350706: Multiply-bounded reference type expressions6350731: Annotation system prohibits certain annotations, drops others6371674: inference: Inferred types' bounds should help infer unconstrained type variables6407464: BigInteger should support Autoboxing.66412514: Message "except.never.thrown.in.try" have to be reported in extra cases6427253: Support for Method Level Annotation Inheritance6433012: A simplified syntax for using Runnable6444738: need access to method parameter names when processing annotations at runtime6463976: Add Lambda, Thunk, Predicate, etc., to complement Runnable6469144: RFE: consider adding traits to Java6479372: Add self types (type of 'this' aka ThisClass) to the language6480391: JLS3 5.1.10 ? means ? extends Object6488666: inference: lub of typevariables does not yield expected results6500704: Add language support for converting methods to interfaces6512103: Annotation-qualified optional disallowance of raw generic types6514490: final fields can be read before being definitely assigned6519124: RFE: Add Keyword Management6534270: Support "suppresses" new keyword in method signatures6557326: Generics RFE: allow <X,Y>foo(), instead of this.<X,Y>foo()6569520: Omit 'return null;' for Void methods (or allow void as a type parameter)6570766: Support for public abstract enum declaration6594979: JVMS 2ed 4.9.4 is overly broad on restricting uninitialized objects in backward jumps6602336: instanceof bytecode instruction is too strict6640435: inference: propagate >> and == constraints to help uninferred type vars6643818: Eager-linking VMs should be prohibited to perform early error throwing6644562: Re-specify membership of intersection types6674900: Clarify the difference between a Type Variable and a Type Parameter6674901: Please clarify ReferenceType6690688: Enhanced-for-loop translation as described in JLS 14.14.2 is not type-safe6707036: Need SE Platform Spec to list supported classfile versions6718388: Missing rules for intersection types6719603: Require NoClassDefFoundError to chain original exception, add JCK test6720843: Clarify that the throw statement can take null6742436: Improved Parallelism in the Java Runtime Environment6746458: writing libraries in Java for non-Java languages requires support for exotic identifiers6754038: writing libraries in Java for non-Java languages requires support for invokedynamic sites6775422: OSGi & Dependency Injection6785114: Return type inference (15.12.2.8) doesn't work with autoboxing6785612: Generifying a class breaks compatibility wrt >1.5 clients

21

Asking the right question

Why don't you...

22

Asking the right question

Why don't you...

23

A better question

Why don't we...

24

Project Coin> Participatory effort! Call for proposals:

● Write a detailed proposal● Prototype optional● Analysis and critiques on the list

25

Project Coin Statistics

0

2

4

6

8

10

0

10

20

30

40

50

60

70

Project Coin Proposal Submissions

Days after Opening

Subm

itted

Pro

posa

ls P

er D

ay

Tota

l Sub

mitt

ed P

ropo

sals

26

Feature Selection Process> Generate feature candidates> Test

● Prototype!● Analyze bodies of code

Ewan Tempero's “Qualitas Corpus”> Decide

27

Stability versus Progress> Default response is to keep the language as-is> Burden is on the proposer to convince that a

change gets in;burden is not to convince to keep a change out

> Language changes● Slow availability● Heavyweight● Multiple points in toolchain

> Don't use language changes as first-line solution

28

Prefer Library Changes> Enhanced for each loop iteration control

Propose to add an explicit iteration variable wrapped in an API richer than Iterator

> Alternative, add richer API elsewhere:● 5015163 (str) String merge/join that is the inverse

of String.split().● 6463989 (coll) Provide Iterable utility methods and

light-weight Iterable implementations

29

So you want to change the language...> Update the JLS> Implement in a

compiler> Add essential

library support> Write tests> Update the VM Spec.

> Update the VM and class file tools

> Update JNI> Update reflective APIs> Update serialization

support> Update javadoc output

30

Updating the JLS> Grammar changes?> Type system

changes?> New conversions?> Naming conventions?> Structure of packages,

classes, and interfaces?

> Annotation locations?> Method resolution?> Source compatibility?> Binary compatibility?> Reachability or

definite assignment?

31

Updating Class File Consumers> Class file consumers include

● VM● javap● pack200/unpack200● ASM, BCEL, obfuscators, ...

> Implications● Even just a new class file version requires a minor

change● Exposure at API level requires coordination

32

Updating Reflective APIs> Core reflection

(java.lang.Class and java.lang.reflect.*)

> Annotation Processing model (from JSR 269)(javax.lang.model.*)

> Doclet API> apt API> Platform Debugger Architecture (JPDA)

33

Improved Exception HandlingSubmitted by Neal Gafter> Problems:

● Often have to repeat code in parallel catch clauses

try { doWork(file);} catch (final Except1 | Except2 ex) {logger.log(ex);

throw ex;}

34

Sizing up past changes> Normal maintenance: Tiny

> Hexadecimal floating-point literals Very small

> for-each loop Small> static import Small

(but more complicated than expected)

35

Looping, pre 1.5

int[] data = …long sum = 0;

for(int i = 0; i < data.length; i++) sum += data[i];

List data = …long sum = 0;Iterator it = data.iterator();while(it.hasNext()) sum += ((Integer) it.next()). intValue();

36

Looping, post 1.5

int[] data = …long sum = 0;for(int e : data) sum += e;

List<Integer> data = …long sum = 0;for(int e : data) sum += e;

37

Sizing up past changes> Normal maintenance: Tiny

> Hexadecimal floating-point literals Very small

> for-each loop Small> static import Small

(but more complicated than expected)> enum types Medium> Autoboxing and unboxing Medium> Annotation types Large> Generics Huge

38

Enums: A Cautionary Tale> EJ, first edition

Item 21: Replace enum constructs with classes● Variation 1: Basic typesafe enum● Variation 2: Extensible typesafe enum

> enum construct outgrowth of basic variation● Many language support issues already discussed

serialization, switches, library support, specialized enum constants, …

> What is left to do?

39

> Update the JLS> Implement in a

compiler> Add essential

library support> Write tests> Update the VM Spec.

Enums: Step by Step> Update the VM and

class file tools> Update JNI> Update reflective APIs> Update serialization

support> Update javadoc output

40

Update the JLS> §3.9 Keywords> §8.1 Class Declaration> §8.1.4 Superclasses and Subclasses> §8.9 Enums> §9.7 Annotations> §13.4.26 Evolution of enums> §14.11 The switch Statement> §16.5 Definite Assignment and Enum Constants

41

More enum support> Add essential library supportjava.lang.Enum

EnumSet and EnumMapEnumConstantNotPresentException

> Update the VM Spec.ACC_ENUM flag

> Update the VM and class file tools

42

Still more enum support> Update reflective APIs

The prolonged tale of java.lang.Class.isEnum()public boolean isEnum() {// An enum must both directly extend java.lang.Enum// and have the ENUM bit set; classes for specialized// enum constants don't do the former. return (this.getModifiers() & ENUM) != 0 && this.getSuperclass() == java.lang.Enum.class;}● Third time was the charm!

43

Reflective enum support, cont.> Interaction with Constructor.newInstance:

if((clazz.getModifiers() & Modifier.ENUM)!=0) throw new IllegalArgumentException( "Cannot reflectively create...");if (constructorAccessor == null) acquireConstructorAccessor();return (T) constructorAccessor. newInstance(initargs);

> Are synthesized methodspublic static T[] values();public static T valueOf(String)

synthetic?

44

Enum support, still going...> Update serialization support

● Special support in normal serialization machinery● What about IIOP serialization?

> Update javadoc output> Whew!

45

Bonus Puzzler!> Are these equivalent? Is the second a

compatible replacement for the first?

// Beforepublic enum MetaSyntVar { FOO(21), BAR(42); private int answer; MetaSyntVar(int answer) { this.answer = answer; } public int answer() { return answer;}}

// Afterpublic enum MetaSyntVar { FOO { public int answer() { return 21;}}, BAR { public int answer() { return 42;}}; public abstract int answer();}

46

Kinds of Compatibility> Source, several degrees of source compatibility,

not discussed in detail in JLS> Binary, defined in JLS §13.2

“A change to a type is binary compatible with (equivalently, does not break binary compatibility with) preexisting binaries if preexisting binaries that previously linked without error will continue to link without error.”

> Behavioral“Changes to the body of a method or constructor do not break [binary] compatibility with pre-existing binaries.” JLS §13.4.22

47

JLS §13.4.16 abstract Methods

“Changing a method that is declared abstract to no longer be declared abstract does not break compatibility with pre-existing binaries.

Changing a method that is not declared abstract to be declared abstract will break compatibility with pre-existing binaries that previously invoked the method, causing an AbstractMethodError.”

48

Choices

A “After” enum is invalid and won't compileB Clients won't compile or linkC Clients won't compile, but still linkD Clients compile and link, but an exception like

NoSuchMethodException is thrown at runtime

E Clients compile, link, and run the same with both versions

49

Another lookand Voting!



A. “After” won't compileB. Source and binary incompatibleC. Source incompatible, binary compatibleD. Exception at runtimeE. Fully source, binary, and behavioral compatible

50

Result

A “After” enum is invalid and won't compileB Clients won't compile or linkC Clients won't compile, but still linkD Clients compile and link, but an exception like

NoSuchMethodException is thrown at runtime

E Clients compile, link, and run the same with both versions*

*Looks a little different under core reflection.

51

Why?> What can go wrong?

“Changing a method that is not declared abstract to be declared abstract will break compatibility with pre-existing binaries that previously invoked the method, causing an AbstractMethodError.” JLSv3 §13.4.16

> But enum types have strong instance control, the only objects with that type are created in the enum class, so the situation causing the binary incompatibility cannot occur. ● No rogue instances from cloning, serialization,

constructors, or reflection

52

Public Contract of an enum> Name and modifiers of the enum type> Name and order of enum constants> Declared methods, etc.



53

Moral> Be very certain of type system changes!

● Lots of details and interactions!● Changing the type system means many new

questions can be asked, must be prepared to answer them.

54

Changes oversized for JDK 7> enum types Medium> Properties Medium – Large> Autoboxing and unboxing Medium> Annotation types Large> Reification Large> Closures Large – Huge> Generics Huge

55

Automatic Resource ManagementSubmitted by Josh Bloch> Manually closing resources is very tricky!// Today static void copy(String src, String dest) throws IOException { InputStream in = new FileInputStream(src); try { OutputStream out = new FileOutputStream(dest); try { byte[] buf = new byte[8 * 1024]; int n; while ((n = in.read(buf)) >= 0) out.write(buf, 0, n); } finally { out.close(); } } finally { in.close(); }}

56

Automatic Resource Management

// Possible Tomorrow static void copy(String src, String dest) throws IOException { try (InputStream in = new FileInputStream(src); OutputStream out = new FileOutputStream(dest)) { byte[] buf = new byte[8192]; int n; while ((n = in.read(buf)) >= 0) out.write(buf, 0, n); }}

57

Automatic Resource Management package java.lang.auto;/** * A resource that must be closed * when it is no longer needed. */public interface AutoCloseable { void close() throws Exception;} package java.io;public interface Closeable extends AutoCloseable { void close() throws IOException;}

58

Indexing syntax for Lists and MapsSubmitted by Shams Mahmood Imam

List<String> list = Arrays.asList(new String[] {"a", "b", "c"});String firstElement = list[0];Map<Integer, String> map = new HashMap<>();map[Integer.valueOf(1)] = "One";

59

Indexing syntax for Lists and Maps

// New superinterfaces to indicate syntax?interface GettableFromInt<E> { E get(int);}interface Gettable<V> { V get(Object); }interface Settable { E set(int, E);}interface Puttable { V put(K, V);}java.util.List<E> extends GettableFromInt<E>, Settable<E>, …java.util.Map<K, V> extends Gettable<V>, Puttable(K, V), …

60

Collection LiteralsSubmitted by Josh Bloch

List<String> list = ["a", "b", "c"];String firstElement = list[0];Map<Integer, String> map = {1 : "One"};

61

Large ArraysSubmitted by James Lowden> With last two features, can be written as a pure

library!> VM support helpful but not required

62

Language support for JSR 292Submitted by John Rose> Toward a Renaissance VM (TS-5216)

John Rose & Brian GoetzToday,18:00-19:00

> JSR 292 Cookbook, (BOF-5236)Christian Thalinger & John RoseThursday, 18:30-19:20

63

DiamondSubmitted by Jeremy Manson > Have to repeat type parameters on

● Left hand side in a variable declaration AND on● Right hand side in a constructor call

> Right hand parameters are mostly redundant● Have the compiler infer them

Map<Bar, List<Foo> map = new HashMap<>();

64

DEMO

65

Coming Soon...> Final set of proposals

● Initial implementations in future JDK 7 builds● Explicitly enable with “-source 7”

66

Not a change, better diagnostics: Beforeinterface List<E> {}class Test { <T> void merge(List<T> l1, List<T> l2) {} void test(List<? extends Test> list) { merge(list, list); }}Test.java:6: <T>merge(List<T>,List<T>) in Test cannot be applied to (List<capture#339 of ? extends Test>,List<capture#768 of ? extends Test>)

merge(list, list); ^1 error

67

Not a change, better diagnostics: Afterinterface List<E> {}class Test { <T> void merge(List<T> l1, List<T> l2) {} void test(List<? extends Test> list) { merge(list, list); }}Test.java:6: method merge in class Test cannot be applied to given types

merge(list, list); ^ required: List<T>,List<T> found: List<CAP#1>,List<CAP#2> where T is a type-variable: T extends Object declared in method <T>merge(List<T>,List<T>)

where CAP#1,CAP#2 are fresh type-variables: CAP#1 extends Test from capture of ? extends Test CAP#2 extends Test from capture of ? extends Test1 error

68

Not a change: More information...> Summary information printed first, configurable

verbosity> Information on bounds, no more hash codes!> For more information:

Java™ Programming Language Tools in JDK™ Release 7, (BOF-4135)Maurizio Cimadamore & Jonathan GibbonsThursday, 8:30-9:20

69

Language Design Parting Thoughts“If this book has convinced the reader that a programming language designer needs the expertise of a scientist, the precision of a mathematician, and the taste of an artist as well as the pragmatism of an engineer, then it has achieved one of its objectives.”

―R. D. TennentPrinciples of Programming Languages

70

Q & Ahttp://blogs.sun.com/darcy

http://openjdk.java.net/projects/coin/

Joseph D. Darcyhttp://blogs.sun.com/[email protected]

http://blogs.sun.com/darcy

72

Backup Slides

73

For further consideration...> Better integral literals, by Bruce Chapman and

Derek Foster> Improved Exception Handling, Neal Gafter> Automatic Resource Management, Josh Bloch> Elvis and Other Null-Safe Operators, written by

Neal Gafter, submitted by Stephen Colebourne > Simplified Varargs Method Invocation, Bob Lee

74

More for further consideration...> Indexing access syntax for Lists and Maps,

Shams Mahmood Imam> Collection Literals, Josh Bloch> Large Arrays, James Lowden> Language support for JSR 292, John Rose> Strings in switch, Joe Darcy> Improved Type Inference for Generic Instance

Creation (diamond), Jeremy Manson

75

Hexadecimal Floating-Point Literals> Handy to have textual representation that is

● Human readable● Clearly unambiguous● Mappable to floating-point format

> Examples(2–2–52)·21023 as 0x1.fffffffffffffp10232–1074 as 0x1.0P-1074 or 0x0.0000000000001P-1022

76

Source Compatibility Threat Levels

Still Compiles

No Longer Compiles

Binary-preserving

Behaviorally Equivalent

77

Delete foo

public final class C { double foo(double d) { return d * 2.0;}}

Still Compiles

No Longer Compiles

Binary-preserving


78

Delete foo

Addint bar() { return 42;}


Still Compiles

No Longer Compiles

Binary-preserving


79


Addvoid double foo(int i) { return i * 2.0;}

Delete foo


Still Compiles

No Longer Compiles

Binary-preserving


80

Still Compiles

No Longer Compiles

Binary-preserving


Addvoid double foo(long l){ return (double) (el * 2L;)}


Addvoid double foo(int i) { return i * 2.0;}

Delete foo


81

(3, 4)

(5, 1)

82

(3, 4)N

1=7

(5, 1)N

1=6

83

(3, 4)N

1=7

N2=5

(5, 1)N

1=6

N2≈5.1

Small Language Changes in JDK™ Release 7: …...> Modularity – aid writing and managing large...

Documents

Transcript of Small Language Changes in JDK™ Release 7: …...> Modularity – aid writing and managing large...