Companies such as IBM, the Eclipse Foundation, and Red Hat have decided to support the deployment of the controversial plan (modularity) in Java 9.
Modularity is a distinctive but also highly controversial feature of the upcoming Java 9 release, and it seems similar to a proposal passed by the Java community a few weeks ago that initially did not gain everyone’s approval.
This week a new round of voting was completed: the Java Community Process Executive Committee passed the Java Platform Module System public review vote—the proposal known as Java Specification Request 376—by a vote of 24-0.
In a round of voting held in May this year, because the proposal was approved only by a narrow margin of 13:10, the committee was concerned that the proposal lacked consensus and might have a destructive impact on the Java community. Therefore, it decided to postpone the modular system of the Java Development Kit 9 to a release between July 27 and September 21.
1. Project Jigsaw; Modular Source Code
Project Jigsaw aims to modularize Java code and split the JRE into interoperable components, and it is one of the many features of Java 9. JEP is the first step toward Jigsaw’s four steps; it does not change the real structure of the JRE and JDK. JEP is for modularizing the JDK source code so that the build system can compile modules and check module boundaries at build time. This project was originally to be released with Java 8, but due to the delay it will be added to Java 9.
Once completed, it may allow customizing components according to a project’s needs, thereby reducing the size of rt.jar. The rt.jar package in JDK 7 and JDK 8 contains about 20,000 classes, but many of them are not used in certain specific environments (even though Java 8’s compact profile feature already includes part of the solution, there is still class redundancy). This is done so that Java can be easily applied to small computing devices (such as network devices), improving its security and performance, and also allowing developers to more easily build and maintain these libraries.
2. Simplified Process API
To this day, Java’s ability to control and manage system processes is limited. For example, to conveniently obtain your program’s process PID today, you either call a native program or use some workarounds. Moreover, each (system) platform needs a different implementation to ensure you get the correct result.
The expected code to obtain Linux PIDs currently looks like this:
public static void main(String[] args) throws Exception
{
Process proc = Runtime.getRuntime().exec(new String[]{ "/bin/sh", "-c", "echo $PPID" });
if (proc.waitFor() == 0)
{
InputStream in = proc.getInputStream();
int available = in.available();
byte[] outputBytes = new byte[available];
in.read(outputBytes);
String pid = new String(outputBytes);
System.out.println("Your pid is " + pid);
}
}In Java 9, it can be changed to the following (supporting all operating systems):
System.out.println("Your pid is " + Process.getCurrentPid());This update will expand Java’s ability to interact with the operating system: adding some new, straightforward methods to handle PIDs, process names and states, and to enumerate multiple JVMs and processes, and more.
3. Lightweight JSON API
There are currently various Java tools for handling JSON, but the JSON API is unique in that it will be part of the Java language, lightweight and using Java 8’s new features. It will be released in the java.util package (but JSON in JSR 353 is handled via third-party packages or other methods).
4. Money and Currency API
After Java 8 introduced the date and time API, Java 9 introduces a new currency API to represent currency, support conversion between currencies, and various complex operations. For details about this project, please visit https://github.com/JavaMoney, which already provides usage instructions and examples. Here are a few important examples:
// New types: Money & FastMoney
Money amt1 = Money.of(10.1234556123456789, "USD"); // Money is a BigDecimal
FastMoney amt2 = FastMoney.of(123456789, "USD"); // FastMoney is up to 5 decimal places
Money total = amt1.add(amt2);
// Formatting money into each country's currency:
MonetaryAmountFormat germanFormat = MonetaryFormats.getAmountFormat(
Locale.GERMANY);
System.out.println(germanFormat.format(monetaryAmount)); // 1.202,12 USD5. Improved Lock Contention Mechanism
Lock contention is a bottleneck that limits the performance of many Java multi-threaded applications. The new mechanism has been validated by various benchmarks to improve the performance of Java object monitors, including Volano. In the test, the communications server opened a huge number of processes to connect to clients, many of which requested the same resource, simulating a heavy-load daily application.
Through such stress tests we can estimate the JVM’s throughput limit (messages per second). JEP achieved excellent results in 22 different tests; if the new mechanism can be applied in Java 9, application performance will be greatly improved.
6. Code Segmented Caching
Another Java 9 performance improvement comes from the JIT (Just-in-time) compiler. When a piece of code is executed repeatedly, the virtual machine compiles it into native code and stores it in the code cache, thereby improving compiler efficiency by accessing code in different segments of the cache.
Unlike the original single cache region, the new code cache is divided into three types based on the code’s own lifecycle:
- Permanent code (JVM built-in / non-method code)
- Short-term code (profiled code applicable only under certain conditions)
- Long-term code (non-profiled code)
Cache segmentation improves program performance in various ways; for example, during garbage collection scanning it can directly skip non-method code (permanent code), thereby improving efficiency.
7. Smart Java Compilation, Phase Two
The first phase of the smart Java compilation tool sjavac began with the JEP 139 project, aimed at improving JDK compilation speed on multi-core processors. Now the project has entered its second phase (JEP 199), with the goal of improving sjavac and making it the default general-purpose Java compilation tool that replaces the current JDK compilation tool javac.
Other content worth looking forward to:
8. HTTP 2.0 Client
Although the HTTP 2.0 standard has not been officially released, it has entered the final review stage and is expected to be reviewed before Java 9 is released. JEP 110 will redefine and implement a brand-new Java HTTP client to replace the current HttpURLConnection, and it will also implement HTTP 2.0 and web sockets (original text: websockets). It has not yet been officially recognized by JEP, but we hope to include this project’s content in Java 9.
The official HTTP 2.0 RFC (Request for Comments, a series of official documents such as technical discussions / meeting records) is scheduled for release in February 2015; it is based on Google’s SPDY (Speedy) protocol. Networks based on the SPDY protocol show a significant speedup of between 11.81% and 47.7% compared to networks based on the HTTP 1.1 protocol, and some browsers have already implemented this protocol.
9. Project Kulla: Java’s REPL Implementation
This project named Kulla recently announced it would conduct integration testing in April 2015. Although it is unlikely to make it in time for the Java 9 release, if progress is fast it might just make it. Currently Java has no official REPL (Read-Eval-Print-Loop) approach, meaning that if you want to run a few lines of Java code for a quick test, you still need to wrap those lines in a project or method. Although some popular IDEs have Java REPL tools, they are not officially supported, and the Kulla project may become the official REPL solution released by Java.