Time for a new thread

First look at JDK 13: The list of JEP candidates is getting longer

JAX Editorial Team
© Shutterstock / kolektif.idea

We are almost a month away from the general availability of JDK 12 but it is already time to move forward! The development repositories for JDK 13 are open and today we take a look at a new JEP candidate.

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.


  • 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, with overhead less than 1% if possible.
  • Event streaming must be able to co-exist with non-streaming recordings, both disk and memory based.


  • 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

Your email address will not be published.