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

First look at JDK 13: Switch Expressions (Preview) and Text Blocks (Preview) are targeted to the next release

JAX Editorial Team
JDK
© Shutterstock / kolektif.idea

The development of JDK 13 proceeds smoothly and we see two more JEPs targeted to the next Java release, including Switch Expressions (Preview). Let’s have a look.

One quick update to this thread is in order.

Two more JEPs are now targeted to JDK 13 including the much-discussed Switch Expressions (Preview).

Let’s refresh our memory.

Targeted to JDK 13

Summary: Extend switch so it can be used as either a statement or an expression, and so that both forms can use either traditional case ... : labels (with fall through) or new case ... -> labels (with no fall through), with a further new statement for yielding a value from a switch expression. These changes will simplify everyday coding, and prepare the way for the use of pattern matching (JEP 305) in switch. This will be a preview language feature.

Description: 

  • Arrow labels – In addition to traditional “case L :” labels in a switch block, a new simplified form is proposed with “case L ->” labels.
  • Switch expressions – The switch statement gets extended so it can be used as an expression.
  • Yielding a value – Most switch expressions will have a single expression to the right of the “case L ->” switch label. In the event that a full block is needed, a new yield statement is introduced to yield a value, which becomes the value of the enclosing switch expression.
  • Exhaustiveness – The cases of a switch expression must be exhaustive; for all possible values there must be a matching switch label. (Obviously, switch statements are not required to be exhaustive.)

 

Summary: Add text blocks to the Java language. A text block is a multi-line string literal that avoids the need for most escape sequences, automatically formats the string in a predictable way, and gives the developer control over format when desired. This will be a preview language feature.

Goals:

  • Simplify the task of writing Java programs by making it easy to express strings that span several lines of source code, while avoiding escape sequences in common cases.
  • Enhance the readability of strings in Java programs that denote code written in non-Java languages.
  • Support migration from string literals by stipulating that any new construct can express the same set of strings as a string literal, and interpret the same escape sequences, and be manipulated like a string literal.

 

 

Update June 3, 2019

We are back with the latest update on the development of JDK 13!

This time around, we see two more JEPs getting proposed to target, including the much-discussed Switch Expressions (Preview), as well as JEP 353 being now targeted to JDK 13.

Let’s have a look.

Proposed to target

Summary: Extend switch so it can be used as either a statement or an expression, and so that both forms can use either traditional case ... : labels (with fall through) or new case ... -> labels (with no fall through), with a further new statement for yielding a value from a switch expression. These changes will simplify everyday coding, and prepare the way for the use of pattern matching (JEP 305) in switch. This will be a preview language feature.

Summary: Add text blocks to the Java language. A text block is a multi-line string literal that avoids the need for most escape sequences, automatically formats the string in a predictable way, and gives the developer control over format when desired. This will be a preview language feature.

Targeted to JDK 13

Summary: Replace the underlying implementation used by the java.net.Socket and java.net.ServerSocket APIs with a simpler and more modern implementation that is easy to maintain and debug. The new implementation will be easy to adapt to work with user-mode threads, a.k.a. fibers, currently being explored in Project Loom.

 

 

Update May 17, 2019

We are back with more Java news!

Today we take a look at a newly submitted JEP candidate as well JEP 353, submitted by Brian Goetz himself, is proposed to target JDK 13.

Let’s get started.

JEP candidate

Summary: Add text blocks to the Java language. A text block is a multi-line string literal that avoids the need for most escape sequences, automatically formats the string in a predictable way, and gives the developer control over format when desired. This will be a preview language feature.

Goals:

  • Simplify the task of writing Java programs by making it easy to express strings that span several lines of source code, while avoiding escape sequences in common cases.
  • Enhance the readability of strings in Java programs that denote code written in non-Java languages.
  • Support migration from string literals by stipulating that any new construct can express the same set of strings as a string literal, and interpret the same escape sequences, and be manipulated like a string literal.

Non-goals:

  • It is not a goal to define a new reference type, distinct from java.lang.String, for the strings expressed by any new construct.
  • It is not a goal to define new operators, distinct from +, that take Stringoperands.
  • Text blocks do not directly support string interpolation. Interpolation may be considered in a future JEP.

Proposed to target

Summary: Replace the underlying implementation used by the java.net.Socket and java.net.ServerSocket APIs with a simpler and more modern implementation that is easy to maintain and debug. The new implementation will be easy to adapt to work with user-mode threads, a.k.a. fibers, currently being explored in Project Loom.

 

 

Update May 9, 2019

Last time we updated this post, we had two JEPs proposed to target JDK 13.

And today both the ZGC: Uncommit Unused Memory and Dynamic CDS Archives JEPs are targetted to JDK. Things are moving fast, right?

Let’s refresh our memory on what those JEPs are all about.

Targeted to JDK 13

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.

Motivation: Archiving application classes using AppCDS in HotSpot provides additional startup time and memory benefits relative to the default CDS archive. However, currently, a three-step procedure is required in order to use AppCDS for a Java application. See the details here.

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 built-in 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.

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.

 

 

Update April 26, 2019

It has been a while since the last time we updated this thread but today we come back with some interesting news!

We reach the next step in the development of the next Java version and we see the first two JEPs being proposed to target JDK 13. On top of that, we have two new JEP candidates with ‘Switch Expressions’ making a second entry, after JEP 325: Switch Expressions (Preview) was included in the latest Java release.

Let’s have a look.

Proposed to target

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

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.

JEP candidates

Summary: Related to JEP 325: Switch Expressions (Preview) – Extend the switch statement so that it can be used as either a statement or an expression, and so that both forms can use either the traditional scoping and control flow or a new, simplified scoping and control flow that includes a new statement for yielding a value from a switch expression.

Summary: Replace the underlying implementation used by the java.net.Socket and java.net.ServerSocket APIs with a simpler and more modern implementation that is easy to maintain and debug. The new implementation will be easy to adapt to work with user-mode threads, a.k.a. fibers, currently being explored in Project Loom.

 

 

Update April 1, 2019

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