What s new in Java 10

Get a quick overview of what's changed in J**A 10.

J**a, one of the most widely used programming languages today, released its tenth major version on March 21, 2018. In order to iterate faster and better follow up on community feedback, the release cycle of the j**a language version has been adjusted to be released every 6 months. J**A 10 is the first major release of the new release cycle after this new rule. J**a 10 brings a number of new features, one of which is the most popular for developers in the inference of local variable types. In addition, there are a number of other new features, including garbage collector improvements, GC improvements, performance improvements, thread control, and more. This article mainly introduces the new features in J**A 10, and hopes that readers can quickly understand the changes brought by J**A 10 from the introduction of this article.

Local variable type inference is the most noteworthy new feature in J**A 10, and it is another important improvement made by J**a developers to simplify the writing of J**a applications.

This new feature will add some new syntax to j**a, allowing developers to omit the often unnecessary local variable type initialization declarations. The new syntax will reduce the verbosity of ja while maintaining a commitment to static type safety. Local variable type inference is mainly about introducing reserved type names into j**a syntax that are common in other languages (e.g., c, j**ascript).var。But there are special things to pay attention to:varNot a keyword, but a reserved word. As long as the compiler can infer such a type, developers no longer need to specifically declare the type of a local variable, i.e., they can define the variable at will without specifying the type of the variable. This improvement would also be handy for chained expressions. Here's a simple example:

Listing 1Example of local variable type inference.

var list = new arraylist();// arraylistvar stream = list.stream();// stream

In the example above, in the previous version of the j**a syntax, the initialization list was written as follows:

Listing 2j**a type initialization example.

list list = new arraylist();stream stream = getstream();

Listing 3Example of version type initialization after j**a 7.

