jdk 9 language, tooling, and library features · •prepare for jdk 9 [con2937] monday, sep 19,...

Copyright © 2016, Oracle and/or its affiliates. All rights reserved.

JDK 9 Language, Tooling, and Library Features More than modules!

#JDK9LangToolsLibs Joseph D. Darcy (@jddarcy) Java Platform Group Oracle September 19, 2016


Safe Harbor Statement

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 © 2016, Oracle and/or its affiliates. All rights reserved. 3

Pic

ture

s co

pyr

igh

t 2

01

2 J

ose

ph

D. D

arcy

All

righ

ts r

eser

ved.


Survey: Which JDK train are you using in production?

4

• JDK 9 EA with cutting edge Jigsaw

• JDK 9 EA

• JDK 8

• JDK 7

• JDK 6

• JDK 5.0 or older


JDK 9 Overview

5


JDK 9 Information

• Current proposed schedule: GA July 2017, weekly updates:

• Early access binaries + docs: https://jdk9.java.net/

• Early access binaries with cutting edge Jigsaw: https://jdk9.java.net/jigsaw/

• OpenJDK : • Project: http://openjdk.java.net/projects/jdk9/

• Mailing list: http://mail.openjdk.java.net/mailman/listinfo/jdk9-dev

• Source code: http://hg.openjdk.java.net/jdk9/dev/

• Adoption: http://mail.openjdk.java.net/pipermail/adoption-discuss/ https://wiki.openjdk.java.net/display/quality/Quality+Outreach/

• JEPs (JDK Enhancement Proposals) used for project tracking

6

https://jdk9.java.net/

https://jdk9.java.net/jigsaw/

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

http://mail.openjdk.java.net/mailman/listinfo/jdk9-dev



http://hg.openjdk.java.net/jdk9/dev/

http://mail.openjdk.java.net/pipermail/adoption-discuss/



https://wiki.openjdk.java.net/display/quality/Quality+Outreach/

http://openjdk.java.net/jeps/0


Capsule summary of modularity impact in JDK 9

• Modules bundle together one or more packages and can offer stronger encapsulation than jars

• Supporting changes throughout the platform:

• module-info.java files to declare dependencies between modules

• Changes to javac command line to find types in modules as well as in jars

• Corresponding updates to java command line and runtime

• New reflective APIs to model modules (core reflection, javax.lang.model, etc.)

8


• Prepare for JDK 9 [CON2937] Monday, Sep 19, 12:30 pm – 1:30 pm Tuesday, Sep 20, 2:30 pm – 3:30 pm

• Introduction to Modular Development [CON3707], Monday, Sep 19, 2:30 pm – 3:30 pm Wednesday, Sep 21, 3:00 pm – 4:00 pm

• Advanced Modular Development [CON3711], Monday, Sep 19, 5:30 pm – 6:30 pm Wednesday, Sep 21, 4:30 pm – 5:30 pm

• Project Jigsaw: Under the Hood [CON2963], Tuesday, Sep 20, 4:00 pm – 5:00 pm

• Modules and Services [CON2949], Tuesday, Sep 20, 11:00 am – 12:00 pm Thursday, Sep 22, 2:30 pm – 3:30 pm

• Project Jigsaw Hack Session [TUT4210], Wednesday, Sep 21, 8:30 am – 10:30 am

9

Jigsaw Team JavaOne 2016 Modularity Sessions & Tutorial

https://oracle.rainfocus.com/scripts/catalog/oow16.jsp?event=javaone&search=CON2937&search.event=javaone





https://oracle.rainfocus.com/scripts/catalog/oow16.jsp?event=javaone&search=TUT4210&search.event=javaone


Outline

• Stewardship and platform evolution

• Tooling improvements

• Language changes

• Library updates

• Q & A

10


Outline




• Library updates

• Q & A

10

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

0 20 40 60 80 100 120 140

JDK 8 cumulative

JDK 9 cumulative

Difference (9-8)

Cumulative Bugs fixes by build in JDK 8 and 9

JDK 9 b134

JDK 8 GA


Outline




• Library updates

• Q & A

10

Many feature cross these boundaries


Stewardship 11


Background: JDK General Evolution Policy

“The general evolution policy for Java SE APIs implemented in OpenJDK is:

1. Don’t break binary compatibility (as defined in the Java Language Specification).

2. Avoid introducing source incompatibilities.

3. Manage behavioral compatibility changes.”

• Extends to language evolution too

• Continue to recognize old class files

• Limit cases where currently legal code stops compiling

• Avoid changes in code generation introducing behavioral change

12

From the OpenJDK Developers’ Guide

http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html




Release Compatibility Regions

Behavioral

Bin

ary



Behavioral

Bin

ary

Security Update Releases (CPU), 8u75, 8u81, 8u85, …

Note: Figure not drawn to scale.



Behavioral

Bin

ary

Security Update Releases (CPU), 8u75, 8u81, 8u85, …

Feature Update Releases (PSU), 8u20, 8u40, …



Platform Release Compatibility Region

Behavioral

Bin

ary


Platform Release Compatibility Region

Behavioral

Bin

ary

Platform Release, JDK 8 GA, JDK 9 GA



Example: changing the iteration order of HashSet

• Specification of HashSet.iterator() : “Returns an iterator over the elements in this set. The elements are returned in no particular order.”

• Changing iteration order is allowed by the specification and:

• Binary compatible (same set of methods)

