Java Platform, Standard Edition

Java Language Updates

Release 12

F13631-01

March 2019

Java Language Changes for Java SE 12

Java SE 12 introduces switch expressions, plus a new kind of case label that prevents fall through. These features are available as preview features.

Preview Features

A preview feature is a new feature whose design, specification, and implementation are complete, but which is not permanent, which means that the feature may exist in a different form or not at all in future JDK releases.

Introducing a feature as a preview feature in a mainline JDK release enables the largest developer audience possible to try the feature out in the real world and provide feedback. In addition, tool vendors are encouraged to build support for the feature before Java developers use it in production. Developer feedback helps determine whether the feature has any design mistakes, which includes hard technical errors (such as a flaw in the type system), soft usability problems (such as a surprising interaction with an older feature), or poor architectural choices (such as one that forecloses on directions for future features). Through this feedback, the feature's strengths and weaknesses are evaluated to determine if the feature has a long-term role in the Java SE Platform, and if so, whether it needs refinement. Consequently, the feature may be granted final and permanent status (with or without refinements), or undergo a further preview period (with or without refinements), or else be removed.

Every preview feature is described by a JDK Enhancement Proposal (JEP) that defines its scope and sketches its design. For example, JEP 325 describes the preview feature Switch Expressions. For background information about the role and lifecycle of preview features, see JEP 12.

Using Preview Features

To use preview language features in your programs, you must explicitly enable them in the compiler and the runtime system. If not, you'll receive an error message that states that your code is using a preview feature and preview features are disabled by default.

To compile source code with javac that uses preview features from JDK release n, use javac from JDK release n with the --enable-preview command-line option in conjunction with either the --release n or -source n command-line option.

For example, suppose you have an application named MyApp.java that uses the JDK 12 preview language feature switch expressions. Compile this with JDK 12 as follows:

javac --enable-preview --release 12 MyApp.java

Note:

When you compile an application that uses preview features, you'll receive a warning message similar to the following:

Note: MyApp.java uses preview language features.
Note: Recompile with -Xlint:preview for details

Remember that preview features are subject to change and are intended to provoke feedback.

To run an application that uses preview features from JDK release n, use java from JDK release n with the --enable-preview option. To continue the previous example, to run MyApp, run java from JDK 12 as follows:

java --enable-preview MyApp

Note:

Code that uses preview features from an older release of the Java SE Platform will not necessarily compile or run on a newer release.

The tools jshell and javadoc also support the --enable-preview command-line option.

Sending Feedback

You can provide feedback on preview features, or anything else about the Java SE Platform, as follows:

  • If you find any bugs, then submit them at Java Bug Database.
  • If you want to provide substantive feedback on the usability of a preview feature, then post it on the OpenJDK mailing list where the feature is being discussed. To find the mailing list of a particular feature, see the feature's JEP page and look for the label Discussion. For example, on the page JEP 325: Switch Expressions (Preview), you'll find "Discussion amber dash dev at openjdk dot java dot net" near the top of the page.
  • If you are working on an open source project, then see Quality Outreach on the OpenJDK Wiki.

Switch Expressions

Java SE 12 introduces switch expressions, which (like all expressions) evaluate to a single value, and can be used in statements. Java SE 12 also introduces a new kind of case label that eliminates the need for break statements to prevent fall through.

Note:

This is a preview feature, which is a feature whose design, specification, and implementation are complete, but which is not permanent, which means that the feature may exist in a different form or not at all in future JDK releases. To compile and run code that contains preview features, you must specify additional command-line options. See Preview Features. For background information about the design of switch expressions, see JEP 325.

Consider the following switch statement that prints the number of letters of a day of the week:

public enum Day { SUNDAY, MONDAY, TUESDAY,
    WEDNESDAY, THURSDAY, FRIDAY, SATURDAY; }

// ...

    int numLetters = 0;
    Day day = Day.WEDNESDAY;
    switch (day) {
        case MONDAY:
        case FRIDAY:
        case SUNDAY:
            numLetters = 6;
            break;
        case TUESDAY:
            numLetters = 7;
            break;
        case THURSDAY:
        case SATURDAY:
            numLetters = 8;
            break;
        case WEDNESDAY:
            numLetters = 9;
            break;
        default:
            throw new IllegalStateException("Invalid day: " + day);
    }
    System.out.println(numLetters);

