Shulou(Shulou.com)06/01 Report--

In this issue, the editor will bring you about the new features of Java 10. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

Local variable type inference

Local variable type inference is the most noteworthy new feature in Java 10, which is another important improvement made by Java language developers to simplify the writing of Java applications.

This new feature will add some new syntax to Java, allowing developers to omit local variable type initialization declarations that are usually unnecessary. The new syntax will reduce the verbosity of Java code while maintaining a commitment to static type safety. Local variable type inference mainly introduces the reserved type name var, which is common in other languages (such as C #, JavaScript), into Java syntax. But it's important to note that var is not a keyword, but a reserved word. As long as the compiler can infer this type, developers no longer need to declare the type of a local variable, that is, they can define the variable at will without specifying the type of the variable. This improvement is also convenient for chained expressions. Here is a simple example:

Listing 1. Example of local variable type inference

one

two

Var list = new ArrayList (); / / ArrayList

Var stream = list.stream (); / / Stream

Doesn't it look like JS? Does it feel more and more like JS? Although the inference of variable types is not a new concept in Java, it is a big improvement in local variables. When it comes to variable type inference, introducing generics from Java 5, to operators in Java 7 allowing initialization of List without binding types, to Lambda expressions in Java 8, and then to local variable type inference introduced in Java 10, Java type inference is moving forward dramatically.

In the above example, in previous versions of Java syntax, the initialization list was written as follows:

Listing 2. Example of Java type initialization

one

two

List list = new ArrayList ()

Stream stream = getStream ()

The initialization list is written as follows when the operator allows you to initialize the list without binding a type of ArrayList:

Listing 3. Example of version type initialization after Java 7

one

two

List list = new LinkedList ()

Stream stream = getStream ()

However, the use of this kind of var variable type inference also has limitations, which is limited to local variables with initializers, index variables in enhanced for loops and local variables declared in traditional for loops, but cannot be used to infer the parameter types of methods, cannot be used for constructor parameter type inference, cannot be used for inference method return types, and can not be used for field type inference. It also cannot be used to capture expressions (or any other type of variable declaration).

However, for developers, explicit declaration of variable types provides more comprehensive information about the program language, which is of great help to understand and maintain the code. The new introduction of local variable type inference in Java 10 can help us write more concise code quickly, but the use of the reserved word var for local variable type inference is bound to lead to the lack of visualization of variable types, and it is not easy and clear to distinguish the types of variables by using var at any time. Once var is widely used, developers will inevitably have some difficulties in understanding the execution process of the program when they read the code without the support of IDE. Therefore, it is recommended to define variable types explicitly as far as possible, while keeping the code concise, but also need to take into account the readability and maintainability of the program.

Integrate JDK code repository

To simplify the development process, multiple code bases are merged into a single code repository in Java 10.

In the released version of Java, the whole set of JDK code has been stored in multiple Mercurial repositories according to different functions. The eight Mercurial repositories are: root, corba, hotspot, jaxp, jaxws, jdk, langtools, nashorn.

Although the above eight repositories are independent of each other to keep the component code clearly separated, there are many shortcomings in managing these repositories at the same time, and it is impossible to manage the associated source code. The most important of these is that changesets involving multiple repositories cannot be atomic commit. For example, if a bug fix requires changes to code that stores two different code bases separately, you must create two commits: one in each repository. This discontinuity can easily reduce the traceability and complexity of project and source control tools. In particular, it is common that multiple cross-warehouse changes such as atomic commit cannot be performed across repositories of interdependent change sets.

To solve this problem, JDK 10 merges all existing repositories into a single Mercurial repository. A secondary effect of this consolidation is that a single Mercurial repository is more easily mirrored (as a Git repository) than the existing eight repositories, and makes it possible to run atomic commits across interdependent changesets, thus simplifying the development and management process. Although there has been some resistance from outside developers during the integration process, the JDK development team has made this change part of JDK 10.

Unified garbage collection interface

In the current Java architecture, the components that make up the garbage collector (GC) implementation are scattered across parts of the code base. Although these conventions are familiar to JDK developers using GC plans, it is often confusing for new developers about where to find source code for a particular GC or to implement a new garbage collector. More importantly, with the emergence of Java modules, we want to exclude unnecessary GC in the construction process, but the current horizontal structure of the GC interface will make it difficult to eliminate and locate problems.

To solve this problem, you need to consolidate and clean up the GC interface to make it easier to implement the new GC and better maintain the existing GC. In Java 10, in the aspect of hotspot/gc code implementation, a clean GC interface is introduced to improve the isolation of different GC source code. The implementation detail code shared among multiple GC should exist in auxiliary classes. This approach provides sufficient flexibility to implement the new GC interface, while allowing existing code to be reused in a mixed manner, and to keep the code cleaner and tidy, making it easy to troubleshoot collector problems.

Parallel full garbage collector G1

If you have come into contact with Java performance tuning, you should know that the ultimate goal of tuning is to achieve fast and low-latency memory garbage collection through parameter settings to improve application throughput and avoid complete GC triggered by untimely memory collection (Full GC will cause application stutters).

The G1 garbage collector, the default garbage collector for Hotspot in Java 9, is designed as a low-latency garbage collector to avoid Full GC, but when concurrent collection cannot quickly reclaim memory, it triggers the garbage collector to roll back for Full GC. The G1 garbage collector in previous Java versions performed GC based on the single-threaded tag scan compression algorithm (mark-sweep-compact). To minimize the impact of application pause caused by Full GC, Java 10 will introduce multithreaded parallel GC for G1, while using the same number of parallel worker threads as younger generation recycling and hybrid recycling, thus reducing the occurrence of Full GC, resulting in better performance improvements and greater throughput.

In Java 10, the parallelized mark-sweep-compact algorithm will be used and the same number of threads will be used as the younger generation recycling and hybrid recycling. The specific number of parallel GC threads can be adjusted by the:-XX:ParallelGCThreads parameter, but this also affects the number of worker threads used for younger generation and mixed collection.

Application class data sharing

The class data sharing mechanism (Class Data Sharing, CDS) has been introduced in Java 5, which allows a group of classes to be preprocessed into shared archive files so that memory mapping can be performed at run time to reduce the startup time of Java programs. When multiple Java virtual machines (JVM) share the same archive files, it can also reduce the amount of dynamic memory. At the same time, it reduces the resource consumption of multiple virtual machines running on the same physical or virtual machine. Simply put, the Java installer converts the core classes in rt.jar into internal representations ahead of time and dumps them into a shared archive (shared archive). Multiple Java processes (or JVM instances) can share this data. To improve startup and footprint, Java 10 extends existing CDS capabilities to allow application classes to be placed in a shared archive.

The CDS feature extends on the basis of the original bootstrap class and adds CDS (Application Class-Data Sharing) support to the application class.

The principle is that the process of loading the class is recorded at startup, written to a text file, and the startup text is read and loaded directly when starting again. Imagine that if there is no big change in the application environment, the startup speed will be improved.

You can imagine that it is similar to the dormancy process of the operating system, when the computer is closed, the current application environment is written to disk, and the environment can be quickly restored when it is used again.

An analysis of the memory usage of large enterprise applications shows that such applications usually load tens of thousands of classes into application class loaders, and if AppCDS can be applied to these applications, it will save tens or even hundreds of megabytes of memory for each JVM process. In addition, the analysis of micro-services on the cloud platform shows that many servers load thousands of application classes at startup. AppCDS can make these services start quickly and improve the response time of the whole system.

Thread-local control

In existing versions of Java, JVM threads can only be enabled or stopped, and cannot operate on a single thread. To be able to operate on a single thread, thread control in Java 10 introduces the concept of JVM safe points, which allows thread callbacks to be implemented by the thread itself or the JVM thread without running the global JVM safe point, while keeping the thread in a blocking state, 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 functions is significantly increased, and the existing time semantics for reaching the global security point of JVM is changed.

The added parameter is-XX:ThreadLocalHandshakes (enabled by default), which will allow users to select security points on supported platforms.

Some adjustments to JDK have been made since Java 9, and users are warned of deletions that will be performed by the tool in a future version each time the javah tool is called. When compiling JNI code, you no longer need a separate Native-Header tool to generate the header file, because this can be done through the javac added in Java 8 (JDK-7150368). At some point in the future, JNI will be replaced by the results of the Panama project, but there is no specific timetable for when it will happen.

Additional Unicode language tag extensions

Since Java 7 began to support BCP 47 language tags, Unicode locale extensions related to calendars and numbers have been added in JDK, and ca and nu language tag extensions have been added in Java 9. In Java 10, the Unicode language tag extension will continue to be added, specifically: to enhance the java.util.Locale class and its related API, in order to more easily obtain the required language environment information. At the same time, the following extension support has been brought in this upgrade:

Table 1.Unicode extension table

For example, one way to join Java 10:

Listing 4. Unicode language tag extension example

one

Java.time.format.DateTimeFormatter::localizedBy

Through this method, you can use a certain number style, region definition or time zone to obtain the local environment information of the language needed for the time information.

Heap allocation on standby storage device

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

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 the page cache and provide mapping between virtual memory and device physical memory. NV-DIMM may have higher access latency than DRAM, and low-priority processes can use NV-DIMM memory for the heap, allowing higher-priority processes to use more DRAM.

To do heap allocation on such a standby device, you can use the heap allocation parameter-XX:AllocateHeapAt =, which points to the file of the file system and uses memory mapping to achieve the expected result of heap allocation on the standby storage device.

Experimental JIT Compiler based on Java

Java-based JIT compiler Graal is enabled in Java 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 Java 9.

Graal is a Java bytecode-oriented compiler with Java as the main programming language. Compared with C1 and C2 implemented with C++, its modularization is more obvious and easier to maintain. Graal can be used as a dynamic compiler to compile hot methods at run time, or as a static compiler to achieve AOT compilation. In Java 10, Graal is released as an experimental JIT compiler (JEP 317). Introducing the Graal compiler research project into Java may provide the basis for JVM performance to match (or be fortunate to surpass) the current C++ version.

HotSpot still uses the C2 compiler by default in Java 10, and to enable Graal as the JIT compiler, use the following parameters on the Java command line:

Listing 5. Enable Graal as a JIT compiler example

one

-XX:+ UnlockExperimentalVMOptions-XX:+ UseJVMCICompiler

Root certificate authentication

Add the parameter-cacerts to the keytool since Java 9 to view the root certificate managed by the current JDK. The cacerts directory in Java 9 is empty, which will cause a lot of inconvenience to developers. Starting with Java 10, a default set of CA root certificates will be provided in JDK.

The cacerts KeyStore, which is part of JDK, is designed to contain a set of root certificates that can be used to establish trust in the certificate chain of various security protocols. However, the cacerts KeyStore in the JDK source code has so far been empty. Therefore, key security components, such as TLS, do not work by default in JDK builds. To resolve this problem, the user must use a set of root certificate configurations and CA root certificates under the cacerts KeyStore.

Time-based version release mode

Although the version string scheme introduced in JEP 223 is a significant improvement over the past. However, this scheme is not suitable for the future release of a new version of Java at a strict six-month pace.

According to the semantics of JEP 223, every developer who builds or uses components based on JDK (including the publisher of JDK) must decide the version number in advance and then switch to it. Developers have to modify the code to check the version number in the code, which is embarrassing and confusing for all participants.

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

Mark Reinhold, chief architect of the Oracle Java platform group, introduced some ideas about the future version of Java on his blog. (can you accept that the next version of Java 9 is Java 18.3? ). He mentioned that Java is scheduled to be released on a half-yearly basis, rather than deciding on a large version based on important features as before, which may be delayed again and again if a major feature is delayed for some reason.

At that time, Mark also proposed a mechanism for naming version numbers based on time, such as 18.3 for the next version to be released in March 2018, 18.9 for the next version, and so on.

However, after discussion, considering the compatibility with the previous version number and other issues, the final naming mechanism is:

$FEATURE.$INTERIM.$UPDATE.$PATCH

$FEATURE, plus 1 for each release, regardless of the specific version content. The March 2018 version is JDK 10J September, the September version is JDK 11, and so on.

$INTERIM, intermediate version number, released in the middle of a large version, contains problem fixes and enhancements, and does not introduce incompatibility changes.

These are the new features of Java 10 shared by the editor. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.