• Source compatible (same set of methods)

• But a change in behavioral compatibility change; people can and do implicitly rely on iteration order

• Therefore, this kind of change generally wouldn’t be made in either kind of update release, but would be (and has been) made in a platform release.

15

http://download.java.net/java/jdk9/docs/api/java/util/HashSet.html

http://download.java.net/java/jdk9/docs/api/java/util/HashSet.html


Check the release notes and compatibility guides

• Use source, binary, behavioral categorization

• Compatibility guides distinguish between

• Java SE incompatibilities

• JDK incompatibilities

• JDK 8 Compatibility Guide discusses changing the order of methods returned by Class.getMethods()

• (JDK 9 guide expected later in the release)

• See also: The Science and Art of Backward Compatibility [CON5773], Ian Robertson, Tuesday, Sep 20, 12:30 pm – 1:30 pm

16

http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html

https://oracle.rainfocus.com/scripts/catalog/oow16.jsp?event=javaone&search=con5773&search.event=javaone


How is JDK 9 different?

• Same general model, but to support adding modularity, larger compatibility impact than usual allowed, including behavioral incompatibilities

• Certain build artifacts going away; no more rt.jar!

• Driven by modularity, even breaking binary compatibility in very select cases by removing ill-placed APIs including:

• Break unfortunate dependencies on Java Beans, part of the java.desktop module: • java.util.logging.LogManager.{add, remove}PropertyChangeListener

• java.util.jar.Pack200.Packer/Unpacker.{add, remove}PropertyChangeListener

• Also: java.awt.Component.getPeer removed since it referred to ComponentPeer types outside of Java SE

• More muscular deprecation policy with better tools to manage and inform

17


Outline




• Library updates

• Q & A

18


jshell

19


A historical perspective on REPL

• Lisp systems decades back provided a read-evaluate-print-loop (REPL) to interact with the language

• Similar functionality is found in Ruby and Python as well as Scala, Groovy, and Clojure

• What about Java?

20


jshell – new command in $JDK/bin in JDK 9

21

OpenJDK Project Kulla/JEP 222: jshell: The Java Shell (Read-Eval-Print Loop)


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












jshell – new command in $JDK/bin in JDK 9

• Teaser Demo

• Less ceremony for students learning Java

• Less formal way for experienced developers to

• Explore using a new API

• Experiment with new language features

• Leverages many existing JDK technologies

• For more information see: JShell: An Interactive Shell for the Java Platform [CON7643], Robert Field, Wednesday, Sep 21, 10:00 am – 11:00 am

21

OpenJDK Project Kulla/JEP 222: jshell: The Java Shell (Read-Eval-Print Loop)














JavaDoc.Next http://openjdk.java.net/projects/javadoc-next/

22


HTML 5

• The javadoc tool has historically generated HTML 4.01 output

• HTML 5 is a new HTML standard, finalized October 2014

• Richer semantic structure

• New attributes defined

• Use javadoc -html5 … to opt-into the new output

• (Still uses frames-style layout)

23

JEP 224: HTML5 Javadoc

HTM

L 5

logo

fro

m w

ww

.w3

.org

/htm

l/lo

go/i

nd

ex.h

tml




Configuring doclint

• Doclint checks can be run as part of javadoc or as part of javac; (both used in JDK build)

• HTML checks are appropriate for chosen version of HTML output

• Checks can be limited to chosen language accessibility (public, protected, …)

• Checks can be enabled / disabled per category

• Example, for public and protected types, do all checks except for reference: -Xdoclint:all/protected,-reference

• Checks can be limited to selected packages (new in JDK 9):

• To check java.* and javax.*: '-Xdoclint/package:java.*,javax.*'

• To exclude example.com: '-Xdoclint/package:-example.com.*'

24


Doclint and package filtering

• Doclint, added in JDK 8, performs various structural and semantic checks on javadoc tags in various categories:

• Accessibility: conditions that may be flagged by an accessibility checker, such as obsolete attributes or headers out of sequence

• HTML: HTML conformance issues (vary with DOCTYPE), e.g. anchor already defined, bad start-end tag matching

• Missing: missing comment or missing tag within a comment (e.g. not all parameters have a @param tag)

• Reference: the target of an @see, @link, @throws, etc. is invalid

• Syntax: malformed HTML in comments

25


Simplified Doclet API

• Doclets are plugins to javadoc; standard doclet most commonly used

• Doclet APIs

• Don’t follow current best-practices for API design

• Uses an inaccurate and hard to evolve language model

• Replace old Doclet APIs with newer APIs with better functionality

• Use javax.lang.model API for language model

• Use DocTree API (com.sun.source.doctree)

• Simpler and more compact

26

JEP 221: Simplified Doclet API






javadoc search

• Demo!

• By default javadoc output now has a search box • Client-side implementation in JavaScript

• Indexes package names, type names, field names, module names

• Can include new tag to add other index items

27

JEP 225: Javadoc Search






Getting from one JDK release to another Multi-release jar files and javac --release

28


Cross-compiling with the --release flag

29


Cross-compiling to older releases

30

https://blogs.oracle.com/darcy/entry/how_to_cross_compile_for

• To use javac to compile to older release N, must set

• -source N

• -target N

• -bootclasspath jdkN/lib/rt.jar

https://blogs.oracle.com/darcy/entry/how_to_cross_compile_for


Policy on older releases: 1 + 3 back

• Started implementing in JDK 8