It would be better if you could "return" the length of the day's name instead of storing it in the variable numLetters; you can do this with a switch expression. Furthermore, it would be better if you didn't need break statements to prevent fall through; they are laborious to write and easy to forget. You can do this with a new kind of case label. The following is a switch expression that uses the new kind of case label to print the number of letters of a day of the week:

    Day day = Day.WEDNESDAY;    
    System.out.println(
        switch (day) {
            case MONDAY, FRIDAY, SUNDAY -> 6;
            case TUESDAY                -> 7;
            case THURSDAY, SATURDAY     -> 8;
            case WEDNESDAY              -> 9;
            default -> throw new IllegalStateException("Invalid day: " + day);
        }
    );    

The new kind of case label has the following form:

case label_1, label_2, ..., label_n -> expression;|throw-statement;|block 

When the Java runtime matches any of the labels to the left of the arrow, it runs the code to the right of the arrow and does not fall through; it does not run any other code in the switch expression (or statement). If the code to the right of the arrow is an expression, then the value of that expression is the value of the switch expression.

You can use the new kind of case label in switch statements. The following is like the first example, except it uses "arrow case" labels instead of "colon case" labels:

    int numLetters = 0;
    Day day = Day.WEDNESDAY;
    switch (day) {
        case MONDAY, FRIDAY, SUNDAY -> numLetters = 6;
        case TUESDAY                -> numLetters = 7;
        case THURSDAY, SATURDAY     -> numLetters = 8;
        case WEDNESDAY              -> numLetters = 9;
        default -> throw new IllegalStateException("Invalid day: " + day);
    };
    System.out.println(numLetters);

You can use "colon case" labels in switch expressions:

    int numLetters = switch (day) {
        case MONDAY:
        case FRIDAY:
        case SUNDAY:
            System.out.println(6);
            break 6;
        case TUESDAY:
            System.out.println(7);
            break 7;
        case THURSDAY:
        case SATURDAY:
            System.out.println(8);
            break 8;
        case WEDNESDAY:
            System.out.println(9);
            break 9;
        default:
            throw new IllegalStateException("Invalid day: " + day);
    };

Java SE 12 expands the break statement to take an argument, which is the value that the case label produces in a switch expression.

Note:

It's recommended that you use "arrow case" labels. It's easy to forget to insert break statements when using "colon case" labels; if you do, you might introduce unintentional fall through in your code.

For "arrow case" labels, to specify multiple statements or code that's not an expression or throw statement, enclose them in a block. Specify the value that the case label produces with the break statement:

    int numLetters = switch (day) {
        case MONDAY, FRIDAY, SUNDAY -> {
            System.out.println(6);
            break 6;
        }
        case TUESDAY -> {
            System.out.println(7);
            break 7;
        }
        case THURSDAY, SATURDAY -> {
            System.out.println(8);
            break 8;
        }
        case WEDNESDAY -> {
            System.out.println(9);
            break 9;
        }
        default -> {
            throw new IllegalStateException("Invalid day: " + day);
        }
    };  

Java Language Changes for Java SE 11

Java SE 11 lets you declare formal parameters of implicitly typed lambda expressions with the var identifier; see Local Variable Type Inference.

Java Language Changes for Java SE 10

Java SE 10 introduces support for inferring the type of local variables from the context, which makes code more readable and reduces the amount of required boilerplate code.

Local Variable Type Inference

In JDK 10 and later, you can declare local variables with non-null initializers with the var identifier, which can help you write code that’s easier to read.

Consider the following example, which seems redundant and is hard to read:

URL url = new URL("http://www.oracle.com/"); 
URLConnection conn = url.openConnection(); 
Reader reader = new BufferedReader(
    new InputStreamReader(conn.getInputStream()));

You can rewrite this example by declaring the local variables with the var identifier. The type of the variables are inferred from the context:

var url = new URL("http://www.oracle.com/"); 
var conn = url.openConnection(); 
var reader = new BufferedReader(
    new InputStreamReader(conn.getInputStream()));

var is a reserved type name, not a keyword, which means that existing code that uses var as a variable, method, or package name is not affected. However, code that uses var as a class or interface name is affected and the class or interface needs to be renamed.

