Java 10 new features decryption __java

How to download JDK 10.

Users must first join the early user program before downloading JDK 10 beta

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

OpenJDK https://download.java.net/java/jdk10/archive/45/GPL/openjdk-10+45_linux-x64_bin.tar.gz

Oracle JDK https://download.java.net/java/jdk10/archive/45/BCL/jdk-10+45_linux-x64_bin.tar.gz

The main features of JDK 10 include:

A local variable type inference, which expands the type inference to local variables by enhancing the language attribute, in order to reduce the "ritual" associated with coding while maintaining a security commitment to the static type.

A clean garbage collector interface to improve the isolation effect between the garbage collector source code, which provides better modularity for internal garbage collection code in the HotSpot virtual machine, and also makes it easier to add new garbage collectors to HotSpot.

Parallel, complete G1 garbage collector, to improve the worst-case latency problem by implementing parallelism.

Enabling HotSpot to assign an object heap to a user-specified standby memory device (such as a NVDIMM memory module) also predicts that future systems may be using heterogeneous memory architectures.

Linux/x64 Java-enabled Just-in-time compilers on an experimental basis on the platform (https://www.infoworld.com/article/3187868/application-development/ oracles-java-on-java-experiment-picks-up-steam.html).

Consolidate multiple repositories of JDK into one, simplifying development. The current code base is decomposed into multiple libraries, which is prone to source code management issues.

Application data sharing to reduce space occupancy and startup time by sharing common class metadata across processes.

A thread-local handshake, which can also perform a callback to a thread without executing a global VM security point, while implementing a single-threaded stop callback.

The JDK provides a set of default certificates, and the CA program for open source Java SE is more appealing to developers.

New features

As with the previous JDK version, there are some key features for the upcoming JDK 10. These features can be grouped into two main categories: (1) Target release, (2) Recommended publication. The former indicates that some features have been scheduled to be published in JDK 10, and the latter type indicates that these features also require increased support and maturity. Once the condition allows, it can be upgraded to a target publishing state.

Target Publishing

There are currently two main features for JDK 10:

Local variable type inference, which deletes the lengthy, manual type information required for most object instantiations

The JDK library that consolidates source tree source trees, that is, the different JDK libraries will be merged into a single repository. Local Variable type inference

Strongly typed programming languages have many advantages, including discovering type errors at compile time, but they also introduce a large number of boilerplate code, especially when defining local variables. For example, when we want to instantiate an object, we are forced to provide an explicit type on the left side of the assignment and provide the implementation type on the right side of the assignment, as shown in the following fragment:

MyObject value = new MyObject ();
However, when this process repeats a large number of tasks, object instantiation can become frustrating and tedious. Many of the most popular strongly typed programming languages, such as C + +, C #, and go, provide a function of local variable type inference in the definition process (for example, C + + provides the Auto keyword, C # provides the VAR keyword). However, there is still a lack of such functionality in Java, which requires developers to explicitly declare the expected manifest type of the variable.

To address this problem, the Java Development Toolkit (JDK) Improvement recommendation (JEP) 286 presents a context-sensitive keyword var that allows local variables to be initialized in the following ways:

var value = new MyObject ();
var list = new ArrayList ();
However, when this process repeats a large number of tasks, object instantiation can become frustrating and tedious. Many of the most popular strongly typed programming languages, such as C + +, C #, and go, provide a function of local variable type inference in the definition process (for example, C + + provides the Auto keyword, C # provides the VAR keyword). However, there is still a lack of such functionality in Java, which requires developers to explicitly declare the expected manifest type of the variable.

To address this problem, the Java Development Toolkit (JDK) Improvement recommendation (JEP) 286 presents a context-sensitive keyword var that allows local variables to be initialized in the following ways:

var value = new MyObject ();
var list = new ArrayList ();
Because the VAR keyword is context sensitive, its use has the following rule definition:

Code using VAR as a variable, method, or package name will not be affected, and code using VAR as the class or interface name will be affected.

Similarly, type inference is constrained by the following methods:

Inferred types are limited to initialization of local variables, enhanced for loop indexes, and declarations in traditional for loops, which are not used in method forms, constructor forms, method return types, fields, capture forms, or any other type of variable declaration.

Given all the limitations and nuances, this feature will help ease a lot of tedious action in the application Java code created by developers and simplify the JDK code base. More information can be found in the official Jep 286 specification. Consolidated JDK Library

Currently, there are 8 different mercurial repositories for storing a large number of source code that contains JDK:

Root
Corba
Hotspot
Jaxp
Jaxws
Jdk
Langtools
Nashorn
Although too many repositories provide a clear separation of the various components that make up the JDK, managing multiple storage inventories is a major drawback.

The most important of these is that a single bug fix cannot be tracked by atoms in two different parts of the JDK. For example, if a bug fix requires changes to two parts of the system contained in the isolated repository, two commits must be submitted: one in each repository. This discontinuity can easily reduce the traceability and complexity of project and source control tools.

To address this issue, Jep 296 recommends merging all existing repositories into a single mercurial repository. A secondary effect of this consolidation is that this single mercurial repository is more easily mirrored (as a git repository) than the existing 8 repositories.

Although external developers have some resistance during this consolidation process, the JDK development team appears to be working to make this change part of JDK 10. For more information, see Jep 296, and propose to consolidate the JDK OpenJDK mercurial repository declaration published by Michael Redlich.

Recommended publication

In addition to the two target features, JDK 10 currently has three recommendations, of which two is primarily an upgrade of the JDK's garbage collector section, and the other focuses on upgrading the JDK's native threading capabilities.

1. Cleaning up the garbage collection interface

In the current JDK architecture, the components that make up the garbage collector (GC) implementation are dispersed across parts of the code base. Although these conventions are familiar to JDK developers who plan to use GC, for new developers, it is often confusing to have a specific GC source code, or to create a new GC. More importantly, with the advent of Java modules, we want to exclude unwanted GC during the build process, but the current crosscutting structure of the GC interface excludes this enhancement.

Jep 304 is designed to address this problem and recommends consolidating and cleaning GC interfaces to make it easier to implement new GC and better maintain existing GC. Upon completion of this recommendation, GC execution will be responsible for providing the following:

Heap,collectedheap of the child class

Barrier Set,barrierset, which implements various obstacles to the runtime

The realization of a collectorpolicy

Implementation of the Gcinterpretersupport, which implements various obstacles to the GC of the interpreter (using assembler instructions)

Implementation of the Gcc1support, which implements the various barriers to GC for the C1 compiler

Implementation of the Gcc2support, which implements the various barriers to GC for the C2 compiler

Initialization of the final GC-specific parameters

Set up Memoryservice, associated memory pools, memory managers, and more.

For more information about these changes, see the Jep 304 specification; For more information about the Java GC, see the Garbage Collector Foundation Guide provided by Oracle. G1 garbage collector Parallelization

With the release of JDK 9, the Garbage-first (G1) GC replaces the parallel collector as the default GC. To reduce the impact of garbage collection in JDK versions other than JDK 9, the G1 collector will be parallelization (to match the characteristics of the parallel collector). Although there is no information on the implementation details of this parallelization, more details about this change can be found in the Jep 307 specification.

For more information about GC implementations, see Oracle's G1 Guide and parallel Collector's Guide. Project Thread Local handshake

Currently, stopping a Java thread is a "whole or not" process that requires a safe point for a Java Virtual machine (JVM) to stop a thread. In order for a separate thread to stop, Jep 312 proposes to include the callback in the thread. This change is limited because it significantly increases the performance overhead of existing JVM functionality and changes the existing time semantics that reach the JVM's global security point. For more information on this proposal, see the Thread-local handshake openjdk discussion at Jep 312.

Conclusion

Although JDK 9 is new to many Java developers, its development has not stopped. In particular, JDK 10 promises to introduce a type inference mechanism for local variable instantiation and merge existing JDK repositories into a single mercurial repository.

In addition, in a more mature and supportive scenario, JDK 10 may also include important upgrades to the GC interface and default GC implementations, as well as the addressable ability to upgrade to a single thread in the JVM. Although the release of JDK 10 is still relatively distant in the future, the included features are likely to become an important milestone on the Java timeline.

Reprint Link http://codebay.cn/post/6349.html