Download link: http://jdk.java.net/10/ .

Changes that will appear in this release

• JEP 286 : Local-Variable Type Inference
  Local type inference with var . Ambiguous feature. Regularly causing buzz in the ezine.

  
  

   var list = new ArrayList<String>(); // infers ArrayList<String> var stream = list.stream(); // infers Stream<String> 

  
  
• JEP 296 : Consolidating the JDK source forest into a single repository
  Tidy repositories. The general public is usually not interested.
• JEP 304 : Garbage-Collector Interface
  Improve the isolation of the main source code from the GC by creating a good clean interface for the GC.
• JEP 307 : Parallel Full GC for G1
  Release Note: JEP 307: Parallel Full GC for G1 : “The G1 collector is designed to do without full GC, but when a parallel assembly cannot reclaim memory quickly enough, it returns to full GC. The old full GC implementation in G1 used the mark-sweep-compact single-threaded algorithm. After the implementation of JEP-307, full GC was parallelized and began to use the same number of parallel thread-workers as in young and mixed. ” (I remind you that young GC processes only regions of young / survivor, mixed - also old, full - all hip, young / tenured).
• JEP 310 : Application Class-Data Sharing
  In order to speed up the launch and reduce the amount of memory used, it is proposed to extend the existing feature called Class-Data Sharing (“CDS”) by packing classes into a common archive.
• JEP 312 : Thread-Local Handshakes
  Ability to perform callback on threads without making global safepoint for JVM. The feature allows you to cheaply stop single threads, not just “all or nothing”.
• JEP 313 : Remove the Native-Header Generation Tool (javah)
  The javah utility javah no longer needed, because the native headers can now do javac (starting with JDK8, in fact)
• JEP 314 : Additional Unicode Language Tag Extensions
  Support for new Unicode extensions: cu (currency type), fw (first day of week), rg (region override), tz (time zone).
• JEP 316 : Heap Allocation on Alternative Memory Devices
  HotSpot VM can now allocate hipp memory on other devices, for example, on NV-DIMM. Some operating systems are already able to allocate non-DRAM memory, placing it on a file system, for example, NTFS DAX and ext4 DAX . The -XX:AllocateHeapAt=<path> option is added -XX:AllocateHeapAt=<path> .
• JEP 317 : Experimental Java-Based JIT Compiler
  Graal , can be used as the main JIT compiler. This is done as an experiment, and can only be enabled on Linux / x64. "
• JEP 319 : Root Certificates
  The JDK has a cacerts keystroke , which is needed to store root certificates. But in OpenJDK, it is still empty. Therefore, nishtyaki type TLS in OpenJDK by default do not work. Now this cacerts will be correctly configured and filled, and the nishtyaki will start working. In addition, it will smooth the difference between OpenJDK and Oracle JDK.
• JEP 322 : Time-Based Release Versioning
  Feature releases will add new features. Update releases will only fix bugs.

Release plan

For JDK10, the plan looks like this :
(Details of all phases are explained in a separate document )

• 2017/12/14 First deceleration phase
• 2018/01/11 All Tests Run
• 2018/01/18 The second phase of deceleration
• 2018/02/08 First Release Candidate

--- you are here ---

• 2018/02/22 Final Release Candidate
• 2018/03/20 General Availability

But how ... Is there another carriage bugs?

There is a document about what requirements JDK 10 must meet in order to become a successful release candidate. The point of this phase of the process is to concentrate on fixing only those bugs that are absolutely critical to the success of the project. Next I will describe how these requirements look for the OpenJDK developers themselves.

Each bug has a priority, from P1 (for the most important bugs) and ending with P5 (for the least important). Specific criteria for choosing a priority depend on the specific project.

Formally, the list of requirements for RC looks like this:

• You need to fix all the P1 level bugs that appeared in JDK 10 and that are critical for a successful release release.
• You need to step back from fixing P1 bugs that were not added to JDK 10, which are not critical to a successful release of a release, but which were initially considered to be related to the release of JDK 10.
• Explicitly postponing all P1 bugs that relate to JDK 10, but are not critical, or which, for some very significant reason, cannot be fixed in this release.

Any P2-P5 level bugs should be postponed until the next release, regardless of whether they have already entered the product code, tests or documentation. Including, all fixes with noreg-doc and noreg-test tags should now be explicitly confirmed and have a P1 level.

There is no point in explicitly postponing unrepaired P2-P5 level bugs.

From now on, new assemblies will appear every week only when there is a need for it.

P1 level bugs

An updated list of bugs can be found here: http://j.mp/jdk-rc . If someone from the OpenJDK developers is responsible for a bug from this list, then he should do one of the following:

• Develop a fix for the bug and then ask for confirmation of the integration of this fix; or
• If the bug did not appear in JDK 10 (this information is in the “Affects Version” field), then you can either remove it from the list by simply clearing the “Affects Version” field, or enter tbd_feature there (if you only need to fix it in the major release), either enter there tbd_update (if the fix is ​​worth doing in any release), or enter there the number of a specific release; or
• If the bug appeared in JDK 10, but is not critical or cannot be repaired on time, then you can ask that this bug be explicitly postponed using the appropriate process that we previously checked during the slowdown phase of RDP-1 .

In any case, you should not change the prioritized bug just to remove it from the list. The priority of a bug should reflect the importance of fixing regardless of any particular release, and this practice has been maintained for many years of development by the JDK.

P2-P5 Level Bugs

Release Candidate contains only P1 level bugs. P2-P5 level bugs are not relevant for general release status, starting from the current moment and beyond. Regardless of which release they originally wanted to fix. Therefore, with the bugs P2-P5, it does not make sense to do something special. No need to postpone them (explicitly, using the appropriate procedure, or implicitly, by changing the "Fix Version" field). However, you can change the value of this field to tbd_feature or tbd_update , if this may be useful for future work.

Bugs P2-P5, which are aimed only at tests or documentation, will no longer be corrected.

Will we use the top ten when it comes out?

Probably yes. Regular releases are not experimental , they are full releases with at least six-month support from Oracle. Their difference from LTS is only in the period of support, which for LTS will be not less than 3 years. Presumably, releases will appear in March and September.

Mark Reinhold’s confirming slide from the FOSDEM'18 conference:

Minute advertising. Concerning all important JEPs, we will try to publish separate articles on Habré, in the blog JUG.ru Group . Some things we bring to the conference, for example, Christian Thalinger talks about Graal , and Volker Simonis talks about Application Class-Data Sharing . The video will be a few months after the conference, but if you go there live - you can talk directly with the developers of all these technologies.