var can be used for the following types of variables:

  • Local variable declarations with initializers:

    var list = new ArrayList<String>();    // infers ArrayList<String>
    var stream = list.stream();            // infers Stream<String>
    var path = Paths.get(fileName);        // infers Path
    var bytes = Files.readAllBytes(path);  // infers bytes[]
    
  • Enhanced for-loop indexes:

    List<String> myList = Arrays.asList("a", "b", "c");
    for (var element : myList) {...}  // infers String
  • Index variables declared in traditional for loops:

    for (var counter = 0; counter < 10; counter++)  {...}   // infers int
  • try-with-resources variable:

    try (var input = 
         new FileInputStream("validation.txt")) {...}   // infers FileInputStream
    
  • Formal parameter declarations of implicitly typed lambda expressions: A lambda expression whose formal parameters have inferred types is implicitly typed:

    BiFunction<Integer, Integer, Integer> = (a, b) -> a + b;

    In JDK 11 and later, you can declare each formal parameter of an implicitly typed lambda expression with the var identifier:

    (var a, var b) -> a + b;

    As a result, the syntax of a formal parameter declaration in an implicitly typed lambda expression is consistent with the syntax of a local variable declaration; applying the var identifier to each formal parameter in an implicitly typed lambda expression has the same effect as not using var at all.

    You cannot mix inferred formal parameters and var-declared formal parameters in implicitly typed lambda expressions nor can you mix var-declared formal parameters and manifest types in explicitly typed lambda expressions. The following examples are not permitted:

    (var x, y) -> x.process(y)      // Cannot mix var and inferred formal parameters
                                    // in implicitly typed lambda expressions
    (var x, int y) -> x.process(y)  // Cannot mix var and manifest types
                                    // in explicitly typed lambda expressions

Local Variable Type Inference Style Guidelines

Local variable declarations can make code more readable by eliminating redundant information. However, it can also make code less readable by omitting useful information. Consequently, use this feature with judgment; no strict rule exists about when it should and shouldn't be used.

Local variable declarations don't exist in isolation; the surrounding code can affect or even overwhelm the effects of var declarations. Style Guidelines for Local Variable Type Inference in Java examines the impact that surrounding code has on var declarations, explains tradeoffs between explicit and implicit type declarations, and provides guidelines for the effective use of var declarations.

Java Language Changes for Java SE 9

The major change to Java Platform, Standard Edition (Java SE) 9 is the introduction of the Java Platform module system.

The Java Platform module system introduces a new kind of Java programing component, the module, which is a named, self-describing collection of code and data. Its code is organized as a set of packages containing types, i.e., Java classes and interfaces; its data includes resources and other kinds of static information. Modules can either export or encapsulate packages, and they express dependencies on other modules explicitly.

To learn more about the Java Platform module system, see Project Jigsaw on OpenJDK.

Apart from the new module system, a few changes have been made to the Java language. The rest of this guide describes those changes.

More Concise try-with-resources Statements

If you already have a resource as a final or effectively final variable, you can use that variable in a try-with-resources statement without declaring a new variable. An "effectively final" variable is one whose value is never changed after it is initialized.

For example, you declared these two resources:

        // A final resource
        final Resource resource1 = new Resource("resource1");
        // An effectively final resource
        Resource resource2 = new Resource("resource2");

In Java SE 7 or 8, you would declare new variables, like this:

        try (Resource r1 = resource1;
             Resource r2 = resource2) {
            ...
        }

In Java SE 9, you don’t need to declare r1 and r2:

// New and improved try-with-resources statement in Java SE 9
        try (resource1;
             resource2) {
            ...
        }

There is a more complete description of the try-with-resources statement in The Java Tutorials (Java SE 8 and earlier).

Small Language Changes in Java SE 9

There are several small language changes in Java SE 9.

@SafeVarargs annotation is allowed on private instance methods.

The @SafeVarargs annotation can be applied only to methods that cannot be overridden. These include static methods, final instance methods, and, new in Java SE 9, private instance methods.

You can use diamond syntax in conjunction with anonymous inner classes.

Types that can be written in a Java program, such as int or String, are called denotable types. The compiler-internal types that 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 the diamond operator. Because the inferred type using diamond with an anonymous class constructor could be outside of the set of types supported by the signature attribute in class files, using the diamond with anonymous classes was not allowed in Java SE 7.

In Java SE 9, as long as the inferred type is denotable, you can use the diamond operator when you create an anonymous inner class.

The underscore character is not a legal name.

If you use the underscore character ("_") an identifier, your source code can no longer be compiled.

Private interface methods are supported.

Private interface methods are supported. This support allows nonabstract methods of an interface to share code between them.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.


Java Platform, Standard Edition Java Language Updates, Release 12

F13631-01

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

Describes the updated language features in Java SE 9 and subsequent releases.

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.