days
-1
-1
hours
0
-3
minutes
-5
-4
seconds
-5
-2
search
Time for a new thread

The official schedule for JDK 13 is here

JAX Editorial Team
JDK
© Shutterstock / kolektif.idea

So far we have been going over any new candidate that lands on the table but today we are talking about something more official. The final schedule for JDK 13 is here!

A couple of weeks ago, Mark Reinhold added in the mailing list a proposed schedule for JDK 13.

Since no objections rose, here is what the final schedule for Java 13 looks like:

 

Update March 29, 2019

A bit more than a week ago we welcomed the latest Java version.

But even though JDK 12 just arrived, we are already exploring our option for the future versions of JDK!

Today we welcome a new JEP in the list of candidates.

Summary: Enhance the java.nio.MappedByteBuffer class so that instances can be mapped to non-volatile memory, with writes committed via an efficient cache-line flush.

Goals: The primary goal of this proposal is to extend the public API of MappedByteBufferso that it can be used to access and update NVM efficiently from a Java program.

Non-goals: The goals of this JEP do not extend beyond providing access to and durability guarantees for NVM. In particular, it is not a goal of this JEP to cater for other important behaviors such as atomic update of NVM, isolation of readers and writers, or consistency of independently persisted memory states.

 

 

Update March 15, 2019

Only a few days away from the general availability of JDK 12, and we are already moving forward!

Today we take a look at yet another addition to the JEP candidates list for future JDK!

Summary: Enhance ZGC to return unused heap memory to the operating system.

Motivation: ZGC does not currently uncommit and return memory to the operating system, even when that memory has been unused for a long time. This behavior is not optimal for all types of applications and environments, especially those where memory footprint is a concern. Other garbage collectors in HotSpot, such as G1 and Shenandoah, provide this capability today, which some categories of users have found very useful. Adding this capability to ZGC would be welcomed by the same set of users.

 

Update March 4, 2019

We are getting closer and closer to the general availability of JDK12 – only a couple of weeks left!

But there is no time to chill because we have yet another JEP candidate coming out for JDK 13.

Let’s have a look.

Summary: Extend application class-data sharing to allow the dynamic archiving of classes at the end of Java application execution. The archived classes will include all loaded application classes and library classes that are not present in the default, base-layer CDS archive.

Goals

  • Improve the usability of application class-data sharing (AppCDS). Eliminate the need for users to do trial runs to create a class list for each application.
  • Static archiving enabled by the -Xshare:dump option, using a class list, should continue work. That includes classes for both builtin class loaders and user-defined class loaders.

Non-goals

  • Only classes loaded during an application’s execution will be archived. A class that exists in a given JAR file but is not loaded during execution will not be archived.
  • Java heap objects created during an application execution will not be dynamically archived.
  • Dynamic archiving will not be done if an application exits abruptly, e.g., if it crashes.

 

 

Update February 18, 2019

We are only a month away from the general availability of Java 12 but it is already time to move forward!

We still have a long way to go until JDK 13 is released but for now, let’s focus on what we have so far. The list of candidates is getting longer; case in point, JEP 349 has joined the party.

Summary: Expose JDK Flight Recorder data for continuous monitoring.

Goals

  • Provide an API for the continuous consumption of JFR data on disk, both for in-process and out-of-process applications.
  • Record the same set of events as in the non-streaming.case, with overhead less than 1% if possible.
  • Event streaming must be able to co-exist with non-streaming recordings, both disk and memory based.

Non-goals

  • Provide synchronous callbacks for consumers.
  • Allow consumption of in-memory recordings.

Risks and assumptions:

  • Operations in API callbacks may provoke JFR events, which could lead to infinite recursion. This can be mitigated by not recording events in such a situation.

 

 

Update February 4, 2019

Things in the tech world are moving at the speed of light and so does the JDK! JDK 12 entered Rampdown Phase Two just a couple of weeks ago but things are moving forward already with the development repositories for bug fixes, small enhancements, and JEPs as proposed and tracked being open for JDK 13.

On top of that, we have a new JEP candidate being introduced so the time has come for a new thread!

We still have a long way to go until the release of the next version of the JDK but for now, let’s focus on what we have so far.

JEP candidates

Summary: Enable Java compilers to use alternate translation strategies, such as invokedynamic, in order to improve the performance of certain JDK methods designated as compiler intrinsic candidates. Specifically, intrinsify the invocation of String::format and Objects::hash.

Goals: Enable JDK developers to (i) tag methods as candidates for compile-time intrinsification, and (ii) describe appropriate alternate translations of intrinsification candidates that conform to the specification of the candidate method.

Non-goals: It is not a goal to expose the intrinsification mechanism for use outside of the JDK libraries.

Risks and assumptions: If not properly implemented, the alternate translation may not be perfectly behaviorally compatible with the specification or original implementation. Even if properly implemented, an alternate implementation may not properly track changes made to the original implementation in the future. Also, even if properly implemented and tracked, the maintenance of intrinsic candidate methods and their alternate translations is made more difficult, since changes may need to be made in two places and must be behaviorally identical.

Make sure to follow this thread to keep up with everything new that happens in the Java world! 

Leave a Reply

Be the First to Comment!

avatar
400
  Subscribe  
Notify of