• In JDK 9, supported -source/-target values:

• 9 (the default)

• 8

• 7

• 6 (deprecated, warning issued when used)

• In JDK 10, supported -source/-target values: 10, 9, 8, 7 (deprecated)

31

JEP 182: Policy for Retiring javac -source and -target Options









Why the bootclasspath needs to be set

// JDK N public class Library { public void foo(double d) {…} } // JDK N+1 public class Library { public void foo(double d) {…} public void foo(int i) {…} }




public class Client { public static void main(String… args) { (new Library()).foo(1234); } }





If Client is compiled against JDK N+1 but run against JDK N:





If Client is compiled against JDK N+1 but run against JDK N: Exception in thread "main" java.lang.NoSuchMethodError: Library.foo(I)V at Client.main(Client.java:3)


An explicit warning as of JDK 7

• javac –cp … -source 6 -target 6 Client.java warning: [options] bootstrap class path not set in conjunction with -source 1.6

• The warning can be suppressed with -Xlint:-options

33

https://blogs.oracle.com/darcy/entry/bootclasspath_older_source



An explicit warning as of JDK 7

• javac –cp … -source 6 -target 6 Client.java warning: [options] bootstrap class path not set in conjunction with -source 1.6

• The warning can be suppressed with -Xlint:-options

• But despite the warning, bugs still came in…

33




JDK 9’s do-what-I-want approach: --release N

• javac --release N … is semantically equivalent to javac -source N -target N –bootclasspath rtN.jar…

• Information about APIs of earlier releases available to javac • Stored in a compressed fashion

• Only provide Java SE N and JDK N-exported APIs that are platform neutral

• Same set of release values N as for -source / -target

• Incompatible combinations of options rejected

34

JEP 247: Compile for Older Platform Versions



Advantages of --release N

• No user need to manage artifacts storing old API information

• Should remove need to use tools like the Maven plugin Animal Sniffer

• May use newer compilation idioms than the javac in older releases • Bug fixes

• Speed improvements

35

http://www.mojohaus.org/animal-sniffer/


Multi-release jar files JEP 238

36



Issues distributing a jar file for multiple JDK releases

• Inconvenient to package and distribute multiple jar files for an API, one for JDK N, another for JDK N+1, etc.

• Instead use a single jar file to run against multiple JDK releases, so compile for the oldest release supported

• Slows adoption of new features

• Able to use reflection in some circumstances, but slow and awkward

• Modularity features of JDK 9 make some shouldn’t-be-used JDK APIs harder to access (don’t use sun.* APIs!)

37


An alternative: multi-release jar files

• Common/shared contents of the jar are put in the root as usual

• JDK-platform specific overrides are put in the META-INF directory in subdirs, e.g. META-INF/versions/9, META-INF/versions/10, etc.

• Created using additional arguments to the jar command

• java.util.jar.JarFile and consumers of jar files (java, javac, …) updated to be multi-release aware

38


Outline




• Library updates

• Q & A

39


JEP 213

Milling Project Coin in JDK 9

Ph

oto

co

pyr

igh

t 2

01

1 J

ose

ph

D. D

arcy

. All

righ

ts r

eser

ved

.



Project Coin features in JDK 7

• Binary literals and underscores in literals

• Strings in switch

• Diamond

• Multi-catch and more precise rethrow

• try-with-resources

• Varargs warnings

41

Standardized under JSR 334

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

https://jcp.org/en/jsr/detail?id=334


A few small amendments in JDK 9

• Allow @SafeVargs on private instance methods.

• Allow effectively-final variables to be used as resources in the try-with-resources statement.

• Allow diamond with anonymous classes if all type arguments of the inferred types are denotable.

• Complete the removal, begun in Java SE 8, of underscore from the set of legal identifier names.

• Source-level private interface methods.

42

Project Lambda amendments


@SafeVarargs on private instance methods

43


Example from JDK 5.0 and 6

List<List<String>> monthsInTwoLanguages =

Arrays.asList(Arrays.asList("January", "February"),

Arrays.asList("Gennaio", "Febbraio"));

44

See JLSv3 §4.12.2.1 – Heap Pollution






44


