How Project Amber Will Revolutionize Java

This is the editorial for the SitePoint Java Channel newsletter that we send out every other Friday. Subscribe here!

Earlier this week Brian Goetz, Java Language Architect at Oracle, officially announced Project Amber and I could not be more excited about it! It will continue what Java 8 began and make Java a much less verbose and even more fun language. Type inference, massively simplified data classes, pattern matching, ... all of this has been bubbling up in recent months but it is great to see it put on official tracks.

(While this might be new to Java, non-Java devs might scoff and look down on us with comments like, "we've been using that for ten years, now." Well, good for you but no reason to rain on our parade so stfu!)

Revolutionary Fighters

I'm sure you can't wait to see those improvements I promised, so let's do that first. Once we've explored them I will spend a few words on Project Amber and release date speculations.

(If you're interested to see how these proposals and value types might play together, have a look at What Future Java Might Look Like).

Local Variable Type Inference

Java has done type inference since Java 5 (for type witnesses in generic methods) and the mechanism was extended in Java 7 (diamond operator), 8 (lambda parameter types), and 9 (diamond on anonymous classes). Under Project Amber it is planned to be extended to type declarations of local (!) variables:

// now
URL url = new URL("...")
URLConnectoin conn = url.openConnection();
Reader reader = new BufferedReader(new InputStreamReader(conn.getInputStream()));

// maybe in the future
var url = new URL("...")
var conn = url.openConnection();
var reader = new BufferedReader(new InputStreamReader(conn.getInputStream()));

Here, the types of url, conn, and reader are perfectly obvious. As a consequence the compiler can infer them, making it unnecessary for us to specify them.

Note that type inference is not dynamic typing - it's still strong typing just with less typing (Brian's pun, presumably intended). The type information will still end up in the bytecode and IDEs will also be able to show them - it's just that we don't have to write it out anymore.

For more information, have a look at JEP 286.

Enhanced Enums

As it stands, enums can not be generic, meaning you can not give individual enum instances fields of specific types:

// now
public enum FavoriteNumber {

    INTEGER(42),
    FLOAT(3.14);

    // wouldn't it be nice if this were more specific than Number?
    public final Number favorite;

    FavoriteNumber(Number favorite) {
        this.favorite = favorite;
    }

}

Project Amber considers to let enums have type parameters:

// maybe in the future
public class FavoriteNumber<T extends Number> {

    INTEGER<Interger>(42),
    FLOAT<Float>(3.14);

    // wouldn't it be nice if this were more specific than Number?
    public final T favorite;

    FavoriteNumber(T favorite) {
        this.favorite = favorite;
    }

}

And the great thing is, the compiler will perform sharp type checking and know which generic types a specific enum instance has:

// maybe in the future
float favorite = FavoriteNumber.FLOAT.favorite;

For more information, have a look at JEP 301.

Lambda Leftovers

Continue reading %How Project Amber Will Revolutionize Java%

by Nicolai Parlog via SitePoint