BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News A First Look at Java 10 Release Candidate 1

A First Look at Java 10 Release Candidate 1

Bookmarks

Scheduled for a GA release on March 20, 2018, Java 10 RC1 is now available for the Java community. This will be the first upgrade that will follow Oracle's new six-month release cycle. Earlier this month, the proposed final draft of Java 10 (18.3) (JEP 383) was published and recently entered into the final release candidate phase as per the proposed schedule.

As specified in the release candidate document, the specific goals are to:

  • Fix all P1 bugs that are new in JDK 10 and critical to the success of the release;
  • Decommit from fixing any P1 bugs that are not new in JDK 10 and are not critical to this release, but were previously targeted to this release; and
  • Explicitly defer any P1 bugs that are new in JDK 10 but are either not critical to this release or cannot, for good reason, be fixed in this release.

Any bugs categorized as P2 through P5 bugs will be addressed in future releases, regardless of their status in product code, tests, or documentation.

As reported by InfoQ last November, some of the new features of Java 10 have already been in development for some time. Developers can expect the following:

JEP-286: Local-Variable Type Inference

The most intriguing and anticipated feature in Java 10 is local-variable type inference that introduces the new reserved type name, var. It is now possible to write the following code:

    
var x = 10;
var y = 20;
var z = application.getSum(x,y);

public int getSum(int x,int y) {
    return x + y;
    }

var list = new ArrayList<String>();
list.add("Hello!");
list.add("World!");
    

var may only be used in:

  • local variables with initializers
  • for-loop indices
  • the local scope of a conditional loop.

var may not be used in parameter lists and as a return types. Therefore, the following code will not compile:

    
public int passByVar(var y) {
    return y;
    }

public var returnVar(int y) {
    return y;
    }
    

More code examples can be found on GitHub.

Based on the results of two surveys conducted by Oracle in early 2016, developers were in favor of a local-variable type inference mechanism. However, their main concern was over readability as discussed in the survey summary:

For example, code like the following strawman was offered by several commenters:

    
var x = y.getFoo()
    

as evidence of "see, its unreadable, you have no idea what 'x' is." The readability problem here, though, stems from the fact that 'x' is just a poorly chosen variable name. Having a manifest type might make up for the programmer's laziness, but it would be better to just choose a good variable name in the first place.

While every situation may be different, we believe that, with judicious use of this feature in well-written code, readability is actually *enhanced*. Consider a block of locals:

    
UserModelHandle userDB = broker.findUserDB();
List<User> users = db.getUsers();
Map<User,Address> addressesByUser = db.getAddresses();
    

What is the most important thing on each line, the variable *name*, the variable *type*, or the initializing expression? We claim it is the name that is most important -- because they describe the role of the variable *in the current program*. And the variables names are not so easy to visually pick out from the above code -- they're stuck in the middle of each line, and at a different place on each line.

Ideally, we'd like for the most important thing to be front-and-center in the reader's view. If we rewrite the above block with inferred types:

    
var userDB = broker.findUserDB();
var users = db.getUsers();
var addressesByUser = db.getAddresses();
    

the true intent of this code pops out much more readily; the variable names are (almost) front and center. The lack of manifest types is not an impediment, because we've chosen good variable names.

Improved Garbage Collection

JEP-304 introduces a new garbage collector interface. As reported by InfoQ:

It will be easier for vendors to produce JDK builds that contain, or exclude a specific GC algorithm. With new GC approaches such as Shenandoah, ZGC and Epsilon in development, then this makes sense. There are even efforts within the community to deprecate and even remove the Concurrent-Mark-Sweep collector (CMS) although at present there is no production-quality feasible replacement for it.

JEP-307 solves a problem with the G1 garbage collector that, as of Java 9, uses a single-threaded algorithm. InfoQ also stated:

This means that if G1 ever has to fall back to a full GC then a nasty performance shock awaits. The aim of JEP 307 is to parallelize the full GC algorithm so that in the unlikely event of a G1 Full GC then the same number of threads can be used as in the concurrent collections.

Features Removed

The utility, javah, has officially been removed. The motivation, as stated in JEP-313, explains:

The tool has been superseded by superior functionality in javac, added in JDK 8 (JDK-7150368). This functionality provides the ability to write native header files at the time that Java source code is compiled, thereby eliminating the need for a separate tool.

Focusing on the support provided by javac eliminates the need to upgrade javah to support recent new paradigms, such as API access via the Compiler API in javax.tools.*, or the new java.util.spi.ToolProvider SPI added in JDK 9.

Mandy Chung, principal member of the technical staff at Oracle, recently posted a proposal on OpenJDK to finally remove the Runtime.runFinalizersOnExit() and System.runFinalizersOnExit() methods for JDK 11 as they have been deprecated since Java 1.2. These methods have been deemed unsafe as calls to finalizers on live objects while other threads are concurrently manipulating those objects may result in erratic behavior or deadlock.

Details on all new features and ones that will be removed can be found on the release notes.

Resources

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Inferred local types will introduce type information embedded in variable names

    by Jørgen Ringen,

    Your message is awaiting moderation. Thank you for participating in the discussion.


    var list = new ArrayList<String>();
    list.add("Hello!");
    list.add("World!");


    This example perfectly illustrates my biggest concern with inferred local variables. Instead of naming the list something meaningful, like "messages", the type is now embedded in the name. This makes the code more verbose and less concise.

    Consider the following example:

    var people = findPeople();


    It's impossible to see if it's a set, list or map of people. My concern is that names like "peopleMap", "peopleList", etc will start showing up.

  • var is the worst thing added to Java ever

    by Michael McCutcheon,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    This is horrible. Hiding the types does NOT in any way make the code more readable or maintainable. It will take longer to hover the mouse over all of these 'vars' to see what the type is than it would to just read it in the code. Just imagine a class with 60 variables on it, all defined with 'var'. This completely destroys the clarity of the code. Now you have to look at the imports to see what classes are actually being referenced by the class. Lets say you're trying to find 3 variables out of the 60 that are List<Map>...you're going to have to hover over each of the 60 to find the three. This is beyond idiotic.

    Additionally, as others have suggested, now we're going to end up with convoluted-ass variable names to make up for the missing type information. And those variable names may not even suggest the correct type if they're misnamed.

    Whomever suggested this 'feature' should be fired, their computers thrown out, their desk burned to with fire and the earth where it stood salted.

  • Re: var is the worst thing added to Java ever

    by Fredy Sierra,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    "Just imagine a class with 60 variables on it, all defined with 'var'". ???

    That is not possible.

    I do not know if it was not clear to you.

    var may only be used in:

    - local variables with initializers
    - for-loop indices
    - the local scope of a conditional loop.

  • Re: var is the worst thing added to Java ever

    by Richard Richter,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Var may be misused even on local variables, but I'm personally looking forward to it. It's another tool, yet it does not change the language that much. I understand people who don't like it, but seeing people saying "Whomever suggested this 'feature' should be fired, their computers thrown out, their desk burned to with fire and the earth where it stood salted."... without really knowing what it is all about is just ridiculous. I'd rather work in dynamically typed language than with people with such judgements. :-)

  • Re: var is the worst thing added to Java ever

    by Michael McCutcheon,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thank you for the clarification...it's slightly less of an abomination than I originally thought. In that case, the guy should only be fired. :)

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT