Java 10 has Ar­rived! Check Out the New Fea­tures

Java 10 was re­leased just over a few months ago and ex­perts are still analysing its salient fea­tures. It has come out on sched­ule, true to the prom­ise of a six-month re­lease cy­cle that Or­a­cle Cor­po­ra­tion made af­ter the re­lease of Java 9. Here’s a quick lo

OpenSource For You - - Contents - By: Astha Sri­vas­tava The au­thor is a soft­ware de­vel­oper, and can be reached at asthasri25@gmail.com.

Hur­ray! Java 10 is out! Most of us are still not done with ex­plor­ing Java 9, which was re­leased on Septem­ber 21, 2017, and ex­actly six months later, Java 10 has been re­leased by Or­a­cle Cor­po­ra­tion. So, what is Java 10 all about? Let’s find out.

An in­tro­duc­tion to Java 10

JDK 10, i.e., the Java De­vel­op­ment Kit, ver­sion 10, is an im­ple­men­ta­tion of the Java SE 10 plat­form. This re­lease was tracked by JEP 2.0 (Java En­hance­ment Pro­posal), which con­tains fea­tures to be de­vel­oped in the spec­i­fied re­lease. Java 10 is avail­able to the pub­lic and can be down­loaded from Or­a­cle’s web­site. This re­lease of Java is re­lated to JSR 383 (Java Spec­i­fi­ca­tion Re­quest).

Java 10 was re­leased on March 20, 2018, for gen­eral avail­abil­ity. It pro­vides many new fea­tures, in­clud­ing lo­cal vari­able types, ex­per­i­men­tal fea­tures, etc. Java 10 was cre­ated in close col­lab­o­ra­tion with the OpenJDK Com­mu­nity — the col­lab­o­ra­tor for the open source im­ple­men­ta­tion of the Java SE plat­form.

What are these new fea­tures?

Given be­low are the main new fea­tures in­tro­duced in Java 10. Let us dis­cuss them in de­tail.

1. Lo­cal-vari­able type in­fer­ence: Java 10 has in­tro­duced a new way of declar­ing and ini­tial­is­ing lo­cal vari­ables with the key­word ‘var’. So, it uses: var list = new Ar­rayList<String>(); // in­fers Ar­rayList<String> …in­stead of: List<String> list = new Ar­rayList<String>();

This is re­stricted to lo­cal vari­ables, which are in­dexes de­clared in loops. This fea­ture is not avail­able for method, con­struc­tor, method re­turn types, fields, catch blocks, or any other kind of vari­able dec­la­ra­tion. The main ob­jec­tive be­hind in­tro­duc­ing this new data type is to en­hance the Java lan­guage to ex­tend type in­fer­ence to dec­la­ra­tions of lo­cal vari­ables.

2. Garbage Col­lec­tor in­ter­face and par­al­lel full GC for G1: The Garbage Col­lec­tor in­ter­face has been in­tro­duced to im­prove the source code isolation of dif­fer­ent garbage col­lec­tors (GCs), hence pro­vid­ing bet­ter mod­u­lar­ity for

in­ter­nal GC. It is added as an isolation for GCs at build­time, which helps in per­for­mance.

Par­al­lel full GC is im­ple­mented to re­move the con­cur­rent ac­cess of the GC. The nor­mal G1 garbage col­lec­tor is de­signed to avoid full col­lec­tions, but when the con­cur­rent col­lec­tions can’t ac­cess mem­ory that fast, then an er­ror, ‘GC Full’, will oc­cur. Hence­forth, in Java 10, par­al­lel threads will be used to ex­e­cute GC com­mands. 3. Ap­pli­ca­tion class-data shar­ing: This im­ple­men­ta­tion in Java 10 is also to im­prove per­for­mance by shar­ing meta­data across dif­fer­ent Java pro­cesses. It ex­tends the ex­ist­ing class-data shar­ing to al­low ap­pli­ca­tion classes to be placed in the shared ar­chive, to re­duce the foot­print and the startup time.

4. Thread-lo­cal hand­shakes: A hand­shake op­er­a­tion is a call­back ex­e­cuted for each thread in Java when that thread is in a safe state (safe­point). The thread-lo­cal hand­shake in­tro­duces a way to ex­e­cute a call­back on threads with­out per­form­ing a global VM safe­point, which will make the process for stop­ping in­di­vid­ual threads pos­si­ble and in­ex­pen­sive. Cur­rently, this is not fea­si­ble for all ar­chi­tec­tures. Now, it has been im­ple­mented only for x64 and SPARC pro­ces­sors.