warning: [unchecked] unchecked generic array creation for varargs parameter of type List<String>[] Arrays.asList(Arrays.asList("January", ^






44


warning: [unchecked] unchecked generic array creation for varargs parameter of type List<String>[] Arrays.asList(Arrays.asList("January", ^

But nothing bad actually happens in this case, so the error is uninformative.


Reminder: @SafeVarargs from Project Coin

• New annotation type java.lang.SafeVarargs and application to libs

• Summary: no longer receive uninformative unchecked compiler 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)

• Removes warnings from method call sites

45


Annotation Properties

• Annotations are only inherited on classes, not on interfaces or methods

• Therefore, a @SafeVarargs annotation can only be used on methods that cannot be overridden:

• final methods

• static methods

• Constructors (from a certain point of view, special static methods)

• private methods (omitted in JDK 7)

46


Language Specification updates

• JLS §9.6.4.7. @SafeVarargs It is a compile-time error if a variable arity method declaration that is neither static nor final is annotated with the annotation @SafeVarargs.

47


Language Specification updates

• JLS §9.6.4.7. @SafeVarargs It is a compile-time error if a variable arity method declaration that is neither static nor final is annotated with the annotation @SafeVarargs.

47

nor private


Effectively final variables & try-with-resources

48


Refresher: try-with-resources You type this:

try (Resource r = aa()) { bb(r); } catch (Exception e) { cc(); } finally { dd(); }




Compiler generates (approximately) this:

try { Resource r = null; try { r = aa(); bb(r); } finally { if (r != null) r.close(); } } catch (Exception e) { cc(); } finally { dd(); }

⇒




Compiler generates (approximately) this:

try { Resource r = null; try { r = aa(); bb(r); } finally { if (r != null) r.close(); } } catch (Exception e) { cc(); } finally { dd(); }

It’s actually more complicated because of the way exceptions from close() are handled.

⇒


try ResourceSpecification Block

Full disclosure: try-with-resources actual desugaring


try ResourceSpecification Block

{ final VariableModifiers_minus_final R #resource = Expression; Throwable #primaryException = null; try ResourceSpecificationtail 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(); } } } }

⇒

Full disclosure: try-with-resources actual desugaring


Structure of the resources to be managed

• In Java SE 7, the resources to be managed by a try-with-resources statement must be fresh variables declared in the statement: try (Resource r = …)

• The original proposal allowed general expressions that were AutoCloseable, but this was found to be problematic for a variety of reasons such as: Resource r = new Resource1(); // First resource object try (r) { r = new Resource2(); // Second resource object } // Which object(s) should have a close method called?

51


Refined proposal: reuse final or effectively final resources

• Instead of general expressions, just allows variables that are either:

• final or

• effectively final

to be used as resources.

• Effectively final variables are not explicitly declared as final, but could be and still have the program compile, see JLS §4.12.4.

• Variables have an explicit type, avoiding the need for type inference.

52

https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html




Example

Instead of final Resource r = new Resource(); try (Resource r2 = r) { … }

53


Example

Instead of final Resource r = new Resource(); try (Resource r2 = r) { … }

can just use final Resource r = new Resource(); try (r) { … // Cannot mutate r }

53


Grammar of the specification change, JLS §14.20.3

Resource:

{VariableModifier} UnannType VariableDeclaratorId = Expression

54





Grammar of the specification change, JLS §14.20.3

Resource:

{VariableModifier} UnannType VariableDeclaratorId = Expression

VariableAccess

VariableAccess:

ExpressionName

FieldAccess

54





Core of the semantics of the specification change

An operand to try-with-resources statement may be a VariableAccess expression, which is an expression name (6.5.6) or a field access expression (15.11). The name or expression must denote a final or effectively final variable of type AutoCloseable which is definitely assigned before the try-with-resources statement; otherwise, a compile-time error occurs.

55


Core of the semantics of the specification change

An operand to try-with-resources statement may be a VariableAccess expression, which is an expression name (6.5.6) or a field access expression (15.11). The name or expression must denote a final or effectively final variable of type AutoCloseable which is definitely assigned before the try-with-resources statement; otherwise, a compile-time error occurs.

(Besides a direct construct like a local variable or method parameter, a resource to be managed could be a final field in an object or a final static field of a nested class, including a construct like (new Foo()).finalResourceField).

55


Diamond with anonymous classes, take two

56


Diamond and anonymous classes, review

Object o; List<?> arg = ...; o = new Box<>(arg);

public class Box<T> { private T value; public Box(T value) { this.value = value; } T getValue() { return value; } }


Diamond and anonymous classes, review

Object o; List<?> arg = ...; o = new Box<>(arg);

public class Box<T> { private T value; public Box(T value) { this.value = value; } T getValue() { return value; } }

The compiler needs to infer the type to use for Box. The language is still statically typed even though it is not always explicitly typed.


Inside the compiler…

Object o; List<?> arg = ...; o = new Box< >(arg);



Object o; List<?> arg = ...; o = new Box< List<capture of ?> >(arg);



Object o; List<?> arg = ...; o = new Box<

Capture conversion; results in a non-denotable type (For details see JLS §5.1.10)

List<capture of ?> >(arg);





A Box can be subclassed, including anonymously

Object o; List<?> arg = ...; o = new Box<List<capture of ?>>(arg){…}; List<capture of ?>


Class file expressed as lower-level source code

Object o; List<?> arg = ...; o = new Box$1(arg);

class Box$1 extends Box<List<capture of ?> >{…}



Anonymous classes translate into a new class file with a full set of attributes.





Anonymous classes translate into a new class file with a full set of attributes.



Type info needs to be stored in a Signature attribute (JVMS §4.7.9)

https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html




Language feature interactions over time



Inner classes, JDK 1.1




Generics, JDK 5.0




Generics, JDK 5.0

Diamond, JDK 7




Generics, JDK 5.0

Diamond, JDK 7 “Today’s problems come

from yesterday’s solutions.” –Brian Goetz via Peter Senge via …

JDK 7 Result: Cannot use diamond with anonymous classes in any circumstances.


A forward-looking statement from the JSR 334 Expert Group

“Internally, a Java compiler operates over a richer set of types than those that can be written down explicitly in a Java program. The compiler-internal types which cannot be written in a Java program are called non-denotable types. Non-denotable types can occur as the result of the inference used by diamond. Therefore, using diamond with anonymous inner classes is not supported since doing so in general would require extensions to the class file signature attribute to represent non-denotable types, a de facto JVM change. It is feasible that future platform versions could allow use of diamond when creating an anonymous inner class as long as the inferred type was denotable.”

JSR 334 Proposed Final Draft, June 2011

http://jcp.org/aboutJava/communityprocess/pfd/jsr334/index.html


Java SE 9 allows use of diamond when creating an anonymous inner class as long as the inferred type is denotable. (JDK-8073593)

63

https://bugs.openjdk.java.net/browse/JDK-8073593




Partial specification updates: JLS §15.9.3 Choosing the Constructor and its Arguments

It is a compile-time error if the superclass or superinterface type of the anonymous class, T, or any subexpression of T, has one of the following forms:

• A type variable (4.4) that was not declared as a type parameter (such as a type variable produced by capture conversion (5.1.10))

• An intersection type (4.9)

• A class or interface type, where the class or interface declaration is not accessible from the class or interface in which the expression appears.

The term “subexpression” includes type arguments of parameterized types (4.5), bounds of wildcards (4.5.1), and element types of array types (10.1). It excludes bounds of type variables.

64


Partial specification updates: JLS §15.9.5 Anonymous Class Declarations

The superclass or superinterface type is given by the class instance creation expression (15.9.1); if this type is generic and its type arguments are elided using '<>', the type arguments are inferred while choosing a constructor (15.9.3). If the class instance creation expression elides the supertype's type arguments using '<>', then for all non-private methods declared in the class body, it is as if the method declaration is annotated with @Override (9.6.4.4). [Note:] When the diamond form is used, the inferred type arguments may not be as anticipated by the programmer. Consequently, the supertype of the anonymous class may not be as anticipated, and methods declared in the anonymous class may not override supertype methods as intended. Treating such methods as if annotated with @Override (if they are not actually annotated with @Override) helps avoid silently incorrect programs.

65


Effectiveness of recutting diamond

• In JDK 7, diamond could eliminate explicit type arguments at ≈90% of constructor call sites

• Diamond with anonymous classes should allow removal of a large fraction of the remaining 10%.

• JDK code base updated to use this feature, hundreds of call sites (JDK-8078467)

• Main beneficiaries were uses of java.security.PrivilegedAction

66





An underscore is no longer an identifier name JDK-8061549: Disallow ‘—‘ as a one-character identifier

67









Starting in Java SE 8

• Part of Project Lambda / JSR 335

• Cannot use ‘_’ as an identifier for a lambda parameter; avoid confusion with “wunderbar” from other languages

• If used elsewhere legal, but generates a warning; from javac: warning: '_' used as an identifier (use of '_' as an identifier might not be supported in releases after Java SE 8)

• Only a single underscore as an identifier generates a warning, use as a separator inside a longer identifier is fine

68

Discussed in http://mail.openjdk.java.net/pipermail/lambda-dev/2013-July/010661.html

http://mail.openjdk.java.net/pipermail/lambda-dev/2013-July/010661.html






Future possibilities

• Partial diamond: new Foo<String, _>();

• Partial witnesses: foo.<String, _>bar()

• “Don’t care” parameter names, suppress “var not used” warnings

• …

69

Syntactic name reclamation


private interface methods

70


Background: default methods

• Starting in Java SE 8, as part of Project Lambda interfaces can have default methods.

• Default methods are non-abstract and thus have a method body.

• At the JVM level, interfaces could have private methods; helpful to implement lambdas, etc.

• However, private interface methods were not valid in the source language.

71


Now in Java SE 9...

• As planned, now in Java SE 9 interfaces can have private methods in the source level too:

• static methods

• instance methods

• Sample usage: helper methods to implement default methods

72

JDK-8071453: Allow interface methods to be private





Deprecation and imports JEP 211: Elide Deprecation Warnings on Import Statements

73


Copyright © 2016, Oracle and/or its affiliates. All rights reserved. Oracle Confidential 74

Background: warnings, warnings, everywhere

0

2000

4000

6000

8000

10000

12000

8-b

01

8-b

05

8-b

09

8-b

13

8-b

17

8-b

21

8-b

25

8-b

29

8-b

33

8-b

37

8-b

41

8-b

45

8-b

49

8-b

53

8-b

57

8-b

61

8-b

65

8-b

69

8-b

73

8-b

77

8-b

81

8-b

85

8-b

89

8-b

93

8-b

97

8-b

10

1

8-b

10

5

8-b

10

9

8-b

11

3

8-b

11

7

8-b

12

1

8-b

12

5

8-b

12

9

9-b

01

9-b

05

default

static

cast

serial

unchecke

raw

deprecat



0

2000

4000

6000

8000

10000

12000

8-b

01

8-b

05

8-b

09

8-b

13

8-b

17

8-b

21

8-b

25

8-b

29

8-b

33

8-b

37

8-b

41

8-b

45

8-b

49

8-b

53

8-b

57

8-b

61

8-b

65

8-b

69

8-b

73

8-b

77

8-b

81

8-b

85

8-b

89

8-b

93

8-b

97

8-b

10

1

8-b

10

5

8-b

10

9

8-b

11

3

8-b

11

7

8-b

12

1

8-b

12

5

8-b

12

9

9-b

01

9-b

05

default

static

cast

serial

unchecke

raw

deprecat

Lint warnings “fix-it” day Warnings

Clean up day

A productive summer intern



0

2000

4000

6000

8000

10000

12000

8-b

01

8-b

05

8-b

09

8-b

13

8-b

17

8-b

21

8-b

25

8-b

29

8-b

33

8-b

37

8-b

41

8-b

45

8-b

49

8-b

53

8-b

57

8-b

61

8-b

65

8-b

69

8-b

73

8-b

77

8-b

81

8-b

85

8-b

89

8-b

93

8-b

97

8-b

10

1

8-b

10

5

8-b

10

9

8-b

11

3

8-b

11

7

8-b

12

1

8-b

12

5

8-b

12

9

9-b

01

9-b

05

default

static

cast

serial

unchecke

raw

deprecat

Lint warnings “fix-it” day Warnings

Clean up day

A productive summer intern

Lint warnings enabled in build


Number of javac lint warnings in JDK 9 jdk repo today

Oracle Confidential 75




Covers all of the following:

• Open code

• Closed code

• Platform-specific code

• Generated code

• -Xlint:all –Werror in the build





• Open code

• Closed code


• Generated code


Warnings-free modules include:

• java.base: packages java.lang, java.util, java.math, ….

• java.desktop: packages java.awt, javax.swing, …

• java.compiler: packages javax.lang.model, …





• Open code

• Closed code


• Generated code


Warnings-free modules include:

• java.base: packages java.lang, java.util, java.math, ….

• java.desktop: packages java.awt, javax.swing, …

• java.compiler: packages javax.lang.model, …

†corba, jaxp, jax-ws, not included

†


Technical dividends of going warnings free

• Did you declare a serialVersionUID in your exception type? (All exceptions are serializable; thanks RMI!)

• Did you override equals and hashCode correctly? (Nuanced and accurate check.)

• Is that fallthrough in a switch intentional? (Possible security issue; c.f. “goto fail; goto fail;”)

• Is it really acceptable to have a new use of that deprecated item?

• “Advice on removing javac lint warnings” https://blogs.oracle.com/darcy/entry/warnings_removal_advice


javac as the first-line static analysis tool

https://blogs.oracle.com/darcy/entry/warnings_removal_advice


Deprecation warnings

• Several hundred deprecation warnings in the JDK

• Generated by use of deprecated types, methods, constructors, fields

• Mandated by JLS §9.6.4.6 @Deprecated

• Can resolve warnings by:

• Removing use of the deprecated element(s)

• Propagating @Deprecated to the use-sites too (a cure worse than the disease!)

• @SuppressWarnings("deprecation")

77


import p.DepLib;

public class Client2 {

public static void main(String… args) {

DepLib dl = new DepLib();

dl.foo();

}

}

// DepLib.java

package p;

@Deprecated

public class DepLib {

public DepLib() {}

public void foo() {return;}

}

78

A wrinkle in Java SE 5.0 through 8


import p.DepLib;




dl.foo();

}

}

Note: Client2.java uses or overrides a deprecated API.

// DepLib.java

package p;

@Deprecated


public DepLib() {}


}

78



import p.DepLib;




dl.foo();

}

}

