When will JDK 10 be released?
JDK 10 is a partial implementation of Java 10 Standard Edition and will be released on March 20, 2018. Key improvements include a native type inference, a garbage collected "clean" interface. Oracle has set a six-month release schedule for Java. It was originally intended to name upgrades and subsequent releases based on the year and month of release, so that the first release would be called Java 18.3, but this plan was later discontinued. How to download JDK 10? Users must join the Early Adopter Program before they can download the JDK 10 beta
How to download JDK 10?
Users must join the Early Adopter Program before they can download the JDK 10 beta
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
Key features of JDK 10 include:
A local variable type inference that extends type inference to local variables by enhancing language features, with the goal of reducing the "ceremony" associated with coding, while maintaining the promise of static type safety.
A clean garbage collector interface to improve isolation between garbage collector source code, which allows for better modularity for the internal garbage collection code in the HotSpot virtual machine, and makes it easier to add new features to HotSpot garbage collector.
Parallel, full G1 garbage collector that improves worst-case latency issues by enabling parallelism.
Enabling HotSpot to allocate object heaps to user-specified spare memory devices (such as NVDIMM memory modules) also indicates that future systems may adopt heterogeneous memory architectures.
Experimental enablement of Java-based just-in-time compilers on Linux/x64 platforms ( https://www.infoworld.com/article/3187868/application-development/oracles-java-on-java-experiment-picks-up- steam.html).
Simplifies development by combining multiple JDK repositories into one. The current code base is broken up into multiple libraries, which is prone to source code management issues.
Application data sharing reduces space occupation and startup time by sharing metadata of common classes across processes.
Thread-local handshake, callbacks to threads can be performed without implementing global VM safepoints, and single-thread stop callbacks are implemented.
The JDK provides a set of default certificates, the CA program of the open source Java SE, which is more attractive to developers.
new function
As with previous JDK releases, there are some major features for the upcoming JDK 10. These features can be grouped into two main categories: (1) target releases, (2) recommended releases. The former indicates that certain features are planned for release in JDK 10, and the latter indicates that these features still require increased support and maturity. Once conditions permit, it can be promoted to a target release state.
target release
There are currently two main features targeting JDK 10:
-
Local variable type inference, which removes the tedious inclusion of manual type information required for most object instantiations
-
Integrate the JDK libraries of the source tree, i.e. different JDK libraries will be merged into a single repository.
1. Local variable type inference
Strongly typed programming languages have many advantages, including finding type errors at compile time, but they also introduce a lot of boilerplate code, especially when defining local variables. For example, when we wish to instantiate an object, we are forced to provide the explicit type on the left side of the assignment and the implementation type on the right side of the assignment, as shown in the following snippet:
MyObject value = new MyObject();
However, object instantiation can become frustrating and tedious when the process is repetitive for a large number of tasks. Many of the most popular strongly typed programming languages, such as C++, C#, and Go, provide a type of local variable type inference function during the definition process (eg C++ provides the auto keyword, C# provides the var keyword). However, Java still lacks such a feature, which requires the developer to explicitly declare the expected manifest type of a variable.
To address this, Java Development Kit (JDK) Improvement Proposal (JEP) 286 proposes a context-sensitive keyword var that allows local variables to be initialized in the following ways:
var value = new MyObject();
var list = new ArrayList<MyObject>();
However, object instantiation can become frustrating and tedious when the process is repetitive for a large number of tasks. Many of the most popular strongly typed programming languages, such as C++, C#, and Go, provide a type of local variable type inference function during the definition process (eg C++ provides the auto keyword, C# provides the var keyword). However, Java still lacks such a feature, which requires the developer to explicitly declare the expected manifest type of a variable.
To address this, Java Development Kit (JDK) Improvement Proposal (JEP) 286 proposes a context-sensitive keyword var that allows local variables to be initialized in the following ways:
var value = new MyObject();
var list = new ArrayList<MyObject>();
Since the var keyword is context sensitive, its use is defined by the following rules:
Code that uses var as a variable, method, or package name will not be affected; code that uses var as a class or interface name will be affected.
Again, type inference will be constrained in the following way:
The inferred type will be restricted to initialization of local variables, enhanced for loop indexing, and declarations in traditional for loops; it (will) not be used in method forms, constructor forms, method return types, fields, capture forms, or any other variable declaration of type.
With all the limitations and nuances in mind, this feature will help relieve a lot of tedious action in the Java code of applications created by developers and simplify the JDK codebase. More information can be found in the official JEP 286 specification.
2. Integrated JDK library
Currently, there are 8 different Mercurial repositories for storing extensive source code containing the JDK:
root
corba
hotspot
jaxp
jaxws
JDK
langtools
nashorn
While a plethora of repositories provide clear separation of the various components that make up the JDK, managing multiple repositories has some major drawbacks.
The most important of these is that a single bug fix cannot be atomically tracked in two different parts of the JDK. For example, if a bug fix requires changes to two parts of the system contained in separate repositories, then two commits must be made: one in each repository. This discontinuity easily reduces the traceability and complexity of projects and source code management tools.
To address this, JEP 296 recommends merging all existing repositories into a single Mercurial repository. A secondary effect of this merging is that this single Mercurial repository is much easier to mirror (as a Git repository) than the existing 8 repositories.
While there has been some resistance from outside developers during this integration, the JDK development team appears to have committed to making this change part of JDK 10. See JEP 296 for more information, and proposes to incorporate the JDK 10 OpenJDK Mercurial repository announcement published by Michael Redlich.
Proposed release
In addition to the two target features, there are currently three proposals for JDK 10, two of which are mainly to upgrade the garbage collector part of the JDK, and the other focuses on the upgrade of the native threading function of the JDK.
1. Clean up the garbage collection interface
In the current JDK structure, the components that make up the garbage collector (GC) implementation are scattered across parts of the codebase. While these conventions are familiar to JDK developers using GC schedules, new developers are often confused about the source code for a particular GC, or creating a new GC. More importantly, with the advent of Java modules, we wanted to exclude unwanted GC from the build process, but the current cross-cutting structure of the GC interface precludes this enhancement.
JEP 304 was designed as a solution to this problem and proposes to consolidate and clean up the GC interface to make it easier to implement new GCs and better maintain existing ones. Upon completion of this proposal, the GC executive will be responsible for providing the following:
-
heap, a subclass of CollectedHeap
-
barrier set, a subclass of BarrierSet, which implements various barriers at runtime
-
An implementation of CollectorPolicy
-
An implementation of GCInterpreterSupport, which implements various barriers to the interpreter's GC (using assembly instructions)
-
An implementation of GCC1Support, which implements various obstacles to GC for the C1 compiler
-
An implementation of GCC2Support, which implements various obstacles to GC for the C2 compiler
-
Initialization of final GC specific parameters
-
Set up MemoryService, related memory pools, memory managers, etc.
See the JEP 304 specification for more information on these changes; see the Garbage Collector Fundamentals Guide provided by Oracle for more information on the Java GC.
2. G1 garbage collector parallelization
With the release of JDK 9, Garbage-First (G1) GC replaced 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 parallelized (to match the characteristics of parallel collectors). While there is currently no information on the implementation details of this parallelization, more details on this change can be found in the JEP 307 specification.
For more information on GC implementation, see Oracle's G1 Guide and Parallel Collector Guide.
3. Project thread local handshake
Currently, stopping a Java thread is an "all-or-nothing" process that requires a Java Virtual Machine (JVM) safepoint to stop a thread. To stop individual threads, JEP 312 proposes to include callbacks into threads. This change is limited because it significantly increases the performance overhead of existing JVM functions and changes the existing time semantics for reaching JVM global safepoints. See the Thread-Local Handshake OpenJDK discussion of JEP 312 for more information on this recommendation.
in conclusion
Although JDK 9 is very 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 to merge existing JDK repositories into a single Mercurial repository.
Additionally, in a more mature and supported case, JDK 10 may also include some significant upgrades to the GC interface and default GC implementation, as well as to the addressability of a single thread in the JVM. While the release of JDK 10 is still relatively far in the future, and the included features are likely to be a major milestone in the Java timeline.
Source: CodeBay : http://codebay.cn/post/6349.html
Contact
- Author: Peng Lei
- Source: http://www.ymq.io
- The copyright belongs to the author, please indicate the source when reprinting
- Wechat: Pay attention to the public account, search cloud library, focus on research and knowledge sharing of development technology