days
-6
-5
hours
-2
-3
minutes
-1
-7
seconds
-4
-1
search
Time to say goodbye or not yet?

JDK 12 patrol: Discussion on Raw String Literals (Preview) reignited

JAX Editorial Team
jdk12
© Shutterstock /Stephen Plaster  

The tech world is moving fast and we’re in for the ride! The JDK 12 development repositories are open and we thought it’s time to start a new thread in order to keep track of everything that’s going live. JEP 326: Raw String Literals may have dropped from JDK 12 but the discussion about the feature has been brought back to life. Let’s have a quick look.

Last month, we saw JEP 326: Raw String Literals getting dropped from the JDK and we had a closer look at the reasons behind the decision and the community’s feedback.

Nonetheless, the conversation on the feature and its function continues.

Just last week, Brian Goetz reignited the discussion on raw string literals with a new message to the mailing list, touching upon a number of topics including process errors made, how other languages deal with raw strings what should be the next steps.

Make sure to check out the message to get all the details.

 

Update December 12, 2018

Unlike all the other thread updates with which we welcomed new JEPs coming on board, today we are discussing a JEP that got proposed to get dropped from JDK 12.

JEP 326: Raw String Literals (Preview) is proposed to drop from the JDK and here are the reasons why.

Brian Goetz wrote:

The Preview Feature mechanism is intended for features for which there is a high confidence that the feature is “done”, and the likelihood that significant changes would be made before making the feature permanent is low. At this time, and after extensive consideration, Jim and I no longer believe this to be the case, and we think letting it preview in its current state would be to the detriment of the language. We’re of course disappointed that this means it will take slightly longer for this feature to make it into the language, but we think that’s the best choice.

Here is some of the feedback on the design (incomplete and in no particular order):

  • The two-backquote sequence “ could be confused for an empty string, but in fact is an opening delimiter.
  • There is no direct way to start or end a raw string literal with a backquote.
  • Raw string literals can be multi-line, but traditional string literals cannot. (Alternately, multi-line string literals MUST also be raw, which isn’t always what the user wants.) This is an unnecessary asymmetry, given that these properties are logically independent, and such asymmetries generally increase the cognitive load on the user.
  • We have relatively few unused punctuation characters left, and using backquote for RSLs may be excessively profligate. Further, using another quote character for raw string literals (rather than a prefix, modifier, embedded sequence, or similar mechanism) leaves us in a tight spot if we discover the need for a third kind of string literal. We’ve not sufficiently explored alternatives that would let us avoid burning one of the few remaining characters we have.
  • The backquote character is somewhat typographically lightweight; it is easy to miss, and could, therefore, cause confusion over where a large string ends and the containing code resumes.
  • The “any number of quotes” rule can confuse IDEs over whether a sequence of quotes is open-contents-close, or a large opening delimiter, limiting their ability to help by filling in closing delimiters and placing the caret in the right place. We want Java to remain one of the most tool-friendly languages.
  • While it’s cool that we can embed a seventeen-quote run in an eighteen-quoted string, such strings can also get pretty hard to read.

Keep in mind that discussion on the technical details of this feature can continue to take place on the amber lists.

 

Update December 7, 2018

Just last week we saw four new JEPs being proposed to target and now the time has come to be become targeted to JDK 12.

So let’s have a quick update.

Targeted to JDK 12

Summary: Add a new garbage collection (GC) algorithm named Shenandoah which reduces GC pause times by doing evacuation work concurrently with the running Java threads. Pause times with Shenandoah are independent of heap size, meaning you will have the same consistent pause times whether your heap is 200 MB or 200 GB.

Non-Goals: This is not the one GC to rule them all. There are other garbage collection algorithms which prioritize throughput or memory footprint over responsiveness. Shenandoah is an appropriate algorithm for applications which value responsiveness and predictable short pauses. The goal is not to fix all JVM pause issues. Pause times due to reasons other than GC like Time To Safe Point (TTSP) issues or monitor inflation are outside the scope of this JEP.

Summary: Introduce an API to model nominal descriptions of key class-file and run-time artifacts, in particular constants that are loadable from the constant pool.