// DepLib.java

package p;

@Deprecated


public DepLib() {}


}

79



import p.DepLib;

@SuppressWarnings("deprecation")




dl.foo();

}

}

// DepLib.java

package p;

@Deprecated


public DepLib() {}


}

79



import p.DepLib;

@SuppressWarnings("deprecation")




dl.foo();

}

}

Note: Client2.java uses or overrides a deprecated API.

// DepLib.java

package p;

@Deprecated


public DepLib() {}


}

79



Deprecation warning in detail

Client2.java:1: warning: [deprecation] DepLib in p has been deprecated import p.DepLib; ^ 1 warning

• Warning on import mandated by the JLS

• Use of the type in this location cannot be annotated for suppression

• Warning is unhelpful; if all other uses of the deprecated type can be suppressed, shouldn’t have to resort to using its fully qualified name everywhere to be warning-free.

80

With javac -Xlint:deprecation …


Specification update: JLS §9.6.3.6 @Deprecated

A Java compiler must produce a deprecation warning when a type, method, field, or constructor whose declaration is annotated with the annotation @Deprecated is used (i.e. overridden, invoked, or referenced by name), unless:

• The use is within an entity that is itself annotated with the annotation @Deprecated; or

• The use is within an entity that is annotated to suppress the warning with the annotation @SuppressWarnings("deprecation"); or

