Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5

New Features On Java Development Kit (JDK) 13?

Massive breakthrough as Java Development Kit (JDK) 13 scheduled for September 17 release, with the release candidate stages beginning in the coming months. While Java 12 launched
without the much anticipated Raw String Literals , it is a no-brainer that the supposedly enhancement to ease Java development will be coming with the Java Development Kit (JDK) 13.
The OpenJDK reference page for Java Development Kit (JDK) 13 doesn't however list new features for the upgraded standard Java, albeit some few proposals covering packages, unused heap memory, and application class-data sharing, are cited as being targeted for the new release.
Along with the Raw String Literals, JDK 13 has been slated to come with a tool for packaging self-contained Java apps, which tool is called jpackage and would be based on JavaFX javapackager toolkit with support for native packaging formats that give users natural installation experience. It will also allow for launch-time parameters specification at packaging time, which can be invoked programmatically through the ToolProvider or directly from the command line.
Although, most applications will need to be installed natively on a “first-class” way instead of being placed on the class or module path. And the packaging tool is able to fill gaps left by the Java Web Start technologies, which were removed ostensibly as part of JavaFX from JDK 11.
JDK Enhancement Proposals also include, the extending of application-class data sharing (AppCDS) which enables dynamic archiving of classes at the application execution. With archived classes comprising all library classes not present in the default, base-layer CDS archive and loaded applications. The proposal, however is still in the early stage, and intended to improve the usability of AppCDS by eliminating the need for users to run trials in creating a class list for application.
Admittedly, the ZGC (Z Garbage Collector) enhancement to restore unused memory to the operating system, which proposal is cited as integrated into JDK 13, billed as a scalable, low-latency collector, currently doesn't restore unused memory even when the memory has been unused in a long period.
However, this is not optimal for most applications and environment, as those where memory footprint is really a concern, like containers or environment where applications are idle for a long period or are sharing or competing with other resources.


Forum Jump:

Users browsing this thread: 1 Guest(s)