Motivation: Programs which deal with loadable constants would be simpler if they could manipulate classes and methods, and less well-known artifacts such as method handles and dynamically-computed constants, in a purely nominal, symbolic form:

  • Bytecode parsing and generation libraries must describe classes and method handles in symbolic form. Without a standard mechanism, they must resort to ad-hoc mechanisms, whether descriptor types such as ASM’s Handle, or tuples of strings (method owner, method name, method descriptor), or ad-hoc (and error-prone) encodings of these into a single string.
  • Bootstraps for invokedynamic that operate by spinning bytecode (such as LambdaMetafactory) would be simpler if they could work in a symbolic domain rather than with “live” classes and method handles.
  • Compilers and offline transformers (such as jlink plugins) need to describe classes and members for classes that cannot be loaded into the running VM. Compiler plugins (such as annotation processors) similarly need to describe program elements in symbolic terms.

These kinds of libraries and tools would all benefit from having a single, standard way to describe loadable constants.

Summary: Make G1 mixed collections abortable if they might exceed the pause target.

Motivation: One of the goals of G1 is to meet a user-supplied pause time target for its collection pauses. G1 uses an advanced analysis engine to select the amount of work to be done during a collection (this is partly based on application behavior). The result of this selection is a set of regions called the collection set. Once the collection set has been determined and the collection has been started then G1 must collect all live objects in all regions of the collection set without stopping.

Summary: Enhance the G1 garbage collector to automatically return Java heap memory to the operating system when idle.

 

Update November 30, 2018

  • JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)

Summary: Add a new garbage collection (GC) algorithm named Shenandoah which reduces GC pause times by doing evacuation work concurrently with the running Java threads. Pause times with Shenandoah are independent of heap size, meaning you will have the same consistent pause times whether your heap is 200 MB or 200 GB.

Summary: Introduce an API to model nominal descriptions of key class-file and run-time artifacts, in particular constants that are loadable from the constant pool.

  • JEP 344: Abortable Mixed Collections for G1

Summary: Make G1 mixed collections abortable if they might exceed the pause target.

  • JEP 346: Promptly Return Unused Committed Memory from G1

Summary: Enhance the G1 garbage collector to automatically return Java heap memory to the operating system when idle.

 

Update November 13, 2018

 

Here’s the small update we have for today.

Targeted to JDK 12

Summary: Add a basic suite of microbenchmarks to the JDK source code, and make it easy for developers to run existing microbenchmarks and create new ones.

Goals:

  • Based on the [Java Microbenchmark Harness (JMH)][1]
  • Stable and tuned benchmarks, targeted for continuous performance testing
    • A stable and non-moving suite after the Feature Complete milestone of a feature release, and for non-feature releases
    • Support comparison to previous JDK releases for applicable tests
  • Simplicity
    • Easy to add new benchmarks
    • Easy to update tests as APIs and options change, are deprecated, or are removed during development
    • Easy to build
    • Easy to find and run a benchmark
  • Support JMH updates
  • Include an initial set of around a hundred benchmarks in the suite

JEPs targeted to JDK 12 so far

 

Update November 12, 2018

JEP candidates

JEP 344: Abortable Mixed Collections for G1

Summary: Make G1 mixed collections abortable if they might exceed the pause target.

Motivation: One of the goals of G1 is to meet a user-supplied pause time target for its collection pauses.

Non- goals: Make all pauses in G1 abortable.

JEP 345: NUMA-Aware Memory Allocation for G1

Summary: Improve G1 performance on large machines by implementing NUMA-aware memory allocation.

Motivation: Large enterprise applications, in particular, tend to run with large heap configurations on multiple sockets, yet they want the manageability advantage of running within a single JVM. We are seeing customers using the G1 collector increasingly running up against this scaling bottleneck.

Non- goals: 

  • Support for other collectors than G1.
  • Support for other OSes than Linux and Solaris.
  • NUMA-awareness of other parts of the G1 collector like task queue stealing remembered sets or refinement.

JEP 346: Promptly Return Unused Committed Memory from G1

Summary: Enhance the G1 garbage collector to automatically return Java heap memory to the operating system when idle.