• The use and declaration are both within the same outermost class.

81


Specification update: JLS §9.6.3.6 @Deprecated

A Java compiler must produce a deprecation warning when a type, method, field, or constructor whose declaration is annotated with the annotation @Deprecated is used (i.e. overridden, invoked, or referenced by name), unless:

• The use is within an entity that is itself annotated with the annotation @Deprecated; or

• The use is within an entity that is annotated to suppress the warning with the annotation @SuppressWarnings("deprecation"); or

• The use and declaration are both within the same outermost class.

• The use is within an import statement that imports the type or member whose declaration is annotated with @Deprecated.

81

; or


Result: now tractable to clear a code base of deprecation warnings.

82


More on deprecation: API Deprecation isn’t necessarily API depredation

83


What does deprecation mean?

• Don’t use it because it’s harmful?

• Don’t use it because it is going away?

• Why aren’t items deprecated years ago removed yet?

• …

84


More informative @Deprecated annotation in 9

• Clarified semantics and new information in the @Deprecated annotation:

• boolean forRemoval() (defaults to false)

• String since() (defaults to "")

• example: @Deprecated(since="9", forRemoval=true)

• @Deprecated annotations in core platform updated

• Supporting updates to JLS, javac, javadoc

• New static analysis tool: jdeprscan, analyzes class files and jar files for use of APIs deprecated in the JDK

85

JEP 277: Enhanced Deprecation