5. Re­move the na­tive-header gen­er­a­tion tool: Javah, which is the func­tion­al­ity to write na­tive header files at the time when Java source code is com­piled (thereby elim­i­nat­ing the need for a sep­a­rate tool), has been re­moved. This has been done be­cause there were no di­rect JDK de­pen­den­cies on the Javah tool.

6. Ad­di­tional Uni­code lan­guage-tag ex­ten­sions: This fea­ture adds some more Uni­code lan­guage tags. It en­hances the java.util.Lo­cale pack­age and the re­lated

APIs to im­ple­ment ad­di­tional Uni­code ex­ten­sions of the ‘BCP (Best Cur­rent Prac­tice) 47’ lan­guage tags.

7. Heap al­lo­ca­tion on al­ter­na­tive mem­ory de­vices: In this fea­ture, the fo­cus is on heap mem­ory al­lo­ca­tion. Some­times, be­cause of mul­ti­ple tasks run­ning at the same time, heap mem­ory gets full and leads to an er­ror. To solve that prob­lem, heap mem­ory can now be al­lo­cated on other mem­ory de­vices such as an NV-DIMM.

To al­lo­cate the heap in an al­ter­na­tive mem­ory, add the fol­low­ing new op­tion: XX:Al­lo­cateHeapAt=<path>.

This op­tion will map the mem­ory to the path of the file sys­tem, and use mem­ory map­ping to achieve the de­sired re­sult of al­lo­cat­ing the ob­ject heap on the mem­ory de­vice. 8. Ex­per­i­men­tal Java-based JIT com­piler: For ex­per­i­men­tal pur­poses, a new JIT (Just in Time) com­piler has been in­tro­duced — Graal, which is to be used on the Linux/x64 plat­form. Graal is based on the ex­per­i­men­tal Ahead-of-Time (AOT) com­piler in­tro­duced in JDK 9. 9. Time-based re­lease ver­sion­ing: A ver­sion num­ber is a non-empty se­quence of el­e­ments sep­a­rated by pe­riod char­ac­ters (U+002E). A ver­sion num­ber never has trail­ing zero el­e­ments. This is based on se­man­tic ver­sion­ing, which de­fines ver­sion num­bers and the way they change, con­vey­ing mean­ing about the un­der­ly­ing code and what has been mod­i­fied from one ver­sion to the next.

The ver­sion­ing for­mat in Java 10 is used like ver­sion num­ber, $VNUM, pos­si­bly fol­lowed by pre-re­lease, build and other op­tional in­for­ma­tion, as shown be­low:

$VNUM(-$PRE)? \+$BUILD(-$OPT)? $VNUM-$PRE(-$OPT)? $VNUM(+-$OPT)?

The pros and cons of Java 10

In this new re­lease from Or­a­cle Cor­po­ra­tion, many new changes have been made. These changes have been pri­mar­ily done at the JDK level to boost per­for­mance by pro­vid­ing al­ter­na­tive heap mem­ory, the thread-lo­cal hand­shake, etc. They will not have much of an ef­fect at the code level.

When refac­tor­ing HotSpot in­ter­nal code, there is a risk that per­for­mance could be harmed, for ex­am­ple if ad­di­tional vir­tual calls are in­tro­duced. But this risk can be mit­i­gated by con­tin­u­ous per­for­mance test­ing. It will break the work based on the as­sump­tion that noth­ing in the fun­da­men­tal de­sign of G1 pre­vents a par­al­lel full GC. The fact that G1 uses re­gions will most likely lead to more wasted space af­ter a par­al­lel full GC, than for a sin­gle threaded one.

What’s in it for de­vel­op­ers?

For de­vel­op­ers, the main change is the new lo­cal data type ‘var’. This new fea­ture will add some syn­tac­tic sugar to Java, sim­pli­fy­ing it and im­prov­ing the de­vel­oper ex­pe­ri­ence. The new syn­tax will re­duce the ver­bosity as­so­ci­ated with writ­ing Java, while main­tain­ing the com­mit­ment to static type safety. De­vel­op­ers fre­quently com­plain about the de­gree of boil­er­plate cod­ing re­quired in Java. Man­i­fest type dec­la­ra­tions for lo­cals are of­ten con­sid­ered un­nec­es­sary; hence, us­ing var is much bet­ter com­pared to declar­ing any other data type. Lo­cal vari­able type in­fer­ence al­lows a sim­i­lar ef­fect in less tightly struc­tured APIs.

Ever since the re­lease of Java 9 last Septem­ber, the whole plat­form has changed. Java 9 in­tro­duced us to mod­u­lar Java and many other fea­tures, as well as the idea that Java would be switch­ing to a six-month re­lease cy­cle. Java 10 per­haps doesn’t of­fer the big­gest and most game­break­ing changes, but it is the start of a new era of Java that prom­ises a re­lease every six months.

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.