Motivation: Currently the G1 garbage collector may not return committed Java heap memory to the operating system in a timely manner. G1 only returns memory from the Java heap at either a full GC or during a concurrent cycle.

Non-Goals:

  • Sharing of committed but empty pages between Java processes. Memory should be returned (uncommitted) to the operating system.
  • The process of giving back memory does not need to be frugal with CPU resources, nor does it need to be instantaneous.
  • Use of different methods to return memory other than available uncommit of memory.
  • Support for other collectors than G1.

 

Update November 5, 2018

Proposed to target JDK 12

Summary: Add a basic suite of microbenchmarks to the JDK source code, and make it easy for developers to run existing microbenchmarks and create new ones.

Goals:

  • Based on the [Java Microbenchmark Harness (JMH)][1]
  • Stable and tuned benchmarks, targeted for continuous performance testing
    • A stable and non-moving suite after the Feature Complete milestone of a feature release, and for non-feature releases
    • Support comparison to previous JDK releases for applicable tests
  • Simplicity
    • Easy to add new benchmarks
    • Easy to update tests as APIs and options change, are deprecated, or are removed during development
    • Easy to build
    • Easy to find and run a benchmark
  • Support JMH updates
  • Include an initial set of around a hundred benchmarks in the suite

 

Update October 11, 2018

Today we add two more JEPs to the targeted to JDK 12 list and we see the implementation of JEP 341 been pushed into jdk/jdk repository.

Let’s have a closer look.

Targeted to JDK 12

JEP 325: Switch Expressions (Preview)

Summary: Extend the switch statement so that it can be used as either a statement or an expression, and that both forms can use either a “traditional” or “simplified” scoping and control flow behavior. These changes will simplify everyday coding, and also prepare the way for the use of pattern matching (JEP 305) in switch. This will be a preview language feature.

Motivation: As we prepare to enhance the Java programming language to support pattern matching (JEP 305), several irregularities of the existing switch statement — which have long been an irritation to users — become impediments. These include the default control flow behavior (fall through) of switch blocks, the default scoping of switch blocks (the block is treated as one single scope) and that switch works only as a statement, even though it is commonly more natural to express multi-way conditionals as expressions.

The current design of Java’s switch statement follows closely languages such as C and C++, and supports fall-through semantics by default. Whilst this traditional control flow is often useful for writing low-level code (such as parsers for binary encodings), as switch is used in higher-level contexts, its error-prone nature starts to outweigh its flexibility. We propose to introduce a new form of switch label, written “case L ->” to signify that only the code to the right of the label is to be executed if the label is matched.

JEP 326: Raw String Literals (Preview)

Summary: Add raw string literals to the Java programming language. A raw string literal can span multiple lines of source code and does not interpret escape sequences, such as \n, or Unicode escapes, of the form \uXXXX. This will be a preview language feature.

Goals

  • Make it easier for developers to
    • express sequences of characters in a readable form, free of Java indicators,
    • supply strings targeted for grammars other than Java, and
    • supply strings that span several lines of source without supplying special indicators for new lines.
  • Raw string literals should be able to express the same strings as traditional string literals, except for platform-specific line terminators.
  • Include library support to replicate the current javac string-literal interpretation of escapes and manage left-margin trimming.

Non-Goals

  • Do not introduce any new String operators.
  • Raw string literals do not directly support string interpolation. Interpolation may be considered in a future JEP.
  • No change in the interpretation of traditional string literals in any way, including:
    • multi-line capability,
    • customization of delimiters with repeating open and close double-quotes, and
    • handling of escape sequences.

In addition to JEPs 325 and 326 being targeted to JDK 12, the implementation of JEP 341 has been pushed into jdk/jdk repository.

 

Update  

Targeted to JDK 12

JEP 340: One AArch64 Port, Not Two

Summary: Remove all of the sources related to the arm64 port while retaining the 32-bit ARM port and the 64-bit aarch64 port.