Lots more to say about deprecation

Get the full patient history and prognosis from Stuart Marks a.k.a. Dr. Deprecator (@DrDeprecator) at Enhanced Deprecation in Java 9 [CON3297] Wednesday, Sep 21, 1:00 pm – 2:00 pm

86



Outline




• Library updates

• Summary and Q & A

87


New Version-String Scheme

• Summary the “1.” in “1.9” is going away being replaced with $MAJOR.$MINOR.$SECURITY

• Full version strings can also have build numbers and optional information

• Old java version "1.8.0_101" Java(TM) SE Runtime Environment (build 1.8.0_101-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)

• New java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+135) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+135, mixed mode)

88

JEP 223



Process API Updates

• On java.lang.Process new methods to get the PID, direct children, and all descendents

• New java.lang.ProcessHandle interface for better control

89

JEP 102



Strings and string concatenation

• JEP 254: Compact Strings: replace String-internal char[] representation (16 bits/char) with a byte[] array plus encoding field

• Based on contents of string, either 1-byte per character or 2-bytes per character representation

• Transparent to users; same API with better memory density

• JEP 280: Indify String Concatenation: string concatenation is a common operation; javac compiles this down to StringBuilder calls. Call pattern may not be optimal for a given JVM implementation.

• New stable library entry point java.lang.invoke.StringConcatFactory

• Compilers use this facility; dynamically linked at runtime, optimized by JVM

90







Tiered attribution Re-engineering type inference in javac; JEP 215

91



// javac uses type inference for the <> public static void main(String argv[]) { C<String> c1 = new C<>(); }

class C<U> { U foo; C() {} C(C<U> o) { foo = o.foo; } C(U foo) { this.foo = foo;} }


// compilation time: 0m0.353s public static void main(String argv[]) { C<String> c2 = new C<>( new C<>()); }

But once we nest it... class C<U> { U foo; C() {} C(C<U> o) { foo = o.foo; } C(U foo) { this.foo = foo;} }


// compilation time: 0m0.364s public static void main(String argv[]) { C<String> c3 = new C<>( new C<>( new C<>())); }



// compilation time: 0m0.436s public static void main(String argv[]) { C<String> c4 = new C<>( new C<>( new C<>( new C<>()))); }



// compilation time: 0m0.510s public static void main(String argv[]) { C<String> c5 = new C<>( new C<>( new C<>( new C<>( new C<>())))); }



// compilation time: 0m0.645s public static void main(String argv[]) { C<String> c6 = new C<>( new C<>( new C<>( new C<>( new C<>( new C<>()))))); }



// compilation time: 0m0.899s public static void main(String argv[]) { C<String> c7 = new C<>( new C<>( new C<>( new C<>( new C<>( new C<>( new C<>())))))); }



// compilation time: 0m1.448s public static void main(String argv[]) { C<String> c8 = new C<>( new C<>( new C<>( new C<>( new C<>( new C<>( new C<>( new C<>()))))))); }



// compilation time: 25m20.590s public static void main(String argv[]) { C<String> c16 = new C<>( new C<>( new C<>( new C<>( ... new C<>( new C<>( new C<>()))))))))))))))); }



// compilation time: 0m49.278s void foo() { m(null, () -> m(null, () -> m(null, () -> m(null, () -> m(null, () -> m(null, () -> m(null, () -> m(null, () -> m(null, (Callable<String>)null))))))))); }

Also for lambdas... class Klass { static class A0 { } static class A1 { } static class A2 { } <Z extends A0> Z m(A0 t, Callable<Z> ct) { return null; } <Z extends A1> Z m(A1 t, Callable<Z> ct) { return null; } <Z extends A2> Z m(A2 t, Callable<Z> ct) { return null; } <Z> Z m(Object o, Callable<Z> co) { return null; } }


JDK 8 Compiler performance, linear time scale

0

400

800

1200

1600

2 4 6 8 10 12 14 16 18 20 22

Compilation time

javac 8

Diamond nesting level

Seconds

“I’m not slacking off. My code’s compiling.”

https://xkcd.com/303/






JDK 8 Compiler performance, log time scale

0.25

1

4

16

64

256

1024

4096

2 4 6 8 10 12 14 16 18 20 22

Compilation time

javac 8


Seconds

Note: log scale on y-axis


JDK 9 Compiler performance with tiered attribution

0.25

1

4

16

64

256

1024

4096

2 4 6 8 10 12 14 16 18 20 22

Compilation time

javac 8

javac 9

javac 9 -release 8


Seconds

Note: log scale on y-axis


Tiered Attribution results

• More efficient construction of constraints used in type inference

• Performance improvement, worst case dramatically improved

• Compatibility with existing attribution approach

• Opened the door to more optimizations and improvements

105


Security libraries and tooling overview

106


Security tools and libraries, three general categories

• Language and Runtime security controls

• APIs and Libraries for integrating security into your applications

• JSSE (SSL/TLS)

• JCE (crypto)

• PKI (Public Key Infrastructure)

• …

• Tools for managing security (keytool, jarsigner, etc.)

107


Security area goals and roadmap

• Provide out-of-the box secure defaults

• Restrict broken or weak cryptographic algorithms and protocols

• Ensure API and tool defaults are safe to use

• Provide sufficiently strong algorithms for every security function

• Incorporate new security standards & adhere to industry best practices

• Crypto Roadmap: http://java.com/cryptoroadmap

