Features in Java 10
The following Java10 features are very simple and easy to understand.
The Var keyword:
Like JavaScript, Kotlin, and Scala, now Java 10 introduced a var keyword that allows you to declare a local variable without specifying its type. The type will be inferred from context. For example, when you say var name = "Silan", then the compiler will already know the type is String.
The var keyword can only be used for local variables, i.e. variables inside methods or code blocks — you cannot use it for member variable declaration inside the class body.
But like Python, it doesn't make Java a dynamically typed language. Java is still a statically typed language, and once the type is assigned, you cannot change it. For example, var name = "Silan" is ok, but if we will assign name =100; then it is not right.
This is one of the most eye-catching features of Java 10. It reduces the amount of boilerplate code needed to declare local variables in Java.
Overall we can say in a single statement that we can declare variables without specifying the associated type. A declaration such as:
List<String> l=new ArrayList<String>();
Can be written as var l=new ArrayList<String>();
Note:Type The inference is not a new Concept in JAVA but it is a new concept for local variables.
The Var Keyword Though Powerful But Comes At a Conditions:
The scope of the var keyword is local i.e.
for (var i = 0; i < 5 ; i++) //correct
public void test()
{
var name = “java8s.com” ;//correct
}
However
Class Test
{
Var name; //gives an error
}
To summarize the above, the var keyword has a local scope i.e. a local variable can only have var data type but not an instance variable.
Garbage Collector Interface:
With the current JDK structure, the garbage collectors are scattered throughout the code base. Thus whenever a new developer tries to make some changes or create a new one,the current jdk architecture precludes the following.
The JEP-304 is supposed to:
Better modularity for HotSpot internal GC code.
Make it simpler to add a new GC to HotSpot without perturbing the current code base.
Make it easier to exclude a GC from a JDK build.
Parallel Full GC(Garbage Collection) for G1:
The JEP-307 aimed to provide parallel GC with the G1 garbage collector.
The G1 garbage collector is designed to avoid full collections, but when the concurrent collections can't reclaim memory fast enough a fall back full GC will occur. The current implementation of the full GC for G1 uses a single threaded mark-sweep-compact algorithm.
We intend to parallelize the mark-sweep-compact algorithm and use the same number of threads as the Young and mixed collections do.
Heap Allocation on Alternating Memory Devices:
With the NVDIMM(Non-volatile dual –in-line memory module) becoming cheap, Oracle introduced the JEP 316 to allow lower priority jvm’s(like daemons, services) to use NVDIMM memory for the heap. And other high priority processes to use the DRAM.
Consolidating a JDK Forest Into a Repository:
In the current architecture of jdk, the source code is stored in 8 different repositories namely (1) root, (2) CORBA, (3) hotspot, (4) jaxp, (5) jaxws, (6) jdk, (7) langtools, and (8) nashorn.
The problem with such an approach to store the source code is that whenever a change is made in a repository the same change needs to be carried out in all other repositories thus increasing the time complexity thus with JEP-296, It was proposed that all the 8 repositories are to be combined into a single mercurial repository.
Thread-Local Handshakes:
·
JEP-312 provided a way to execute a callback on threads without
performing a global VM safe point. Make it both possible and cheap to stop
individual threads and not just all threads or none.
·
Improving biased lock revocation to only stop individual threads
for revoking biases, rather than all of them.
·
Reducing the overall VM latency impact of different types of
serviceability queries such as acquiring stack traces for all threads which on
a VM with a large number of Java threads can be a slow operation.
·
Performing safer stack trace sampling by reducing reliance on
signals.
·
Eliding some memory barriers using so-called Asymmetric Dekker
Synchronization techniques, by performing handshakes with Java threads. For
example, the conditional card mark code inherently required by G1 and used by
CMS, will not need memory barriers. As a result, the G1 post writes barrier can
be optimized, and branches that try to avoid the memory barrier can be removed.
0 comments:
Post a Comment