Tasks to be completed as part of this JEP:

  • Remove all arm64-specific sources and #ifdefs related to 64-bit versus 32-bit builds in open/src/hotspot/cpu/arm
  • Scan the remaining JDK sources for #ifdefs related to this port
  • Remove the build option for building this port. Make the aarch64 port the default build for the 64-bit ARM architecture.
  • Validate that the remaining 32-bit ARM port continues to build and run the conformance tests with no regressions that did not exist prior to the changes related to this JEP.

JEP 341: Default CDS Archives

Summary: Enhance the JDK build process to generate a class data-sharing (CDS) archive, using the default class list, on 64-bit platforms.

Goals

  • Improve out-of-the-box startup time
  • Eliminate the need for users to run -Xshare:dump to benefit from CDS

Non-Goals

  • We will generate the default archive only for native builds, not for cross-compiled builds.
  • We will generate the default archive only for 64-bit builds; support for 32-bit builds may be added later.

JEP drafts

JEP draft: Support ByteBuffer mapped over non-volatile memory

Summary: Allow MappedByteBuffers to be mapped over non-volatile memory with writes committed via an efficient cache line flush.

JEP draft: Implement C++14 Language Features

Summary: Introduce C++14 compliant language features into HotSpot C++ source code.

 

Update September 17, 2018

JEP candidates

JEP 340: One AArch64 Port, Not Two

Summary: Remove all of the sources related to the arm64 port while retaining the 32-bit ARM port and the 64-bit aarch64 port.

JEP 341: Default CDS Archives

Summary: Enhance the JDK build process to generate a class data-sharing (CDS) archive, using the default class list, on 64-bit platforms.

JEP 342: Limit Speculative Execution

Summary: Help developers and deployers defend against speculative-execution (“Spectre”) vulnerabilities by providing a means to limit speculative execution, and enable further mitigations to be implemented in future releases.

JEP 343: Packaging Tool

Summary: Create a new tool for packaging self-contained Java applications. The jpackager tool will take as input a Java application and a Java run-time image, and produce a Java application image that includes all the necessary dependencies.

 

Update September 5, 2018

Proposed to target

Granted, two features may not seem like much but we’re just getting started!

JEP 325: Switch Expressions (Preview)

Summary: Extend the switch statement so that it can be used as either a statement or an expression, and that both forms can use either a “traditional” or “simplified” scoping and control flow behavior. These changes will simplify everyday coding, and also prepare the way for the use of pattern matching (JEP 305) in switch. This will be a preview language feature.

SEE ALSO: “Developers will see Java 11 as a better, cleaner implementation of the features they use in Java 8”

JEP 326: Raw String Literals (Preview)

Summary: Add raw string literals to the Java programming language. A raw string literal can span multiple lines of source code and does not interpret escape sequences, such as \n, or Unicode escapes, of the form \uXXXX. This will be a preview language feature.

While we are on the JDK 12 topic, don’t miss our interview series about Project Skara. What do you think is the most beneficial alternative SCM and code review for the JDK source code? Check out what the experts had to say.

The results of the JAXenter poll seem to be pretty clear. Git wins. That’s it. No further explanation needed.

On the other hand, the three interviews we had with Java experts paint a not-so-crystal-clear picture. Let me explain.

In the first interview, we talked to Java Champion and JavaOne Rock Star speaker Stephen Colebourne, who seems to be rather enthusiastic about the prospect of migrating JDK source code management to Git.

From my perspective, I think using Git instead of Mercurial is a great idea. I can’t see any case to move to any other SCM.

Stephen Colebourne

However, for our second interview, we caught up with OpenJDK Author Patrick Reinhart who based his view mostly on the popularity of Git as opposed to Mercurial.

For new contributors, Git seems to be more tool-friendly than Mercurial is at the moment.

Patrick Reinhart

For our last interview, that went online just yesterday, we talked to OpenJDK committer Thomas Stüfe, who seems to have a rather conservative opinion on the matter.

 I see no pressing technical reasons to switch to Git. I work with both SCMs and to me, none has a clear lead in performance or functionality.

Thomas Stüfe

See all the interviews here: 

zgqwzg

uzqwg

Leave a Reply

Be the First to Comment!

avatar
400
  Subscribe  
Notify of