• Public document of Oracle’s upcoming restrictions and changes to security defaults; first published August 2016

108

http://java.com/cryptoroadmap


Highlights of security updates in 9

• More secure crypto defaults including increasing the key size for the RSA and DiffieHellman implementations from 1024 bits to 2048 bits

• Certificates with weak keys no longer accepted by default

• MD2 or MD5, RSA or DSA with key size < 1024, etc.

• System property to change configuration if really needed

• New crypto hash SHA-3 (JEP 287: SHA-3 Hash Algorithms)

• Better SecureRandom algorithm (JEP 273: DRBG-Based SecureRandom Implementations)

• Accelerated crypto operations on x64 and Sparc (JEP 246: Leverage CPU Instructions for GHASH and RSA)

109













For more security information…

• Making the JDK More Secure [CON2699], Sean Mullan, Monday, Sep 19, 11:00 am – 12:00 pm

• Bof: OpenJDK Security Group: Discussion and Q&A [BOF2637], Sean Mullan, Bradford Wetmore, & Jeffrey Nisewanger, Tuesday, Sep 20, 7:00 pm – 7:45 pm

110


https://oracle.rainfocus.com/scripts/catalog/oow16.jsp?event=javaone&search=BOF2637&search.event=javaone


Client libraries and FX

111


FX

• Modularity

• JavaFX is now modularized; strong encapsulation

• JEP 253: Public UI Control skins and more CSS APIs

• New APIs for previously non-public features

• Other improvements:

• High DPI: Linux support + API to query & control scaling

• JEP 283: Enable GTK 3 on Linux

• Updated GStreamer and WebKit

• Smaller enhancements + Bug fixes

112




Client libraries (awt, swing, imageio, etc.) summary

• Finished generification of the Swing and awt APIs!

• High-dpi screens across all operating systems; JEP 263

• HarfBuzz Font-Layout Engine, JEP 258

• Marlin Graphics Renderer, JEP 265, replacing both Pisces and Ductus

• TIFF support in imageio, JEP 262

• For more information:

• New and Noteworthy in the Java SE 9 Client [CON1469] Philip Race and Jim Graham, Monday, Sep 19, 11:00 am – 12:00 pm

• Meet the Oracle JavaFX and JDK Client Team [BOF1463] Kevin Rushforth and Philip Race, Monday, Sep 19, 7:00 pm – 7:45 pm

113






https://oracle.rainfocus.com/scripts/catalog/oow16.jsp?event=javaone&search=BOF1463&search.event=javaone


Miscellaneous library treats

114


Convenience Factory Methods for Collections

How many times have you written code like: Set<String> set = new HashSet<>(); set.add("a"); set.add("b"); set.add("c"); set = Collections.unmodifiableSet(set);

115

JEP 269



Convenience Factory Methods for Collections

How many times have you written code like: Set<String> set = new HashSet<>(); set.add("a"); set.add("b"); set.add("c"); set = Collections.unmodifiableSet(set);

or like Set<String> set = Collections.unmodifiableSet(new HashSet<>( Arrays.asList("a", "b", "c")));

115

JEP 269



No more!

• Can now write: Set<String> set = Set.of("a", "b", "c");

• New static factory methods named “of” on Set, List, and Map.

• Return unmodifiable collections.

• Randomized iteration for set and maps.

• For more information see Collections Refueled, Stuart Marks, [CON4341] Thu Sep 22 4:00 pm – 5:00 pm

116



New public static methods in java.util.Objects

• <T> T requireNonNullElse(T obj, T defaultObj)

• <T> T requireNonNullElseGet(T obj, Supplier<? extends T> supplier)

• int checkIndex(int index, int length)

• int checkFromToIndex(int fromIndex, int toIndex, int length)

• int checkFromIndexSize(int fromIndex, int size, int length)

117


Odds and ends

• Mathematical functions

• {Math, StrictMath}.fma() (fused-multiply accumulate)

• {Math, StrictMath}.{multiplyExact, floorDiv, floorMod}

• BigInteger.sqrt, BigDecimal.sqrt

• Lexicographical array comparison in java.util.Arrays (with intrinsics!)

• Timeouts added to java.util.concurrent.CompletableFuture

• java.lang.invoke.VarHandle on par with C++ atomics

118


Summary

119


JDK 9 Language, Tooling, and Library features

• Fundamental development changes coming with modularity

• Smaller improvements coming in other areas:

• Finish long-anticipated polishing of Projects Coin and Lambda

• Features to support long-term evolution and multi-release planning

• Features span language, tools, library, (and JVM)

• Large and small features cross language, tooling, library, (and JVM) areas

• Can follow developments in OpenJDK

• EA builds of JDK 9 available today for your evaluation

120


Q & A Slides: https://blogs.oracle.com/darcy/resource/JavaOne/J1_2016-jdk9-lang-tools-libs.pdf

JDK 9 EA builds: https://jdk9.java.net/ JDK 9 EA builds with latest Jigsaw: https://jdk9.java.net/jigsaw/

Follow-up questions: #JDK9LangToolsLibs

121

https://blogs.oracle.com/darcy/resource/JavaOne/J1_2016-jdk9-lang-tools-libs.pdf









https://jdk9.java.net/

https://jdk9.java.net/jigsaw/

https://twitter.com/search?f=tweets&q=

jdk 9 language, tooling, and library features · •prepare for jdk 9 [con2937] monday, sep 19,...

Documents