list list = new linkedlist<>(stream stream = getstream();

However, for developers, explicit declarations of variable types provide more comprehensive information about the programming language, which is very helpful for understanding and maintaining. The new local variable type inference introduced in J**A 10 allows us to quickly write more concise **, but reserved words for local variable type inferencevarThis will inevitably lead to a lack of visualization of variable types, and it is not always easy to distinguish the type of a variable using var. OncevarIt is widely used, and developers reading ** without the support of an IDE will inevitably make it difficult to understand the execution process of the program. Therefore, it is recommended to define the variable type as explicitly as possible, and while maintaining the most concise, it is also necessary to take into account the readability and maintainability of the program.

To simplify the development process, multiple libraries will be merged into a single repository in J.A. 10.

In the released version of J**A, the entire set of JDK has been stored in multiple Mercurial repositories according to different functions: root, corba, hotspot, jaxp, jaxws, jdk, langtools, nashorn.

While the above eight repositories are independent of each other to keep the components clearly separated, there are a number of drawbacks to managing these repositories at the same time, and it is not possible to manage the associated sources. One of the most important points is that changesets involving multiple repositories cannot be made atomic committed. For example, if a bug fix requires changes to be stored independently of two different libraries, two commits must be created: one in each repository. This discontinuity can easily reduce the traceability and increase the complexity of project and source management tools. In particular, it is not possible to perform atomic commits across repositories that depend on each other, and it is not uncommon for multiple cross-repository variations to be performed.

To solve this problem, all existing repositories were merged into a single Mercurial repository in JDK 10. A secondary effect of this merger is that a single Mercurial repository is easier to mirror (as a Git repository) than the existing eight repositories, and makes it possible to run atomic commits across repositories of interdependent changesets, simplifying the development and management process. While there was some resistance from external developers during the integration process, the JDK development team has made this change part of JDK 10.

In the current j**a structure, the components that make up the garbage collector (GC) implementation are scattered across the various parts of the library. While these conventions are familiar to JDK developers using GC plans, it can often be confusing for new developers to find sources for a particular GC or to implement a new garbage collector. What's more, with the advent of j**a modules, we want to exclude unwanted GC in the build process, but the horizontal structure of the current GC interface will make it difficult to troubleshoot and locate the problem.

To solve this problem, the GC interface needs to be consolidated and cleaned up to make it easier to implement new GCs and better maintain existing GCs. In J**A 10, a clean GC interface was introduced for the Hotspot GC implementation, improving the isolation of different GC sources, and implementation details shared between multiple GCs should exist in the helper class. This approach provides enough flexibility to implement a new GC interface, while allowing for a mix and match reuse of existing **, and the ability to keep ** cleaner and neater for easy collector troubleshooting.

If you have been exposed to j**a performance tuning, you should know that the ultimate goal of tuning is to achieve fast and low-latency memory garbage through parameter settings to improve application throughput, and avoid full GC triggered by untimely memory ** as much as possible (full GC will cause application lag).

The G1 garbage collector is the default garbage collector for Hotspot in J**A 9, which is designed as a low-latency garbage collector to avoid full GC, but when concurrent collection cannot be fast, it will trigger the garbage collector to fall back for full GC. In the previous J**A version, the G1 garbage user used a single-threaded mark-sweep-compact algorithm to execute GC. To minimize the impact of application stuttering caused by Full GC, J**A 10 will introduce multi-threaded parallel GC to G1 while using the same number of parallel worker threads as younger and hybrid, reducing the occurrence of Full GC for better performance gains and greater throughput.

Ja 10 will use the parallelized Mark-Sweep-Compact algorithm and use the same number of threads as the younger generation and the hybrid. The specific number of parallel GC threads can be found at:-xx：parallelgcthreadsparameters, but this also affects the number of workers used for younger generation and mixed collection.

The Class Data Sharing (CDS) mechanism has been introduced in J**A 5, which allows a set of classes to be preprocessed into shared archives, so that memory mapping can be done at runtime to reduce the startup time of J**A programs, and when multiple J**A virtual machines (JVMs) share the same archive file, it can also reduce the dynamic memory footprint, and reduce the resource consumption of multiple virtual machines running on the same physical or virtual machine. In simple terms, the j**a installer will putrt.jarThe core classes are converted into internal representations in advance and dumped into a shared archive. Multiple J**a processes (or JVM instances) can share this data. To improve startup and footprint, J**A 10 expands on the existing CDS functionality to allow application classes to be placed in a shared archive.

The CDS feature extends CDS (Application Class-Data Sharing) support for application classes on top of the original Bootstrap class.

The principle is to record the process of loading the class at startup, write it to a text file, and directly read the startup text and load it when it is started again. Imagine that if there were no major changes to the application environment, the startup speed would be improved.

Think of it as a hibernation process similar to an operating system, where the current application environment is written to disk when the computer is closed, and the environment can be quickly restored when it is used again.

Analysis of memory usage in large enterprise applications shows that such applications typically load tens of thousands of classes into the application classloader, and that being able to apply AppCDS to these applications can save tens or even hundreds of megabytes of memory per JVM process. In addition, analysis of microservices on cloud platforms shows that many servers load thousands of application classes at startup, and appcds can make these services start quickly and improve overall system response time.

In the existing J**a version, the JVM thread can only be started or stopped, and there is no way to operate on a single thread. In order to be able to operate on a single thread, the concept of a JVM security point is introduced in JVM 10, which will allow threads to be implemented without running a global JVM security point, either by the thread itself or by the JVM thread, while keeping the thread blocked, making it possible to stop a single thread, rather than just enabling or stopping all threads. In this way, the performance overhead of existing JVM features is significantly increased, and the existing semantics of the time to reach the JVM's global security point are changed.

The added parameters are:-xx:threadlocalhandshakes(Enabled by default), which will allow users to select security points on supported platforms.

Since J**A 9, some tweaks to the JDK have been underway, and every time a user calls the JAAH tool, they are warned of the deletion that the tool will perform in a future release. When compiling jni, a separate native-header tool is no longer needed to generate header files, as this can be added via j**a 8 (jdk-7150368).j**acto finish. At some point in the future, JNI will be replaced by the results of the Panama project, but there is no specific timeline for when this will happen.

Since J**A 7 began to support BCP 47 language markup, the JDK has added unicode locale extensions related to calendars and numbers, and in J**A 9, new support has been added to both CA and NU language tag extensions. In J**A 10, the Unicode language tag extension will continue to be added, specifically: enhancementsj**a.util.localeclasses and their related APIs to make it easier to obtain the required locale information. This upgrade also brings the following extended support:

Table 1Unicode Extended Table.

Encoding Annotation CU Currency Type FW First Day of the Week RG Region Covers TZ Time Zone.

As j**a 10 joins a method:

Listing 4Example of a Unicode language label extension.

j**a.time.format.datetimeformatter::localizedby

Hardware technology continues to evolve and it is now possible to use non-volatile RAM with the same interface and similar performance characteristics as traditional DRAM. J**A 10 will enable the JVM to use heaps for different types of storage mechanisms to allocate heap memory on optional memory devices.

Some operating systems already provide a way to use non-DRAM memory through the file system. For example: NTFS DAX mode and ext4 DAX. The memory-mapped files in these file systems bypass page caching and provide a mapping of virtual memory to the device's physical memory. NV-DIMMs may have higher access latency compared to DRAM, and low-priority processes can use NV-DIMM memory for the heap, allowing high-priority processes to use more DRAM.

To make a heap allocation on such a standby, you can use the heap allocation parameter-xx：allocateheapat =, which will point to the file system and use memory mapping to achieve the desired result of heap allocation on an alternate storage device.

The J**A-based JIT compiler Graal is enabled in J**A 10 and used as an experimental JIT compiler on the Linux x64 platform to start testing and debugging, and Graal will use the JVM Compiler Interface (JVMCI) introduced in J**A 9.

Graal is a j**a programming language for j**a bytecode-oriented compiler. Compared to C1 and C2 implemented in C++, it is more modular and easier to maintain. Graal can be used as a dynamic compiler to compile hotspot methods at runtimeIt can also be used as a static compiler to achieve AOT compilation. In J**A 10, Graal was released as an experimental JIT compiler (JEP 317). Bringing the Graal compiler research project into J**A might provide the basis for JVM performance to match (or surpass) current versions of C++.

Hotspot in J**A 10 still uses the C2 compiler by default, to enable Graal as a JIT compiler, use the following argument on the J**A command line:

Listing 5Enable Graal as a JIT compiler sample.

-xx：+ unlockexperimentalvmoptions -xx：+ usejvmcicompiler

as part of the JDKcacertsA keystore is designed to contain a set of root certificates that can be used to establish trust in a chain of certificates for various security protocols. However, the jdk sourcecacertsThe keystore has been empty so far. As a result, in JDK builds, critical security components such as TLS are not functioning by default. To resolve this issue, users must use a set of root certificate configurations and a CA root certificate under the Cacerts keystore.

While the version string scheme introduced in JEP 223 is a significant improvement over the past. However, this scenario is not suitable for a situation where a new version of J**a is released on a strict six-month cadence in the future. According to the semantics of JEP 223, every developer who builds on the JDK or uses a component, including the publisher of the JDK, must finalize the version number in advance and then switch over. The developer has to modify the check version number in the section, which is awkward and confusing for all involved.

The version number scheme introduced in the previous JDK version will be rewritten in J**A 10, and the new version will be defined using the version number format defined based on the time model. Retains compatibility with the JEP 223 version string scheme, while also allowing for time-based publishing models other than the current model. Enables developers or end users to easily find out when a release is being released so that developers can judge whether to upgrade to a new version with the latest security fixes or possible additional features.

Mark Reinhold, Chief Architect of Oracle's J**A Platform Group, blogged about some ideas for future versions of J**A (you can accept that the next version of J**A 9 is J**A 18.)3 ?）。He mentioned that the J**a plans to release on a time-bound basis, with a release every six months, rather than identifying major releases by important features as before, and if a major feature is delayed for some reason, the release may be delayed again and again.

At the time, Mark also proposed a mechanism for naming version numbers based on time, such as the next version to be released in March 2018, which is 183, and the next version is 189, and so on for later versions.

However, after discussion, considering the compatibility with the previous version number, the final choice of the naming mechanism is:

$feature.$interim.$update.$patch

$feature: 1 is added for each release, regardless of the specific version content. The March 2018 release is JDK 10, the September release is JDK 11, and so on. $interim: Intermediate version number, released in the middle of a major version, containing bug fixes and enhancements, and not introducing incompatible changes. Although it's only six months away from the release of J**A 9, the release of J**A 10 brings a number of new features and enhancements, but these are just a few of the main features that will impact developers the most, and hopefully the next J**a release will bring more and more changes. The above is just a little personal thinking in the actual project, if there are deficiencies, I hope that readers can be able to Haihan, if so, I hope that readers can give feedback, exchange experiences, and make progress together.