Announcement: Java12 has released!

Open JDK and Oracle JDK are available…

Oracle started a new six month Java release cycle, from the last update oracle is working quite a lot to release new versions quickly for every 6months. we can expect some cool, new features for developers at a faster rate. I have seen some of the features that you can expect to see in the JDK 12 release. You can get the Open JDK 12 early access build and try out these preview features. Let’s take a closer look.

1. JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental).

2. JEP 230: Microbenchmark Suite.

3. JEP 325: Switch Expressions.

4. JEP 326: Raw String Literals (dropped from JDK 12 release).

5. JEP 334: JVM Constants API.

6. JEP 340: One AArch64 Port, Not Two.

7. JEP 341: Default CDS Archives.

8. JEP 344: Abortable Mixed Collections for G1.

9. JEP 346: Promptly Return Unused Committed Memory from G1.

Shenandoah: A Low-Pause-Time Garbage Collector: —

Java development team is going to make a couple of significant changes to the G1 garbage collector. The main aim of changes in G1 garbage collector is to maintain the same consistent pause times. It is implemented with the help of new garbage collection (GC) algorithm named Shenandoah which reduces GC pause times by doing evacuation work concurrently with the running Java threads on a program. Pause times with Shenandoah are independent of heap size, that means you can able to maintain the same consistent pause times whether your heap is 200 MB or 200 GB.

Microbenchmark Suite: —

Add a basic suite of microbenchmarks to the JDK source code, and make it easy for developers to run existing microbenchmarks and create new ones.

The microbenchmark suite will be co-located with the JDK source code in a single directory and, when built, will produce a single JAR file. Co-location will simplify adding and locating benchmarks during development. When running benchmarks, JMH provides powerful filtering capabilities that allow the user to run only the benchmarks that are currently of interest. The exact location remains to be determined.

Goals:

1. Based on the [Java Microbenchmark Harness (JMH)][1]
2. Stable and tuned benchmarks, targeted for continuous performance testing
3. A stable and non-moving suite after the Feature Complete milestone of a feature release, and for non-feature releases.
4. Support comparison to previous JDK releases for applicable tests

Simplicity

1. Easy to add new benchmarks
2. Easy to update tests as APIs and options change, are deprecated, or are removed during development
3. Easy to build
4. Easy to find and run a benchmark
5. Support JMH updates
6. Include an initial set of around a hundred benchmarks in the suite

Switch Expressions: —

Extend the switch statement so that it can be used as either a statement or an expression, and that both forms can use either a "traditional" or "simplified" scoping and control flow behavior. These changes will simplify everyday coding, and also prepare the way for the use of pattern matching in the switch case.

Existing switch case is closely related to the programming languages like C, C++, and JavaScript, etc… those languages support the fall-through switch condition in a control flow to avoid that problem development team come up with a new modification for the switch statement in JDK12.

For example, in the following code, there are many break statements make it unnecessarily verbose, and this visual noise often masks hard to debug errors, for the programmers where missing break statements mean that accidental fall-through occurs.

switch (day) {
    case MONDAY:
    case FRIDAY:
    case SUNDAY:
        System.out.println(6);
        break;
    case TUESDAY:
        System.out.println(7);
        break;
    case THURSDAY:
    case SATURDAY:
        System.out.println(8);
        break;
    case WEDNESDAY:
        System.out.println(9);
        break;
}

The above code is the old conventional style of the switch case statement. The new proposal statement will be —

switch (day) {
    case MONDAY, FRIDAY, SUNDAY -> System.out.println(6);
    case TUESDAY                -> System.out.println(7);
    case THURSDAY, SATURDAY     -> System.out.println(8);
    case WEDNESDAY              -> System.out.println(9);
}

From JDK12 onwards we can write the switch statements as mentioned above.

Raw String Literals (dropped from JDK 12 release): —

One major proposal for JDK 12, is the removal of raw string literals. According to the JEP, “A raw string literal can span multiple lines of source code and does not interpret escape sequences, such as \n, or Unicode escapes of the form \uXXXX”. that is the reason they removed the string literal.

Example:-

String myContent = "<html>\n" +
                   "    <body>\n" +
                   "		    <p>Hello World.</p>\n" +
                   "    </body>\n" +
                   “</html>\n";

From JDK12 we can write the above statement as follows —

String myNewContent = `<html>
                           <body>
                              <p>Hello World.</p>
                           </body>
                       </html>
                       `;

JVM Constants API: —

The purpose of implementing new constants API is to make it easier for programs that manipulate class files to model bytecode instructions, which have to handle loadable constants.

Broadly speaking every Java class has a constant pool which stores the operands for bytecode instructions in the class. and It also has a constant pool, Each entry in the table is a loadable constant and has the following format:

cp_info {
    u1 tag;
    u1 info[];
}

The tag specifies what type the constant is —

For E.g:- 7 means it’s Class, 10 is a Method Reference, 8 is a String, etc...

The info array gives more information about the constant depending on the constant type.

JVM instructions, e.g. LDC and invoke dynamic instructions, rely on the information in this table (rather than the run-time layout of classes, interfaces, etc). When these instructions are executed, the loadable constant becomes a live value, E.g. a Class, String, int, etc.

Programs that work with class files have to model these bytecode instructions and deal with the loadable constants. If the constant type is something like a String or an Integer, this works without issue because those are primitive data types. But when it comes to classes and interfaces it becomes more complicated.

Loading classes are not always straightforward, and there are several ways it can fail, for example, if the Class does not exist or cannot be accessed. then it might cause an issue, To avoid that problem —

This is where JEP 334 comes in.

In Java 12 there is now an API so that these values can be handled symbolically. For example, there is an interface called ClassDesc which can be used to symbolically represent a loadable constant of type Class, MethodHandleDesc to represent method handle constants, MethodTypeDesc to represent method type constants and so on.

One AArch64 Port, Not Two: —

Remove all of the sources related to the arm64 port while retaining the 32-bit ARM port and the 64-bit aarch64 port.

Removing this port will allow all contributors to focus their efforts on a single 64-bit ARM implementation, and eliminate the duplicate work required to maintain two ports. This feature was implemented to improve the effectiveness in the development.

Default CDS Archives: —

Enhance the JDK build process to generate a class data-sharing (CDS) archive, using the default class list, on 64-bit platforms.

The goal of implementing the Default CDS Archives is —

1. Improve out-of-the-box startup time.
2. Eliminate the need for users to run -Xshare:dump to benefit from CDS.

Currently, a JDK image includes a default class list, generated at build time, in the lib directory. Users who want to take advantage of CDS, even with just the default class list provided in the JDK, must run java -Xshare:dump as an extra step. This option is documented, but many users are unaware of it. To overcome this issue they come with default CDS Archives —

Since they are making CDS Archive as auto we can use directly but if you want to disable it then run the command -Xshare:off.

Abortable Mixed Collections for G1: —

Make G1 mixed collections abortable if they might exceed the pause target. for the complete description of JEP344.

Promptly Return Unused Committed Memory from G1: —

Enhance the G1 garbage collector to automatically return Java heap memory to the operating system when idle.

For complete information about this feature JEP346.

Conclusion

Thank you for reading.

With so many exciting and user-friendly features, I think Java12 will meet the expectations of the developers.

If you liked this article please click on the clap and leave me your valuable feedback.

Hello busy people, I hope you had fun reading this post, and I hope you learned a lot here! This was my attempt to share what I’m learning.

I hope you saw something useful for you here. And see you next time! 😉🤓

Have fun! Keep learning new things and coding to solve problems.😇

Check out My Twitter, Github, and Facebook. 🙂